上一篇我們找到了一些辦法來繞開紅警2的反調試機制。這一期我們要步入正題，來尋找能夠處理窗口點擊造成變化的函數(shù)

Windows有一個工具叫做spy++，這個工具在visual studio的tools里可以找到。雖然spy++對于我們做逆向工作幫助有限。但是還是能夠告訴我們windows窗體發(fā)送了哪些信息。

點開spy++，點擊搜索，有一個好玩的東西，把那個探針給移到游戲窗口下，就會告訴你窗口的PID和句柄等信息，然后你就可以右鍵點擊消息來查看這個窗口發(fā)送的消息。我們可以通過過濾來過濾掉一些不用的消息

有一說一，看著這些消息一直刷還是挺有意思的（奇怪的癖好）

我們可以看見，當我們點擊10個灰熊坦克的時候，窗口發(fā)送了這些消息。如果我們能知道這個消息最后被那個函數(shù)處理了，我們就可以使用程序從外部調用這個函數(shù)，從而實現(xiàn)自動化的操作，實現(xiàn)了自動化的操作，就可以開發(fā)AI程序了。

但是Spy++是不會告訴我們窗口消息最后被誰處理了的。所以我們需要使用調試器來完成這個工作

現(xiàn)在我們需要使用調試器來調試這個代碼了，我們首先發(fā)現(xiàn)EIP寄存器停在了

有一個非?？拥氖虑槭?，當你點進“線程”欄里查看線程的時候，你會發(fā)現(xiàn)所有的線程都有一個等待原因，然后你以為這個線程在等待，但是實際上這個等待原因很有可能是上一次等待的等待原因，而這個線程實際上沒有等待。本來今天可以給大家兩更的，但是因為被這個東西坑了半天，我花了半天思考為什么所有的線程都在等待，但是游戲卻能正常運行。（反正拖更不是我的錯就是了）

于是一個猜測就是，這個NtUserPeekMessage正在循環(huán)執(zhí)行。NtUserPeekMessage 函數(shù)是用于檢查線程消息隊列中是否存在消息，如果存在就將消息從隊列中刪除并返回，如果不存在就會掛起線程等待直到隊列中出現(xiàn)消息。Windows將在消息的接收者線程上分派消息。這個線程將接收到消息，并將其傳遞給相應的窗口過程（即消息處理函數(shù)）進行處理。

再多廢話兩句，因為這個PeekMessage卡了我挺久的，之前看見有人在評論區(qū)說我是大佬，實際上我不是干逆向工程這行的，前一篇我也說了，我的老本行是后端開發(fā)和一些關于智能算法的研究，所以連小佬都不算，只是業(yè)余愛好想要學習研究一下，很多技術我都是現(xiàn)學現(xiàn)賣的。要是真有大佬的話，請多多指教一下我。

所以PeekMessage在取出消息之后，會被放進MSG結構體中，然后通過GetMessage或者DispatchMessage函數(shù)將其傳遞給相應的消息處理函數(shù)。所以問題的關鍵就在于尋找是那個函數(shù)把消息取了出來并且派發(fā)給消息處理函數(shù)。這個時候，符號表就很有用處，打開Ghidra可以發(fā)現(xiàn)有8處關于DispatchMessageA的引用

這個時候大家就很奇怪了，為什么有8處在派送消息處理函數(shù)呢？這個有可能是因為在整個程序中有多個窗口或者對話框需要處理消息，每個窗口或者對話框都需要自己的消息處理函數(shù)，所以會有多個循環(huán)來處理不同窗口或者對話框的消息。此外，還有可能是程序中包含多個線程，在不同線程中需要處理不同的消息循環(huán)，也會導致出現(xiàn)多個類似的代碼段。但是這個還需要進一步分析

這一篇的字數(shù)也差不多了，我也做了超多的研究，這篇是我熬夜肝出來的，要是我是大佬的話，這些工作量可能就是半小時的事情，但是我是萌新寶寶，所以花了很長的時間。下一篇我們會把一些主要的接口全都挖掘出來，這一篇就當是準備了。有些人可能會覺得比較水，但是我其實做了一堆研究，包括使用resource hacker之類的來研究UI之類的。而且我也要盡量給大家保證一天一更吧

下集預告：x32dbg尋找邏輯變化（下/中）