xxxx(四)：接受消息hook地址分析

   今天来分析一下xxxx接受消息的call；测试的账号在虚拟机，发消息的账号在物理机；

   1、老规矩：逆向分析的起点都从CE开始；给测试账号发送辨识度高的消息，这时暂时不要在测试账号打开消息。因为此时的消息刚经过网络传输，还是ASCII格式，所以千万不要勾选UTF-16，只能找ASCII码找（下面详细解释原因）！

 重复发送0000000000、1111111111、2222222222、3333333333等辨识度很好的字符串，最终锁定3个地址：

 

  这里再详细解释一下用ASCII码找的逻辑，先介绍一下数据包整体的处理过程，如下：

•   数据通过网络到达网卡后，会暂时存在网卡的缓存；网卡此时通过控制总线通知cpu来取数据；
•   cpu通过数据总线把数据从网卡的缓存读取到内存
•   os再根据数据包的端口号找到这个数据包属于哪个进程，然后再发送给进程在内存的缓存
•   进程收到数据后根据业务需求处理数据，具体到这里就是在界面展示出来

  由此可以得出以下几点结论：

•    同一份数据在好几个不同的地方都存了，原因就是上述各种转手、倒腾导致的
•    数据都是通过ASCII发送的，os和进程的缓存也都是ASCII格式，并且缓存的地址是不变的，所以才能通过发送不同的数据来确定缓存的地址；一旦在页面展示出来，消息就是一条一条的了，那么在内存存放的地址肯定会改变，绝对不会再让不同的消息共用同一块内存，此时再通过不同的消息查找是找不到真正哪个缓存地址的！

 2、目前看不出是哪个是消息接受函数写入的地址，只能3个地址都下断点试试；正当对第二个地址下断点时，下面内存展示的内容引起了我的注意: 第一个内存只展示了收到的消息，但这个内存还展示了msgsource、疑似MD5等，这个是原始消息接受内存的可能性最大，果断下内存写入断点：

  

   继续给测试账号发消息，成功断下：从寄存器看，是edi指向了这块内存区域；rep movs是连续写入的指令，应该就是这里没错了！

   

   核心dll的基址是711B0000， 断点指令的地址是724472AE，offset=0x724472AE-711B0000=0x12972AE，记住这个base，以后重新打开的时候就能直接通过偏移找到这行代码了；

   

   这个时候就可以通过栈回溯一层一层查找函数调用了；理论上可以在栈上找到xxxx软件的每个函数然后下断点，但这样做效率太低。继续挨个往下回溯栈时发现了一个关键词：”lass SyncMgr“， 这个从字面看是疑似是最后同步消息的函数，这个字符串也是ASCII码，所以跳到这里观察一下这个函数：

   

   返回处是一个push指令，该指令前面有一个call调用，在这里下个断点，断下来如下：

   

    继续向下观察堆栈：找到了发送消息的id（已经打码）和消息本身；为了证实，这里可以继续发其他的消息，看看下面”eeeeeeeeee“会不会变成发送的消息。我这里已经尝试过了，确实是这样的，这个call就是发消息的call了，edi指向了消息的结构体！这个call的调用地址是0x7157CB6B-0x711B0000（核心dll的基址）= 0x3CCB6B；以后如果重新加载了xxxx，可以直接根据这个基址找这个call；后续代码也要hook这个地址！

   这个call有个特点：跳转地址是[eax+0x8]，而eax又来自另一个内存地址[0x72A52BF0]，属于间接call；每次重新加载dll的时候，由于OS的随机地址分配基址，可能地址都不一样，因此直接找call的入口不太合适，就死死守住这里调用call的地方！

   

   接下来就是计算关键数据的偏移了：

•     发消息ID（有可能是群，也有可能是个人）的偏移=[[esp]]+（0x76AD70-0x76AD30）= [[esp]]+0x40
•     消息内容的偏移 = [[esp]]+（0x76AD98-0x76AD30）= [[esp]]+0x68
• 
• 群里发张图片还会注明是哪个用户发的；
• 
•     如果是群消息，那么这里是个人ID = [[esp]]+（0x76AE94-0x76AD30）==  [[esp]]+0x164；如果是个人消息，这里直接是00；
•    [[esp]]+0x178处还有一串疑似MD5的字符串，个人猜测有可能是校验的MD5，防止消息内容被第三方截取后篡改内容（有点类似https证书的认证）；

        

        消息最后以<msgsource>结尾！

       大家有没有主注意到：账号的id、消息内容、md5这些字符串后面紧接着都会有两个4字节数字？ 这些数字的大小刚好等于字符串的长度！个人猜测这是对字符串做长度校验的，避免字符串过长覆盖了某些重要的数据，比如返回地址等，造成栈溢出攻击！

        至此，接受消息call的偏移地址找到了，消息存放的地址也找到了，下一步写代码hook消息的接受！

说明：

1、xxxx版本号：3.1.0.41

参考：

1、https://www.bilibili.com/video/BV1Sg4y1b7uc?p=11 最新实战xxxx hook分析

 2、https://www.freebuf.com/articles/others-articles/210289.html   PC xxxx逆向：发送与接收消息的分析与代码实现

 

====================2021.2.6更新=================================

        互联网两大头部厂商这几天又在互相掐架，网传其中原因之一是：B厂家读取了T厂家xxxx关系链的数据，从本文逆向分析来看，技术上这个是完全可能的！关系链是T厂家最核心的资产和护城河，岂容他人觊觎？