先通过未读消息树内存断点,关联到相关可疑的类,因为消息内容和未读消息数量肯定存在某种关联,通过CE逐步过滤内存地址
内存断点触发后,会关联到一个频繁触发的call,但又不是最终的消息类hook call,在其调用层上方的call打断点,不建议再内存读写这个call打断点,太底层的函数,调用函数会很多,触发最频繁,我们要的是一个收发消息的时候会频繁触发,但其他不会触发的call
这时候你再发送一条消息,并在这个call打断点,断下后去搜索文本消息内容,你可以发送一个比较奇怪的文本内容,这样搜索到关联的内存地址比较少,更好定位
微信用了STL模板,消息内容格式是std::string,存在一定的特征结构,通过CE搜索字节码,会定位到一个类, string特征如图,容器一般是F的整数倍,F的上方是字符串的大小
假设你发了一个filehelper的文本内容,其十六进制为:66 69 6C 65 68 65 6C 70 65 72 00 00 00 00 00 00 0A 00 00 00 00 00 00 00 0F 00 00 00 00 00 00 00,在CE中搜:
这时候会得到多个地址,逐个排查,其中有个地址就是消息监听的地址,会关联到某个类
但是这个类,是首次触发未读消息的时候才会断下,其上方存在跳转,构造这个类的调用函数就是最终要监听的函数
传播安全知识、拓宽行业人脉——看雪讲师团队等你加入!
KTRG889 博主V多少