本文作者：sodme
本文出處：http://blog.csdn.net/sodme
宣告：本文可以不經作者同意任意轉載、複製、傳播，但任何對本文的引用均須註明本文作者、出處及本行宣告資訊。謝謝！

　　封包分析的手段，說簡單也挺簡單的，那就是：比較！要不斷地從不同的思維角度對封包進行對比分析，要充分發揮你的想象力不斷地擷取自己需要的包進行比較。不僅要作橫向（同類）的比較，還要作縱向（不同類）的比較。即時對於同一個包，也要不斷地反覆研究。

　　初涉封包分析的新手，一般會不知道封包分析究竟該從何入手。基於經驗，本文將告訴你一般會從哪些型別的包入手進行分析以及應該怎樣對封包進行初步的分析。需要指出的是：封包分析是一件非常有趣但同時也非常考驗耐心的事，通常，半天的封包分析下來，會讓你眼前全是諸如“B0 EF 58 02 10 72....”之類的網路資料，而且附帶有頭疼、頭暈症狀，所以，沒有充分的心理準備，還請不要輕易嘗試。呵呵。

　　從事封包分析的基本前提是：應該瞭解和熟悉TCP協議，並知道資料包“粘合”是怎麼一回事。當然，我們平常截獲到的包，從數量上來看，只有一小部分是屬於“粘合”的情況。但如果不瞭解它，將可能會對你的分析思路產生誤導和困惑。關於“粘包”的更詳細解釋，請參考我的另外一篇文章“拼包函式及網路封包的異常處理(含程式碼) (http://blog.csdn.net/sodme/archive/2005/07/10/419233.aspx)”。

　　上一篇有關魔獸世界封包分析的文章（http://blog.csdn.net/sodme/archive/2005/06/18/397371.aspx）中，我根據客戶端與伺服器端連線及斷開事件的處理流程以及登入過程中的一些資料包分析了魔獸的架構和登入邏輯。這篇文章中，我將結合聊天資料包的分析，來闡述魔獸世界封包的大體結構。  

　　首先解釋一下我們的目標：封包的大體結構。封包的大體結構包含哪些內容呢？一般情況下，封包的大體結構至少包括兩方面的資訊：
　　1、一個封包是如何表示它的長度的？封包長度是由哪個欄位表示的？（或者說：如何表示封包的開始和結束的）
　　2、各種不同的封包型別是通過哪個欄位表示的？

　　是不是所有遊戲的封包都必然會有表示“長度”資訊的“欄位”呢？答案是否定的。有的遊戲確實沒有采用這種方式，它們的作法設定特殊的包開始和包結束標誌。但是，從應用的角度來看，偶推薦使用“長度”這樣的方法，因為不管在網路底層的處理效率以及上層應用的處理便捷性來說，使用“長度”欄位標識一個完整的邏輯包都是比較好的辦法。在確定了封包的大體結構後，我們才方便分析具體型別包（比如聊天、行走等）的詳細結構。

　　作資料包分析，在單純採用黑箱分析的階段，我們選取的資料包，須要是具有這種性質的，即：在資料包傳送前客戶端未進行加密等處理時，這個資料包中的部分內容，我們是已經知道的。這樣的包，就可以作為封包分析的突破口。這樣看來，我們拿“聊天封包”作為第一個分析物件也就不難理解了，因為我們說的話，打上去的字，我們自己是知道的，但是我們說的話經過客戶端的處理後，發到網路上的可能就是已經加了密的或者加了校驗碼的。站在黑箱分析的角度，我們能作的，就是不斷擷取各種“聊天包”進行對比、判斷和總結。

　　OK，開啟你的commview。讓我們從“聊天封包”開始。

　　分析“聊天包”的前提，是我們能夠正常判斷哪種型別的資料包是屬於聊天的，不要誤把行走或其它的資料包當作了聊天資料包。為了減小分析難度，建議新手到遊戲中人少或周圍沒有玩家的地方進行封包分析。這樣一來沒人打擾，二來你的網路通訊量會相對小得多，比較容易進行一些封包判定。

　　第一步，我們需要確定客戶端與伺服器通訊所用的埠，然後在commview的rules->ports中設定伺服器埠，截獲與該埠通訊的所有資料包。伺服器埠的確定方法：不要使用其它網路通訊工具，開啟commview，進遊戲，截包，觀察其通訊埠。進行封包分析時，特別是初期的封包分析時，你的網路通訊應該儘可能是單一的，即：除了遊戲，其它的通訊軟體儘可能不要開。但當你確定了伺服器的IP和埠後，就可以照常使用其它網路軟體了。

　　第二步，如前面述，在遊戲中找個人少或沒人的地方，開始“自言自語”，呵呵。說話的內容，建議以字母和數字為宜，不要說中文。因為中文是雙位元組的，而字母和數字是單位元組的，對於單位元組的資訊內容，截包軟體會以單位元組的文字資訊顯示，但對於雙位元組的漢字而言，截包軟體在對其進行顯示時由於換行等原因會造成部分中文顯示有亂碼，不容易直接看出中文內容。如果執意要說中文，偶也不攔你，給你推薦一個工具：String Demander(下載地址：http://www.cnxhacker.com/Download/show/395.html)，這個軟體，可以查詢中文所對應的編碼。

　　第三步，設定好commview的rules並使之生效，開始截包。

　　觀察通過以上的過程所截的包，可以發現，魔獸世界的聊天封包的說話內容是明文的！這一點，用不著大驚小怪，呵呵。聊天封包本身並不會對遊戲的關鍵邏輯造成損害，所以，即使讓其明文顯示也不足為奇。但是，我們還是不太相信自己的眼睛，於是再截若干個包，發現包中的說話內容確實是明文的！但是，包的其它欄位卻是我們一時看不懂的“密文”。

　　看來，下面的事情就是對這些包裡的“密文”進行研究了。一般情況下，這種“密文”的加密方法，通過封包分析是分析不出來的，但，我們仍然可以通過封包分析來推論一些與“密文”生成演算法有關的問題。我們可以作以下的對比分析：
　　1、連續三次輸入“a”，並分別觀察及儲存封包資料；
　　2、連續三次輸入“aa”，並分別觀察及儲存封包資料；
　　3、連續三次輸入“aaa”，並分別觀察及儲存封包資料。

　　輸入的封包用例，我們選擇了字母"a"，它的ASCII碼是61。輸入的規律是：每種情況連續輸入三次，然後逐次增加a字母的個數。於是，我們發現這樣一個有趣的現象：
　　1、包中有關說話的內容是明文的；
　　2、即使針對於同樣的說話內容，比如“a”，客戶端所發出去的包也是不一樣的；
　　3、當一次說話的字母個數增加1時，封包的總體長度也隨之增加1；
　　4、除每個封包的前面6個位元組以及說話的位元組外，其餘的封包內容每次都一樣；
　　5、每個聊天封包的結尾位元組都是0。

　　於是，我們可以試著得出如下結論：
　　1、包是沒有壓縮的，它所使用的加密演算法應該是按位元組進行的，並沒有改變封包的長度使之看上去使用統一的長度；
　　2、包是以0結尾的（儘管我們不知道它是以什麼表示開頭的，呵呵）；
　　3、封包加密演算法中所使用的金鑰是可變的，即針對於相同的資料包內容由於加密的金鑰不同，所以產生的密文也不同。由於客戶端的資料傳到伺服器端後，伺服器端還要對資料進行解密。所以，客戶端的加密演算法與伺服器端的解密演算法應該共用了前6位元組中的某些內容，以此作為解密演算法的金鑰。如果這6位元組中沒有包含有關封包加、解密所需要的同步資料，那客戶端和伺服器之間應該會通過其它的方式同步這樣的資料。不過，偶傾向於前者，即：這6位元組中應該含有加、解密所需要的金鑰資訊。

　　回頭看我們上面觀察到的有趣現象，針對於第2點，反過來想，這應該也是最起碼的功能了。就是說，即使客戶端作出的是同樣的動作，在客戶端發出的包中，包的內容也是不一樣的。這樣，外掛就不能靠單純的重複發相同的包而達到其目的了。

　　分析來分析去，我們還是沒能確定魔獸封包的大體結構。其實，到現在，我覺得我此文的目的已經達到了，即向大家展示封包分析的思維角度和思維方式。至於具體結果，偶覺得倒真的不重要的了。可以肯定地告訴大家的是，魔獸的封包結構偶大致已經掌握了。偶僅在此公佈我的分析結果：
　　1、魔獸的封包長度欄位是每個封包的前兩位元組，它的表示方式是：前兩位元組的數值＋2。之所以加這個2，是因為封包長度欄位本身佔用了兩個位元組的長度。
　　2、魔獸的封包型別偶推斷是第三和第四位元組，其中普通聊天的型別標識是“95 00”。

　　請不要來信向我詢問任何有關魔獸封包破解的內容，偶能說的都已經在文章裡說了，偶之所以寫這個系列的文章不是想破解魔獸，而是想以這樣優秀的一款遊戲作為案例來向大家展示它在封包設計方面值得我們學習和討論的地方，同時向更多的朋友普及有關封包分析的常識、工具以及思維方式，僅此而已。

　　ps:由於每次封包分析的內容都很多，所以，一有了點結論後，要及時記錄和總結，並與之前取得的總結進行對比，及時更新相關的記錄文件。