某聊天软件防撤回尝试
寒假想学学dll注入的东西，防撤回应该是比较简单的一类了。来点我最喜欢的实战环节，然后再去学ctf。
大概来说，防撤回分下面这几步：
- 用户A在客户端A向服务器发起撤回请求
- 服务器响应撤回请求，向所有相关客户端发送撤回指令
- 其他客户端接收撤回指令，删除存储在本地的用户A的消息
如果我能爆改某厂的服务器的话，我就不会窝在这写blog了，所以我们考虑在本地做手脚
某绿色软件的电脑版
版本：
需要用到的是x32dbg，一步一步分析吧。
先打开微信，然后直接附加进程
然后微信会卡死，我们在dbg里面跑到最后，会发现微信能点击登录按钮了。这个时候的模块是wechatwin.dll，根据名字和文件夹里面的大小来看这玩意估计是主要的dll。
据此，我们考虑在这个dll里面找一找有没有我们想找的撤回模块。
在符合里面找到这个dll，然后进去看看
要找的是撤回模块，直接在当前模块搜字符串，拼音和英语都试一试
revoke和recall的关键字都有，但是可以找到更关键的关键字：revokemsg，看这名字应该是撤回消息
来到这个函数，我们这里就是在7AF24C68处
看了一圈没发现什么好利用的地方，然后突然想到：刚刚搜revoke的时候看见了把函数地址压入栈的操作，会不会有一个是在压这个函数的栈呢
退回引用的地方，发现这句话
而且只有这句话在调用revokemsg的地址，那么去看看
这个逻辑很好理解，考虑把je改成jmp或者把下面一大串全nop了。由于je jmp指令大小一样，直接改成jmp跳过去吧。然后右键补丁然后修补，保存出来的dll文件命名为WeChatWin.dll，替换就行，替换前建议备份预备不测。
测试一下
done
某红色软件的电脑版
版本：
这次dbg附加的时候很难看出来哪个dll比较关键，考虑换个方式。
刚刚在微信里查找的关键字是revoke，毕竟俩软件是一个厂的，我们在这里面也试试revoke
用notepad++在qq所在的文件夹查找
值得关注的是，我们在IM.dll和MsgMgr.dll找到了tencent.im.msgrevoke.UinTypeUserDef这个方法
msgrevoke，就是消息撤回，那么重点关注他们。
用LordPE看看输出表，大概确定一下他们的作用。
首先是IM.dll，结合搜索引擎以及微软的官方文档，可以确定下面四个是Comebaseapi.h下的方法，是一些API接口常用的东西，然后第一个函数目测是自写的
然后MsgMgr.dll只有下面四个玩意，没有自写函数，那我们应该先试着分析IM.dll。（后来想想，毕竟q官网写的是I'm qq）
确定好了就开干。依然使用x32dbg附加进程，然后像微信那样去符号里面找IM.dll，然后搜revoke
但这一次没有微信那么简单，我们找出了一大堆差不多的字符串，静态分析应该很难办。
那么我们试着动调去找一下。先运行，直到左下角的暂停状态变成运行状态，也就是qq能正常使用的时候，然后在刚才找到的这些命令上右键全部下断点。然后用手机给自己发一条消息，撤回
看字符串：CTX Revoke Message Service，CTX撤回信息服务，那么这附近应该有撤回模块。
现在，一个最简单的想法就是：把这下面所有的call一个一个给他绕过再撤销，尝试出哪一个才是调用撤回函数的call。
nop了一下发现：D15F位置的call是正确的。测试了一下确实没有撤回
然而在群聊里面：
看来不是一个模块？并没有完全搞定，那继续分析吧。一个简单的想法是：这次下断点后在群聊里面撤回
这一次先在这里停下来
有了上一次的经验，我们能够对照着找一下。一个特点是：私聊模块有一个字符串是bytes_reserved，而调用撤回函数的call是夹在"bytes_reserved"和"OnSysProtobufDataCome failed to get bytes_reserved"中间的。群聊模块这里我们又发现了相似的bytes_userdef。我们按着这个特征再来nop一次试试
把中间这个call给nop掉然后修补，但还是不行。
但在字符串窗口发现：这次好像有两个这种地方
那么到第二组字符串看看
把这个call也nop了，然后成功的把我qq玩崩了，猜测是简单粗暴的nop把逻辑搞抽象了，那回溯一下换成jmp跳转吧，直接把push bytes_userdef的句子改成jmp，跳转到call下面的test语句就行
测试一下
算是完成了
