Bugku-好多压缩包

首先是大佬的解题思路

作者:M4x W4n9-王奥博 出处:http://www.cnblogs.com/WangAoBo/

在crc32碰撞还原出所有压缩包中的文件内容之后

到了base64解码crc碰撞的结果时出了问题,经过对比,发现多了一个字节'0D'

但是事实上无论是否有'0D',对解码后的文件再编码之后的结果是一样的

掏出ascii表查看一番,发现是回车符,好像没什么不对。。


ASCII表

仔细看这个后面跟着'0A',这是换行来着,也就是\r\n。好吧我不知道哪错了,但隐约觉得有问题


这是我用来base64解码的脚本

f = open('out','r') # out存着crc碰撞的结果

s = f.read()

f.close()

s = base64.b64decode(s)

f = open('flag','w')

f.write(s)

f.close()

后来发现将写模式调为wb,会发现'0D'字节不见了,然后就能正常完成后续操作了

事实上这就是wb模式与w模式的一个区别

是为了与linux,unix兼容, 本来换行原来就是0A('\n'), 微软把\n 改为了\r\n,即从0A改为0D 0A.,开启wb的话就只存入0A了


回到base64编码结果却一样的问题上来

我是这么写的

f = open('flag','r')

s = f.read()

s = base64.b64encode(s)

f.close()

print s

想到可能是r模式的问题,看了一下,确实'0D'会被忽略,用rb模式读的话就不会出现base64编码一样的问题了

总的来说就是微软的锅,没错!!!

二进制模式的读写会区分\r\n与\n,但是文本模式不会

二进制模式回车是\r\n,文本模式\r\n会被转为\n

对了,回车符\r是回到这一行的行首,而换行符\n是换到下一行,但是这下一行是同列的下一行,如果是在行尾换行的话,也就是到了下一行行尾了,就相当于按了一下方向键下键

推荐阅读更多精彩内容