红色警戒2逆向系列：spy++和Ghidra寻找逻辑变化（上）

上一篇我们找到了一些办法来绕开红警2的反调试机制。这一期我们要步入正题，来寻找能够处理窗口点击造成变化的函数

Windows有一个工具叫做spy++，这个工具在visual studio的tools里可以找到。虽然spy++对于我们做逆向工作帮助有限。但是还是能够告诉我们windows窗体发送了哪些信息。

点开spy++，点击搜索，有一个好玩的东西，把那个探针给移到游戏窗口下，就会告诉你窗口的PID和句柄等信息，然后你就可以右键点击消息来查看这个窗口发送的消息。我们可以通过过滤来过滤掉一些不用的消息

有一说一，看着这些消息一直刷还是挺有意思的（奇怪的癖好）

我们可以看见，当我们点击10个灰熊坦克的时候，窗口发送了这些消息。如果我们能知道这个消息最后被那个函数处理了，我们就可以使用程序从外部调用这个函数，从而实现自动化的操作，实现了自动化的操作，就可以开发AI程序了。

但是Spy++是不会告诉我们窗口消息最后被谁处理了的。所以我们需要使用调试器来完成这个工作

现在我们需要使用调试器来调试这个代码了，我们首先发现EIP寄存器停在了

有一个非常坑的事情是，当你点进“线程”栏里查看线程的时候，你会发现所有的线程都有一个等待原因，然后你以为这个线程在等待，但是实际上这个等待原因很有可能是上一次等待的等待原因，而这个线程实际上没有等待。本来今天可以给大家两更的，但是因为被这个东西坑了半天，我花了半天思考为什么所有的线程都在等待，但是游戏却能正常运行。（反正拖更不是我的错就是了）

于是一个猜测就是，这个NtUserPeekMessage正在循环执行。NtUserPeekMessage 函数是用于检查线程消息队列中是否存在消息，如果存在就将消息从队列中删除并返回，如果不存在就会挂起线程等待直到队列中出现消息。Windows将在消息的接收者线程上分派消息。这个线程将接收到消息，并将其传递给相应的窗口过程（即消息处理函数）进行处理。

再多废话两句，因为这个PeekMessage卡了我挺久的，之前看见有人在评论区说我是大佬，实际上我不是干逆向工程这行的，前一篇我也说了，我的老本行是后端开发和一些关于智能算法的研究，所以连小佬都不算，只是业余爱好想要学习研究一下，很多技术我都是现学现卖的。要是真有大佬的话，请多多指教一下我。

所以PeekMessage在取出消息之后，会被放进MSG结构体中，然后通过GetMessage或者DispatchMessage函数将其传递给相应的消息处理函数。所以问题的关键就在于寻找是那个函数把消息取了出来并且派发给消息处理函数。这个时候，符号表就很有用处，打开Ghidra可以发现有8处关于DispatchMessageA的引用

这个时候大家就很奇怪了，为什么有8处在派送消息处理函数呢？这个有可能是因为在整个程序中有多个窗口或者对话框需要处理消息，每个窗口或者对话框都需要自己的消息处理函数，所以会有多个循环来处理不同窗口或者对话框的消息。此外，还有可能是程序中包含多个线程，在不同线程中需要处理不同的消息循环，也会导致出现多个类似的代码段。但是这个还需要进一步分析

这一篇的字数也差不多了，我也做了超多的研究，这篇是我熬夜肝出来的，要是我是大佬的话，这些工作量可能就是半小时的事情，但是我是萌新宝宝，所以花了很长的时间。下一篇我们会把一些主要的接口全都挖掘出来，这一篇就当是准备了。有些人可能会觉得比较水，但是我其实做了一堆研究，包括使用resource hacker之类的来研究UI之类的。而且我也要尽量给大家保证一天一更吧

下集预告：x32dbg寻找逻辑变化（下/中）