逆向WeChat(三)

 

本篇在博客园地址https://www.cnblogs.com/bbqzsl/p/18198572

上篇回顾，对象是WEUIEngine。WeUIEngine使用了chrome::base框架，但只用来实现了单一的功能，只为了DUI的动画计时器。  (PS#20240528。i made a mistake of my ignoring TaskScheduler. i only focused on the pump. they use TaskScheduler. )

chrome::base框架没有用作主线程的dispatcher，所有多线程并不向chrome::base框架投递执行代码。win32线程的消息队列是一个优先级队列，PostMessage除了manual文档的官方用途外，往往也用作deferred队列来使用。chrome::base框架使用的也就是这个队列，只是用了一个专门的窗口。既然chrome::base在wechat中只是一个花架子，那么一定需要一个等价物。

是的，这就是EventCenter。看名字，我就情不自禁地想起iOS的[NSNotificationCenter defaultCenter]。两个主要的函数[[NSNotificationCenter defaultCenter] addObserverForName:object:queue:usingBlock:]注册， [[NSNotificationCenter defaultCenter] postNotificationName:userInfo:]发送事件。

事实也是这样，WeChat定义了一个EventCenter，依附在UI主线程。项目之初应该是这个设计思路的。因为在早期的事件，会在一个专门的表注册它的名字，这样就可以通过名字来注册观察者或发送事件。但是根据逆向分析，实际应用却将名字搁置在一边，不知道是多年来改版后搁置的，还是一开始就没有在用。后面的开发见没有用，就干脆不注册名字了。

观察者必须使用EventHandler接口来注册到EventCenter。EventCenter依附在UI主线程的一个deferred队列，有独立的窗口，作用就是依附在线程的消息队列。如字面意思，EventCenter在UI主线程分派事件处理器。EventCenter作为全局单件，任意线程的任意代码都可以使用它postEvent来发送事件。

下面是一些逆向的佐证。

通过列出当前EventCenter在案登记了处理器的事件，比对事件名字表，可以发现，每个类别早期编号的事件，都遵从起名字，并注册名字。后期就懒得这样做了。

下图是通过LoginWnd向EventCenter查询在案登记的事件。然后再向名字表查询事件的名字。高兴的是，早期的事件还可以知道名字。可惜的是，后期的事件没有名字可以查。

下图演示一个应用场景，在点重新扫描后，跟踪发送事件。可以看到是WinMarsWrap::OnTaskEnd在发送事件ON_SCENE_NET_RESPONSE。既然事件发送者已经引出来了，后面自然就是会对Mars进行逆向一下。

下图演示，通过EventCenter列出所在在案登记的处理器对象，并列出它们的类名字。每个处理器对应着独立的功能，基本上所有功能都依赖了这个EventCenter。到这里wechat的基本结构脈胳也有了一个比较清晰的图了。

综上所述，将EventCenter的应用场景换作iOS，就是

[[NSNotificationCenter defaultCenter] addObserverForName:@“ON_SCENE_NET_RESPONSE” object:nil queue:[NSOperationQueue mainQueue] usingBlock:^{ loginwnd->processEvent(); }]

[[NSNotificationCenter defaultCenter] postNotificationName:@“ON_SCENE_NET_RESPONSE” userInfo:response]

本篇到这里，下一篇再见。

我还有逆向通达信系列。

我还有一个K线技术工具项目KTL，可以用C++14进行公式，QT，数据分析等开发。