对CRC32的小结加上bugku一道题目:好多压缩包

CRC32就是校验值，一般来说不同的文件校验值不一样，所以我们可以挨个爆破，当然这是在文件比较小的时候。下面是几种情形。

1.

我新建了一个flag.txt文档，里面是我的生日20180818

然后我对它进行压缩并且加密，密码很复杂，爆破就不用想了。

假设现在有这么一个题目：
给你一个flag.zip，然后告诉你flag是我的生日，你必须得知道flag.txt里面的内容，但是你爆破的话是爆破不出来的，这个时候我们即可以进行crc32碰撞了。先查看crc检验值：

写脚本： (生日是八位数，这个应该都知道吧。。。。所以flag.txt是八个字节)

是不是爆破出来了啊。值得注意的是：
密码位数你得知道(这个可以查看txt字节数确定)。
文字的具体内容最好是已经通知了是什么格式，比如说数字，字母之类的，还有就是文件要小。换句话说位数要少，不然很慢。刚刚看到了，只是8位数字，而且还不是10的8次方，仅仅是2018*2*12*2*12种情况就用了2.9s，而且还只是纯数字。可以这么想，给你一个文件，里面，ascii有的他都有，位数在100来为的话位的话，运行起来是很慢的。

2.

bugku-好多压缩包
这里我们就遇到了上边说的很极端的情况了。。
打开文件头，发现时zip的文件头，直接在后缀加上.zip，解压。发现有68个压缩包，每一个压缩包都有一个四字节的加密的txt文档。

这题的思路：zip加密后我们一般的思路是先看看是不是伪加密，发现不是。然后尝试爆破，可是这有68个压缩包啊，出题人很明显是不想让你爆破的。然后再想想一个压缩包有四个字节，我们可以尝试一下crc32碰撞。
下边上大佬的脚本。

分析一下这个脚本:他为什么是四位数？
在记事本里面，一个汉字和中文的标点符号两个字节，一个英文字母和英文的标点符号占一个字节。
我们猜测是英文字符啊，毕竟中文字符的话有几万个，你要是用中文字符的话和爆破有什么区别呢？所以一个txt里面是四个字符。

获取zip文件得crc32值，大佬的脚本那里已经说的很详细了。

然后在说下这个dic，它表示的是字符的范围。其实更保险的话应该是用string.printable,下面看一下两者的区别。

虽然printable更保险，但是时间会更长，毕竟爆破的字符数更多了。这里解出来之后发现是一段base64字符串，也就没有什么区别了，因为base64范围：0-9 A-Z a-z + / = 这64个字符string.ascii_letters + string.digits + '+/='已经完全给包含了，看来还是经验啊，大佬们可能一眼就看穿了这是个base64字符串。

惊了，还是挺快的，十来分钟就完事了。

解密base64

放到winhex，经验让我这么做的。注意，这里粘贴的时候粘贴为uniocde方式.

winhex是原始数据和16进制的对应，我们刚base64解出来的肯定不是16进制啊。

ascii也不行，这里有很多ascii码也不能代表的数据，所以用unicode。

在这里不知道为什么莫名其妙的多了很多空格(0x00)，我不明白为什么。我看大佬们的wp，它们似乎很轻松的就把这些base64解码后的数据引入了winhex，而我这里净是问题。

最后想用python脚本解的

然后winhex导入txt就可以得到了。

他这里有段内容，说是修复file就能得到flag，而且我们还发现了里面有个flag.txt，猜测压缩文件里放了个txt。文件头没见过，不过应该是修复为zip或者rar压缩包。

看结尾不是504B，说明不是zip，那就是rar了，网上没找到rar文件尾，自己新建了个rar丢wnhex里面看了看，果然如此，在文件头加上526172211A0700，另存为.rar文件。

打开后直接解压，发现时在rar的注释里面。

 flag{nev3r_enc0de_t00_sm4ll_fil3_w1th_zip}