A. 游戲封包加密方式
常見的加密演算法可以分成三類，對稱加密演算法，非對稱加密演算法和Hash演算法。對稱加密指加密和解密使用相同密鑰的加密演算法。對稱加密演算法的優點在於加解密的高速度和使用長密鑰時的難破解性。假設兩個用戶需要使用對稱加密方法加密然後交換數據，則用戶最少需要2個密鑰並交換使用，如果企業內用戶有n個，則整個企業共需要n×(n-1) 個密鑰，密鑰的生成和分發將成為企業信息部門的惡夢。對稱加密演算法的安全性取決於加密密鑰的保存情況，但要求企業中每一個持有密鑰的人都保守秘密是不可能的，他們通常會有意無意的把密鑰泄漏出去——如果一個用戶使用的密鑰被入侵者所獲得，入侵者便可以讀取該用戶密鑰加密的所有文檔，如果整個企業共用一個加密密鑰，那整個企業文檔的保密性便無從談起。常見的對稱加密演算法有DES、3DES、Blowfish、IDEA、RC4、RC5、RC6和AES非對稱加密指加密和解密使用不同密鑰的加密演算法，也稱為公私鑰加密。假設兩個用戶要加密交換數據，雙方交換公鑰，使用時一方用對方的公鑰加密，另一方即可用自己的私鑰解密。如果企業中有n個用戶，企業需要生成n對密鑰，並分發n個公鑰。由於公鑰是可以公開的，用戶只要保管好自己的私鑰即可，因此加密密鑰的分發將變得十分簡單。同時，由於每個用戶的私鑰是唯一的，其他用戶除了可以可以通過信息發送者的公鑰來驗證信息的來源是否真實，還可以確保發送者無法否認曾發送過該信息。非對稱加密的缺點是加解密速度要遠遠慢於對稱加密，在某些極端情況下，甚至能比對稱加密慢上1000倍。常見的非對稱加密演算法有：RSA、ECC（移動設備用）、Diffie-Hellman、El Gamal、DSA（數字簽名用）Hash演算法Hash演算法特別的地方在於它是一種單向演算法，用戶可以通過Hash演算法對目標信息生成一段特定長度的唯一的Hash值，卻不能通過這個Hash值重新獲得目標信息。因此Hash演算法常用在不可還原的密碼存儲、信息完整性校驗等。常見的Hash演算法有MD2、MD4、MD5、HAVAL、SHA加密演算法的效能通常可以按照演算法本身的復雜程度、密鑰長度（密鑰越長越安全）、加解密速度等來衡量。上述的演算法中，除了DES密鑰長度不夠、MD2速度較慢已逐漸被淘汰外，其他演算法仍在目前的加密系統產品中使用。
B. 怎樣利用WPE封包修改網游數據
首先我們將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"上。（對比一下很容易的，但你不能太遲鈍咯，呵呵）