![26b00843863b5c2ac2cd1351843fd9e7.png](https://i-blog.csdnimg.cn/blog_migrate/5f9aeaba42b4b06b994983f4726e707a.jpeg)
Python3 中的默认编码是 UTF-8,这给大家写 Python 代码带来了很大的便利,不用再像 Python2.x 那样为数据编码操碎了心。但是,由于全面转向 UTF-8 编码,Python3 里面会有一些小细节,稍有不慎容易栽坑。本文就对二进制数据 XOR 编码这一种操作,浅析 Py2/Py3 中默认编码相关的一个细节小差异而引起的小 Bug。
XOR 编码是最简单有效的编码方法之一,虽然简单,但仍然应用广泛。在分析恶意样本时,经常会遇到样本内置的隐秘数据或者网络通信数据,用到了 XOR 编码。比如,一个典型就是 XOR.DDoS 家族,它样本内部关键字符串全用 XOR 编码过,而且其网络通信中 Bot 发给 C2 的上线数据包和 C2 给 Bot 下发的控制指令数据包中均涉及 XOR 编码/解码操作。
对于这类样本,分析的时候我们不免要写一些自动化的解析脚本,把其中的编码数据还原成名文以便分析。在其他开发场景中也偶尔会用 Python 写一些 XOR 编码/解码的程序。网上一搜 「Python XOR 编码 加密」或者「Python XOR encoding crypt」,都会搜出很多别人发出来的 Python XOR 编解码脚本,大多数情况下拿来直接用就行。比如我搜来的几个中文帖子中的相关脚本(本人不保证下面截图里代码的正确性):
![9e687c35adedfeceb2b84042514a18db.png](https://i-blog.csdnimg.cn/blog_migrate/aa330884a4ca48450efb33dae7d80544.jpeg)
![503a27b50e6a1f4e3b498a3238cdca61.png](https://i-blog.csdnimg.cn/blog_migrate/848324ce554bd916c9a6397cdef49e1e.jpeg)
![4d3b2804261c398d7f1cbed20090e961.png](https://i-blog.csdnimg.cn/blog_migrate/08eae3df019cb122f31f7fa63a6aa4ae.jpeg)
![dec01762780fc881df944b62873b7a41.png](https://i-blog.csdnimg.cn/blog_migrate/a461e4b9d47a7eeca93ba3ce608c7d60.jpeg)
这些脚本,在 Python2 环境下都没有问题,都可以正确进行 XOR 编解码,然而如果直接拿到 Python3 环境下去运行,却会发生一个不容易发现的小 Bug。来看一段在 ipthon3 里的操作记录:
In [1]: def xor_crypt(data, key): ...: cipher_data = [] ...: len_data = len(data) ...: len_key = len(key) ...: for idx in range(len_data): ...: bias = key[idx % len_key] ...: curr_byte = data[idx] ...: cipher_data.append(chr(bias ^ curr_byte)) ...: return bytearray("".join(cipher_data).encode()) ...:In [2]: xor_key = b'0123456789'In [3]: sam1 = b'abcdefgh'In [4]: sam2 = b'abcdefghijklmnopqrstuvwxyz'In [5]: print(xor_crypt(sam1,xor_key))bytearray(b'QSQWQSQ_')In [6]: print(xor_crypt(xor_crypt(sam1,xor_key), xor_key))bytearray(b'abcdefgh')In [7]: print(xor_crypt(sam2, xor_key))bytearray(b'QSQWQSQ_QS[]_][EGEKMEGEKMO')In [8]: print(xor_crypt(xor_crypt(sam2,xor_key), xor_key))bytearray(b'abcdefghijklmnopqrstuvwxyz')In [9]: sam3 = b'x7fx80x81x90x91xA0xA1xB0xB1xC0xC1xD0xD1xE0xE1xF0xF1xFA'In [10]: print(xor_crypt(sam3, xor_key))bytearray(b'Oxc2xb1xc2xb3xc2xa3xc2xa5xc2x95xc2x97xc2x87xc2x89xc3xb9xc3xb1xc3xa1xc3xa3xc3x93xc3x95xc3x85xc3x87xc3x8d')In [11]: print(xor_crypt(xor_crypt(sam3,xor_key), xor_key))bytearray(b'x7fxc3xb3xc2x83xc3xb1xc2x87xc3xb7xc2x95xc3xb5xc2x9dxc3xbbxc2xa5xc3xb3xc2xa5xc3xb1xc2xb3xc3xb7xc2xbfxc3xb4xc2x81xc3xbaxc2x81xc3xb2xc2x93xc3xb0xc2x97xc3xb6xc2xa5xc3xb4xc2xadxc3xbaxc2xb5xc3xb2xc2xb5xc3xb0xc2xb9')In [12]: print(len(sam3))18In [13]: print(len(xor_crypt(xor_crypt(sam3,xor_key), xor_key)))69
可以看到,仿照 Python2 环境下那些常用的 XOR 编码操作写的函数,在 Python3 环境下,偶尔会出现意料之外的结果:上面的操作记录中,对于 sam1 和 sam2 两个全都是可打印字符的字节串进行 XOR 编解码是没有问题的;但是对于 sam3 ,一个内含大量 HEX 值大于 0x7F 的非可打印字符字节串,原本是 18 个字节,进行两次 XOR 操作之后竟然变成了 69 个字节。
这就十分蹊跷了。问题出在哪个环节?是函数内部的字节列表 cipher_data 的问题,还是最后 bytearray() 操作出了问题,还是进行 XOR 计算的时候, chr() 函数的问题?
经过一番排查,发现这是 chr() 函数的问题。先看这个函数在 Python2 和 Python3 中各有什么表现:
![a09ee64fcd1bac8450e32c87db32cd03.png](https://i-blog.csdnimg.cn/blog_migrate/98b7f3fa920d4b25305e4107c70dbadf.jpeg)
![5d6b6d0071dd30a1d0f0814d47fce473.png](https://i-blog.csdnimg.cn/blog_migrate/c6ff0cf48baf0244177aee6ae77a5d9e.jpeg)
在 Python2 版本中,除了 chr() 还有一个 unichr() ,可以看到 Py2 中的 unichr() 与Py3 中的 chr() 行为是一致的:对于 HEX 值大于 0x7F 的字符,返回值占 2 Bytes;对于 HEX 值小于或等于 0x7F 的字符,返回值占 1 Byte。
为什么会出现这么个差异?刚开始一直以为 chr() 函数只会返回 1 Byte 的结果,对此感到很是不解。
查阅一下 Py2 中 chr() 和 unichr() 的文档如下:
![25b90b8aed48bafd2619561c08201e3b.png](https://i-blog.csdnimg.cn/blog_migrate/57c9a0bc31d3df28b9a4471614c192b0.jpeg)
![4a8c1eeb4516caa0729a1d901b64ffd7.png](https://i-blog.csdnimg.cn/blog_migrate/1b8de1628665032b24170737965a65ec.jpeg)
而 Py3 中 chr() 函数的文档说明如下:
![199161899e56b78a81e7e1d5d757a61e.png](https://i-blog.csdnimg.cn/blog_migrate/5373a9569a485a5e6fbfe0afbbc847dc.jpeg)
从文档来看, Py3 中的 chr() 函数确实对应到了 Py2 中的 unichr() 函数,只返回 Unicode 编码的结果。在点破最后的一层窗户纸之前,我们再去 CPython 的源码里瞅一眼,以便把这个结论锤结实了。
Py3 中的 chr() 函数,源码中是这样实现的:
![dd7a1935a07eb60a387eb0397abb642a.png](https://i-blog.csdnimg.cn/blog_migrate/a6e4cd6de6b6cb1073cf1286cc46add7.jpeg)
![e879ff7297520c851aacff30c82b8e7a.png](https://i-blog.csdnimg.cn/blog_migrate/a76d7282b1ed842cb7bf2f4c9c8dd691.jpeg)
![8ae86d03f8cbe6cbdd0a614c04ecc75f.png](https://i-blog.csdnimg.cn/blog_migrate/e56894784d70195aa1f5c4d7e470e276.jpeg)
至于其中的 unicode_char() 函数如何实现,我们就不深究了,知道它就是返回一个 Unicode 编码的字符即可。再看 Py2 中 unichr() 函数:
![6a1a62b706af8f1c75f5978ddd4e00f4.png](https://i-blog.csdnimg.cn/blog_migrate/9e8889861e6430a2045df4bcc960d715.jpeg)
如出一辙有木有。
那 最后一层窗户纸 到底是什么?就是 Py3 默认的 UTF-8 编码了。在 http://www.utf-8.com 网站上有这么一段话:
UTF-8 encodes each Unicode character as a variable number of 1 to 4 octets , where the number of octets depends on the integer value assigned to the Unicode character. It is an efficient encoding of Unicode documents that use mostly US-ASCII characters because it represents each character in the range U+0000 through U+007F as a single octet .
注意上面加粗部分的重点:
- UTF-8 编码的字符占 1~4 个字节;
- 字符 U+0000 到 U+007F 都用一个字节来表示,其它字符 1 个字节不够,就用 2~4 个字节来表示。
这样就明确上面问题的原因了:Py3 中的 chr() 函数,只有在参数的 HEX 值位于 [0x00, 0x7F] 区间内的时候才返回 1 Byte 的结果,这个结果同于 Py2 中的 chr() 函数;当 HEX 值大于 0x7F ,其返回值占 2 Bytes,行为同于 Py2 中的 unichr() 函数。
那么 Py3 中正确的 XOR 编解码姿势是什么?上面 ipython3 操作记录中的函数稍加改动即可:
def xor_crypt(data, key): cipher_data = [] len_data = len(data) len_key = len(key) for idx in range(len_data): bias = key[idx % len_key] curr_byte = data[idx] cipher_data.append(bias ^ curr_byte) return bytearray(cipher_data)
当然,还有更简洁的写法:
def XORCrypt(data, key): return bytearray(a^b for a, b in zip(*map(bytearray, [data, key])))
“我自己是一名从事了多年开发的Python老程序员,辞职目前在做自己的Python私人定制课程,今年年初我花了一个月整理了一份最适合2019年学习的Python学习干货,从最基础的到各种框架都有整理,送给每一位喜欢Python小伙伴,想要获取的可以转发文章并关注我的头条。在后台私信我:01,即可免费获取。"
![05205521206b3bdf37ec06dc3b9588a0.png](https://i-blog.csdnimg.cn/blog_migrate/25cf5ae883f0b629ac898fd24c21560f.jpeg)