逆向WeChat (五)-数字星空

本篇逆向mmmojo.dll，介绍如何使用mmmojo，wmpf_host_export的mojo。

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

上一篇逆向分析了mars这个网络模块，本篇逆向mojoIPC。如何从mojo core的MojoHandle找出binding层的Remote跟Receiver，并使用。

本篇内容结构：

0.mojo与orb架构

1.mojo网络协议栈

2.Invitation链路握手

3.MergePort，MessagePipe握手

3.1.Remote，Receiver传递。

4.Mojo对象

5.Trap, Arm, Proactor, Reactor

6.从Trap出发找Remote还有Receiver

7.MMMojoService

8.实战使用OCR

本篇的mojo专指chromium项目的mojo子项目，区别于AI领域的mojo语言。并且地，专指传统的MojoCore。2022年开始MojoCore逐步向IPCZ过渡，ipcz在github可查得始于chromium102。所以为了演示，WMPF使用85xx版本以保持使用MojoCore，而不是IPCZ。

我认为mojo是使用了orb架构，google了一下没有人这么说，那只能是我个人观点了，没有权威背书。或者换一种说法，可以orb架构来认识mojo，mojo中有许多orb架构的东西，但mojo只能用于本地机器的进程间，不是中间件。

对象请求代理的解释在https://en.wikipedia.org/wiki/Common_Object_Request_Broker_Architecture。

AI这样分析：

我的根据是从CORBA的熟知的架构图。

以network.mojom.NetworkContext接口为例，mojom分别生成骨架代码，NetworkContextProxy，NetworkContextStub。

当我看到remote, pending_remote，bind等，我的第一关联印象就是ZeroIce的ObjectPrx，stringToProxy， unchecked_cast，checked_cast。

同理地，mojo core作为一种通信设备主管network，io线程池，dispatcher等事，等同于ZeroIce的Communicator。

mojo网络使用其专用通信线程。那么就借用我们熟悉的TCP/IP网络模型来认识mojo的网络模型。

我将Channel看作链路层，Port为IP层，MessagePipe类比UDP，DataPipe类比TCP。其中DataPipe实现以MessagePipe作为eventfd，SharedBuffer作为queue。MachPort早就有这个实现了，MachPort在IPC通信时可以传递VM内核对象。还是iphone4的时代。

我使用windows平台进行分析，所以在本篇里，Channel使用NamedPipe作为通信链路。每个mojo core看作一个mojo设备，在mojo网络代表一个节点node。同一进程内可以有多个mojo设备，每一个PE文件都可以编译进一个mojo设备。我说的mojo设备应该跟官方的mojo embbeder是同一个意思。以WeChat为例，WeChat.exe进程一共加载了2个mojo embbeder，分别来自mmmojo.dll，wmpf_host_export.dll。

每个mojo设备只有一个名字，所以在mojo网络中是唯一的。node之间有且只有一条有效链路，在当下。两个node之间不能够同时有两条或以上链路。所以，在上层的port，都使用同一条链路跟同一个节点node进行通信。

同样是IPC，zmq的SOCKET是真实对应一个底层socket，独立一条链路。那么Port是什么东东在mojo。IPC离不开一个关键字，就是MQ。zmq的SOCKET就是一种类型的MQ。每个SOCKET在上层都有接收跟发送的总计两个MQ。本方SOCKET的发送MQ通过链路socket将数据发送到对方SOCKET的接收MQ。我现在将前面的句子迭代名称。在mojo环境，本方Port的发送MQ通过两个Node之间链路NamedPipe将数据发送到对方Port的接收MQ。这样，Port的本质就是一个MQ。mojo::ports::Port的定义里，对象的主要资源就是一个用来接收MessageQueue。message_pipe就是两个互成Peers的Ports。对于有人喜欢用一个百万ports来衬托mojo比别的IPC利害，虽然不假，但也没有多少实际意义。只要有内存，56位的地址空间随你耗。但所有的一切跟一切都离不开一条链路。

这么一来，Node-Port，Node关联的是底层链路Channel，Port关联的是上层MQ。Node-Port就是如何通过Channel将数据放到对方的MQ。NodeController就可以看作是一个mojo设备的驱动，完成这些工作。

在这个mojo网络之上，运行着ORB。说人话就是，mojom跟c++bindings。

于是我们就可以得到自下而上的mojo网络协议栈。

找到一篇用协议栈来分析mojo的文章https://blog.lazym.io/2020/06/22/Mojo-More-of-a-Protocol/

接下来，我们来看握手。

这里存在两个层面的握手。链路层的握手，ports层的握手。

先来看链路层的握手。

invitation就是node之间在底层链路channel进行的连接握手。invitation跟一个关键字sync相关，sync不难让人想到TCP的sync包，也就是发起握手连接。这套握手礼仪就是invitation。

发起方扮演Inviter，接受方扮演Invitee。他们你来我往寒暄几轮。

下图是抽象后的简化图，最终的目标是让双方都AddPeer。如果有一方没有AddPeer，他就是没记住你，他不认识你。

再来看ports的握手。这是一个MergePort的过程。或者说MessagePipe是如何在两个node之间建立“连接”。因为Port层不具有真正意义上的连接。

remote或receiver的传递或者返回，是通过MergePort来实现。下图是CreateURLLoaderFactory方法如何返回一个pending_receiver<URLLoaderFactory>的。

mojo通过UserMessage携带PortDescriptor，要求跟对方新绑定成一对Ports，并告知对方使用指定的PortName。灰色的Port只做引线人，短暂地当了一下子的Proxy。这个过程称作MergePort。

不过在完成UpdataPreviousPeer前，发起方仍然使用ProxyPort进行通信。这样能够让MergePort跟消息通信顺滑地同时进行，毕竟一整套MergePort流程跑下来，需要来往几轮。

下图是Browser向GPU绑定VizMain接口，并调用VizMain.CreateGpuService等方法，尽管Browser跟GPU努力地去促进ObserverProxying的工作，但是在Browser完成UpdataPreviousPeer前，Browser仍旧使用着ProxyPort去调用VizMain接口的方法。

MergePort流程抽象成下图

mojo有两种途径可以进行MergePort。一种是通过Invitation，另一种MessagePipe。我们并不能直接使用ports层的控制协议进行MergePort。我们必须依赖Mojo对象去自动完成MergePort的动作。

Invitation使用MojoAttachMessagePipeToInvitation跟MojoExtractMessagePipeFromInvitation，附加在Invitation握手流程。MessagePipe使用MojoAppendMessageData跟MojoGetMessageData，附加在一次Message传递。

下面演示，mmmojo跟wmpf_host，建立Invitation并MergePort建立新的MessagePipe连接。

下面演示，mmmojo跟wmpf_host，通过MessagePipe进行MergePort建立新的MessagePipe连接。

需要注意的是，MergePort发生在ports层，对于系统外部的使用者是透明不可见的，我将其归纳在ports层的控制协议。MergePort结束后的peer port，如果没有一个MessagePipe认领，使用者也是没有办法使用的。毕竟对于系统边界外部，只有MessagePipe是可知的，而不是Port。如果将MessagePipe等一类Mojo对象，归纳成一层。那么这一层是最接近系统边缘的。

接下来认识Mojo对象。《windows核心编程- 第三章内核对象》已经阐明了句柄与内核对象的关系。(随手找了篇别人的第三章笔记)。内核对象由操作系统内核管理，内核通过内核对象句柄表，将句柄显露给用户空间，句柄就是内核对象句柄表的索引。这里要声明，在mojo代码里，platform对应操作系统平台，system对应的是mojo设备(或者mojo embedder, mojo core)。所以PlatformHandle就是OS的内核对象句柄。相应地MojoHandle就是mojo内核对象句柄。同理地，每个mojo设备的内核，维护着各自的Mojo内核对象句柄表。Mojo内核对象都是Dispatcher对象。它们分别有MessagePipeDispatcher, DataPipeConsumerDispatcher, DataPipeProducerDispatcher, InvitationDispatcher, SharedBufferDispatcher, WatcherDispatcher等。特别地，在接口层Watcher对应另一个名称Trap。

Trap是一种特殊的对象资源，本人认为类似于epoll。为MessagePipe，DataPipe内核对象提供异步IO事件的支持。

epoll让与确立了事件关联的fd，将触发事件添加到自己的ready list，用户藉由epoll_wait将事件取出。

类似地，Trap让与确立事件关联的MessagePipe或DataPipe，将触发的事件添加到它的ready_watches_，用户藉由MojoArmTrap将事件取出。

如果你能够很好地适应英文语境，若不能请不要理会Arm的字面意思，尝试一下换个角度去理解。坦诚地我适应不了Arm这个单词，换成epoll_wait去理解，一下子就通了。

WatcherDispatcher有一个成员armed_来标识是否正在进行Arm模式。Arm模式是一种Proactor模式。相反地，当armed_=false时，ArmTrap对应着Reactor模式。下面分析Arm模式是如何利用edge-trigger事件，来实现Proactor模式。c++binding层中，SimpleWatcher对应的是Proactor模式，WaitSet对应的是Reactor模式。

WatcherDispatcher的ready_watches_相当于level-trigger事件。

每个Watch的成员last_known_result_，用来判断是否产生了一个edge-trigger事件。

MessagePipeDispatcher，以下面的路径，WatcherSet，WatcherDispatcher，Watch，通过NotifyState函数，产生level-trigger事件，添加进WatcherDispatcher.ready_watches_。过程中Watch通过last_known_result_判断是否为edge-trigger事件，如果是edge-trigger事件，并且正进行Arm模式，就会在当前线程的RequestContext上将Trap的Callback安排一次后续的回调，从而实现了Proactor模式。这时armed_就会设置成false关闭Arm模式进入Reactor模式。现在ArmTrap退变成epoll_wait用来轮询level-trigger事件。SimpleWatcher在回调函数用Reactor模式将所有level-trigger事件处理。ArmTrap函数本身的基本作用首先是一个事件轮询(Reactor)，然后有一个高阶的功能Arm(Proactor)。

或者换个角度，Arm模式是将ready_watches_是否为空，看作一个事件，不关心个别Watch。并且只对ready_watches_从空至有的edge-trigger事件发起回调。我们熟悉对edge-trigger的处理，是必须对事件源的数据读完。现在在这次回调中，事件源不是单个Watch，而是一整个ready_watches_，我们务必要将ready_watches_里面所有的Watch，将每个Watch对应的事件源的数据读完。将ready_watches_清空后，Arm才能重新开启，否则ArmTrap只能用于轮询ready_watches_里面的独立level-trigger事件。这大概就是只有CreateTrap可以设定一个唯一的回调函数，而AddTrigger并不给独立的事件设定回调函数。因为一整个Trap看作一个事件，这个事件就是ready_watches_是否为空。

ArmTrap是一个非阻塞函数，为弥补，在C++binding层的WaitSet提供了阻塞的版本。WaitSet通过一个Trap来对应一个默认的系统事件，WaitSet可以阻塞等待一个或多个系统事件，但至少包括它自身默认的事件。当Trap的ready_watches_不为空时，WaitSet的默认事件处理ON状态，Wait操作不会阻塞。但是Trap的ready_watches_空时，WaitSet的默认事件处理OFF状态，Wait操作就阻塞起来。直到Arm模式因为ready_watches_由空转有，回调函数将WaitSet的默认事件ON，从而唤醒阻塞的Wait操作。当Trap因为ready_watches_不再空关闭了Arm模式，在Wait操作前都需要ArmTrap轮询是否有事件，在有事件情况下预先将WaitSet的默认事件ON，从而使得后面的Wait操作不阻塞立即返回。如果要中止Wait操作，可以搭配另外指定的事件，让Wait同时阻塞等待这个事件，通过这个事件就可以唤醒中止Wait操作。这样就是一个epoll_wait的阻塞版本的实现。

然后顺带一提RequestContext，这个好像参照了linux的软件中断-后半处理。简单地说，就是内核在系统调用期间，硬中断事件保存到软中断队列，在系统调用线束时，控制权由内核空间转回用户空间前，顺便将软中断队列的事件给处理完。Mojo系统调用，当前线程在堆栈构建一个局部的RequestContext，并在TLS保存指针，给所有调用帧使用。当这次调用结束，局部的RequestContext析构时，将队列的回调通通执行。Arm模式就是利用RequestContext，将回调安排在RequestContext的回调队列中。延后到Mojo系统调用再执行。这样就可以充分契合多核环境的多线程。

下图演示，使用Arm-Proactor模式。Trap回调函数，进行Reactor穷尽所有level-trigger事件。

下图演示，使用Arm-Reactor模式。Trap回调函数只通知事件，唤醒我在控制台线程手动进行Reactor处理所有level-trigger事件。

where are we? 现在小结一下，我们认识了链路Channel，链路连接Invitation，Port的连接MergePort，Mojo对象Trap。那么如何跟C++Binding的Service联系上。直接操作NamedPipe，只是在直接操作链路。Service使用MessagePipe进行通信，我们至少也要知道一个Service与哪个Port是对应的。但是我们仍然不知道Service对应的对象。我们熟知LongLongAgoFarFarAway有一个套路，底层向上层传递消息都用通知，而可以对一个MessagePipe监视的就只有Trap。Trap就是找到上层Service的一个关键。

只要拆解Trap，就可以上观天文下知地理。向上可以追踪Service，向下可以溯得MessagePipe。如我上面已经提到，Trap在Binding层主要有两个高阶的类，分别是SimpleWatcher同WaitSet。SimpleWatcher正是专门为MessagePipe提供Proactor-Read的。换句话是通向上层Receiver的。

下图演示通过Core的句柄表可以过滤出所有Trap，并找出哪些是SimpleWatcher。

然后通过SimpleWatcher找出Remote或者Receiver。下图演示

从底层Trap到上层ServiceStub的线索如下图。分别是Trap，SimpleWatcher::Context, SimpleWatcher, Connector，InterffaceEndpointClient，ServiceStub。

从Connector开始，往上所有参与的类皆是MessageReceiver。MessageReceiver使用了责任链模式，用虚函数MessageReceiver::Accept传递责任并处理Message。Connector对应着一个MessagePipe以及它的SimpleWatcher。它既代表一个底层通信MessagePipe的连接，同是也是底层跟Binding上层承接的连接点。Remote跟Receiver都是一个InterfaceEndpointClient。当一个InterfaceEndpointClient没有incoming_receiver_时，它角色则是Remote，是ServiceProxy的receiver_，这时InterfaceEndpointClient::Accept负责发送，注意的是Accept的责任来自上层的Proxy。相反地，当有incoming_receiver_时，它角色则是Receiver，并且incoming_receiver_就是ServiceStub。这时InterfaceEndpointClient::Accept直接将责任传递给ServiceStub，Accept责任来自底层的SimpleWatcher通知。

从上层开始的outgoing:

ServiceProxy, to InterfaceEndpointClient::Accept, to Connector::Acceptr, to MessagePipe

从底层开始的incoming:

MessagePipe, to SimpleWatcher, to Connector::ReadMessage, to incoming_receiver_->Accept, to ..., to InterfaceEndpointClient::Accept, to ServiceStub。

这样的话，只要构建一个Message，调用InterfaceEndpointClient::Accept，就可以使用服务了。如果InterfaceEndpointClient是Remote的话就会发送请求，如果是Receiver的话就会直接交给ServiceStub处理。采用这种方法需要注意一点，core部分的代码变更的情况比较少，但是binding部分的代码变更还是非常频繁的，这个Message并非abi创建的Message，而是binding层的Message，必须紧贴mojo embedder的代码版本。

回到mmmojo.dll。WeChat与子进程服务通过mmmojo.dll进行Ipc，与Wmpf通过wmpf_host_export.dll进行Ipc。mmmojo.dll定义了一个唯一的服务MMMojoService。实际上它是一个类似IPC.mojom.Channel的单向通路。所有服务需要一组双向通路，也就是两边都互为对方的MMMojoService。事实也是这样。逆向分析后得到MMMojoServiceImpl，既包含Remote到对方的MMMojoService，同时包含Receiver接受对方的调用本方的MMMojoService。

mmmojo设计了一个MMMojoEnvironment，并以MMMojoDelegate作为MMMojoServiceImpl的Delegation。让外界能够实现MMMojoDelegate抽象类，就可以通过MMMojoEnvironment绑定成MMMojoService进行使用。一个MMMojoEnvironment对应了一个默认的MMMojoServiceImpl，MMMojoServiceProxy，MMMojoServiceStub，Remote，Receiver。MMMojoEnvironment另外还有两个MMMojoServiceImpl携带了独立线程，分别用于“RW"跟“RW sync"。外部使用只要的实现了MMMojoDelegate的具体类，就可以直接通过MMMojoEnvironment使用MMMojoService进行IPC。mmmojo.dll的Read系列导出函数，对应使用MMMojoServiceImpl跟Receiver，Write系列导出函数则对应使用MMMojoServiceProxy跟Remote。ReadInfo同WriteInfo，对应MMMojoService的方法的参数进行了封装。ReadInfoRequest同WrtireInfoRequest对应RawPayload。换句话，mmmojo使用MMMojoService将mojo封装到IPCChannel服务，以c函数导出接口。使用者无须关心mojom，MMMojoService。

MMMojoDelegate有8个接口方法，前三个是给MMMojoService使用的，后面5个可能是MMMojoEnvironment使用的。

MMMojoService接口方法到MMMojoDelegate虚拟函数的关系如下：

比较简单常用的是MMMojoService::0, MMMojoService::1两个方法，分别对应MMMojoDelegate::OnReadPush，MMMojoDelegate::OnReadPull。这里说明一下，Service的每个method都有一个hashname，salt不同编译出来的hashname也不会相同。这里归约成hashname表的序号。MMMojoService::0就是第一个method。

Push的向MMMojoService服务端推消息，不要求返回结果。MMMojoService::0的调用，是没有返回结果的。

Pull则是向MMMojoService服务端拉消息，要求返回结果。MMMojoService::1的调用，是返回结果的。

WeChat跟子进程服务就用mmmojo.dll进行protobuf IPC。

旧版的WeChat应该是将OCR功能做在WeChatUtility.exe。WeChat会将图片的灰度图发给WeChatUtility.exe。使用MMMojoService::1。