我是菜鳥，高手勿噴，謝謝，

最近逆向某捕魚游戲，由于需求需要逆向他的封包數(shù)據(jù)，bp recv加給內(nèi)存下斷點，找到解密消息的地方（收包子線程里面），我要的是是怎們處理里封包，而不只是解密過程，接著向下追查，發(fā)現(xiàn)游戲先是把解密好的數(shù)據(jù)放在模塊內(nèi)存里面，然后給主線程（主窗口）發(fā)消息，告訴他，收到網(wǎng)絡消息并給你解密好了，趕緊處理吧，發(fā)消息是使用的postmessage，窗口句柄參數(shù)是主窗口，消息ID是0x4FF，以前看過郁金香的視頻教程，好像可以用SPY++找到主窗口的窗口消息處理函數(shù)，在哪里下消息斷點，一下就可以攔截了，無奈自己當時沒有記錄筆記，又找不到看的哪個視頻，自己動手找窗口處理函數(shù)，找了半天還是不行，找不到哪個函數(shù)，只能百度了“OD消息斷點”。大概收獲如下：

http://blog.csdn.net/liujiayu2/article/details/51789282

按照教程，依然沒有找到處理窗口消息的地方，哎，怪我太笨，，

無奈我只自己寫個工程，簡單逆向?qū)W習下，工程代碼如下（只列舉自己寫的，很簡單）：

#define MSG_TEST 0x4FF ON_MESSAGE(MSG_TEST, &Ctest2Dlg::msg) #include "ClogFile.h" LRESULT Ctest2Dlg::msg(WPARAM w, LPARAM l) {//輸出字符串l gConsoleLog.WriteLogInfo("%s",(char*)l);return 0; }DWORD WINAPI func(LPVOID lpThreadParameter) { char *p = new char[20]; ZeroMemory(p, 20); strcpy(p,"1234567890"); ::PostMessage(AfxGetApp()->GetMainWnd()->m_hWnd, MSG_TEST, 0, (LPARAM)p);return 0; }void Ctest2Dlg::OnBnClickedButton1() { // TODO: 在ú此?添?加ó控?件t通?知a處鋦理え?程ì序ò代洙?碼? CreateThread(NULL, 0, func, NULL, 0, NULL); }

按照上面的教程依然沒有找到我自己寫的msg(WPARAM?w, LPARAM?l)函數(shù)體，于是我進下了一下小研究，

找到gConsoleLog.WriteLogInfo("%s",(char*)l);這句的反匯編代碼，下斷點，點擊下按鈕，讓程序跑到斷點出，看調(diào)用堆棧，如下：

?

可以看到WinMain函數(shù)也在其中，這不是我們點擊按按鈕調(diào)用的，我們看到user32.DispatchMessageA

和MSG(0x4FF)結構體，最終調(diào)用到了我們的msg(WPARAM?w, LPARAM?l)函數(shù)體，我決定親自試一下，看看能不能調(diào)用到。

1.在DispatchMessageA上下條件斷點，[[esp+4]+4] == 0x4FF ?(消息ID)

2.點擊按鈕，程序成功在DispatchMessageA處斷下

3.F8單步走，走到user32.74E07BC5處的call,F7跟進去，因為堆棧是這么指示的

4.一直跟著堆棧走確實最終走到了msg(WPARAM?w, LPARAM?l)函數(shù)體

走到是走到了，這是一路走來真不容易，每個call里面都有幾十個call,必須在指定的call跟進去，不能走過了，也不能早走，但是看看這些，全是在系統(tǒng)代碼區(qū)，最終一走到用戶代碼區(qū)就正好到了我們想要的函數(shù)體，肯定有簡便的方法吧，根據(jù)我們前面看到的文章（雖然沒找到函數(shù)體，依然學到了東西）打開OD的內(nèi)存窗口，找到可執(zhí)行程序test2的代碼段，.text

?

右鍵F2下斷點，這個斷點表示，一旦程序運行了用戶層代碼，立即斷下，并自動清除斷點。

我們按照這個方法試下test2程序，

1.在DispatchMessageA上下條件斷點，[[esp+4]+4] == 0x4FF ?(消息ID)

2.點擊按鈕，程序成功在DispatchMessageA處斷下

3.test2.text下F2斷點，

4.F9運行程序

理論上來講應該是直接就到了我們的msg(WPARAM?w, LPARAM?l)函數(shù)體，可惜，沒到，到了下邊這個地方

?

瞬間心里難受，竟然有這種幺蛾子，怎么辦？

冷靜過后，我們思考下，到了這里時候，我們真正想到的地方msg(WPARAM?w, LPARAM?l)函數(shù)體，到過還是沒到過？再來一變，這次在步驟3上面加上，在我們最終目的地加上斷點，執(zhí)行步驟4之后發(fā)現(xiàn)直接走到了上面截圖的地方，還沒到我們最后的目的地，那就接著往下走走唄，F8單步運行，發(fā)現(xiàn)程序運行到了系統(tǒng)領空，那就繼續(xù)給test2.text下F2斷點，F9運行程序，到了下面，

?

依然沒有經(jīng)過最終目的地，沒事我們沖上面的步驟，經(jīng)過再兩次的重復，突然柳暗花明到了我們最終目的地，這是什么情況，我現(xiàn)在還是不清除，但是可以確定的是這種方式確實可以找到，我們最終的目的地，

?

回想下我們看到的那幾篇文章，發(fā)現(xiàn)他下的是TranslateMessage斷點，我下的是DispatchMessageA斷點，那咱就試試這個TranslateMessage斷點法，經(jīng)過測試，也可以找到最終的消息響應函數(shù)msg(WPARAM?w, LPARAM?l)?，歷程和DispatchMessageA斷點一樣的。

有了上面的實戰(zhàn)經(jīng)驗我們就開始弄弄我們的游戲，為方便描述，我重新寫這個具體步驟：

?

1.在DispatchMessageA上下條件斷點，[[esp+4]+4] == 0x4FF ?(消息ID)

2.點擊按鈕，程序成功在DispatchMessageA處斷下

3.test2.text下F2斷點，

4.F9運行程序

5.程序斷下，觀看程序斷的地方是不是最終想要的地方，是就結束，不是就執(zhí)行F8,程序會再進入系統(tǒng)領空，

6.重復執(zhí)行步驟3、4、5直到我們找到最終的處理消息的地方

?

肯能你會問了，你怎么知道到達用戶端代碼是不是我們最終想要的呢？說下最終的特征：

?

?

上面截圖是我們的測試工程，

特點1，進入的是一個完整的函數(shù)的頭，不可能是函數(shù)體的半中間，更不可能是jmp指令

特點2，函數(shù)體有兩個參數(shù)，其實就是postmessage的WPARAM?w和LPARAM?l，在TranslateMessage的時候就要注意這兩個參數(shù)的值，鋼筋函數(shù)體時，看下堆棧的第二個和第三只，應該就是兩個參數(shù)（第一個參數(shù)是call產(chǎn)生的，表示要返回的地方）

經(jīng)過測試，哎，一直沒到我們想要的地方，并且進入了一個死循環(huán)，研究發(fā)現(xiàn)這個循環(huán)是

收包->解密->派遣??->收包->解密->派遣 ->收包->解密->派遣 這樣死循環(huán)，怎么辦？知道我把這篇文章命名為困難重重的原因了吧，，

?

我有點小不服氣，以為運氣原因，連續(xù)試了幾次，每次，都是這樣，我有陸續(xù)換了幾個OD,都是這樣，沒辦法只能想為什么會如此了。因為我們是下斷點再加F9的找，這樣可能會導致操作系統(tǒng)切換線程，切過去我們再單步走，走不出死循環(huán)了，差不多就是這個意思。

?

廢話不大多說了，直接說我想到的解決方案：

我們發(fā)現(xiàn)系統(tǒng)領空就是兩個dll的切換和調(diào)用，user32和mfc100.同一個程序連續(xù)啟動兩次，把兩個連接庫加載到內(nèi)存中的地址可能會變（變前16位，后16位不會變），這個我們知道的，和應用程序一樣。我們拿我寫的那個測試程序做多次實驗，發(fā)現(xiàn)從TranslateMessage調(diào)用到最終的消息響應函數(shù)，調(diào)用堆棧很相似，（相同是調(diào)用堆棧地址的后16位，不同的是前16位），這就說明其實執(zhí)行代碼和流程固定不變的。這是時可以猜測即使不同的程序從TranslateMessage調(diào)用到最終的消息響應函數(shù)，執(zhí)行代碼和流程也應該是固定不變的。那如果是這樣我們直接找到最后誰調(diào)用我們響應函數(shù)在哪里下斷點就好了，就比如第一個圖的mfc100.dll 502CF274這個地址，我們在這個地方下斷點，端下來再直接F8就到了，

按照上面的思路，按照下面的步驟，就可以找到最終消息響應函數(shù)了，

1.在TranslateMessage上下條件斷點，[[esp+4]+4] == 0x4FF ?(消息ID)

2.找到最終調(diào)用test項目的響應函數(shù)的地方，下斷點

3.F9,直接到步驟2斷點的地方，

4.F8,到用戶區(qū)的消息響應代碼

?

如何在游戲中找到最終調(diào)用處理消息call的位置？

1.看測試項目中調(diào)用最后處理消息call的代碼，如下（來自mfc100.dll的代碼）：

5833F590 ???51 ?????????????push ecx

5833F591 ???50 ?????????????push eax

5833F592 ???8BCF ???????????mov ecx,edi

5833F594 ???FFD6 ???????????call esi ????????????????????????????????; test2.Ctest2Dlg::msg

2.把我們的有游戲加載上來，直接在mfc100.dll找“所有命令序列”，把上面的匯編指令貼進去，正好只有一個，也不用排除了，

?

?

注意：

上面的步驟，也執(zhí)行了F9,為什么沒有切換線程？應該是同線程運行比線程切換快的多的原因吧。

?

??

?

總結

以上是生活随笔為你收集整理的OD-困难重重的追踪消息断点的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。