本文作者：sodme
本文出處：http://blog.csdn.net/sodme
聲明：本文可以不經作者同意任意轉載，但任何對本文的引用都須注明作者、出處及此聲明信息。謝謝！！

　　特別聲明：
　　本人非常欣賞暴雪及他們的游戲，之所以寫這個文章，是想讓大家了解一些網絡封包分析方面的常見方法以及學習暴雪游戲在網 絡處理方面的經驗，偶認為作為一個網絡編程者，熟練掌握封包分析的工具和方法應該是其基本功之一。本文所列的所有封包分析內容，全部是采用普通黑箱方式即 可得來的，并未涉及對魔獸世界可執行程序的逆向工程。同時，除此文涉及的內容外，本人拒絕向任何人透露更詳細的關于魔獸世界封包方面的更多內容，有興趣者 請自己進行相關的試驗，本人在此文中也將盡量避免公開敏感的封包內容及相關加解密算法。謹以此文獻給忠愛的暴雪！

　　一、登錄模塊流程及封包分析

　　我們先看登錄流程。從封包流程來看，魔獸的登錄流程是這樣的：

　　1.由 Client向登錄/賬號服務器(Login Server)發送用戶名及密碼等信息。此數據包的最后部分是用戶名(明文表示，未加密)，在用戶名的前一個字節表示的是用戶名的長度。登錄/賬號服務器 向Client返回登錄成功及后續連接到游戲服務器服務器所必備的信息等。這中間的兩個來往數據包，我還沒有看出具體有什么作用。在這個交互過程中，由登 錄/賬號服務器向Client發送所有的游戲服務器列表，服務器列表數據包的內容包括：ip, port, 服務器上所擁有的角色個數等信息，因服務器列表內容過多，被客戶端分為兩次接收完畢。

　　2.Client收到Login Server的服務器列表后，根據最近訪問的服務器標識(這個信息應該是包含在那個服務器列表數據包中)，連接到最近游戲的那個游戲服務器(Game Server)。連接成功后，Game Server首先向Client發送一個8字節的數據包，據以往的常識判斷，這個數據包的內容很可能是以后客戶端與服務器通信的加密密鑰。

3.Client向Game Server再次發送自己的賬號信息。Game Server與Client經過兩個數據包的交互后，向Client發送角色數據包，此包中包括了玩家在該Game Server所創建的所有角色信息，當然這個信息只是部分的，并不是該角色的所有信息。

　　4.在此后的通信過程中，Client每隔30秒向Game Server發送一個保持連接的包，該包長度為10字節，包的最后四字節是一個遞增數字，前面6字節暫時未看出規律。

5.只要Client沒有點擊某個角色進入最終的Game Server，則Client要始終與Login Server保持連接。當Client點擊角色進入Game Server時，Client才與Login Server斷開連接。在以后的游戲過程中，Client始終與且僅與該Game Server進行數據通信。

　　通過對登錄流程中的數據包初步分析，可以得出以下幾個結論：
　　1.Client向Login Server發的第一個數據包，用戶名部分是采用明文的，且該數據包的內容，每次登錄都一樣，并沒有因時間的不同而發生改變。由此可以推算：針對于此數據 包中的密碼加密算法是固定不變的，換句話說，密碼的加密算法是比較容易通過逆向工程被找到的。偶認為，針對于此處，服務器也應該先向客戶端發送一個加密密 鑰，以后的通信可以用該密鑰作為安全驗證的依據。但暴雪沒有這樣作，最大的可能是為了提高服務器的效率，在登錄服務器上，如果每個客戶端一旦連接成功，登 錄服務器都得向客戶端廣播一個數據包的話，可能這個量還是比較大的，這可能延長了玩家的登錄等待時間，所以他們沒有在這塊作。

2.Client在登錄Login Server的地址，每次Login Server的登錄地址都可能是不一樣的。偶沒有在客戶端目錄里找到這些地址，只在客戶端目錄里找到了四個大區的四個域名，我猜想，魔獸世界是用的DNS 解析的簡單方法來實現Login Server的簡單動態均衡的。不知道這個猜想是否正確。

　　3.“根據玩家最近在玩的哪個游戲，由客戶端和服務器自動為玩家選擇進入這個游戲服務器”，這一項設定充分體現了暴雪一貫的風格：為玩家著想，最大限度地提高游戲的舒適度。再次對暴雪的態度予以肯定！

　　4.一旦玩家進入了游戲世界，客戶端與服務器的通信端口會一直保持不變。即：魔獸世界的游戲世界服務器群設計結構采用的是帶網關的服務器集群。

5.偶覺得在整個的登錄流程中，讓我產生最大疑問的就是Login Server與Client的連接保持邏輯。當Client與Game Server連接了之后，Client并未與Login Server斷開，是一直保持連接的。后來，經進一步的抓包分析，Client之所以要與Login Server保持這樣的連接，是為了當Client重新選擇服務器時，不至于重新連接Login Server。當Client點擊了"選擇服務器"按紐后，Login Server會每隔5秒向Client發一個當前所有的服務器列表數據包。要知道，這個服務器列表數據包的內容可是非常大的，如果有玩家就打開了這個窗口 不關閉，Login Server向這種情況的所有玩家每5秒鐘就發一個服務器列表數據包，這個廣播量可是很大的哦(2k左右，這可是一個用戶是2k哦)。偶認為這里的邏輯設 計是相當不合理的。Login Server如果為了給客戶端提供一個最新的全局服務器列表，可以保持連接，但也沒必要每隔5秒就向客戶端發一個服務器列表，最多只在客戶端在某個服務器 上創建了不同的角色后再更新這個列表也是可以的，但只用更新這個列表中的變化內容即可，不用發全部的完整包，這樣，在通信量上就小了很多。據說，魔獸剛開 始的時候，產生DOWN機的原因就是登錄模塊沒有處理好，偶不知道現在的這個情況是不是已經經過改良的了。但偶還是認為每隔5秒就向客戶端發送一個2K的 包，這一點是不可以被接受的。

　　以上只是針對于魔獸世界登錄流程的簡單分析，沒有多少技術含量，拿出來跟大家相互討論討論，看看有沒有可以借鑒的地方，后面還會有其它部分的封包分析。歡迎繼續關注偶的Blog: http://blog.csdn.net/sodme。

　　偶在文章前面部分說過，作為一個網絡編程人員，熟練使用截包軟件和掌握基本的封包分析方法是其基本能力之一，發此文的目的一個原因也是希望向正在作網絡編程的兄弟介紹一下相關工具的使用和常見的分析方法。下面補充一下關于封包分析的基本方法和相關工具：

　　1.你需要一個截包工具，偶推薦：commview，小巧但功能強大，支持自定義的封包分析插件以DLL形式裝載，也就是說只要你愿意，你可以寫個DLL對某類特殊形式的包進行顯示、記錄、解密等特別處理。

2.如何查看真正的封包數據。在commview里，會詳細列出自網卡級別以上的各層封包數據，包括Ethernet層，IP層和TCP層。而我們作封 包分析時，只需要關注TCP層。但TCP層里也有很多內容，對于我們的分析需求來說，我們需要關注的是其Data字段（在協議目錄里可以看到"data length標識，點擊即可查看data段"）的內容。

　　3.TCP的幾個狀態對于我們分析所起的作用。在TCP層，有個FLAGS字 段，這個字段有以下幾個標識：SYN, FIN, ACK, PSH, RST, URG.其中，對于我們日常的分析有用的就是前面的五個字段。它們的含義是：SYN表示建立連接，FIN表示關閉連接，ACK表示響應，PSH表示有 DATA數據傳輸，RST表示連接重置。其中，ACK是可能與SYN，FIN等同時使用的，比如SYN和ACK可能同時為1，它表示的就是建立連接之后的 響應，如果只是單個的一個SYN，它表示的只是建立連接。TCP的幾次握手就是通過這樣的ACK表現出來的。但SYN與FIN是不會同時為1的，因為前者 表示的是建立連接，而后者表示的是斷開連接。RST一般是在FIN之后才會出現為1的情況，表示的是連接重置。一般地，當出現FIN包或RST包時，我們 便認為客戶端與服務器端斷開了連接；而當出現SYN和SYN＋ACK包時，我們認為客戶端與服務器建立了一個連接。PSH為1的情況，一般只出現在 DATA內容不為0的包中，也就是說PSH為1表示的是有真正的TCP數據包內容被傳遞。TCP的連接建立和連接關閉，都是通過請求－響應的模式完成的。

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

　　初涉封包分析的新手，一般會不知道封包分析究竟該從何入手。基于經驗，本文將告訴你一般會從哪些類型的包入手進行分析以及應該怎樣對封包進行初 步的分析。需要指出的是：封包分析是一件非常有趣但同時也非常考驗耐心的事，通常，半天的封包分析下來，會讓你眼前全是諸如“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:由于每次封包分析的內容都很多，所以，一有了點結論后，要及時記錄和總結，并與之前取得的總結進行對比，及時更新相關的記錄文檔。