逆向调用QQ截图NT与WeChatOCR
QQ出Electron版了, 将截图独立出来了(应该是个过渡, 之后感觉会采用Electron重写), 并且使用的OCR改成了TencentOCR(低版本的WeChatOCR)
本文将重点介绍如何逆向调用WeChatOCR
0x00 逆向调用QQ截图NT
0x01 前期调研
先把QQ运行起来, 看看QQ NT的截图是什么情况的:
注意到 有一个--pcqq-platform-channel-handle的命令行参数, 并且存在一个有mojo字样的命名管道
那就搜索一下, 可以在 里发现, mojo是Chrome实现的一套IPC机制, 并且想要简单使用的话, mojo IPC有一套Invitation机制。
Invitation简单来说就是创建子进程, 并给它传命令行--mojo-platform-channel-handle=xxx。
显然QQ就是从这个基础上改了一个命令行参数, 本质就是采用Mojo IPC进行通信。
那就开逆! (一开始分析的是QQNT 64位版本的, 后面为了方便分析用的是9.9.0.14619 x86版本的, 可能地址会变化)
0x02 分析QQScreenshot.exe
先从被调用端分析, 直接分析QQ太大了, 先小看一下main函数:
这个main函数跟我以前逆的结果差不多哇, 总的来说就是启动QQ截图的环境, 图上画框的函数是启动IPC的, 进去看看:
还是COM的形式, 这里碍于篇幅不再介绍child ipc的过程, 直接看parent ipc的过程
(其实可以发现parent-ipc-core-x86.dll和child-ipc-core-x86.dll是同一个代码编译的DLL)
既然QQScreenshot是通过加载child-ipc-core-x86.dll再通过DllGetClassObject获取COM对象.
那QQ也很有可能是通过加载parent-ipc-core再动态获取COM对象实现的
那就动调一下QQ.exe, 搜索一下这种情况的代码:
1
|
DllGetClassObject
=
GetProcAddress(LibraryA,
"DllGetClassObject"
);
|
0x03 分析parent-ipc-core-x86.dll
定位到DllGetClassObject字符串:
可以看到和QQScreenshot.exe里初始化IPC的过程一模一样, 从parent-ipc-core-x86.dll中获取了一个COM对象
看一下这个COM对象的实现了哪些方法:
前三个函数是实现的IUnknown接口不用管, 其他的方法都可以通过字符串猜出来, 只要确定他们的参数类型就好了, 这里碍于篇幅省略掉(动调能直接看出来)
只介绍一下pCOM->LaunchChildProcess(...)方法:
0x04 LaunchChildProcess方法
通过动调可以发现LaunchChildProcess方法的第5个参数是用来设置接收IPC MSG函数的
在LaunchChildProcess方法里, 会调用base::Thread::task_runner新起一个线程来创建截图子进程↓
怎么确定的这些函数呢?, 因为新版QQ本身就是一个Chrome嘛, 直接通过字符串去搜Chrome的就OK了。
下面进LaunchQQScreenShot函数看看:
整个函数完全就是参考文章里面介绍的Invitation机制。
在这个函数里, 图上第46行, 会从this+48获取截图程序的路径, 因此我们需要构造一个对应的类, 我已经分析好了详情请见附件代码:
之后就是仿写一遍就能调用了, 详细信息还是请见附件代码:
0x10 逆向调用WeChatOCR
QQ采用的TencetnOCR就是低版本的WeChatOCR, 他们也是采用Mojo IPC进行通信
0x11 前期调研
通过 可以知道, 在Mojo中要想调用其他服务要通过Services Manager的转发, 也就是说QQScreenshot.exe是ServiceA, TencentOCR.exe是Service B, QQ.exe则是Service Manager(我猜的, 对不对也无伤大雅):
那想要分析OCR调用过程就不得不用IDA分析一下wrapper.node了(QQ的一个DLL, 主要逻辑都在这个DLL里)
0x12 定位OCR调用函数
通过搜索字符串可以发现很多个感兴趣的:
直接进DoOCRTask函数看看:
在DoOCRTask函数里进行了OCR的初始化以及OCR任务的发送, 即OCRdoInit和SendOCRTask函数
那我们需要分析一下是怎么实现的, 毕竟过程是QQScreenshot把IPC消息发给了我们的程序, 我们的程序要去调用OCR
0x13 分析OCRdoInit函数
首先初始化了TencentOCR.exe和mmmojo.dll的路径, 并很明显赋值给了一个类的成员变量:
之后就是进行了Mojo环境的初始化:在这里设置了命令行参数与回调函数
其中(*v11+4)这个函数是这样的:
就是获取mmmojo.dll的导出函数并保存起来供后面调用
在SetMMMojoEnvironmentCallbacks函数里设置了接收IPC消息的函数这个后面分析
0x14 分析SendOCRTask函数
在SendOCRTask函数里调用了很多方法, 一开始确实看蒙了, 但是通过后面分析可以发现其实逻辑很简单
函数一开始初始化了一些IPbMsg, CPbMsg什么的类, 一开始确实分析不出来这是啥玩意儿, 难不成为了给OCR发个IPC消息还得自己去实现这么多类? 那工作量可太大了(但其实不用, 通过后面的分析就会豁然开朗)
之后SendOCRTask函数调用CreateMMMojoWriteInfo创建了一个write_info这个write_info具体是啥现在也是不清楚, 然后拿到了WriteInfoRequest, 并调用memmove往里写东西, 最后调用了SendMMMojoWriteInfo发送出去, 那我们看看往里写了啥:
wow 龙头出来了! 发现图片路径了, 但问题是前八个字节是啥?
先不管了 既然发送函数分析不出来那就先去看接收IPC MSG的函数
0x15 分析接收IPC MSG的函数
通过分析SetMMMojoEnvironmentCallbacks的参数, 可以发现, 它设置的回调函数是一个虚表里的函数:
看看OnReadPush:
在这个函数里发现了protobuf的字样! (具体在哪发现的我忘了,反正确实有)
我们直接大胆猜测writeinfo、readinfo全是protobuf! 把数据扣下来测试一下(用protobuf-inspector这个工具):
成功了! 同理, readinfo里都是OCR结果的数据包括识别的坐标、UTF8文字、识别率啥的
0x16 分析protobuf格式
数据格式其实很容易看出来, 大体都能猜出来
比如发送的格式:
1
2
3
4
5
6
7
8
9
10
|
message OcrRequest {
int32 unknow
=
1
;
/
/
必定为
0
int32 task_id
=
2
;
message PicPaths {
repeated string pic_path
=
1
;
}
PicPaths pic_path
=
3
;
}
|
接收OCR结果的数据格式:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
|
message OcrResponse {
int32
type
=
1
;
/
/
第一次运行OCR会有push一次type1, 正常OCR结束type0
int32 task_id
=
2
;
int32 err_code
=
3
;
message OcrResult {
message ResultPos {
/
/
四个角的坐标 左上 右上 右下 左下
message PosXY {
float
x
=
1
;
float
y
=
2
;
}
repeated PosXY pos
=
1
;
}
message SingleResult {
/
/
SingleResult是一行结果 OneResult是单字的
ResultPos single_pos
=
1
;
bytes single_str_utf8
=
2
;
/
/
UTF8格式的字符串
float
single_rate
=
3
;
/
/
单行的识别率
message OneResult {
ResultPos one_pos
=
1
;
bytes one_str_utf8
=
2
;
}
repeated OneResult one_result
=
4
;
float
lx
=
5
;
/
/
识别矩形的左上和右下的坐标? 可能是
float
ly
=
6
;
float
rx
=
7
;
float
ry
=
8
;
int32 unknown_0
=
9
;
/
/
未知
ResultPos unknown_pos
=
10
;
/
/
未知
}
repeated SingleResult single_result
=
1
;
/
/
repeated 每行的结果
int32 unknown_1
=
2
;
int32 unknown_2
=
3
;
}
OcrResult ocr_result
=
4
;
}
|
编译一下google的protobuf库, 再拿protoc生成一下头文件和.cc就能用了
WeChatOCR同理, 调用方法是一样的
成品展示
结束语
其实有很多细节没有写出来, 比如QQ设置的接收IPC消息的函数的分析, 比如SendOCRTask第一次调用其实是在OnRemoteConnect回调函数里新起了一个线程异步调用的, 再比如OCR初始化的时候需要SetMMMojoEnvirenmentInitParam来设置--usr-lib,就是mmmojo_64.dll所在的目录。
具体的细节都可以去看附件的代码, 文章中没写出来的代码里都有哦(只能使用Release Win32配置编译)。
参考文章
[1]
[2]
[3]