網路遊戲外掛編寫基顧（2）

　　 三：怎麼來分析我們截獲的封包？

　　首先我們將WPE截獲的封包儲存為文字檔，然後開啟它，這時會看到如下的資料（這裡我們以金庸群俠傳裡PK店小二用戶端發送的資料為例來講解）：

　　第一個檔案：SEND-> 0000 E6 56 0D 22 7E 6B E4 17 13 13 12 13 12 13 67 1BSEND-> 0010 17 12 DD 34 12 12 12 12 17 12 0E 12 12 12 9BSEND-> 0000 E6 56 1E F1 29 06 17 12 3B 0E 17 1ASEND-> 0000 E6 56 1B C0 68 12 12 12 5ASEND-> 0000 E6 56 02 C8 13 C9 7E 6B E4 17 10 35 27 13 12 12SEND-> 0000 E6 56 17 C9 12

　　第二個檔案：SEND-> 0000 83 33 68 47 1B 0E 81 72 76 76 77 76 77 76 02 7ESEND-> 0010 72 77 07 1C 77 77 77 77 72 77 72 77 77 77 6DSEND-> 0000 83 33 7B 94 4C 63 72 77 5E 6B 72 F3SEND-> 0000 83 33 7E A5 21 77 77 77 3FSEND-> 0000 83 33 67 AD 76 CF 1B 0E 81 72 75 50 42 76 77 77SEND-> 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 09SEND-> 0010 05 00 CF 26 00 00 00 00 05 00 1C 00 00 00 892 SEND-> 0000 F4 44 0C E3 3B 13 05 00 29 1C 05 083 SEND-> 0000 F4 44 09 D2 7A 00 00 00 484 SEND-> 0000 F4 44 10 DA 01 DB 6C 79 F6 05 02 27 35 01 00 005 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 09SEND-> 0010 05 00 70 6B 00 00 00 00 05 00 05 00 00 00 1A2 SEND-> 0000 F4 44 0C E3 3B 13 05 00 29 1C 05 843 SEND-> 0000 F4 44 09 D2 56 00 00 00 484 SEND-> 0000 F4 44 10 DA 01 B8 6C 79 F6 05 02 27 35 01 00 005 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 09SEND-> 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 00SEND-> 0010 EB 03 F8 05 02 27 36 01 00 00

　　根據上面的分析，黃狗的代碼為"4B 7D F6 05"（100040011），不過兩隻黃狗伺服器怎樣分辨呢？看看"EB 03 F8 05"（100140011），是上一個代碼加上100000，呵呵，這樣伺服器就可以認出兩隻黃狗了。我們再通過野外遇敵截獲的資料包來證實，果然如此。

　　那麼，這個包的格式應該比較清楚了：第3個位元組為包的長度，"DA"為指令，第5個位元組為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的工作到這裡算是完成了一小半，接下來的事情，怎樣修改封包和發送封包，我們下節繼續講解吧。
　　四：怎麼冒充"用戶端"向"伺服器"發我們需要的封包？

　　這裡我們需要使用一個工具，它位於用戶端和伺服器端之間，它的工作就是進行資料包的接收和轉寄，這個工具我們稱為代理。如果代理的工作單純就是接收和轉寄的話，這就毫無意義了，但是請注意：所有的資料包都要通過它來傳輸，這裡的意義就重大了。我們可以分析接收到的資料包，或者直接轉寄，或者修改後轉寄，或者壓住不轉寄，甚至偽造我們需要的封包來發送。

　　下面我們繼續講怎樣來同時欺騙伺服器和用戶端，也就是修改封包和偽造封包。 通過我們上節的分析，我們已經知道了打多個NPC的封包格式，那麼我們就動手吧！

　　首先我們要尋找用戶端發送的包，找到戰鬥的特徵，就是請求戰鬥的第1個包，我們找"F4 44 1F 30"這個特徵，這是不會改變的，當然是要解密後來尋找哦。 找到後，表示用戶端在向伺服器請求戰鬥，我們不動這個包，轉寄。 繼續向下尋找，這時需要尋找的特徵碼不太好辦，我們先尋找"DA"，這是用戶端發送NPC資訊的資料包的指令，那麼可能其他包也有"DA"，沒關係，我們看前3個位元組有沒有"F4 44"就行了。找到後，我們的工作就開始了！

　　我們確定要打的NPC數量。這個數量不能很大，原因在於網金的封包長度用一個位元組表示，那麼一個包可以有255個位元組，我們上面分析過，增加一個NPC要增加10個位元組，所以大家算算就知道，打20個NPC比較合適。

　　然後我們要把用戶端原來的NPC程式碼分析計算出來，因為增加的NPC代碼要加上100000哦。再把我們增加的NPC代碼計算出來，並且組合成新的封包，注意代表包長度的位元組要修改啊，然後轉寄到伺服器，這一步在編寫程式的時候要注意演算法，不要造成較大延遲。

　　上面我們欺騙伺服器端完成了，欺騙用戶端就簡單了。

　　發送了上面的封包後，我們根據新增NPC代碼構造封包馬上發給用戶端，格式就是"F4 44 12 E9 NPC代碼 02 00 00 03 00 00 00 00 00 00",把每個新增的NPC都構造這樣一個包，按順序連在一起發送給用戶端，用戶端也就被我們騙過了，很簡單吧。

　　以後戰鬥中其他的事我們就不管了，盡情地開打吧。