我觉得作者说得很清楚了，本质是文件太小，只有7字节
循其本
7B大小的文件说明了什么
众所周知，一个ASCII字符占用1B空间，一个UTF-8字符占用2~4B空间，7B大小的纯文本文件，结合这个文本文件的可能内容，因此推出其为三数字+一个ASCII字符+三数字的组合。
什么是CRC
CRC即循环冗余校验算法，它和哈希（散列）算法类似，其值受到每个字符的变化的影响。
另外，CRC算法因具体参数模型不同，对同一文件的校验结果不尽相同；但由于zip压缩普遍采用David Schwadeter的CR -32算法，我们可以直接略过猜参数的阶段。
CRC冗余校验其实与哈希算法类似，其结果对每一个字节的变化都很敏感，选用CRC算法的原因，不过是它比哈希更快。
样本空间的缩减
7B=56bit，样本空间为2^56
但是有前文的基础，假设是纯ASCII字符，样本空间可以下降到2^49（即7B*7bit/B）
除去ASCII中的控制字符和DEL，样本空间下降到96^7
再做进一步推测，两个数应该是100~500的整数，样本空间可以进一步缩小为401×401×96=15436896，这是完全能够接受的量级。
防破解方式
说了这么多其实已经很明显了，在原文件末尾增加一串垃圾数据，能够极大程度地扩大样本空间，使其超出计算机可处理的范围即可。
我真不知道某些人到底在杠什么
14 个赞
V1nci
(Jerry </3cript>)
4
首先这个问题他是不是一个压缩包？你在这扯这个都是解法的问题，本质他是一个压缩包，然后其次这个压损算法展示的crc是源文件的crc，才有能被爆破的空间，如果加密算法生成的压缩包他不保存源文件的CRC你有进行爆破原文的收敛空间么，你在这纠结解法有啥意思呢？说你滚刀，你就直接发帖来杠，杠半天也不看前提
2 个赞
本质上解法和压缩包没有任何关系，其次CRC算法和ZIP压缩算法也没关系，我觉得你应该先去搞清楚什么是CRC、什么是ZIP。
另外，其他的压缩算法比如RAR、7z，也都会提供CRC-32以检验前后文件一致性
3 个赞
delph1s
(威震天)
6
两位佬别打了，其实症结就在，一个在说因为显示了源文件CRC才有可能破解，一个说滚键盘就算显示源文件CRC也比较难破解
3 个赞
V1nci
(Jerry </3cript>)
8
怎么会没有关系？没有这个特性，就不会有你这个爆破原文的方法，与其在这说我去搞清楚这个搞清楚那个，不如你讲讲他们的必要条件和充要条件？那要不你再讲讲MD5彩虹表这套？我觉得你这个解法用来纠结MD5彩虹表比较合适，在这个地方纠结这个地方反而不怎么合适
1 个赞
我觉得你起码应该搞清楚这样一个逻辑，就是破解原理是直接碰撞原文档，全程和压缩算法没半毛钱关系，CRC只是校验一致性的工具而已，把它换成md5，sha2这些散列算法本质是一样的；而能够被破解的原因就是7B的空间，所能产生的样本量太少了，很容易爆破，只要找出CRC-32一致的内容即可
2 个赞
CRC-32在这里的用处和哈希本质相同，用CRC-32原因是速度快，仅此而已
2 个赞
V1nci
(Jerry </3cript>)
12
你说的解法是没毛病的，我从来都没有质疑你的在解法上的描述，我说的你有问题的就是你关于脸滚键盘的描述，其次这个问题本质就是对这个zip加密文件是哪怕再强的密钥，本身量比较小的情况下，可以通过crc加快收敛速度来确定明文，我觉得这个无论关于你的描述还是我的描述，本质上都没有什么太大的区别，最大的问题而是在问题是怎么来的，你认为这个问题跟压缩算法没关系，我认为这个地方是在这个场景下的特殊问题，我觉得本质上也是不冲突的，因为看待问题发起的角度是不一样的。
1 个赞
我重复过很多次了，增加垃圾数据使得样本空间大到不可爆破，就这么简单。
另外我不懂你所说的“收敛速度”是什么意思
2 个赞
neo
(Neo)
17
好好好，理不辩不明。不过不要带着情绪，语言还是要友善哦 
20 个赞
收敛速度
或许他信息与计算科学的吧
一般是xxx迭代法有
1 个赞
我就是不清楚这怎么迭代，原帖的代码和我的思路都是暴力破解碰撞吧
1 个赞
