三：怎麼來分析我們截獲的封包？
首先我們將WPE截獲的封包儲存為文本文件，然後開啟它，這時會看到如下的資料（這裡我們以金庸群俠傳裡PK店小二客戶端傳送的資料為例來講解）：
第一個文件： SEND-> 0000 E6 56 0D 22 7E 6B E4 17 13 13 12 13 12 13 67 1B SEND-> 0010 17 12 DD 34 12 12 12 12 17 12 0E 12 12 12 9B SEND-> 0000 E6 56 1E F1 29 06 17 12 3B 0E 17 1A SEND-> 0000 E6 56 1B C0 68 12 12 12 5A SEND-> 0000 E6 56 02 C8 13 C9 7E 6B E4 17 10 35 27 13 12 12 SEND-> 0000 E6 56 17 C9 12
第二個文件： SEND-> 0000 83 33 68 47 1B 0E 81 72 76 76 77 76 77 76 02 7E SEND-> 0010 72 77 07 1C 77 77 77 77 72 77 72 77 77 77 6D SEND-> 0000 83 33 7B 94 4C 63 72 77 5E 6B 72 F3 SEND-> 0000 83 33 7E A5 21 77 77 77 3F SEND-> 0000 83 33 67 AD 76 CF 1B 0E 81 72 75 50 42 76 77 77 SEND-> 0000 83 33 72 AC 77
我們發現兩次PK店小二的資料格式一樣，但是內容卻不相同，我們是PK的同一個NPC，為什麼會不同呢？ 原來金庸群俠傳的封包是經過了加密運算才在網路上傳輸的，那麼我們面臨的問題就是如何將密文解密成明文再分析了。
因為一般的資料包加密都是異或運算，所以這裡先講一下什麼是異或。 簡單的說，異或就是"相同為0，不同為1"（這是針對二進制按位來講的），舉個例子，0001和0010異或，我們按位對比，得到異或結果是0011，計算的方法是：
0001的第4位為0，0010的第4位為0，它們相同，則異或結果的第4位按照"相同為0，不同為1"的原則得到0，0001的第3位為0，0010的第3位為0，則異或結果的第3位得到0，0001的第2位為0，0010的第2位為1，則異或結果的第2位得到1，0001的第1位為1，0010的第1位為0，則異或結果的第1位得到1，組合起來就是0011。異或運算今後會遇到很多，大家可以先熟悉熟悉，熟練了對分析很有說明 的。
下面我們繼續看看上面的兩個文件，按照常理，資料包的資料不會全部都有值的，遊戲開發時會預留一些字元空間來便於日後的擴充，也就是說資料包裡會存在一些"00"的字元，觀察上面的文件，我們會發現文件一里很多"12"，文件二里很多"77"，那麼這是不是代表我們說的"00"呢？推理到這裡，我們就開始行動吧！
我們把文件一與"12"異或，文件二與"77"異或，當然用手算很費事，我們使用"M2M 1.0 加密封包分析工具"來計算就方便多了。得到下面的結果：
第一個文件： 1 SEND-> 0000 F4 44 1F 30 6C 79 F6 05 01 01 00 01 00 01 75 09 SEND-> 0010 05 00 CF 26 00 00 00 00 05 00 1C 00 00 00 89 2 SEND-> 0000 F4 44 0C E3 3B 13 05 00 29 1C 05 08 3 SEND-> 0000 F4 44 09 D2 7A 00 00 00 48 4 SEND-> 0000 F4 44 10 DA 01 DB 6C 79 F6 05 02 27 35 01 00 00 5 SEND-> 0000 F4 44 05 DB 00
第二個文件： 1 SEND-> 0000 F4 44 1F 30 6C 79 F6 05 01 01 00 01 00 01 75 09 SEND-> 0010 05 00 70 6B 00 00 00 00 05 00 05 00 00 00 1A 2 SEND-> 0000 F4 44 0C E3 3B 13 05 00 29 1C 05 84 3 SEND-> 0000 F4 44 09 D2 56 00 00 00 48 4 SEND-> 0000 F4 44 10 DA 01 B8 6C 79 F6 05 02 27 35 01 00 00 5 SEND-> 0000 F4 44 05 DB 00
哈，這一下兩個文件大部分都一樣啦，說明我們的推理是正確的，上面就是我們需要的明文！
接下來就是搞清楚一些關鍵的字元所代表的含義，這就需要截獲大量的資料來分析。
首先我們會發現每個資料包都是"F4 44"開頭，第3個字元是變化的，但是變化很有規律。我們來看看各個包的長度，發現什麼沒有？
對了，第3個字元就是包的長度！ 通過截獲大量的資料包，我們判斷第4個字元代表指令，也就是說客戶端告訴伺服器進行的是什麼操作。
例如向伺服器請求戰鬥指令為"30"，戰鬥中移動指令為"D4"等。 接下來，我們就需要分析一下上面第一個包"F4 44 1F 30 6C 79 F6 05 01 01 00 01 00 01 75 09 05 00 CF 26 00 00 00 00 05 00 1C 00 00 00 89"，在這個包裡包含什麼訊息呢？
應該有通知伺服器你PK的哪個NPC吧，我們就先來找找這個店小二的程式碼在什麼地方。 我們再PK一個小嘍囉（就是大理客棧外的那個咯）： SEND-> 0000 F4 44 1F 30 D4 75 F6 05 01 01 00 01 00 01 75 09 SEND-> 0010 05 00 8A 19 00 00 00 00 11 00 02 00 00 00 C0 我們根據常理分析，遊戲裡的NPC種類雖然不會超過65535（FFFF），但開發時不會把自己限制在字的範圍，那樣不利於遊戲的擴充，所以我們在雙字裡看看。
通過"店小二"和"小嘍囉"兩個包的對比，我們把目標放在"6C 79 F6 05"和"CF 26 00 00"上。
（對比一下很容易的，但你不能太遲鈍咯，呵呵）我們再看看後面的包，在後面的包裡應該還會出現NPC的程式碼，比如移動的包，遊戲允許觀戰，伺服器必然需要知道NPC的移動坐標，再廣播給觀戰的其他玩家。
在後面第4個包"SEND-> 0000 F4 44 10 DA 01 DB 6C 79 F6 05 02 27 35 01 00 00"裡我們又看到了"6C 79 F6 05"，初步斷定店小二的程式碼就是它了！ （這分析裡邊包含了很多工作的，大家可以用WPE截下資料來自己分析分析）
第一個包的分析暫時就到這裡（裡面還有的訊息我們暫時不需要完全清楚了）
我們看看第4個包"SEND-> 0000 F4 44 10 DA 01 DB 6C 79 F6 05 02 27 35 01 00 00"，再截獲PK黃狗的包，（狗會出來2只哦）看看包的格式： SEND-> 0000 F4 44 1A DA 02 0B 4B 7D F6 05 02 27 35 01 00 00 SEND-> 0010 EB 03 F8 05 02 27 36 01 00 00
根據上面的分析，黃狗的程式碼為"4B 7D F6 05"（100040011），不過兩隻黃狗伺服器怎樣分辨呢？看看"EB 03 F8 05"（100140011），是上一個程式碼加上100000，呵呵，這樣伺服器就可以認出兩隻黃狗了。我們再通過野外遇敵截獲的資料包來證實，果然如此。
那麼，這個包的格式應該比較清楚了：
第3個字元為包的長度，"DA"為指令，第灌水限制節為NPC個數，從第7個字元開始的10個字元代表一個NPC的訊息，多一個NPC就多10個字元來表示。
大家如果玩過網金，必然知道隨機遇敵有時會出現增援，我們就利用遊戲這個增援來讓每次戰鬥都會出現增援的NPC吧。
通過在戰鬥中出現增援截獲的資料包，我們會發現伺服器端傳送了這樣一個包：
F4 44 12 E9 EB 03 F8 05 02 00 00 03 00 00 00 00 00 00 第5-第8個字元為增援NPC的程式碼（這裡我們就簡單的以黃狗的程式碼來舉例）。 那麼，我們就利用單機代理技術來同時欺騙客戶端和伺服器吧！
好了，呼叫NPC的工作到這裡算是完成了一小半，接下來的事情，怎樣修改封包和傳送封包，我們下節繼續講解吧。
|