准备工具：Cheat Engine，OllyDbg，IDA
前一篇（）已经说过 CE 是什么，也应用 CE 研究了如何保存微信语音，这篇继续使用 CE 和 OD 来研究一下微信的消息发送接口。
思路大概是这样：在消息框中输入内容之后，通过 CE 找到内容地址，然后通过内存断点来找到发送该数据的相关代码，从而找到消息发送接口。
分析过程
查找关键数据地址
在输入框输入一个比较特别的文字内容（避免搜索时太多内存选项）后，使用 CE 搜索该内容地址。
由于已经知道确切的消息内容，很容易就能通过 CE 的 Exact value->String 来找到内容地址，修改内容多次筛选，最后留下两个结果（详细操作见上一篇文章）。
通过 CE 修改一下内存的内容，微信输入框中内容同步改变，说明这个内存地址就是输入框中内容地址，最终确认地址是2A1E1A8。
接着在点击发送按钮之后，输入框内容会被清空，所以第一想法就是对内存地址下内存写入断点，可以找到发送过程中清空内容的代码。
打开 OD，挂载到 WeChat.exe 进程，在右下角数据窗口 Ctrl G 输入2A1E1A8，然后右键选择断点->内存写入断点。
F9 让 OD 跑起来，然后点击微信发送按钮，没想到意外发生了，输入框内容清空了，但是断点却没有触发。
怎么回事？断点弄错？地址找错？暂时没有答案。
用 CE 多次重复前面的操作，地址依然是这个地址，断点就是不触发。
通过 OD 查看到，在输入框清空后，2A1E1A8的内容确实没有变化，和发送前一样，并且在重新输入新的内容之后，该内存内容同步更新。
所以结论就是输入框内容地址确实是2A1E1A8，但是清空输入框并不是清空该内存内容，猜测编辑框可能通过控制字符串长短来控制显示的，清空输入框内容就是设置字符串长度为 0。
找到输入框类
清空输入框没有进展了，那怎么办呢？
尝试去找了其他数据，比如发送按钮的发送(S)，发送按钮的提示内容不能发送空白内容等等，数据地址也可以很快找到，但是和我们的分析目标偏的太远了。
几番折腾后，作罢。
转念一想，清空不行，发送总的读取输入框中内容吧，那换成内存访问断点尝试一下。
依然是在右下角数据窗口 Ctrl G 输入2A1E1A8，然后右键选择断点->内存访问断点。
完成后回到微信界面，没想到直接断下了，我还没点发送按钮呢。根据以前的经验，下意识就觉得是界面刷新显示文字触发了断点，这可能会影响分析，根本没办法通过发送按钮来触发内存访问断点。
一般解决方法有：
1、条件断点。也就是屏蔽掉刷新界面触发的断点，但是好像内存断点不支持条件断点啊，要么通过脚本来完成，好麻烦。
2、找其他切入点。废话，清空那边的路都断了，死心吧。
3、其他我不知道的...
放弃了一般的解决方法，我决定看看本次断点究竟干嘛了。
注意到断点的位置不是微信模块WeChatWin.dll中，而是在msftedit.dll，很少见的一个模块。根据目录可以看到是微软系统的一个模块，名字中的edit也可以看出这应该是一个编辑框相关的模块。
可执行模块, 条目 20
基址=6F050000
大小=00094000 (606208.)
入口=6F05D53D msftedit.<ModuleEntryPoint>
名称=msftedit (系统)
文件版本=5.41.21.2510
路径=C:WindowsSystem32msftedit.dll好像和我们的分析目标很贴近嘛，在 OD 中数据窗口右键断点->删除内存断点，然后按下 Alt F9 回到用户模块领空，也就是跳过系统模块的代码，直接回到微信的模块代码中，省过对系统代码的分析。
看到返回到6E20CCC2这个地址，上一行代码就是调用msftedit.dll的函数，我们对其下一个断点，鼠标点击到6E20CCBF这行代码，按下F2下一个int 3断点，然后F9跳过本次分析。
OD 继续断下，此次直接断在了6E20CCBF这个位置，可以看到call调用了msftedit.6F05AD69，这是个什么函数呢？
既然msftedit.dll是微软模块，那么肯定是有符号的嘛，嘿嘿。
这里可以直接在 OD 中加载符号来分析，使用方法是：
1、在 WingDbg 目录下拷贝 dbgeng.dll，dbghelp.dll，srcsrv.dll，symbolcheck.dll，symsrv.dll，symsrv.yes，一共 6 个文件至 OD 目录下。
2、打开 OD，设置符号路径。调试--->选择符号路径。
3、设置 StrongOD 的插件选项。选择加载符号。
原文：
https://blog.csdn.net/sr0ad/article/details/8253311
但是只支持本地符号，也就是得自己下载了模块对应符号到本地，OD 设置符号文件路径后，才能正常使用，有点麻烦。
我这时候一般就会使用 IDA 了，因为它会自己在线下载模块对应的符号，很方便。
用 IDA 打开msftedit.dll，等待些许时间，IDA 下载符号，解析等等完成后，我们去找到msftedit.6F05AD69对应的函数究竟是个什么东西。
但是这里msftedit.6F05AD69的模块基址是6F050000，而 IDA 解析使用的是默认基址0x6FCD0000，要么修改IDA解析基址为6F050000，等待 IDA 重新解析，要么通过偏移计算对应地址。
再解析等太久，直接计算吧，所以要安利我写的一个小工具（偏移计算工具），能够快速计算地址，具体使用见相关文章。
再 IDA 中按下 g，输入6fcdad69，找到msftedit.6F05AD69对应函数为CTxtEdit::OnTxInPlaceActivate。
很明显通过名字OnTxInPlaceActivate可以看出是编辑框中文字激活状态（显示）下就会触发该函数，这不是重点。
重点看CTxtEdit，不言而喻，这就是msftedit.dll中实现的编辑框的类。
如果写过MFC相关代码，应该很快就能想到CTxtEdit肯定还有其他读内容、写内容的函数，叫做GetXXX或者SetXXX。
在 IDA 的函数列表中翻看一下，果然很快就找到了CTxtEdit::GetTextEx和CTxtEdit::SetText。
但到底这两个函数是不是编辑框读写内容的函数呢，我们对这两个函数下断点试试，通过工具算到在 ID 调试中这两个函数的相应地址为6f068437和6f056d37。
在 OD 的底部命令窗口输入bp 6f068437和bp 6f056d37，删掉之前CTxtEdit::OnTxInPlaceActivate的断点，然后F9跑起来。
回到微信界面，这次能够正常显示了，点击发送按钮。OD 触发断点，断在了6f068437也就是CTxtEdit::GetTextEx上，很明显这是发送函数在读取输入框内容。
回溯找到发送函数
此时的调用堆栈是这样的：
在 OD 中回溯调用堆栈跟踪返回到WeChatWi.6E20D239，看到右侧堆栈窗口已经获取到输入框中内容，证明前面的分析没有问题。
再次回溯两层到WeChatWi.6DC15B60，可以看到堆栈中的参数依然是获取到的输入框内容。
[0026E5E4] =0828C070
[0828C070 4] =0828CAF0=>a12bcAAAAA
此时函数首地址是WeChatWi.6DC15B10，进入到IDA中对应函数100d5b10（你要问我为什么此时进入 IDA 查看？我只好说其实这个步骤花费了很多时间，一边 OD 调试，一边 IDA 辅助确认等等，过程并没有这么顺利，篇幅原因省略），然后按下 x 回到上层函数，看到如下代码：
看到click很明显可以看出这就是发送按钮的响应函数了（相关知识可以了解duilib编程，微信界面是duilib实现的）。
到目前找到了发送消息的函数，但还并不是消息发送接口，这还只是界面的操作函数，具体发送消息接口应该在该函数内部被调用。
有技巧找到发送接口
先粗略地在 OD 中跟一遍WeChatWi.6DC15B10的代码逻辑，函数很多，没法很快确认哪个函数是消息发送接口。
截取部分代码感受一下，大概 11 个函数。根据 OD 跟的逻辑大概是sendBtn_GetText_10093860->sub_100DD340->sub_100C50C0->sub_10094100->sub_100DD9D0->sub_100C4450->sub_10323DF0->sub_100DE120。
通常通过调试每个函数的参数、返回结果等基本可以猜测到函数功能，然后来找到消息发送接口。
但这里我偷懒了，因为参数结构复杂，一时半会没法找到关键点，有点晕了。
所以我通过排除法来一一筛选函数，最多 11 次左右就能找到消息发送接口。举个例子，如果sub_100DD340是消息发送接口，在我手工屏蔽其功能之后，消息肯定发不出去了，那么我就可以通过看到的结果（是否发送成功）来确认sub_100DD340是不是要找到的消息发送接口。
具体屏蔽方法：
1、通过 IDA 或 OD 进入sub_100DD340函数内部，找到函数结尾，找到 retn xx 类似代码
2、用 OD 在sub_100DD340函数开始修改汇编代码为 retn xx，双击输入 retn xx 即可
这样sub_100DD340函数直接在入口就返回了，功能没有了，也保证了函数调用时的栈平衡。
在确认sub_100DD340并没有影响消息发送之后，通过右键撤销选择处修改恢复修改的内容。
如此重复筛选其他的函数，最终确认sub_100C4450为发送消息函数。代码接口如下：
sub_100C4450((_DWORD*)(a1_->unk_558 2528), (_msg*)msg);// msg是发送内容，a1_->unk_558 2528)是当前聊天窗口的好友信息，包括wxid和名字之类的信息。
但作为接口依然不够简洁，需要构造好友信息，比较复杂，所以继续深入sub_100C4450内部，看看是否能够找到最简单的接口，比如：
sendmsg(wxid, msg); //传入发给谁，发什么即可sub_100C4450内部依然很复杂，使用和前面同样的方式，先大致跟一遍执行流程，然后通过排除法逐个筛选。
这一次筛选屏蔽的方法换一种，直接在某个函数执行完成之后，通过jmp跳到sub_100C4450结尾，如果某次消息发送成功，最后执行的函数就是我们要的接口。
很幸运，这次在第三个函数就找到了消息发送函数sub_102DA4A0，看看它的参数：
sub_102DA4A0((int)wxid, (int)&v67, msg__, &unk, 1);
sub_102DA4A0@<eax>(intwxid@<edx>, inta2@<ecx>, wxstring*msg, _DWORD*a4, inta5)下图是调试中看到的数据，确认接口没有问题。至于其他两个参数，经过分析是用于接收输出的，没有实际作用，在此不赘述。
如此分析消息发送接口的工作完成，找到了和预期基本一致的接口函数。
总结
篇幅好像有点长了，最后做一下此次分析的总结：
1、ce 找到编辑框中的内容内存
2、发送后，编辑框内容删除，写断点无效，神奇，猜测通过设置长度控制显示
3、改为内存访问断点，进入界面就会断下，徘徊几次后，决定分析，没想到找到了关键点 CTxtEdit::OnTxInPlaceActivate
4、知道编辑框使用了 msftedit.dll 的 CTxtEdit 的类，用 ida 找到符号
5、查询类似 getvalue 的接口，找到 SetText、GetTextEx 等，对这两个函数下断点
6、果然断下，回溯找到了发送的消息响应函数
7、详细分析响应函数，多次通过 retn、jmp 排除，找到真正发送消息函数，最后分析出接口函数
此次分析中 CE 找到地址是第一步非常关键的点，直接就进入了函数调用堆栈内部，对此次分析作用非常明显。
再就是在发送消息响应函数内部，逐个分析找到消息发送接口函数中，通过修改指令来屏蔽函数功能来确认函数功能，比每个函数去分析参数猜测确认功能来的更快，效果更明显。
调试工具非常重要，动（OD）静态（IDA）分析结合能够提高分析速度。
OD 适合分析函数参数、解析数据结构、确认函数功能，IDA 适合分析函数逻辑、整体函数结构、代码框架等等，各有优势。
最后，再次安利一下开源项目：
https://github.com/anhkgg/SuperWeChatPC
此次分析的发送消息接口也会在后续合入到项目中，欢迎star和PR。
