企业官网建设流程全解析

前阵子接手一台退役的旧工作站，硬盘里堆着几十个加密压缩包，当年打包的人早已离职，交接文档里只留了一句“密码是项目代号加日期”。我按这个线索试了七八个组合，全部落空。最后是靠 ARCHPR 的掩码模式，在四十分钟里把包打开的。这件事让我重新认识了“加密压缩包密码恢复”这件事——很多人对它的理解还停留在“挂个字典碰运气”，实际上 ARCHPR 提供的暴力破解、掩码攻击、字典攻击、明文攻击这四种模式，各有各的适用边界。模式选错，跑一个月也是白跑；模式选对，几分钟就出结果。这篇就把这四种模式的原理、参数怎么定、什么时候该切换，以及我自己踩过的几个坑，一次讲透。适合手上有自己遗忘密码的归档包、或者做取证与资产交接时需要处理加密压缩包的人看，不需要密码学背景，但需要一点耐心。

1. 加密压缩包的密码到底藏在文件的哪个位置

很多人第一反应是“密码肯定存在压缩包里，找出来就行”。这个直觉是错的。压缩包里没有密码，只有密码参与运算后留下的痕迹。理解这一点，后面所有的攻击模式选择才有依据。

1.1 ZIP 的本地文件头与加密标志位

ZIP 文件是由一个个“本地文件头 + 压缩数据”串起来的，每个文件头以0x04034b50这个签名开头。文件头里有一个两字节的通用位标志（General Purpose Bit Flag），其中第 0 位（bit 0）为 1 表示这个文件被加密了，第 3 位（bit 3）表示 CRC 和数据长度写在数据后面的描述符里。用十六进制编辑器打开一个加密 ZIP，搜索50 4b 03 04，往后数第 6、7 个字节，就能看到这个标志位。

加密的 ZIP 里，文件头之后跟着一段12 字节的加密头。这 12 字节里前 10 个字节是打包时随机生成的，最后 1 到 2 个字节是所谓的校验字节（check byte）。如果 bit 3 没置位，校验字节取的是该文件 CRC-32 的最高字节；如果 bit 3 置位了，取的是 DOS 修改时间的高字节。这个细节很关键：它意味着攻击程序每试一个密码，只需要解密这 12 字节、比对 1 个字节，就能否掉 255/256 的错误候选。这就是传统 ZIP 能被跑到每秒上百万次尝试的根本原因。

顺便说一个常被忽略的点：ZIP 加密不加密文件名和目录结构。哪怕密码完全不知道，你依然能看到包里有哪些文件、多大、什么时候改的。这给后面的“猜密码”提供了极其重要的线索——从文件名推断项目代号、从修改时间推断日期格式，往往比盲目跑字典有效得多。

1.2 传统 ZipCrypto 与 AES 加密的代际差别

ZIP 有两种加密体系，性能差异是天壤之别。老式的是ZipCrypto（也叫传统 PKZIP 加密），它的核心是三个 32 位密钥的状态机，初始值固定为：

key0 = 0x12345678 key1 = 0x23456789 key2 = 0x34567890

每处理一个明文字节，三个密钥按固定规则滚动更新：

def crc32(crc, b): return (crc >> 8) ^ CRC_TABLE[(crc ^ b) & 0xff] def update_keys(key0, key1, key2, c): key0 = crc32(key0, c) key1 = (key1 + (key0 & 0xff)) & 0xffffffff key1 = (key1 * 134775813 + 1) & 0xffffffff key2 = crc32(key2, (key1 >> 24) & 0xff) return key0, key1, key2

解密时用 key2 派生一个字节的密钥流，与密文异或：

temp = (key2 | 2) & 0xffff stream_byte = ((temp * (temp ^ 1)) >> 8) & 0xff plain_byte = cipher_byte ^ stream_byte

整个流程只有查表和几次乘加，单次密码验证的开销极小。这就是为什么同一个密码，ZipCrypto 包可能几分钟就跑出来，AES 包却要跑上天。

新式的是AES 加密（WinZip AES / AE-x），它用 PBKDF2-HMAC-SHA1 对密码做 1000 次迭代，派生出加密密钥和认证密钥，再用 AES-CTR 模式加密数据，末尾附 10 字节 HMAC 校验。1000 次迭代意味着每验证一个候选密码，计算量是 ZipCrypto 的成百上千倍。表 1 是我实测的粗略速度对比，硬件是普通四核笔记本：

这张表基本决定了一切策略：面对 ZipCrypto，暴力破解是可行选项；面对 AES 和 RAR5，暴力破解基本等于放弃，必须转向字典、掩码缩小空间，或者干脆另想办法。

1.3 为什么“把密码读出来”在数学上不成立

从上面的算法能看出，密码在加解密过程中被单向揉进了密钥状态，最终只留下 12 字节的加密头。你想从加密头反推密码，等价于解一个不可逆的哈希问题。这不是工具不够强，而是设计上就不允许。

所以 ARCHPR 这类工具干的事，本质是高速枚举 + 快速验证，不是“解密”。它每次都完整地走一遍“把候选密码当密钥 → 解密头部 → 比对校验字节 → 命中则继续解压验证”的流程。ARCHPR 比裸比对多做一步：校验字节有 1/256 的误报率，命中后它会再解压一小段数据核对 CRC，确认是真的找到了。这一步增加了一点点开销，但避免了大量的假阳性，实际用起来反而省时间。

理解了这个底层结构，四种攻击模式的定位就清楚了：它们都是“生成候选密码”的策略，区别只在于如何用最少的候选覆盖最大的可能性。

2. 四种攻击模式的适用边界与选择逻辑

ARCHPR 的 Attack type 下拉框里列着 Brute-force、Mask、Dictionary、Plain-text 几项，还有一个 Auto。新手最常见的错误是从上往下挨个试，正确的做法是先想清楚“我对这个密码知道多少”，再决定用哪个。

2.1 暴力破解：只有在搜索空间可计算时才值得开

暴力破解是穷举字符集的所有组合。ARCHPR 里要设三个东西：长度范围（Min/Max length）、字符集勾选（Charset）、以及是否包含空格等特殊项。搜索空间的计算很直接：

搜索空间 = 字符集大小 ^ 密码长度

比如勾选 26 个小写字母 + 10 个数字，字符集是 36，长度固定 8 位，就是 36^8 ≈ 2.82 万亿。按每秒 150 万次算，需要约 2.18 万秒，也就是 6 小时出头。如果勾上大写字母变成 62 个字符，62^8 ≈ 2.18 万亿 × 100，直接飙到 25 天。

我习惯在开跑前先算一遍这个数，超过 3 天的一律不碰暴力模式。有个快速心算法则：字符集每增加一倍，时间翻一倍；长度每增加一位，时间乘以字符集大小。所以“多试一位”的代价远大于“多勾几个字符”。

暴力破解真正有价值的场景其实很窄：密码很短（6 位以内），或者你已经通过某种渠道确认了密码字符构成，只是不知道顺序。比如一位做设备维护的同行，他们车间的旧压缩包密码统一是 6 位纯数字的工号，这种场景暴力模式几分钟就能扫完，没必要上别的花招。

一个实操细节：ARCHPR 的暴力模式支持设置起始密码和结束密码，用来做分段并行。如果你有多台机器，可以把 00000000 到 49999999 分给一台，50000000 到 99999999 分给另一台，各自跑，互不干扰。这个功能在处理大空间时非常实用，比单机死磕快一倍。

2.2 掩码攻击：把“我大概记得”翻译成搜索空间

掩码攻击是我用得最多的模式，也是 ARCHPR 里性价比最高的一项。它的思路是：把密码切成“确定的片段”和“不确定的片段”，不确定的部分用占位符表示。

ARCHPR 的掩码语法和同类工具基本一致，常用占位符如下：

举个我实际遇到的例子。开头提到的那个包，交接文档写“项目代号加日期”。我从文件名和目录结构判断出项目代号是四个字母、首字母大写，日期是四位年份加两位月份。于是掩码写成：

?u?l?l?l?d?d?d?d?d?d

看起来是 10 位，但实际搜索空间只有 26 × 26 × 26 × 26 × 10^6 ≈ 1.19 万亿？不对，这里要算清楚：26^4 × 10^6 = 456976 × 1000000 ≈ 4.57 × 10^11，还是太大。

进一步收窄：项目代号的四个字母其实是英文单词，不是随机组合，所以我把前四位改成字典攻击，后六位用掩码。ARCHPR 不支持这种混合，我的做法是先生成一个“四位单词 + 六位数字”的组合词表，再喂给字典模式。这个思路后面会展开。

如果实在记不清长度，可以勾选“长度范围”，让工具在 6 到 10 位之间逐个长度尝试。但要注意，长度范围会让总空间变成各长度之和，别一不小心把范围开得太宽。

掩码模式最忌讳的是“过度自信”。有人记得“密码里有个 2019”，就把 2019 硬编码进去，结果密码里其实是 2018。我的建议是：能确定的部分硬编码，稍微不确定的就用占位符包住，宁可多跑一些空间，也别因为一个字符猜错而全盘落空。

2.3 字典攻击：词表质量决定一切

字典攻击是拿一个词表文件，逐行当密码试。它的上限完全由词表决定——词表里没有的密码，跑一万遍也出不来。

很多人以为词表越大越好，动辄下载几十 GB 的泄露密码合集。实测下来这个思路效率很低：大词表里充斥着和目标场景无关的内容，跑完要很久，命中率却不见得高。真正有效的是场景化词表。

我的做法是根据目标环境手工构造词表，通常包含这几类：

• 项目名、产品名、部门名的各种大小写和缩写变体
• 人名拼音、工号、内网主机名
• 常见年份、月份、节日、纪念日与上述词根的各种拼接
• 键盘序列（qwerty、1qaz2wsx 这类）及其变形
• 公司名 + 常见后缀（123、!、@、2023 等）

ARCHPR 的字典模式有几个选项值得打开：“尝试所有大小写组合”会把每个词的首字母大写、全大写、全小写都试一遍，代价是候选数翻几倍；“在词后附加数字”可以指定附加 1 到 4 位数字，这个功能非常实用，因为“词根 + 数字”是最常见的密码构造方式。

词表的编码要特别注意。如果密码里可能有中文，词表必须存成 UTF-8，并且确认工具按 UTF-8 解析。我遇到过一次，词表是 GBK 编码，工具按 UTF-8 读进去全是乱码，白跑了两小时才发现。

2.4 明文攻击：唯一能跳过枚举的思路

前三种模式的本质都是“猜密码”，只是猜的方式不同。明文攻击完全不同——它不需要猜密码，而是利用 ZipCrypto 算法的结构性弱点，从已知明文反推出内部密钥状态，再倒推出密码。

这个模式的前提条件很苛刻：你必须拥有加密包中某一个文件的未加密原始版本。比如加密包里有一个report.docx，而你手上恰好有这份文档的原始文件，那就满足了条件。

具体原理和实操细节放在第 4 节展开，这里先给出结论：在满足条件的情况下，明文攻击的耗时是分钟级甚至秒级，与密码长度完全无关。一个 20 位的强密码，暴力破解要跑到宇宙热寂，明文攻击可能 30 秒就出结果。这就是为什么它是四种模式里唯一能对付长密码的选项。

2.5 Auto 模式：不是万能的，但适合做第一轮试探

ARCHPR 还有一个 Auto 模式，会自动按“高频密码 → 短字典 → 小范围掩码”的顺序组合尝试。它的定位是快速筛掉“弱密码”这种情况。

我的用法是：拿到一个包，先跑十分钟 Auto，同时手工分析包体信息。如果 Auto 命中了，省事；没命中，这十分钟也没浪费，因为它已经排除了一大类可能性，接下来就该认真设计掩码或字典了。

不要指望 Auto 能解决复杂情况。它的策略是通用的，而通用策略在具体场景下往往不够精准。

3. 一次完整的恢复实战：从包体侦察到参数落地

光讲理论没意思，把上面这套流程完整走一遍，你会更清楚每一步在干什么。下面这个案例是我帮一位做档案整理的朋友处理的，包是他自己五年前打的，密码忘得干干净净。

3.1 第一步永远是侦察，不是开跑

拿到包的第一件事，绝对不是打开工具点开始。先做三件事：

看文件名和目录结构。用解压软件打开（不用输密码就能看到列表），看里面有哪些文件、命名规则是什么、有没有分层目录。这个包里有 200 多个文件，命名格式统一是2020-03-项目A-周报.docx，说明打包时间是 2020 年 3 月左右，密码很可能与这个时间段或项目名相关。

看包的元信息。右键属性看创建时间、修改时间。这个包的创建时间是 2020-03-15 下午 4 点多，结合周报的日期，密码里含2020或0315的概率很高。

确认加密类型。这一步很重要，直接决定可行性。用十六进制编辑器看文件头，或者用解压软件尝试打开时的报错信息判断。传统 ZipCrypto 的包，某些工具会提示“使用了传统加密”；如果包里出现AE开头的额外字段，那就是 AES 加密。这个包确认是 ZipCrypto，好消息。

侦察阶段花二十分钟，能让后面的搜索空间缩小几个数量级。跳过这一步直接开跑，是最常见的浪费时间的方式。

3.2 把模糊记忆翻译成可执行的参数

朋友回忆说：“密码应该是项目名加日期，可能还有几个符号，长度大概十来位。”这句话信息量其实很大，但需要翻译。

先确定项目名。从文件名看是“项目A”，但实际项目代号可能是英文缩写。我问了他几个可能的写法：ProjectA、projA、PA、XMTA。他确认内部代号是四个字母的英文，首字母大写。于是前四位锁定为?u?l?l?l，但这四个字母是真实单词，不是随机组合，所以我准备了一个包含几十个候选词的小词表。

再确定日期部分。朋友说“大概是年月”，那就是 6 位数字。但年份可能是 2019 或 2020，月份是 01 到 12。这里用掩码?d?d?d?d?d?d会让空间变成 10^6，太大。我的处理是把年份和月份的可能组合枚举出来，做成一个只有几十行的日期列表。

最后是“可能还有几个符号”。这种模糊描述最麻烦。我做了两个版本：一个版本不带符号，一个版本在末尾加一位符号（?s，约 32 种）。两个版本分别跑，先跑不带符号的。

最终方案是：生成一个“词根 × 日期 × 可选后缀”的组合词表，用脚本生成，大约 8 万行，喂给字典模式。这个数量级在 ZipCrypto 上跑起来只要几分钟。

用脚本生成词表的思路很简单，伪代码如下：

roots = ["ProjectA", "ProjA", "PA", "P2020"] dates = ["201912", "202001", "202002", "202003"] suffixes = ["", "!", "@", "#", "123"] with open("wordlist.txt", "w", encoding="utf-8") as f: for r in roots: for d in dates: for s in suffixes: f.write(f"{r}{d}{s}\n") f.write(f"{r}@{d}{s}\n") f.write(f"{r}_{d}{s}\n")

这个脚本生成的组合还不够多，实际我还加了首字母大小写变体、年月日的不同排列顺序。总共 8 万多行，跑完不到十分钟。

3.3 跑起来之后的参数调整与断点续跑

ARCHPR 跑起来之后，界面上会显示当前速度、已尝试数量、预计剩余时间。有几个设置会明显影响速度：

线程数。默认会自动识别 CPU 核心数，但如果你的机器同时在干别的事，可以手动调低一两档，避免抢占资源导致整体变慢。实测在四核机器上，开满四线程比开两线程快约 1.8 倍，不是 2 倍，因为存在调度开销。

界面刷新频率。ARCHPR 默认会频繁刷新进度显示，这在高速运行时反而成了负担。可以在设置里把刷新间隔调大，或者在长时间运行时最小化窗口。

优先级。如果机器还要干别的，把进程优先级设为“低于正常”，让它吃剩余算力，比抢资源导致系统卡顿要好。

断点续跑。这个功能必须用起来。ARCHPR 支持保存当前状态到文件，中断后可以恢复。跑大空间的时候，我一般每半小时存一次状态，防止断电或误操作导致前功尽弃。恢复的时候要注意，状态文件里记录的是当前进度位置，如果中途改过参数（比如改了字符集），恢复会失效。

这个包最终是在字典模式的第 3 万多条命中的。密码是ProjectA@202003。朋友看到结果说“对对对就是这个”，然后补了一句“我明明记得有感叹号的”——所以那些“可能还有符号”的模糊记忆，还真不能忽略。

3.4 没跑出来怎么办：策略回退的顺序

失败是常态。我处理过的包里，一次就跑出来的不到三成。跑不出来的时候，回退顺序很重要，乱试只会浪费时间。我的一般顺序是：

第一轮回退：换词表。字典跑完没命中，先别急着换模式。检查词表是否覆盖了目标场景。补充人名、地名、方言拼音、缩写变体，再跑一遍。很多失败是因为词表不够贴合。

第二轮回退：放宽掩码。如果掩码里有硬编码的部分，把它改成占位符。比如把Project2020改成?u?l?l?l?l?l?l?d?d?d?d。代价是空间变大，但避免了“一个字符猜错满盘皆输”。

第三轮回退：缩短长度范围，先跑短密码。人的密码习惯往往是短的先设，后来才改成长的。先跑 6 到 8 位，再跑 9 到 12 位，很多时候答案在短的那一档。

第四轮回退：确认加密类型是不是搞错了。如果包其实是 AES 加密，那前面所有的高速尝试都是徒劳的。重新确认一遍，避免方向性错误。

第五轮回退：考虑明文攻击。如果能找到包里任一文件的原始版本，这条路比继续猜密码靠谱得多。

4. 明文攻击为什么能绕过搜索：ZipCrypto 的已知明文弱点

这是四种模式里技术含量最高的一种，也是最多人搞不明白的一种。很多人试了一次提示“明文文件不匹配”就放弃了，其实问题出在准备工作上。

4.1 从已知明文反推密钥状态的数学路径

回顾第 1 节的算法：ZipCrypto 的解密是“密文字节 XOR 密钥流派生字节”。如果你同时知道某个位置的密文字节和对应的明文字节，就能直接算出那个位置的密钥流字节：

stream_byte = cipher_byte XOR plain_byte

而密钥流字节是由 key2 派生的：

temp = key2 | 2 stream_byte = ((temp * (temp ^ 1)) >> 8) & 0xff

这个式子只涉及 key2 的低 16 位，可以反解出 key2 的低 16 位的 64 种可能值（因为只用了低 16 位，高位信息丢失）。有了这 64 个候选，再结合后续字节的约束逐步筛选，就能把完整的三个密钥状态确定下来。

一旦内部密钥状态确定，剩下的工作就是“倒推密码”。因为密钥更新是可逆的，从某个已知状态往前推，可以还原出初始状态；而初始状态是由密码逐字节更新得来的。理论上可以直接反算出密码，实际实现中通常是用已知的密钥状态去验证候选密码，或者用“字典 + 快速验证”的方式，此时每个候选的验证成本极低，可以跑很大的词表。

关键在于：ZipCrypto 的算法强度不足以抵抗已知明文攻击。12 字节的加密头加上已知的明文内容，信息量远远超过了密钥状态所需。这是设计年代的局限，不是实现 bug。

4.2 准备“已知明文”的三个硬性条件

明文攻击失败，九成以上是准备阶段出的问题。要成功，必须同时满足三个条件：

条件一：文件内容完全一致。你手上的原始文件，和压缩包里那个文件的解压后内容必须逐字节相同。差一个空格都不行。有人拿“差不多”的版本来试，结果当然是失败。

条件二：压缩方式和压缩级别一致。这一条最容易被忽略。明文攻击需要先把你提供的原始文件按同样的参数压缩，再和包里的密文比对。如果原包是用 Deflate 最高压缩级别压的，你提供的文件被工具用默认级别压，压缩后的字节流就不一样，比对必然失败。

实际操作中，ARCHPR 会自己尝试压缩你提供的文件。但如果你不确定原包的压缩参数，可以多做几个版本：用不同压缩级别各压一份，分别试。还有一个更稳的办法：如果能找到原包里的**存储模式（Store，即不压缩）**文件，那就完全不存在压缩参数问题，因为存储模式的字节流就是原始内容。

条件三：加密方式必须是 ZipCrypto。AES 加密的 ZIP 做不了明文攻击。原因在 1.2 节讲过：AES 的密钥是由 PBKDF2 从密码派生的，密钥流和密码之间隔着一层单向函数，已知明文只能反推出密钥流，反推不出密码。有些工具声称能对 AES ZIP 做“明文攻击”，实际做的是恢复内部密钥而不是恢复密码，拿到密钥后能解密文件，但你依然不知道密码是什么。这两种结果在实践中价值不同，要分清楚。

还有一个补充条件：已知明文的长度。理论上 12 字节就够启动，但实践中建议提供完整文件，或者至少几百字节。太短的明文会让候选状态爆炸，筛选过程变慢。

4.3 一个能跑通的明文攻击流程

还是用实际案例说明。有个包，里面有一个config.ini，加密了。这位用户手上恰好有这份配置文件的原始版本——因为它是从服务器上拷贝下来打包的，服务器上还留着原件。

流程是这样的：

先确认包里config.ini的压缩方式。用解压软件看文件信息，显示是 Deflate，压缩后大小 1247 字节。然后确认原始文件大小一致。

打开 ARCHPR，选择 Plain-text 模式，指定加密的 ZIP 包，然后在“Plain-text file”里指定原始config.ini的路径。工具会自动尝试压缩这个文件并比对。

第一次跑，提示“明文文件不匹配”。原因排查：原包的 Deflate 压缩级别是最高级，而工具默认用的是普通级。我把原始文件用最高压缩级别重新压了一遍（用一个支持指定压缩级别的命令行工具，压成 zip 后提取出压缩数据，或者直接用工具提供的“指定压缩级别”选项），再试，这次匹配上了。

匹配成功之后，进度条走得飞快，大概二十几秒就出了结果。密码是一个 16 位的随机字符串，包含大小写字母、数字和符号。如果靠暴力破解，这个密码的空间是 95^16，约 4.4 × 10^31，按每秒 150 万次算需要 9 × 10^17 年。明文攻击二十几秒解决。

这个对比很能说明问题：明文攻击的价值不在于快，而在于它突破了搜索空间的限制。密码多长、多复杂都无所谓，只要条件满足。

5. 速度、时间与踩坑：那些文档里不会写的经验

工具会用是一回事，用好是另一回事。这一节全是实操中攒下来的东西，有些是吃了亏才明白的。

5.1 时间估算：开跑前必须算的那笔账

我见过太多人挂上工具就去睡觉，第二天起来发现进度条才走了 0.3%。开跑前花两分钟算一下，能省下大量时间。

计算分三步。第一步算搜索空间：字符集大小 ^ 长度，如果有多个长度，就把各长度相加。第二步估算速度：ZipCrypto 在四核 CPU 上大约 150 万次每秒，AES 大约 3000 次每秒，RAR3 大约 800 次每秒。这些数字随硬件浮动，但量级是对的。第三步除一下，得到秒数，再换算成天。

表 2 是我整理的速查表，覆盖常见场景：

看到这个表就明白了：AES 加密的包，长度超过 6 位基本就别想暴力了，必须走字典或掩码。RAR5 更极端，长度超过 5 位就要慎重。

还有一个容易被忽略的因素：验证成本随文件数量变化。如果压缩包里有 200 个文件，工具在命中校验字节后要多做几次验证，速度会略微下降。但主要还是由加密类型决定。

5.2 常见失败原因的排查表

跑不出结果的时候，按表 3 的顺序排查，能覆盖 90% 的情况：

其中“词表行尾有\r”这个坑我踩过不止一次。Windows 上生成的词表默认用 CRLF 换行，某些工具读取时会带上\r，导致密码末尾多一个不可见字符，永远不匹配。解决方法是保存时选 Unix 换行，或者用脚本做一次清洗：

with open("raw.txt", "r", encoding="utf-8", errors="ignore") as f: lines = [ln.strip() for ln in f if ln.strip()] with open("clean.txt", "w", encoding="utf-8", newline="\n") as f: f.write("\n".join(lines))

另外还有个小细节：如果密码首尾可能有空格，strip()会把它去掉。这种情况要单独处理，用rstrip("\r\n")更安全。

5.3 授权边界与更靠谱的替代路径

技术之外说几句实话。这类工具的使用边界很清楚：只能用于你自己拥有并有权处理的文件，或者已经获得明确授权的取证和资产交接工作。帮别人处理之前，让对方出具一份简单的授权说明，写清楚文件来源和处理目的，这既是保护对方也是保护自己。这条线不能模糊。

在动手之前，其实还有很多更省事的路径值得先试。最直接的：去问打包的人。我经手的案例里，有相当一部分最后是通过“翻聊天记录找到当时发的密码”“问离职同事要回密码”解决的，比跑工具快得多。

其次，检查有没有密码管理器、便签、邮件草稿、旧手机备忘录留下了线索。很多人设密码时会顺手记在某处，只是自己忘了。

再次，看看这个包是不是有其他副本。同一个内容被打包过多次的情况很常见，也许某个旧版本用的是简单密码，甚至没加密。拿到旧版本的密码，往往能推断出新版本的构造规律。

最后，如果包里的内容还有其他来源（比如原始文件在别处有备份），那根本不需要破解，直接从源头重新获取即可。

工具是最后手段，不是第一选择。我见过有人为了打开一个自己早就忘了内容的包，跑了三天三夜，最后发现里面的东西服务器上全都有备份。这种时间浪费，比技术上的失败更让人难受。

5.4 我个人的参数习惯

最后分享几个我固定会用的配置，都是踩坑之后定下来的。

掩码设计上，我永远把最可能的字符放在前面。ARCHPR 是按顺序穷举的，把高概率字符排在前面，命中来得更早。比如确定首位是大写字母，就把?u放在最前；如果确定末位是数字，就把?d放最后。这个顺序调整看着不起眼，实际能省掉大量等待。

字典准备上，我习惯准备三份词表分轮次跑：第一份是 50 行以内的核心候选，第二份是几千行的场景词表，第三份才是几万行的扩展组合。先跑小的，快出结果，也快排除错误方向。

跑长任务时，我一定开日志。ARCHPR 的日志会记录尝试速度和状态变化，跑完后回看日志，能判断“是不是参数设错了导致速度异常”，也能在下一次跑类似任务时参考时间估算。

还有一点：不要在同一个包上反复试同一套参数。没结果就是没结果，改参数再试。我曾经在一个包上把同一个词表跑了三遍，就因为“觉得可能是编码问题”，结果第三遍才想起来去检查加密类型——是 AES，前面全白跑。

这套东西说到底，核心就一句：先搞清楚自己知道什么，再决定用什么模式去补那部分不知道的。工具只是把手，判断力在脑子里。