把重要的压缩包密码忘了？聊聊暴力破解 7Zip 的可行性与成本

最近看到一个有点让人揪心的求助帖：一位博主把极其重要的 7Zip 压缩包密码给忘了。

博主发布的求助帖子截图，描述了密码遗忘的具体情况。

只记得密码是由 13 个特定字符组成的，但是顺序完全乱序。听起来仿佛希望很大：毕竟字符集已经锁定，只需要跑全排列就行了。于是这位博主租用了 8 台搭载 V100 GPU 的服务器，打算通过“钞能力”暴力穷举。

算账：时间与金钱的残酷对抗

咱们先来算一笔账。13 个字符的全排列（13!）大约是 62 亿种可能。听起来似乎不多？在计算机世界里，这可是一座大山。

博主反馈，用了 V100 跑了 4 个小时，算了大约 2.1 亿次（70 * 300万）。按照这个速度跑完 62 亿个组合，需要多少时间？

简单一算：62 亿 / 2.1 亿 ≈ 295 个小时。如果按单台机器每小时 3 块钱计算，跑完这一遍要 885 块钱。如果他是 8 台机器并行，时间缩短到 37 小时左右，但费用直接飙升到近 900 块。

最要命的是：还没算完

这 900 块和 37 小时，仅仅是理论上的“一遍”。这里面还有两个巨大的坑：

1. 7Zip 的加密算法太强：7Zip 使用的是 AES-256 加密算法，并且算法设计极其适合抵抗暴力破解。不像旧的 ZIP 格式，7Zip 每次解密尝试都需要大量的哈希运算，GPU 的并行优势在它面前大打折扣（相比于破解 RAR 或旧 ZIP，7Zip 的哈希计算更复杂，难以完全利用 GPU 的并行核心）。V100 跑 2.1 亿次看似很多，但对于 13! 的组合量级来说，简直是杯水车薪。

2. 全加密的效率折损：博主提到是“全加密压缩包（文件名和密码）”。这意味着即使只是想验证文件名是否正确，也需要先跑一遍解密过程。如果文件头结构复杂，校验速度会更慢。

所以，如果你真的打算“梭哈”跑完所有排列，可能准备好几千块机器费和好几天的时间，最后发现——密码里可能包含大小写差异，或者你少记了一个符号。

除了蛮力，还能怎么做？

如果在坐以待毙和倾家荡产之间犹豫，可以试试下面这种更“极客”的思路，也许不需要跑完所有排列就能破局。

1. 换工具：放弃 Hashcat 暴力，转战 John the Ripper 的掩码模式

很多时候大家首选 Hashcat 是因为它吃 GPU 算力猛，但在处理这种复杂排列组合时，CPU 的灵活性有时候更重要。使用 John the Ripper (JtR) 配合 --mask 参数，可能效率更高，特别是当字符集确定时。你可以自定义规则，比如“中间必定是数字”或者“开头必定是字母”，这能瞬间将计算量级从 13! 降下来。

2. 深度回忆：构建“热词”字典

全排列是“冷冰冰”的逻辑，但人脑记密码通常有“热乎乎”的规律。

哪怕顺序忘了，是不是有习惯性的词根？比如 love, 520, admin, qwer 这类片段？如果这 13 个字符能拆解成两三个常见的单词片段，优先尝试这几个片段的组合。比如假设字符包含 a,e,i,o,u 和 1,3,5,7,9，优先尝试元音+数字的交替排列。

这种“掩码字典”攻击，通常能在几分钟内试完几千万种高概率组合，远比硬碰硬跑全排列划算。

3. 检查硬件与压缩包结构

还有一个极低概率但必须排除的可能：确认这个压缩包是否使用的是标准的 7Zip 格式？如果是用 WinRAR 或其他软件打包但后缀改成了 .7z，算法可能完全不同，破解速度会有天壤之别。另外，确认 GPU 驱动和破解工具（如 7z2hash.pl）是否正确生成了包含所有必要校验位的 Hash 文件。有时候 Hash 格式错误会导致工具一直在跑无效数据。

写在最后

7Zip 的安全性在这次“实战”中体现得淋漓尽致。如果你不是国家级的对手或者没有极其特殊的价值驱动，通过云端租赁算力硬刚 AES-256 的全排列，基本上是个“性价比极低”的方案。

建议不如先冷静下来，拿张纸把这 13 个字符写下来，尝试拼凑一下自己过去的键盘习惯或生日规律，用 JtR 跑跑针对性的小字典。实在不行，看看有没有备份，或者——如果数据真的很值钱，去找专业的数据恢复公司（他们可能有更深层的彩虹表或硬件阵列），虽然贵点，但比自己在云服务器上烧钱看进度条要有谱得多。