网站首页 mysql技术

封包解密-02

发布时间：1970-01-01 00:00查看次数：3264

上面介绍了用WPE截包,说了封包应该是十进制的字节集格式,但为了工整显示,所以用十六进制来输出,并且还提供了字符串供参考.但字符串是无法正确显示一些特殊字符的.

下面再介绍一点基础知识,这是前段时间有一个会员向我求助时的记录.以此为例.





取该会员的聊天记录片段

这个会员遇到了这个问题,明文文本 218.60.134.170 被加密成了 3A3930263E3826393B3C26393F38 加密后的文本数据咋看都像是16进制的处理,但是不对.因为若把这段明文转成真正的十六进制,与被加密的十六进制总是有8的相差结果.于是他便顺理成章的认为这只是在不同的时候采用+或-进行运算后再转为十六进制的.

老实说,他的想法确实没错.但这似乎不好控制,得知道一个值在多少或啥条件时才会用加还是用减呢?或许可以试试用别的方式来计算看看.

2 1 8 . 6 0 . 1 3 4 . 1 7 0

3A 39 30 26 3E 38 26 39 3B 3C 26 39 3F 38

通过上面的明文与密文对应的关系来看,明文字符 "1" 总是等于 0x39 这个规律,可以肯定这个算法方式是按一个固定的方法来运算的,并且是一个一个字节来处理.第一个字节的运算结果不会影响到第二字节的处理.

下面我们把这一切都转为十进制字节集来再分析.

 

输出调试文本 (字节集到十进制 (到字节集 (“218.60.134.170”), “,”))
输出调试文本 (字节集到十进制 (十六进制到字节集 (“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,48,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 00110000 00100110 00111110 00111000 00100110 00111001 00111011 00111100 00100110 00111001 00111111 00111000

  8=00111010 因为明文跟密文之间总是相差8,所以我们要重点看看这两段的二进制里与8倒底有什么关系.

在前一节教材里说位运算里最多会被用到的一般都是 XOR 位异或.看看上面的明文与密文间的第四位的结果,只要明文第四位=8 加密后该位就变成0了,,若明文第四位=0 则加密后就成1了.看起来只是把第四位进行简单的反过来而已.而 XOR 则正好符合这种反位的结果.当然 NOT 位取反 也是用来反位的,但 NOT 是把所有的位都反过来,而不能把指定的位反过来.

所以这段数据,只需要把明文数据位异或8就是加密了,把密文数据再次位异或8又能恢复成明文.这就是位异或的最大好处,可以即方便又简单的来进行加密与恢复,这才是导致位异或在可逆算法中被应用最多的原因.

上面的明文与密文用位与 位或 移位 等都无法把全部明文都算成与密文完全相同的结果.

位异或 能把指定的位翻过来

位与  都是1时才为1

位或  都是0时才为0

记住上面的规则..





算法的代码

只要明白了如何算后,写算法的代码就好办了.在 CALL技术-07 的那节里的客户端发送的封包就是用了这种 XOR 的运算方式写的...