在對一款遊戲的數據分析中,明文封包的重要地位是無可取代的,準確的發送封包可以讓我們在實現功能時避免很多風險與麻煩。比如,我們可以節省大量的功能函數的參數分析與特徵定位,也可以跳過大量中間函數的判斷,直接實現功能,甚至可以實現很多普通玩家無法做到的特殊功能。
然而,這一切都是建立在「準備」這兩個字上面的,如果胡亂的使用封包,或者某些結構數據沒有分析完全,很有可能會讓事情變糟,掉線,崩潰,甚至封號等等。
準確的分析封包,不只限於對單個封包的結構進行分析,因為很多功能並不單一封包可以實現的,如果不能將所有相關的封包一一發送,也許無法實現某些功能,甚至可能會在「漏發」之後出現一些未知的錯誤。下面我們對一款本地架設的遊戲封包進行分析。
我們先調到明文封包的位置,分析一個最簡單的打開NPC。
圖中是最外層明文包頭部地址,之前的線程發包分析過程我們就不做講解了。
我們在這個頭部下斷,並打開NPC,遊戲會斷下
返回後重新下斷,對結構體進行分析
這款遊戲有一個特點,就是我們需要通過遊戲自帶的函數申請內存,才可以對明文CALL進行調用,否則遊戲就會崩潰,雖然功能也會實現。
申請結構體之後會在下面的函數中進行組包
根據組包函數的參數可以分析出我們只需要傳入一個NPCID即可
那麼我們通過代碼注入器來對這個封包進行發送
發送之後遊戲沒有反應,NPC並沒有打開。多次嘗試之後依然如此。這說明我們找的封包並不是打開NPC的。相信很多人已經想到問題所在了,再打開NPC之前,有一個前置封包對我們進行了幹擾,而這個封包就是選中NPC。而遊戲中沒有反應的原因是因為選中NPC的本地效果在外層,所以並沒有顯示出來。
那麼我們通過左鍵先選中NPC,然後再次點擊左鍵打開,這時遊戲會斷到一個新的返回地址。
這個函數和選中NPC唯一不同的地址就是組包函數的地址,那麼我們修改之後再次調用
打開NPC成功了
以上的問題常常會對萌新造成一些麻煩,但是注意一些還是可以避免的。
單個的功能實現比較簡單,但是如果我們將這些封包以一定的邏輯組合起來,編成一個腳本的話,會發現可能會出現一些未知的錯誤。
比如,我們發送以下連續封包打開NPC----交任務----接任務
這時就會發現,接受任務無法成功
這時如果手動打開NPC也無法打開NPC,以及接受任務。
這說明我們在這個過程中忽略一些東西,而出現這種問題的主要原因是我們通過函數頭部下斷去分析封包很麻煩,各種跟包和心跳會影響我們的判斷。
想要避免這種問題的出現,我們就需要對明文封包進行HOOK,通過調試輸出對發包流程進行觀察。
由於外層函數HOOK起來比較麻煩,而且還需要調用遊戲自帶的申請內存。所以我們在內層尋找一個比較合適的地方進行HOOK,並分析了加密函數,自我實現send發包。
具體的分析過程略過,感興趣的話可以通過相關課程進行了解。
接著上面繼續分析,由於提交任務是成功的,但是接受任務失敗了,所以我們主要對提交任務的封包進行觀察
在提交任務後,我們得到了這些封包,第一個包很明顯是交任務包,第二個包則是打開NPC,
單獨調用打開NPC,會跟著輸出一個包
單獨發送一次交任務包,會跟出另外兩個包
那麼也就是說我們在提交任務之後,需要再次發送一個打開NPC包,這樣才能夠繼續接受任務。
下面做一個連續測試,打開NPC----交任務----打開NPC----接任務
接受任務成功,說明我們的分析是沒有問題的。
以上就是我們對封包實現功能的分析過程,在這個過程中,HOOK封包使我們的分析簡單多了很多,雖然通過OD去逐條分析每一個訪問也可以達到效果,但是很明顯會麻煩很多。
本文中的實例都是比較簡單的,還有很多遊戲的封包比這個要麻煩很多,不過分析的方法是沒有區別的。如果有什麼意見和疑問,請關注相關群和課程,大家共同探討。
喜訊!2020年度第七期實地課程報名了!
知識改變命運,改變未來!
報名掃描下方二維碼