封包加密解密

1、封包加密解密-01 網(wǎng)絡游戲客戶端與服務器之間需要數(shù)據(jù)交換處理,數(shù)據(jù)包通過TCP網(wǎng)絡協(xié)議進行傳送,這里我們稱數(shù)據(jù)包為封包.之前有教程介紹了如何使用模塊中的功能進行封包攔截,修改,替換等功能.本章將完全講解如何對封包的加密,解密技術. 為什么需要解密封包呢?除非那些封包是明文的(即沒有加密處理過),否則就得解密,只有解密出來了數(shù)據(jù),才能更清楚的了解游戲是如何交換數(shù)據(jù)處理,分析出封包數(shù)據(jù)才能夠做出脫機外掛,完全脫離游戲客戶端,模擬一個客戶端來與游戲服務器連接,做你一切想做的事都沒問題.所以封包加密解密技術是脫機外掛的第一前提條件.即使不做脫機外掛,封包技術仍然比CALL技術更有用處.學過前章后大家

2、應該也知道分析CALL,找CALL,調CALL都不是件容易的事.若能完全解密封包就可以減少或不需要CALL,模擬,內存操作了. 有加密就得有解密,有解密當然要有加密.這是相對立的.對封包數(shù)據(jù)進行加密與解密的函數(shù)過程,稱為算法.那封包加密解密技術容易嗎?比較諷刺的就是,90%以上的網(wǎng)絡游戲的封包都是很容易搞定了.為什么呢?如果算法復雜了的話,會多占CPU性能,而游戲服務器要處理的工作很多,不能把性能全用在加密解密上.舉個簡單的例子,游戲服務器若同時連接在線的玩家有十萬人的話,這些玩家在聊天,打怪,走路等都會產生封包,若算法過于復雜,服務器就很難同時處理得了這么多玩家的封包,何況還得處理數(shù)據(jù)庫中的

3、數(shù)據(jù)呢.出于服務器的性能考慮,所以若想同時能在線更多玩家,就不能進行復雜的算法來加密封包.不然就得限制減少能同時在線的玩家,不然游戲服務器會一卡一卡的,導致所有玩家都玩起來.而還有很多的游戲在設計時,為了減少服務器的負擔,不但算法簡單,還放松了很多的一些數(shù)據(jù)驗證處理.最終漏洞百出,以致于產生了全屏吸怪,穿墻,復制,無敵等等各種變態(tài)外掛. 基本上游戲的加密解密算法,都是采用簡單的位運算.位就是比特位,簡單的說,只是二進制數(shù)據(jù)運算處理罷了.所以有必要了解一些常見的位運算匯編指令.在匯編那章的指令那節(jié),有過一些指令的介紹,這里再介紹一下幾個重中之重的指令.一加減指令 加法指令 ADD (ADD Bi

4、nary Numbers Instruction) 指令的格式：ADD 寄存器/內存地址, 寄存器/內存地址/立即數(shù) 受影響的標志位：AF、CF、OF、PF、SF和ZF 指令的功能是把源操作數(shù)的值加到目的操作數(shù)中。 加1指令 INC (Increment by 1 Instruction) 指令的格式：INC 寄存器/內存地址 受影響的標志位：AF、OF、PF、SF和ZF，不影響CF指令的功能是把操作數(shù)的值加1。 減法指令 SUB (Subtract Binary Values Instruction)指令的格式：SUB 寄存器/內存地址, 寄存器/內存地址/立即數(shù) 受影響的標志位：AF、CF

5、、OF、PF、SF和ZF指令的功能是從目的操作數(shù)中減去源操作數(shù)。 減1指令 DEC (Decrement by 1 Instruction)指令的格式：DEC 寄存器/內存地址 受影響的標志位：AF、OF、PF、SF和ZF，不影響CF指令的功能是把操作數(shù)的值減去1。二、乘法指令計算機的乘法指令分為無符號乘法指令和有符號乘法指令，它們的唯一區(qū)別就在于：數(shù)據(jù)的最高位是作為“數(shù)值”參與運算，還是作為“符號位”參與運算。乘法指令的被乘數(shù)都是隱含操作數(shù)，乘數(shù)在指令中顯式地寫出來。 CPU 會根據(jù)乘數(shù)是8位、16位，還是32位操作數(shù)，來自動選用被乘數(shù)： AL 、 AX 或 EAX 。指令的功能是把顯式操作

6、數(shù)和隱含操作數(shù)相乘，并把乘積存入相應的寄存器中。 無符號數(shù)乘法指令 MUL (Unsigned Multiply Instruction)指令的格式：MUL 寄存器/內存地址 受影響的標志位：CF和OF(AF、PF、SF和ZF無定義)指令的功能是把顯式操作數(shù)和隱含操作數(shù)(都作為無符號數(shù))相乘，所得的乘積按下表的對應關系存放。下表乘法指令中乘數(shù)、被乘數(shù)和乘積的對應關系乘數(shù)位數(shù)隱含的被乘數(shù)乘積的存放位置舉例8位ALAXMUL BL16位AXDX-AXMUL BX32位EAXEDX-EAXMUL ECX（圖5.2） 有符號數(shù)乘法指令 IMUL (Signed Integer Multiply Ins

7、truction)指令的格式：IMUL寄存器/內存地址該指令的功能是把顯式操作數(shù)和隱含操作數(shù)相乘，所得的乘積按表5.2的對應關系存放。IMUL寄存器, 立即數(shù)其寄存器必須是16位/32位通用寄存器，其計算方式為：寄存器 寄存器 × 立即數(shù)IMUL寄存器, 寄存器, 立即數(shù)其寄存器只能是16位通用寄存器，其計算方式為：寄存器 1 寄存器 2 ×立即數(shù) 或 寄存器 1 內存地址×立即數(shù)IMUL寄存器, 寄存器/內存地址其寄存器必須是16位/32位通用寄存器，其計算方式為：寄存器 1 寄存器 1 ×寄存器 2 或寄存器 1 寄存器 1 ×內存地址受影

8、響的標志位：CF和OF(AF、PF、SF和ZF無定義)在指令格式24中，各操作數(shù)的位數(shù)要一致。如果乘積超過目標寄存器所能存儲的范圍，則系統(tǒng)將置溢出標志OF為1。三、除法指令除法指令的被除數(shù)是隱含操作數(shù)，除數(shù)在指令中顯式地寫出來。 CPU 會根據(jù)除數(shù)是8位、16位，還是32位，來自動選用被除數(shù) AX 、 DX-AX ，還是 EDX-EAX 。除法指令功能是用顯式操作數(shù)去除隱含操作數(shù)，可得到商和余數(shù)。當除數(shù)為0，或商超出數(shù)據(jù)類型所能表示的范圍時，系統(tǒng)會自動產生0號中斷。 無符號數(shù)除法指令 DIV (Unsigned Divide Instruction)指令的格式：DIV 寄存器/內存地址 指令的

9、功能是用顯式操作數(shù)去除隱含操作數(shù)(都作為無符號數(shù))，所得商和余數(shù)按下表的對應關系存放。指令對標志位的影響無定義。 有符號數(shù)除法指令 IDIV (Signed Integer Divide Instruction)指令的格式：IDIV 寄存器/內存地址 受影響的標志位：AF、CF、OF、PF、SF和ZF指令的功能是用顯式操作數(shù)去除隱含操作數(shù)(都作為有符號數(shù))，所得商和余數(shù)的對應關系見表。下面表除法指令除數(shù)、被除數(shù)、商和余數(shù)的對應關系除數(shù)位數(shù)隱含的被除數(shù)商余數(shù)舉例8位AXALAHDIV BH16位DX-AXAXDXDIV BX32位EDX-EAXEAXEDXDIV ECX四、邏輯運算指令邏輯運算指

10、令是另一組重要的指令，它包括：邏輯與( AND )、邏輯或( OR )、邏輯非( NOT )和異或指令( XOR )，邏輯運算指令也是經常使用的指令。1、邏輯與操作指令AND(Logical AND Instruction)指令的格式：AND寄存器/內存地址, 寄存器/內存地址/立即數(shù) 受影響的標志位：CF(0)、OF(0)、PF、SF和ZF(AF無定義)指令的功能：是把源操作數(shù)中的每位二進制與目的操作數(shù)中的相應二進制進行邏輯“與操作”，操作結果存入目標操作數(shù)中。例已知(BH)=67H，要求把其的第0、1和5位置為0。解：可以構造一個立即數(shù)，其第0、1和5位的值為0，其它位的值為1，該立即數(shù)即

11、為：0DCH或11011100B，然后用指令" AND BH, 0DCH "來實現(xiàn)此功能。只有對應的1和1才等于1.其它全部為0 ： 0和1=0 1和0=0 0和0=0  匯編 AND 指令等于易語言里的 位與() 和 模塊里的 AND_() .2 、邏輯或操作指令OR(Logical OR Instruction)指令的格式：OR寄存器/內存地址, 寄存器/內存地址/立即數(shù) 受影響的標志位：CF(0)、OF(0)、PF、SF和ZF(AF無定義)指令的功能：是把源操作數(shù)中的每位二進制與目的操作數(shù)中的相應二進制進行邏輯"或操作"，操作結果存入目標

12、操作數(shù)中。例已知(BL)=46H，要求把其的第1、3、4和6位置為1。解：構造一個立即數(shù)，使其第1、3、4和6位的值為1，其它位的值為0，該立即數(shù)即為：5AH或01011010B，然后用指令"OR BL, 5AH"來實現(xiàn)此功能。只有對應的0和0才等于0.其它全部為1 0和1=1 1和0=1 1和1=1 匯編 OR 指令等于易語言里的 位或() 和 模塊里的 OR_() .3、邏輯非操作指令NOT(Logical NOT Instruction)指令的格式：NOT寄存器/內存地址 其功能：是把操作數(shù)中的每位變反，即：10，01。指令的執(zhí)行不影響任何標志位。例已知(AL)=46

13、H，執(zhí)行指令“NOTAL”后，AL的值是什么？解：執(zhí)行該指令后，(AL)=0B9H。該指令只是把二進制位反過來而已 匯編 NOT 指令等于易語言里的 位取反() 和 模塊里的 NOT_() .4、邏輯異或操作指令XOR(Exclusive OR Instruction)指令的格式：XOR寄存器/內存地址, 寄存器/內存地址/立即數(shù) 受影響的標志位：CF(0)、OF(0)、PF、SF和ZF(AF無定義)指令的功能：是把源操作數(shù)中的每位二進制與目的操作數(shù)中的相應二進制進行邏輯"異或操作"，操作結果存入目標操作數(shù)中。例已知(AH)=46H，要求把其的第0、2、5和7位的二進制值變

14、反。解：構造一個立即數(shù)，使其第0、2、5和7位的值為1，其它位的值為0，該立即數(shù)即為：0A5H或10100101B，然后再用指令"XOR AH, 0A5H"來實現(xiàn)此功能。使用XOR運行后,只要對應的位相同時為0 ，0和0=0 1和1=0 對應兩位不同時為1 0和1=1 1和0=1匯編 XOR 指令等于易語言里的 位異或() 和 模塊里的 XOR_() . 五、移位操作指令移位操作指令是一組經常使用的指令，它包括算術移位、邏輯移位、雙精度移位、循環(huán)移位和帶進位的循環(huán)移位等五大類。移位指令都有指定移動二進制位數(shù)的操作數(shù)，該操作數(shù)可以是立即數(shù)或CL的值。在8086中，該立即數(shù)只能

15、為 1 ，但在其后的 CPU 中，該立即數(shù)可以是 1··31 之內的數(shù)。1 、算術移位指令算術移位指令有：算術左移 SAL (Shift Algebraic Left)和算術右移 SAR (Shift Algebraic Right)。它們的指令格式如下：SAL/SAR寄存器/內存地址, CL/立即數(shù)受影響的標志位：CF、OF、PF、SF和ZF(AF無定義)。算術移位指令的功能描述如下，具體功能下圖(a)、(b)所示。算術左移 SAL 把目的操作數(shù)的低位向高位移，空出的低位補0； 算術右移 SAR 把目的操作數(shù)的高位向低位移，空出的高位用最高位(符號位)填補。 例已知(AH

16、)=12H，(BL)=0A9H，試給出分別用算術左移和右移指令移動1位后，寄存器AH和BL的內容。解：用算術左移和右移指令移動1位后，寄存器AH和BL的結果如下表所示。操作數(shù)的初值執(zhí)行的指令執(zhí)行后操作數(shù)的內容(AH)=12H=10010BSAL AH, 1(AH)=24H=100100B(BL)=0A9H=10101001BSAL BL, 1(BL)=52H=1010010B(AH)=12H=10010BSAR AH, 1(AH)=09H=1001B(BL)=0A9H=10101001BSAR BL, 1(BL)=0D4H=11010100B匯編指令 SAL 指令等于易語言里的 左移() 和

17、模塊里的 SAL_() SHL_().匯編指令 SAR 指令在易語言里無對應函數(shù) 等于模塊里的 SAR_() 函數(shù).但要注意模塊里的 SAR_() 是以32位整數(shù)型來運算的,只等于匯編里的 SAR eax,1 這類的32位寄存器的運行結果，若想以16位或8位來運算,需要先把符號位擴展到32位后再處理.2、邏輯移位指令此組指令有：邏輯左移 SHL (Shift Logical Left)和邏輯右移 SHR (Shift Logical Right)。它們的指令格式如下：SHL/SHR寄存器/內存地址, CL/立即數(shù)受影響的標志位：CF、OF、PF、SF和ZF(AF無定義)。邏輯左移/右移指令只有

18、它們的移位方向不同，移位后空出的位都補 0 。它們的具體功能下圖(a)、(b)所示。例已知(AH)=12H，(BL)=0A9H，試給出分別用邏輯左移和右移指令移動1位后，寄存器AH和BL的內容。解：用算術左移和右移指令移動1位后，寄存器AH和BL的結果如下表所示。操作數(shù)的初值執(zhí)行的指令執(zhí)行后操作數(shù)的內容(AH)=12H=10010BSHL AH, 1(AH)=24H=100100B(BL)=0A9H=10101001BSHL BL, 1(BL)=52H=1010010B(AH)=12H=10010BSHR AH, 1(AH)=09H=1001B(BL)=0A9H=10101001BSHR BL

19、, 1(BL)=54H=1010100B匯編 SHL 指令等于易語言里的 左移() 和模塊里的 SHL_() SAL_().匯編 SHR 指令等于易語言里的 右移() 和模塊里的 SHR_().3、雙精度移位指令此組指令有：雙精度左移SHLD(Shift Left Double)和雙精度右移SHRD(Shift Right Double)。它們都是具有三個操作數(shù)的指令，其指令的格式如下：SHLD/SHRD 寄存器/內存地址, 寄存器, CL/立即數(shù);80386+其中：第一操作數(shù)是一個16位/32位的寄存器或存儲單元；第二操作數(shù)(與前者具有相同位數(shù))一定是寄存器；第三操作數(shù)是移動的位數(shù)，它可由C

20、L或一個立即數(shù)來確定。在執(zhí)行SHLD指令時，第一操作數(shù)向左移n位，其“空出”的低位由第二操作數(shù)的高n位來填補，但第二操作數(shù)自己不移動、不改變。在執(zhí)行SHRD指令時，第一操作數(shù)向右移n位，其“空出”的高位由第二操作數(shù)的低n位來填補，但第二操作數(shù)自己也不移動、不改變。SHLD和SHRD指令的移位功能示意圖如下圖所示。受影響的標志位：CF、OF、PF、SF和ZF(AF無定義)下面是幾個雙精度移位的例子及其執(zhí)行結果。雙精度移位指令指令操作數(shù)的初值指令執(zhí)行后的結果SHLD AX, BX, 1(AX)=1234H，(BX)=8765H(AX)=2469HSHLD AX, BX, 3(AX)=1234H，(

21、BX)=8765H(AX)=91A4HSHRD AX, BX, 2(AX)=1234H，(BX)=8765H(AX)=448DHSHRD AX, BX, 4(AX)=1234H，(BX)=8765H(AX)=5123H匯編 SHLD 與 SHRD 在易語言里暫無對應的函數(shù),2.5模塊里也沒加上這兩個函數(shù).4、循環(huán)移位指令循環(huán)移位指令有：循環(huán)左移 ROL (Rotate Left)和循環(huán)右移 ROR (Rotate Right)。指令的格式：ROL/ROR寄存器/內存地址, CL/立即數(shù)受影響的標志位：CF和OF循環(huán)左移/右移指令只是移位方向不同，它們移出的位不僅要進入CF，而且還要填補空出的位

22、。具體功能如下圖(a)、(b)所示。下面是幾個循環(huán)移位的例子及其執(zhí)行結果。循環(huán)移位指令指令操作數(shù)的初值指令執(zhí)行后的結果ROL AX, 1(AX)=6789H=110011110001001B(AX)=0CF12H=1100111100010010BROL AX, 3(AX)=6789H=110011110001001B(AX)=3C4BH=11110001001011BROR AX, 2(AX)=6789H=110011110001001B(AX)=59E2H=101100111100010BROR AX, 4(AX)=6789H=110011110001001B(AX)=9678H=1001

23、011001111000B匯編 ROL 在易語言里無對應函數(shù),模塊里提供了 ROL_().匯編 ROR 在易語言里無對應函數(shù),模塊里提供了 ROR_().5、帶進位的循環(huán)移位指令帶進位的循環(huán)移位指令有：帶進位的循環(huán)左移 RCL (Rotate Left Through Carry)和帶進位的循環(huán)右移 RCR (Rotate Right)。指令的格式：RCL/RCR寄存器/內存地址, CL/立即數(shù)受影響的標志位：CF和OF帶進位的循環(huán)左移右移指令只有移位的方向不同，它們都用原CF的值填補空出的位，移出的位再進入CF。具體功能如下圖(a)、(b)所示。下面是幾個帶進位循環(huán)移位的例子及其執(zhí)行結果。雙

24、精度移動指令指令操作數(shù)的初值指令執(zhí)行后的結果RCL AX, 1CF=0，(AX)=0ABCDH=1010101111001101B(AX)=579AH=101011110011010BRCL AX, 1CF=1，(AX)=0ABCDH=1010101111001101B(AX)=579BH=101011110011011BRCR AX, 2CF=0，(AX)=0ABCDH=1010101111001101B(AX)=AAF3H=1010101011110011BRCR AX, 2CF=1，(AX)=0ABCDH=1010101111001101B(AX)=EAF3H=1110101011110

25、011B匯編 RCL 在易語言里無對應函數(shù),模塊里提供了 RCL_().匯編 RCR 在易語言里無對應函數(shù),模塊里提供了 RCR_().本文重新介紹了這些將在封包算法里將常用到的匯編指令，大家要盡量記住這些指令的運算方式。最多被用到的指令主要有 XOR-位異或 ,ROL-左循環(huán)移位 ,ROR-右循環(huán)移位 ,AND-位與 ,OR-位或 ,SHL-左移 ,SHR-右移 ,NOT-位取反。其它加減乘除,算術移位等用到的機率很少。有些算法指令在易語言里也有對應的函數(shù),或者模塊里也有提供了這些功能,不過需要注意的是目前2.5模塊里提供的這幾個功能是按32位運算的，大家在使用時要注意，有關相應的8位與16

26、位運算的函數(shù)下版時會增加上去。封包加密解密-02前面我們介紹了最常會被用在封包加密解密算法中的指令，本節(jié)開始教大家些入門的知識,如何去分析封包數(shù)據(jù)。分析封包數(shù)據(jù)主要分兩方面：一、用肉眼看,再動手寫代碼測試,對于簡單算法的封包還是容易搞定的。二、動態(tài)調試,對于復雜算法的封包就只能這樣才能跟蹤分析出他的算法。本章教材會全部都講解到,當然先介紹第一方式,用肉眼來看，這可是件辛苦的事喲,大家準備好防輻射的眼鏡與眼藥水吧.可千萬別用眼過度,要記得多做做眼保健操哦。要想用肉眼分析封包,就得要有被加密前的明文內容,與被加密后的封包數(shù)據(jù).只有這樣才能用眼來看,來分析。如果你只有一段密文而沒有對應的明文,就只能

27、扯蛋了。對于獲取加密后的封包很簡單,大家完全可以自已用模塊里的截包功能來編寫個工具出來,也可以找一些現(xiàn)成的封包攔截工具來用,例如老牌的WPE這個軟件。明文包又如何得到呢?比如說我們在游戲里要發(fā)言一段文本內容,同時攔截下這段發(fā)出的封包,就可以肯定這條包里有包含著某些文本內容了。只需要多截幾條不同文本的聊天封包,進行對應就能簡單的分析出來相應的明文文本對應被加密后的封包中哪些數(shù)據(jù)。下面先來介紹些入門知識開一個IE瀏覽器,打開百度網(wǎng)站 在搜索框輸入 42724920 后運行WPE軟件,選擇IE的進程,點擊順三角按鈕開始攔截封包.在百度里點搜索，會被WPE攔載下數(shù)據(jù)包，點擊黑方框的停止按鈕,就可以查看

28、被攔截下來的那些數(shù)據(jù)包了。找到與IE地址欄里顯示的那條封包數(shù)據(jù) GET /s?wd=42724920 這條，在WPE的菜單->文件->另存為->文本文件 保存封包數(shù)據(jù)文本，下面就是這條封包數(shù)據(jù)：16 0 9 429（size） Send（發(fā)送）0000 47 45 54 20 2F 73 3F 77 64 3D 34 32 37 32 34 39 GET /s?wd=4272490010 32 30 20 48 54 54 50 2F 31 2E 31 0D 0A 41 63 63 20 HTTP/1.1.Acc0020 65 70

29、 74 3A 20 69 6D 61 67 65 2F 67 69 66 2C 20 ept: image/gif,0030 69 6D 61 67 65 2F 6A 70 65 67 2C 20 69 6D 61 67 image/jpeg, imag0040 65 2F 70 6A 70 65 67 2C 20 69 6D 61 67 65 2F 70 e/pjpeg, image/p0050 6A 70 65 67 2C 20 61 70 70 6C 69 63 61 74 69 6F jpeg, applicatio0060 6E 2F 78 2D 73 68 6F 63 6B 77

30、61 76 65 2D 66 6C n/x-shockwave-fl0070 61 73 68 2C 20 61 70 70 6C 69 63 61 74 69 6F 6E ash, application0080 2F 76 6E 64 2E 6D 73 2D 65 78 63 65 6C 2C 20 2A /vnd.ms-excel, *0090 2F 2A 0D 0A 52 65 66 65 72 65 72 3A 20 68 74 74 /*.Referer: htt00A0 70 3A 2F 2F 77 77 77 2E 62 61 69 64 75 2E 63 6F p:/www.

31、baidu.co00B0 6D 2F 0D 0A 41 63 63 65 70 74 2D 4C 61 6E 67 75 m/.Accept-Langu00C0 61 67 65 3A 20 7A 68 2D 63 6E 0D 0A 55 73 65 72 age: zh-cn.User00D0 2D 41 67 65 6E 74 3A 20 4D 6F 7A 69 6C 6C 61 2F -Agent: Mozilla/00E0 34 2E 30 20 28 63 6F 6D 70 61 74 69 62 6C 65 3B 4.0 (compatible;00F0 20 4D 53 49 4

32、5 20 37 2E 30 3B 20 57 69 6E 64 6F MSIE 7.0; Windo0100 77 73 20 4E 54 20 35 2E 31 3B 20 54 72 69 64 65 ws NT 5.1; Tride0110 6E 74 2F 34 2E 30 29 0D 0A 41 63 63 65 70 74 2D nt/4.0).Accept-0120 45 6E 63 6F 64 69 6E 67 3A 20 67 7A 69 70 2C 20 Encoding: gzip,0130 64 65 66 6C 61 74 65 0D 0A 48 6F 73 74 3

33、A 20 77 deflate.Host: w0140 77 77 2E 62 61 69 64 75 2E 63 6F 6D 0D 0A 43 6F .Co0150 6E 6E 65 63 74 69 6F 6E 3A 20 4B 65 65 70 2D 41 nnection: Keep-A0160 6C 69 76 65 0D 0A 43 6F 6F 6B 69 65 3A 20 42 41 live.Cookie: BA0170 49 44 55 49 44 3D 42 42 35 46 34 46 39 43 34 35 IDUID=BB5F4F9C450180 34 31 38 3

34、0 43 35 33 31 31 44 35 38 44 45 43 45 4180C5311D58DECE0190 33 30 32 36 45 46 3A 46 47 3D 31 3B 20 42 44 5F 3026EF:FG=1; BD_01A0 55 54 4B 5F 44 56 54 3D 31 0D 0A 0D 0A UTK_DVT=1.在WPE里攔截下來的封包,左中右分三列，第一列無意義,第二列是封包數(shù)據(jù)的十六進制文本,第三列是字符串文本。很多新人總愛抓著第三列的文本數(shù)據(jù)不放，事實上我要嚴肅的告訴你,第三列的文本數(shù)據(jù),如果是明文的情況下可以做為參考用,否則第三列數(shù)據(jù)是沒有多少意

35、義的，為什么呢?因為第三列只能顯示可視的字符,對于非可視的字符統(tǒng)統(tǒng)用 "." 這個點號來表示，這對于我們要進行解密封包是沒有作用的，例如圖上的紅色十六進制數(shù)據(jù) 0D 0A 正是文本里的換行符號，在第三列中無法顯示換行,全用點號來代表了。封包的正文就是這些十六進制的文本數(shù)據(jù)了，但你也不能抓著十六進制就不放了,要知道,封包都應該用十進制的字節(jié)集來表示,但由于十進制從0到255間小則一個字,多則三個字,如果直接顯示就會一團糟,所以絕大多數(shù)的截包類軟件,都會把封包數(shù)據(jù)在三個字符的十六進制來顯示,這樣就能工工整整的排列起來了。于是你恍然大悟,原來只要把這段十六進制的數(shù)據(jù)解密就行了哇!

36、但我要提醒你又透逗了一次，這段十六進制的封包根本就不需要解密,分析封包的最終結果不就是我們得編寫與封包有關的功能嗎?在截包功能里截到的就是字節(jié)集數(shù)據(jù),不是十六進制的,如果是明文的話直接用到文本(字節(jié)集封包) 就能顯示出來了，所以用WPE截下的包,頂多只是把十六進制轉回成十進制的字節(jié)集即可,這個過程算不上加密解密。所以像上面的十六進制的封包數(shù)據(jù),只需要用模塊里的十六進制到字節(jié)集() 就能轉換過來了。字節(jié)集封包=十六進制到字節(jié)集("47 45 54 20 2F 73 3F 77 64 3D 34 32 37 32 34 39 32 30 20 48 54 54 50 2F 31 2E 3

37、1 0D 0A 41 63 63"," ")輸出調試文本(到文本(字節(jié)集封包)上面說的是明文包,明文包自然是無需解密，下面再用WPE攔截在百度里搜“外掛作坊” 看看會截到什么樣的包?13 0 9 445 Send0000 47 45 54 20 2F 73 3F 77 64 3D 25 43 44 25 45 32 GET /s?wd=0010 25 42 39 25 44 32 25 44 37 25 46 37 25 42 37 25 %0020 42 42 20 48 54 54 50 2F 31 2E 31 0D

38、 0A 41 63 63 BB HTTP/1.1.Acc0030 65 70 74 3A 20 69 6D 61 67 65 2F 67 69 66 2C 20 ept: image/gif,0040 69 6D 61 67 65 2F 6A 70 65 67 2C 20 69 6D 61 67 image/jpeg, imag0050 65 2F 70 6A 70 65 67 2C 20 69 6D 61 67 65 2F 70 e/pjpeg, image/p0060 6A 70 65 67 2C 20 61 70 70 6C 69 63 61 74 69 6F jpeg, applica

39、tio0070 6E 2F 78 2D 73 68 6F 63 6B 77 61 76 65 2D 66 6C n/x-shockwave-fl0080 61 73 68 2C 20 61 70 70 6C 69 63 61 74 69 6F 6E ash, application0090 2F 76 6E 64 2E 6D 73 2D 65 78 63 65 6C 2C 20 2A /vnd.ms-excel, *00A0 2F 2A 0D 0A 52 65 66 65 72 65 72 3A 20 68 74 74 /*.Referer: htt00B0 70 3A 2F 2F 77 77

40、 77 2E 62 61 69 64 75 2E 63 6F p:/www.baidu.co00C0 6D 2F 0D 0A 41 63 63 65 70 74 2D 4C 61 6E 67 75 m/.Accept-Langu00D0 61 67 65 3A 20 7A 68 2D 63 6E 0D 0A 55 73 65 72 age: zh-cn.User00E0 2D 41 67 65 6E 74 3A 20 4D 6F 7A 69 6C 6C 61 2F -Agent: Mozilla/00F0 34 2E 30 20 28 63 6F 6D 70 61 74 69 62 6C 65

41、 3B 4.0 (compatible;0100 20 4D 53 49 45 20 37 2E 30 3B 20 57 69 6E 64 6F MSIE 7.0; Windo0110 77 73 20 4E 54 20 35 2E 31 3B 20 54 72 69 64 65 ws NT 5.1; Tride0120 6E 74 2F 34 2E 30 29 0D 0A 41 63 63 65 70 74 2D nt/4.0).Accept-0130 45 6E 63 6F 64 69 6E 67 3A 20 67 7A 69 70 2C 20 Encoding: gzip,0140 64

42、 65 66 6C 61 74 65 0D 0A 48 6F 73 74 3A 20 77 deflate.Host: w0150 77 77 2E 62 61 69 64 75 2E 63 6F 6D 0D 0A 43 6F .Co0160 6E 6E 65 63 74 69 6F 6E 3A 20 4B 65 65 70 2D 41 nnection: Keep-A0170 6C 69 76 65 0D 0A 43 6F 6F 6B 69 65 3A 20 42 41 live.Cookie: BA0180 49 44 55 49 44 3D 42 42 35 46 34 46 39 43

43、 34 35 IDUID=BB5F4F9C450190 34 31 38 30 43 35 33 31 31 44 35 38 44 45 43 45 4180C5311D58DECE01A0 33 30 32 36 45 46 3A 46 47 3D 31 3B 20 42 44 5F 3026EF:FG=1; BD_01B0 55 54 4B 5F 44 56 54 3D 31 0D 0A 0D 0A UTK_DVT=1.通過前一次的包我們知道在 GET /s?wd= 后面的內容是我們輸入在百度搜索框中的文本,但這條包里的結果卻不一樣,明明我們輸入的是 “外掛作坊”但這里居然是 也不知道是

44、什么的玩意，所以可以肯定,原明文內容“外掛作坊”被某種算法給編碼處理過了，因為算法簡單所以稱為編碼,復雜的叫加密,好像沒人這么明確的定義過吧,不管他叫編碼還是叫加密都無所謂了,重要的是我們如何自已也能寫出來這樣的算法。盡管之前說過,要分析封包還是得用那段十六進制的數(shù)據(jù),但這里的第三列字符串文本內容仍然極據(jù)參考意義，看這段被處理過的紅色文本內容,感覺像是十六進制的格式.去掉%分號就是 CD E2 B9 D2 D7 F7 B7 BB 正好八對,外掛作坊四個字剛好也是8字節(jié)的長度，即然懷疑他看起來像是被轉十六進制的,咱只需要試試看就知道了。輸入調試文本 (字節(jié)集到十六進制 (到字節(jié)集 (“外掛作坊”

45、), “ ”)輸出調試文本 (到文本 (十六進制到字節(jié)集 (“CD E2 B9 D2 D7 F7 B7 BB”, “ ”)* CD E2 B9 D2 D7 F7 B7 BB* 外掛作坊測試結果真是這樣的，由此可見網(wǎng)頁的URL中若含有一些特殊字符或中文等時,需要轉為十六進制文本,對于轉為十六進制后的數(shù)據(jù)還加上 % 百分號,來說明后面的是16進制數(shù)據(jù)。上面介紹了用WPE截包,說了封包應該是十進制的字節(jié)集格式,但為了工整顯示,所以用十六進制來輸出,并且還提供了字符串供參考，但字符串是無法正確顯示一些特殊字符的，下面再介紹一點基礎知識,這是前段時間有一個會員向我求助時的記錄，以此為例：這個會員遇到了這

46、個問題,明文文本 70 被加密成了 3A3930263E3826393B3C26393F38 加密后的文本數(shù)據(jù)咋看都像是16進制的處理,但是不對.因為若把這段明文轉成真正的十六進制,與被加密的十六進制總是有8的相差結果.于是他便順理成章的認為這只是在不同的時候采用+或-進行運算后再轉為十六進制的。老實說,他的想法確實沒錯.但這似乎不好控制,得知道一個值在多少或啥條件時才會用加還是用減呢?或許可以試試用別的方式來計算看看。2 1 8 . 6 0 . 1 3 4 . 1 7 03A 39 30 26 3E 38 26 39 3B 3C 26 39 3F 38通過上面的明文與

47、密文對應的關系來看,明文字符 "1" 總是等于 0x39 這個規(guī)律,可以肯定這個算法方式是按一個固定的方法來運算的,并且是一個一個字節(jié)來處理.第一個字節(jié)的運算結果不會影響到第二字節(jié)的處理，下面我們把這一切都轉為十進制字節(jié)集來再分析。輸出調試文本 (字節(jié)集到十進制 (到字節(jié)集 (“70”), “,”)輸出調試文本 (字節(jié)集到十進制 (十六進制到字節(jié)集 (“3A 39 30 26 3E 38 26 39 3B 3C 26 39 3F 38”, “ ”)* 50,49,56,46,54,48,46,49,51,52,46,49,55,48* 58,57,4

48、8,38,62,56,38,57,59,60,38,57,63,56明文與密文的對照結果,確實都相差著8，那么在這都相差8的背后有沒有其它什么玄機呢?如果不是采用加減乘除的方式,那就該是位運算或密碼表了，對于密碼表以后再介紹。如果想知道是不是通過位運算,那就得轉換成二進制才能更直觀的分析：明文=00110010 00110001 00111000 00101110 00110110 00110000 00101110 00110001 00110011 00110100 00101110 00110001 00110111 00110000密文=00111010 00111001 001100

49、00 00100110 00111110 00111000 00100110 00111001 00111011 00111100 00100110 00111001 00111111 00111000 8=00111010 因為明文跟密文之間總是相差8,所以我們要重點看看這兩段的二進制里與8倒底有什么關系。在前一節(jié)教材里說位運算里最多會被用到的一般都是 XOR 位異或，看看上面的明文與密文間的第四位的結果,只要明文第四位=8 加密后該位就變成0了,若明文第四位=0 則加密后就成1了，看起來只是把第四位進行簡單的反過來而已，而 XOR 則正好符合這種反位的結果，當然 NOT位取反也是用來反位的

50、,但 NOT 是把所有的位都反過來,而不能把指定的位反過來，所以這段數(shù)據(jù),只需要把明文數(shù)據(jù)位異或8就是加密了,把密文數(shù)據(jù)再次位異或8又能恢復成明文，這就是位異或的最大好處,可以即方便又簡單的來進行加密與恢復,這才是導致位異或在可逆算法中被應用最多的原因，上面的明文與密文用位與位或移位等都無法把全部明文都算成與密文完全相同的結果。位異或：能把指定的位翻過來位與：都是1時才為1位或：都是0時才為0記住上面的規(guī)則.只要明白了如何算后,寫算法的代碼就好辦了，在 CALL技術-07 的那節(jié)里的客戶端發(fā)送的封包就是用了這種 XOR 的運算方式寫的。封包加密解密-03前段在QQ上又有一會員問我能不能解密一段

51、封包，當時給他解出來了，現(xiàn)在翻出了當時與他的聊天記錄，整理一下寫這篇教程,供大家學習學習，這里講到的將都是些基礎的入門的知識與經驗心得。該網(wǎng)友當時發(fā)了這幅圖片給我，說是他自已截的數(shù)據(jù)包記錄下來的一點數(shù)據(jù),問我這樣的能不能解密?當時我粗略的看了一下最下面的兩行 十六進制與文本數(shù)據(jù)，就回答他是一般的位運算，因為封包的加密與解密一般是離不開位運算，判斷依據(jù)是:一、每個字符對應一個十六進制值。 說明該封包在加解密過程中的長度應該與原文一致,不會因為加解密而變長或變短。二、不管 h 與 p 這兩個字符在什么位置,它們始終對應 DC 與 C4 兩值。 說明該封包在加解密過程中是以單一字節(jié)進行運算的,并且不

52、會影響到下字節(jié)數(shù)據(jù)。雖然有了我的提示,但他還是沒理解,還是不會，后來才知道原來他易語言都還是門外漢 。為了方便分析明文與密文之前的對應關系，我叫他攔截了一段封包數(shù)據(jù)明文：abcdABCD0123456789密文：D5 D6 D7 D0 F5 F6 F7 F0 84 85 86 87 80 81 82 83 8C 8D雖然知道算法里基本都是用位運算的,但這里我還是想偷個懶,以為沒準與加減法就能搞定。 當時簡單的計算了明文a=97=0x61 密文 a=213=0xD5 差值=213-65=116.然后寫了個簡單的代碼把每個字節(jié)都加上116。 代碼運行后輸出的數(shù)據(jù)：D5 D6 D7 D8 B5 B6

53、 B7 B8 A4 A5 A6 A7 A8 A9 AA AB AC AD與之前正確的密文包對比發(fā)現(xiàn)錯了，.abcd 中前三個字符是正確的,第四個d出錯了，汗。看來加減法行不通，位運算才是王道!幸好是每單字節(jié)處理的,位運算范圍不大,還是好計算的,為了算出用哪種位運算我又編了小段代碼：代碼運行后輸出的數(shù)據(jù)： 位異或=180因為每個字節(jié)是八位,數(shù)據(jù)范圍是0-255，所以上面我用一個計次循環(huán)從0到255來進行運算，另外可用于位運算的函數(shù)還有其它幾個,如左右移位,循環(huán)移位等，我這里只采樣測試了位與()、位或()、位異或()、這三個，從輸出的調試文本里,得到可以使用位異或(字節(jié),180)進行加密數(shù)據(jù) a。

54、其實這里我們也可以用上節(jié)學的知識,轉為二進制來查看出來的明文 "abcd" = 97,98,99,100= 01100001 01100010 01100011 01100100密文 "D5 D6 D7 D0" = 213,214,215,208= 11010101 11010110 11010111 11010000仔細看這幾個加密前與加密的二進制,從右向左總是在第 3,5,6,8 四個位被翻過來的特征，那么按這四個位到底是啥值呢? 10110100 = 180 剛好是180。可以用計算器里的科學型來查看,或用模塊里的二到十("1011010

55、0") 來計算. 用肉眼查起來有點累,所以像上面直接寫小段代碼,用1-255全進行測試一下就知道了.呵呵.那么對于其它的數(shù)據(jù),是否也會正確無誤呢?下面編寫了一段完整的加密代碼來測試：輸出調試文本* D5 D6 D7 D0 F5 F6 F7 F0 84 85 86 87 80 81 82 83 8C 8D* abcdABCD0123456789這次加密的數(shù)據(jù)完全正確,不但加密正確,這段代碼還能同時進行解密，注意,如果只是單純的位異或,是即可以加密也可以還原解密，所以在加解密里位異或用到的很多，除此之外就是移位與循環(huán)移位也用得很多.接下來總結一下經驗:一,網(wǎng)絡游戲的封包加密解密一般都是很

56、簡單的 原因是如果算法復雜的話,游戲客戶端無所謂,但服務器網(wǎng)關若要同時處理幾萬個用戶同時在線,并且數(shù)據(jù)量大的情況下,加解密又復雜就會處理不了,再好的服務器配置總不可能全部用來運算數(shù)據(jù)包吧,其中還要對數(shù)據(jù)庫進行大量的處理呢，所以封包的加解密不會太復雜。二、每條封包中常常會有分隔符.分隔符一般都是明文的 例如某游戲中封包格式如 #xxxxxx!?使用#與!兩個符號放在該包的第一與最后字節(jié),起到分隔封包的目的，為什么要分隔封包呢?因為游戲中可能要發(fā)送的數(shù)據(jù)很多很頻繁,常常會見到這種情況 在發(fā)了一條封包后馬上又發(fā)了第二條封包.因為網(wǎng)絡傳輸上的問題，最終第二條封包可能比第一條更快到目標機網(wǎng)卡接收，所以目標機在取回封包時可能同時把兩條包取回來，此時兩條封包會合并在了一塊，于是封包的分隔符就能起