1. 先看清楚对手加密压缩包的底层结构加密压缩包的密码恢复本质上是一场针对密钥派生函数的消耗战。很多人上来就打开 ARCHPR选个“暴力攻击”勾满所有字符集点开始然后盯着进度条发呆三天。问题不在工具在于没搞清楚自己面对的是什么加密方案——ZIP 传统加密和 7z 的 AES-256 之间差了大概六个数量级的尝试速率。同一个密码在前者身上是十分钟的事在后者身上可能是几百年。这篇内容我想解决的就是三个问题这个包到底是怎么加密的、四种攻击模式分别适合什么场景、以及参数该怎么算才不浪费时间。ARCHPR 是很多人接触密码恢复的第一款工具界面朴素四种攻击模式摆在那里看起来像是点点鼠标就能解决的事。但它真正的价值不在“点开始”而在“点之前你做了多少功课”。适合谁看手上有自己多年前加密的备份包、密码只记得大概形状的人做数据迁移时遇到历史加密归档、需要合规恢复的运维以及单纯想搞明白这套机制怎么运转的爱好者。先划一条线下面所有内容都建立在“文件是你自己的或者你有明确授权处理”这个前提上。企业里常见的场景是老员工离职留下的加密归档、十几年前的客户资料备份、自己设了密码又忘了的家庭照片包。这不是攻击别人系统的技术是数据自救。越过这条线的用法我不讨论也不建议任何人尝试。1.1 四种加密方案的真实差异决定了你该不该动手压缩格式看着五花八门但加密方案拢共就那么几类认清这几类的区别比记住任何工具按钮都重要。ZIP 传统加密ZipCrypto是 PKZIP 时代留下来的老方案本质是个流密码。每个文件前面挂 12 字节的加密头密钥由密码经过三个 32 位寄存器的更新运算生成然后对明文做异或。它的致命弱点有两个一是密钥派生极快快到可以每秒试上千万次二是那 12 字节头里只有末尾 1 到 2 个字节是校验值也就是说尝试空间里存在大量“假阳性”——某个错误密码解出来的头恰好对上了校验位工具会误报命中你还得拿完整解压去验证。ZIP AESWinZip AES是后来打的补丁用 PBKDF2-HMAC-SHA1 做密钥派生按加密强度迭代 1000 次然后用 AES-128/192/256 走 CTR 模式加密数据外面再套一层 HMAC-SHA1 做完整性校验。1000 次迭代在今天看来依然不多但它把速率从“千万级”直接拉到了“十万级”以下量级变化非常明显。RAR3大致对应 2.9 到 4.x 版本用的是 AES-128-CBC密钥派生走 SHA-1 迭代迭代次数是 262144 次也就是 2 的 18 次方。这个数字是专门设计来拖慢暴力尝试的效果很显著。RAR5换成了 PBKDF2-HMAC-SHA256迭代 32768 次配合 AES-256-CBC虽然迭代次数看着少了但 SHA-256 加 HMAC 的结构让单次计算成本更高。7z 的 AES-256是目前这几类里最狠的SHA-256 迭代 2 的 19 次方也就是 524288 次。单次尝试的成本高到让纯 CPU 方案基本失去意义。我把这几个方案的核心参数和速率量级整理成一张表你在动手前先对号入座能省掉大量无用功。加密方案密钥派生方式迭代/成本单机尝试速率量级参考明文攻击可行性ZipCrypto自研流密码极低10^6 至 10^8 次/秒可行12 字节已知明文即可ZIP AES-256PBKDF2-HMAC-SHA11000 次10^4 至 10^5 次/秒基本不可行RAR3SHA-1 迭代262144 次10^3 至 10^4 次/秒不可行RAR5PBKDF2-HMAC-SHA25632768 次10^3 至 10^4 次/秒不可行7z AES-256SHA-256 迭代524288 次10^2 至 10^3 次/秒不可行表里的速率是量级参考具体数值取决于你的 CPU 核心数、是否用 GPU、以及工具实现。但“量级”这两个字已经足够你做判断了ZipCrypto 的包值得试一试7z 的包在你对密码毫无记忆的情况下慎重考虑投入产出比。1.2 为什么必须先探测格式再决定策略我见过太多人拿到包直接开跑跑了半天发现是个 RAR5或者压根没注意压缩包里混用了两种加密方案。探测这一步花不了两分钟但能决定后面几小时甚至几天是否白费。探测主要看三件事。第一是压缩格式和版本用7z l -slt 文件名就能看到 Method 字段里面会标明ZipCrypto还是AES-256RAR 的话会显示加密标志位。第二是是否有文件名加密7z 的参数里有-mheon这一项一旦开启连文件列表都看不到这时候连“已知明文”这条路都断了。第三是压缩包里到底有几个文件、每个文件多大这直接关系到明文攻击能不能用。第三条最容易被忽略。一个 500MB 的加密包里如果只有孤零零一个文件而且这个文件你完全不知道内容那明文攻击免谈。反过来如果包里是几百个 Word 文档其中一个是你自己写的、原稿还在手边那情况就完全不一样了。我自己的习惯是探测完立刻在纸上写三行格式是什么、包里有什么、我大概记得密码长什么样。这三行写不出来就别急着开软件。1.3 密码记忆的“形状”比密码本身更有价值这一点是我踩过坑之后才明白的。人对密码的记忆往往是碎片化的——你可能想不起完整密码但记得“前面是公司缩写大写中间有个年份后面跟了三个数字”。这种模糊记忆恰恰是最有价值的输入因为它把攻击空间从一个天文数字压缩到了可计算的范围内。举个具体例子。如果纯暴力8 位大小写加数字是 62 的 8 次方约 2.18 乘 10 的 14 次方种组合按每秒一万次算需要 690 多年。但如果你确定“前 4 位是全大写字母第 5 到 8 位是数字”那就是 26 的 4 次方乘以 10 的 4 次方约 45.7 亿种同样的速率下大约 5.3 天。再进一步如果你记得前 4 位是某个单词那基本就是秒级的事了。所以动手之前花十分钟跟自己较劲这个密码是什么时候设的、当时在什么地方、有没有参考什么词、键盘上是不是有什么规律、有没有把某个数字替换成符号的习惯。这些信息喂给工具比多买一张显卡有用得多。2. 四种攻击模式的取舍逻辑与组合策略ARCHPR 把攻击方式分成四类这个划分其实很合理它对应的是“你对密码知道多少”的四个层次什么都不知道、知道形状、知道可能的词、知道文件内容。很多人的误区是把它当成四个并列选项随便挑一个实际上它们是有优先级的而且经常需要组合使用。2.1 暴力攻击最后才用的笨办法但账要算清楚暴力攻击就是穷举把字符集里所有字符的所有排列组合都试一遍。它的优点是理论上一定能出结果缺点是这个“一定”可能需要几辈子。决定暴力攻击成败的只有两个参数字符集大小和长度上限。组合总数的公式很简单字符集大小 C 的 L 次方。我把常见的组合列出来你感受一下这个增长速度。密码构成字符集大小6 位组合数8 位组合数10 位组合数纯数字10100 万1 亿100 亿小写字母263.09 亿2.09 万亿1.41 乘 10^14大小写字母52197 亿5.34 乘 10^131.45 乘 10^17大小写加数字62568 亿2.18 乘 10^148.39 乘 10^17全部可打印字符957350 亿6.63 乘 10^155.99 乘 10^19看表格最后一列的量级再对比第一节里的速率表结论很清楚8 位以上的全字符集暴力在 7z 或 RAR5 上不具备现实可行性。但在 ZipCrypto 上如果你把长度限制在 6 位以内、字符集收窄到数字加小写那就是几分钟到几小时的事完全值得一试。我实际操作时的顺序是这样的先设一个极窄的范围纯数字 1 到 6 位跑一遍十几分钟出结果最好出不来也损失不大然后逐步放宽每次放宽都问自己一句“这个扩展带来的组合数增长跟我对密码的信心匹配吗”。这个渐进的过程比一次性设个大范围然后干等要理性得多。注意ARCHPR 的暴力攻击默认从最短长度开始递增。如果你的密码确定是 8 位一定要把“最小长度”设成 8否则它会先把 1 到 7 位全部跑一遍纯属浪费。2.2 掩码攻击把人类记忆习惯翻译成参数掩码攻击是暴力攻击的精准版也是我认为性价比最高的一种模式。它的思路是我不知道密码是什么但我知道每一位大概是什么类型。比如“四个大写字母加四个数字”或者“一个常见单词加两位数字”。ARCHPR 的掩码语法跟主流 GPU 工具高度相似常用的占位符有这么几类?d代表数字 0 到 9?l代表小写字母?u代表大写字母?s代表常见符号?a代表全部可打印字符另外还支持自定义字符集。写一个掩码?u?u?u?u?d?d?d?d就精确描述了“四大写加四数字”这个假设。掩码的威力在于它能把组合数压到多低。还是那个例子如果密码真的是“公司缩写大写加年份”?u?u?u?u?d?d?d?d的组合数是 26 的 4 次方乘 10 的 4 次方约 45.7 亿。在 ZipCrypto 上按每秒百万次算一个多小时在 RAR3 上按每秒五千次算大概 100 天——这个数字告诉你在 RAR3 上做这种掩码是不划算的但如果能再收窄比如确定第一位是某个字母那就能降到几天。实际写掩码有几个经验点。第一位置要精确。人的密码习惯往往有固定结构比如“首字母大写 小写单词 数字”那掩码就是?u?l?l?l?l?l?d?d。第二善用自定义字符集。不同工具语法略有差异有的用-1定义一组字符然后在掩码里引?1ARCHPR 也有类似的字符集定义功能。比如你知道密码里那几位只可能是 0、1、2 这三个数字比如月份那就定义一个只含这三个字符的集合组合数立刻从 10 的 n 次方降到 3 的 n 次方。第三先跑窄的再跑宽的。别一上来就把所有位都设成?a那跟暴力攻击没区别。我个人的习惯是先跑一个“高频掩码清单”就是把最常见的几种人类密码结构列出来逐个试?u?l?l?l?l?d?d?d?d首字母大写单词加四位数字、?l?l?l?l?l?l?d?d全小写加两位数字、?d?d?d?d?d?d?d?d纯八位数字比如生日或电话尾号。这个清单跑完通常不超过半小时但命中率相当可观。2.3 字典攻击词表质量决定一切不是词表大小字典攻击的逻辑是拿一份词表逐条尝试还可以附加变异规则——比如首字母大写、末尾加数字、字母替换a 换成 o 换成 0i 换成 1。这条路适合“密码是一个有意义的词”的情况。关于字典攻击最大的误区是以为词表越大越好。我见过有人下载了一个几十 GB 的“超级字典”里面混着各种语言的生僻词、随机字符串、甚至其他项目的泄露密码。跑起来确实壮观但命中率往往不如一个精心构造的几万条小词表。真正有效的词表应该来自你自己的信息场名字的拼音和英文拼写、生日和纪念日的各种数字组合、常用的英文单词、喜欢的书名和歌名、公司的缩写和全称、常去的地方。这些词条加起来可能就几千条但覆盖的是你自己设密码时最可能动用的素材。我一般会先用这个“私人词表”跑一遍再叠加变异规则命中率比通用大字典高得多。变异规则的设计也有讲究。常见的变异包括全部小写、全部大写、首字母大写、末尾追加 1 到 4 位数字、末尾追加一个符号、字母大小写交替、把元音替换成数字、把 s 换成 $、把 a 换成 。这些规则可以组合但组合数会指数增长得有个取舍。我的建议是先用单条规则跑再上两条规则的组合三条以上的组合基本就是在做暴力了不如直接转掩码。还有一个技巧是把字典和掩码串起来用。比如你知道密码是“某个词 两个数字”那就用字典提供前半部分掩码提供后半部分很多工具支持这种混合模式。ARCHPR 本身对混合模式支持有限这时候可以先把词表用脚本加工成带占位符的候选集再喂进去。2.4 明文攻击ZipCrypto 的唯一捷径但条件苛刻这是四种模式里唯一称得上“解密”而非“猜测”的方法也是很多人听说但用不好的方法。原理是这样的ZipCrypto 的加密头里有 12 个字节其中包含一个校验字节而这个校验字节的值可以从文件的 CRC 值推导出来。如果你知道压缩包里某个文件的一部分原始内容至少 12 个字节其中 8 个字节必须连续且起始位置有对齐要求你就能反推出一组内部状态进而还原出用于加密这个文件的密钥流和初始密钥。整个过程是确定性的计算不需要穷举几秒钟就能出结果。听起来很美限制条件也很硬。第一只能对 ZipCrypto 用。AES 加密的 ZIP 不行RAR 和 7z 更不行那些方案在密钥派生阶段就把明文和密钥彻底切断了。第二明文必须至少 12 字节且其中 8 字节连续并在正确的偏移位置上。这个偏移位置通常要求是 12 的整数倍附近实际操作时工具会自动尝试各种对齐方式但如果你的已知明文恰好在文件中间某个位置可能对不上。第三明文必须是文件的原始内容不是重新压缩后的。这一点特别容易翻车——你手上有原始 Word 文档但压缩包里那个是被重新保存过、甚至被压缩软件用不同算法压过的版本字节流变了明文攻击就失效。还有一个隐蔽的条件压缩包不能是“每个文件独立加密”之外的奇怪配置也不能是分卷或者添加了恢复记录的特殊结构绝大多数情况下没问题但极端配置会让工具识别失败。实际操作时ARCHPR 的明文攻击流程大致是选择加密压缩包选“明文攻击”然后指定明文文件。工具会先验证这个明文文件是否真的能对应上包里的某个文件——它会计算明文的 CRC跟包里记录的 CRC 比对。这一步失败基本就宣告没戏通过了才会继续往下算。我遇到过一个典型问题手上有原始文档CRC 也对上了但工具跑完说找不到密钥。后来发现那个文件在压缩包里是分块压缩的而且压缩包里第一个文件的加密头结构和后面文件不一样ZipCrypto 对多文件包的第一个文件有特殊处理。解决办法是换一个包内位置不是第一个的文件作为突破口或者直接用其他工具的明文攻击实现再交叉验证一次。3. 实操全流程从探测格式到拿到明文前面讲的都是判断和原理这一节是完整的动手过程。我按自己实际操作的顺序走一遍你可以照着抄。3.1 第一步识别加密算法与可攻击面先确认三件事。格式和算法用命令行工具查比拿眼睛猜快得多。# 查看压缩包内文件列表与压缩方法 7z l -slt target.zip # 重点看 Method 字段会出现 ZipCrypto 或 AES-256 之类字样 # 如果是 RAR会用 Rar 或 Rar5 标识加密标志位也会显示如果列表能正常显示文件名说明只是内容加密文件名没加密如果列表都读不出来、只报一个密码错误那很可能是开了文件名加密这条路走下去会很难。第二件事确认包的完整性。加密包损坏会导致你试出来的密码无法验证白白浪费一轮。用不带解压的方式测试一遍或者看看文件大小是否与预期一致。第三件事评估明文攻击的可行性。如果格式是 ZipCrypto且包里有你能拿到原始内容的文件这条路应该排在第一位尝试因为它的时间成本是秒级而其他方法可能是小时级。判断方法很简单把包里的文件名列出来逐个对照你手头有没有内容完全一致的原始文件。3.2 第二步掩码跑一遍“人类习惯速查”我的顺序是先去跑一轮高频掩码这是投入产出比最高的一步。具体做法是先建一个小清单把最常见的密码结构排进去每个掩码单独跑跑完一个看结果不要一次性全塞进去。清单大概长这样?d?d?d?d?d?d到?d?d?d?d?d?d?d?d?d纯数字 6 到 9 位覆盖生日、电话尾号、身份证后几位?l?l?l?l?l?l到?l?l?l?l?l?l?l?l纯小写 6 到 8 位?u?l?l?l?l?l?d?d首字母大写单词加两位数字?l?l?l?l?d?d?d?d小写单词加四位数字比如年份?u?u?u?u?d?d?d?d全大写缩写加四位数字这一轮跑完快的话十几分钟。命中就结束没命中也不亏因为排除了一批最可能的结构。参数设置上有几个细节。长度范围要卡死别让工具从 1 位开始慢慢爬。字符集要收窄能确定是数字的位置绝不放大写字母。勾选“保存进度”之类的选项虽然这一轮很短但养成习惯能救急。3.3 第三步字典加规则变异走一轮语义攻击掩码没出结果说明密码不是纯结构化的大概率含词。这一步用字典。词表构造我前面讲过了重点是“私人词表优先”。把名字、生日、常用词、公司缩写这些整理成一个纯文本一行一条注意编码统一用 UTF-8避免出现中文乱码导致候选密码错误。# 词表就是纯文本一行一个候选 # 注意去掉空行和首尾空格这些会浪费尝试次数 grep -v ^$ raw.txt | sed s/[[:space:]]*$// wordlist.txt # 统计一下规模 wc -l wordlist.txt规则变异的部分如果工具自带规则引擎就用工具的没有的话可以用脚本预处理。常见的加工方式是给每条词生成若干变体# 一个极简的变体生成示例思路比代码本身重要 base_words [w.strip() for w in open(wordlist.txt, encodingutf-8) if w.strip()] out set() for w in base_words: out.add(w) out.add(w.lower()) out.add(w.upper()) out.add(w.capitalize()) for n in range(0, 100): out.add(w str(n)) out.add(w.capitalize() str(n)) for sym in [!, , #, ., _]: out.add(w sym) out.add(w.capitalize() sym 1) open(expanded.txt, w, encodingutf-8).write(\n.join(sorted(out)))这段脚本生成的是几十万到几百万量级的候选集配合 ZipCrypto 的速率几十分钟能跑完。如果碰上 RAR3 或 7z这个量级就太奢侈了得把词表砍到几千条以内只保留最高置信度的候选。3.4 第四步上 GPU让速率提升一到两个数量级到这一步如果还没结果说明密码的搜索空间确实大该考虑换硬件了。密码恢复这件事CPU 和 GPU 的差距不是一点点是一到两个数量级。ARCHPR 本身有 CPU 和 GPU 两种计算后端GPU 加速对 ZipCrypto 这类派生成本低的方案提升特别明显对 7z 这种高迭代次数的方案提升有限但仍然可观。除了 ARCHPR另一条路是把哈希提取出来用专门的 GPU 工具跑。提取哈希的做法是用配套的脚本从压缩包里导出校验值# 从 ZIP 提取哈希具体脚本名以你的工具包为准 zip2john target.zip hash.txt # 从 RAR 提取 rar2john target.rar hash.txt # 从 7z 提取 7z2john.pl target.7z hash.txt拿到哈希文件后用 GPU 工具跑字典或掩码。这里要注意模块编号必须和加密方案匹配编号写错会报“无匹配哈希”或者跑出错误结果。模块编号在不同版本间会调整以你本地版本帮助信息里列出的为准别照抄网上的旧教程。命令结构大致是这样# 字典攻击 hashcat -m 模块号 -a 0 hash.txt wordlist.txt # 掩码攻击八位数字示例 hashcat -m 模块号 -a 3 hash.txt ?d?d?d?d?d?d?d?d # 查看进度、中断后恢复 hashcat --status --status-timer30 -m 模块号 -a 3 hash.txt ?d?d?d?d?d?d?d?d--status-timer这个参数很实用它会定期打印当前速率和剩余时间估算你能据此判断还要不要继续。中断之后重新执行同样的命令工具会自动读取进度文件续跑不会从头开始。注意GPU 长时间满负荷运行会降频机箱散热跟不上时速率会掉得很厉害。跑长时间任务前先看一眼温度别把卡跑废了。4. 速度账本不同方案下的时间估算与参数选择我很建议你在按下开始之前先花两分钟把账算一遍。算完你会发现很多“跑一晚上试试”的念头根本不成立而另一些你原本觉得没戏的方向其实很快。4.1 组合数怎么算三种模式各有公式暴力攻击的组合数是字符集大小的长度次方总数 C^L。长度范围是 a 到 b 时要把每一档加起来总数 C^a C^(a1) ... C^b。这里有个容易忽略的点如果 C 比较大最高位那一档会占绝大部分比如 62 字符集从 1 位跑到 8 位8 位这一档占了总数的 98% 以上。所以“从 1 位跑到 8 位”和“只跑 8 位”在时间上几乎没区别别被工具界面上那个范围输入框骗了。掩码攻击的组合数是每一位字符集大小的乘积。?u?u?u?u?d?d?d?d就是 26 乘 26 乘 26 乘 26 乘 10 乘 10 乘 10 乘 10。如果某几位用的是自定义小集合比如三元素的月份集合那就把 10 换成 3。这个乘法很好算但很多人懒得算结果设了一个看着很短、实际组合数爆炸的掩码。字典攻击的组合数是词条数乘以规则数。如果每条词生成 50 个变体词表有 10 万条那就是 500 万次尝试。这个数在 ZipCrypto 上几分钟在 7z 上按每秒 500 次算是 2.7 小时。算完组合数除以你实测的速率就是预估时间。速率一定要实测别信任何网上的数字。跑一个几分钟的小任务看工具显示的“当前速度”那个才是你的真实水平。我拿一个具体例子走一遍。假设手上是个 RAR3 的包你记得密码是“6 到 8 位小写字母加数字”。字符集 36组合数算下来是 36^6 加 36^7 加 36^8约等于 2.8 乘 10^12。实测速率每秒 5000 次时间是 5.6 亿秒折合 17 年。这个结果告诉你必须收窄条件否则不用开始。同样的包如果你想起来“前三位是字母后四位是数字”掩码变成?l?l?l?d?d?d?d组合数 26^3 乘 10^4约 1.76 亿除以 5000大约 9.8 小时。这个就可以接受了挂着跑一晚上。4.2 硬件选择的几个实际经验显卡不是越新越好要看显存带宽和计算单元数量。密码恢复这类计算是典型的整数运算密集型对显存容量要求不高对并行度要求极高。中端卡跑满核心往往比高端卡跑半载更划算。多卡不一定线性加速尤其当工具本身的调度效率一般时。两张卡可能只带来 1.6 倍的提升这时候不如把两张卡分别跑不同的掩码分支覆盖面更广。长时间任务一定要做断点验证。我吃过一次亏跑了三十多个小时中途断电重启后发现进度文件损坏全部重来。从那以后我养成了习惯每跑几小时就手动停一次确认进度能正常恢复再继续宁可损失几分钟也不冒这个险。估算剩余时间时打个折扣。工具显示的剩余时间通常基于理想速率实际会因为降频、系统占用、候选密码分布不均而延长。我一般按显示时间的 1.3 倍做心理预期免得反复查看进度浪费时间。5. 常见问题与排查实录这一节是我这些年遇到的具体问题按出现频率排的。5.1 明文攻击失败的六种原因明文攻击是回报最高也最容易失败的一环我把踩过的坑列出来。第一种明文太短。少于 12 字节基本无效8 字节连续这个要求也经常被忽略。有人拿一个 5 字节的文本文件去试工具直接报错。第二种明文对不上文件内容。你手上的原始文档和压缩包里那份看着是同一个文件实际上版本不同、保存方式不同字节流早就不一样了。判断方法是比对 CRC如果工具报“明文文件 CRC 不匹配”那就彻底没戏。第三种压缩算法不同。同一个文档用不同压缩级别存进包里压缩后的字节流是不同的但明文攻击针对的是压缩后的数据还是原始数据不同工具的假设不一样。ARCHPR 的明文攻击通常要求你提供的是原始文件工具会自己按包里的压缩方式重新压缩一遍再比对。这一步如果失败说明你的压缩软件版本或者压缩参数跟当初不一致。提示为了最大化成功率尽量用与创建压缩包时相同版本、相同压缩级别的软件来准备明文文件。这一点听起来玄实际影响不小。第四种文件在包里的位置特殊。前面提过ZipCrypto 对多文件包的第一个文件有特殊处理加密头结构不一样。解决办法是换一个非首位的文件作为突破口。第五种包被重新打包过。有人把加密包解压出来又重新压缩了一遍这时候 CRC 可能还对得上但加密头和内部状态全变了明文攻击算出来的结果无效。第六种格式判断错误。看着是 .zip 后缀实际是 RAR 改了扩展名或者是个自解压包。用十六进制看前几个字节能确认50 4B开头是 ZIP52 61 72 21开头是 RAR37 7A BC AF 27 1C开头是 7z。5.2 密码找回来了却解不开问题出在哪这是最让人崩溃的情况工具报告命中密码显示在屏幕上复制粘贴去解压提示密码错误。最可能的原因是假阳性。ZipCrypto 的校验位太少错误密码有相当概率蒙混过关。这时候要做的是用完整解压验证或者用工具自带的“验证”功能它会真正解密一段数据来确认。ARCHPR 在报告命中后通常会自动做这个验证但如果你的包是多文件结构验证可能只针对其中一个文件其他文件的密码未必一致。第二个原因是编码问题。密码里含中文、含特殊符号时不同工具对字符编码的处理不一样。Windows 上的压缩软件可能用本地编码GPU 工具可能默认 UTF-8两边对不上就会出这种怪事。解决办法是手动输入密码试一次确认是编码问题后把密码转成对应编码的字节序列再试。第三个原因是包里文件的密码本来就不一样。一个压缩包内不同文件用不同密码加密这在某些工具里是支持的。你恢复出来的是其中一个文件的密码解压另一个自然失败。第四个原因比较隐蔽等价密码。ZipCrypto 的密钥空间存在碰撞理论上可能存在另一个字符串它能解出正确的内容但不是你当初设的那个。这种情况下恢复出来的“密码”看着莫名其妙但确实能用。遇到这种情况别怀疑工具算错了先试试能不能解压。5.3 一份速查表把上面这些整理成表出问题时对着找。现象可能原因处理方式跑了几小时速度只有几百次/秒加密方案派生成本高7z/RAR5收窄搜索空间考虑 GPU或放弃暴力转其他思路明文攻击报 CRC 不匹配明文文件与包内文件内容不一致换文件或用相同版本软件重新生成对照文件明文攻击报“无法定位偏移”明文太短或位于文件中间位置换用文件开头部分确保至少 8 字节连续报告命中但解压失败假阳性或编码不一致用完整解压验证手动确认编码进度无法恢复进度文件损坏或被杀软清理手动停跑验证把进度文件加入白名单多卷压缩包无法识别分卷结构不被支持先合并分卷再对合并后的包操作列表读不出来文件名也被加密放弃明文攻击路线走掩码或字典GPU 跑一半速度骤降温度过高触发降频改善散热降低功耗墙分批跑6. 几个反直觉的实操体会讲几个我实际做下来觉得最有价值的判断可能跟直觉相反。第一先试最笨的那几个密码。我统计过自己处理过的案例相当一部分密码就是123456、888888、生日、手机号尾数、名字拼音加123这种。这类密码在掩码的第一轮就会命中成本是几分钟。很多人上来就设计复杂的字典和规则反而把最简单的可能性漏在最后。第二明文攻击的优先级应该排在最前面而不是最后。因为它成本极低、成功率取决于你手上的素材而不是算力。拿到一个 ZipCrypto 的包第一件事就是翻箱倒柜找原始文件而不是打开软件设参数。我以前也犯过这个错花两天跑字典最后发现包里那个文件的原稿就躺在同一个目录里明文攻击三秒出结果。第三不要迷信大字典。一个几万条的、针对特定目标构造的小词表命中率经常高于几十 GB 的通用字典。通用字典的问题是它覆盖的是“所有人的密码”而你需要的只是“你的密码”。第四时间估算要做而且要做两遍。第一遍在开始前算用来决定要不要做第二遍在跑了十分钟后算用实测速率重新估一次。这两次估算经常差一个数量级因为工具界面上的理论速度跟实际跑起来的速度完全是两回事。第五把每次尝试的参数记下来。我有个文本文件专门记这些包名、格式、试过的掩码、词表规模、耗时、结果。看起来啰嗦但它能避免你在几周后重复跑同一个已经失败过的组合也能让你慢慢摸出自己设密码的习惯规律。这个过程本身挺有意思的像是给过去的自己做了个行为分析。最后提一个后续可以深挖的方向如果目标方案是 AES 系列、派生成本高到暴力不可行那注意力就应该完全转向“找回密码线索”这件事上——翻旧的备忘录、看当时的邮件往来、检查密码管理器的历史记录、问当时一起工作的人。技术手段的天花板往往由你对密码的记忆深度决定而不是由显卡决定。这个认识转变比学会任何工具都值钱。