crunch密码字典生成实战：5个定向口令爆破技巧详解

做渗透测试或者内网口令评估的人应该都有这种体会：手头的字典攒了一堆，真正对上目标账号的没几条。尤其是碰到那种“有安全意识但不多”的目标——密码不是123456，也不是Tr0ub4dor&3，而是姓名首字母加生日再拼个符号。通用字典基本只能靠运气，真正有效的出路是现场生成一份贴着目标习惯的定向字典。

crunch是Kali Linux里最老牌、最稳的密码字典生成工具之一，体积小、参数全、生成速度快。这篇文章我把自己常用的5个实战技巧完整写一遍，从字符集指定、模式匹配、过滤去重，到挂hashcat规则链、输出控制和断点续传，每个技巧都会给出命令示例和背后的思路。适合刚接触口令安全的新手，也适合想把手头字典流程化、定制化的老手。

注意：以下内容仅用于授权范围内的渗透测试、漏洞评估、CTF比赛或者自己的实验环境，任何针对真实系统的口令测试都必须先获得书面授权。

1. 技巧一：自定义字符集准确指定，别让字典生成无意义的组合

1.1 先搞懂crunch最基础的参数

crunch的核心用法一句话就能讲清：

crunch <最小长度> <最大长度> [字符集] [选项]

不指定字符集时，crunch默认使用26个小写字母abcdefghijklmnopqrstuvwxyz。很多人第一次用会踩这个坑：明明想生成小写+数字的8位密码，直接敲了crunch 8 8，等半天生成的全是字母，完全用不上。原因就是没有显式给出字符集。

正确定义字符集的方式是把字符集直接作为第三个参数：

crunch 8 8 abcdefghijklmnopqrstuvwxyz0123456789 -o dict.txt

这行命令会生成所有由小写字母和数字组成的8位密码，输出到dict.txt。

常见的字符集还可以从Kali自带的字符集文件里引用，文件在/usr/share/crunch/charset.lst。先看一下里面有什么：

cat /usr/share/crunch/charset.lst

里面定义了很多现成的字符集，比如lowercase、uppercase、numeric、mixalpha、mixalpha-numeric、hex-lower等。引用方式是用-f参数：

crunch 8 8 -f /usr/share/crunch/charset.lst mixalpha-numeric -o dict.txt

这条命令等价于用大小写字母加数字的集合生成8位密码。写起来比手工敲一长串字符集清爽，也不容易漏字符。

1.2 字符集里有哪些隐形的坑

用自定义字符集时有三个细节特别容易翻车。

第一个细节，字符集里面不能有重复字符。比如你写crunch 6 6 abcabc123 -o out.txt，crunch会直接报错，提示字符集里有重复项。信息大概是：

crunch: FATAL: Charset set 'abcabc123' contains duplicate characters, please modify charset set to not contain duplicates

如果你是从某个文本文件里提取字符集，先做一次去重再喂给crunch。比如用sort -u处理过后再拼进命令行。

第二个细节，特殊字符在shell里有含义。想生成包含!、#、$的密码时，命令行里直接写会被shell解释掉。正确的做法是把字符集用单引号包起来：

crunch 6 6 'abcd!#$' -o special.txt

第三个细节，字符集的顺序决定了字典的输出顺序。crunch会按照字符集字符串从左到右的顺序进行组合，靠前的字符组合会先被输出。这意味着如果你希望字典按某种优先级排列，可以把最可能出现的字符放在最前面。我在实战中会有意把目标可能用的字符往前放，生成的字典优先级高，爆破时往往能更快命中。

提示：在用crunch之前，先算一下组合数量。6位长度、20个字符的字符集，组合数是20的6次方，也就是6400万条，落盘要好几个GB。字符集每多一个字符，体量都是指数级增长。心里要有一本账。

2. 技巧二：用模式匹配锁定目标密码的“长相”

2.1 占位符规则：@、,、%、^

信息收集做完之后，目标密码往往不是完全未知的，而是“看起来应该长什么样”。比如某公司要求密码必须包含大写字母、数字和特殊符号，或者某人习惯用姓名拼音首字母加生日。这种时候用-t模式把密码骨架固定下来，效率远高于全量穷举。

crunch的-t参数支持以下几类占位符：

举个例子，生成“5位数字+2位小写字母”的7位密码，命令是：

crunch 7 7 -t %%%%%@@

生成结果是00000aa、00000ab、00000ac……一直到99999zz。

再比如公司要求密码格式是“大写字母开头+小写字母+数字结尾”，固定模式就是：

crunch 8 8 -t ,@@@@@@%

2.2 从信息收集到密码骨架：一个完整推导案例

模式匹配最有价值的地方在结合社工信息做定向生成。我拿一个黑盒场景举例，目标信息已脱敏，纯演示。

假设目标账号绑定的信息是：

• 姓名：Li Wei
• 出生年份：1990
• 常用昵称：lw
• 所在地简称：bj

一个常见的密码习惯是“姓名首字母+生日日期+特殊符号”。骨架大概是lw加上8位数字再加一个!。固定字符可以直接写在-t模式里，不需要占位符：

# 生成 lw + 8位数字 + ! 的11位密码，例如 lw19900101! crunch 11 11 -t lw%%%%%%%%!

这条命令会把lw和!当作固定字符，中间8个%逐位穷举数字。

再深入一层。如果目标习惯用邮箱前缀当密码，密码包含@符号，那就有一个大坑：@在-t模式里默认是小写字母占位符，不是普通字符。你想生成abc@123这种密码，直接写模式会被crunch理解成别的东西。解决办法是加-l参数，把模式中第一个@按字面值处理：

# 把 @ 当作固定字符而不是小写字母占位符 crunch 7 7 -t abc@%%% -l @

这条命令生成的是abc@000到abc@999。如果少了-l @，生成结果就完全变了。这个细节我在实战里被坑过一次，当时为了生成邮箱类口令，跑了半天发现生成的全是以abc开头的随机小写字母组合，而不是包含@符号的密码。

2.3 模式匹配和字符集怎么配合

-t模式下，占位符使用的字符范围仍然由命令行里的字符集决定。比如你想生成3位数字+1位特殊字符的密码，但特殊字符只希望从!#$三个中选：

crunch 4 4 '0123456789!#$' -t %%%

这里有个天然限制：字符集会对所有占位符生效，crunch没办法为数字位和特殊符号位分别指定不同的字符集。所以更灵活的做法是，把最确定的几位直接写成固定字符，只对不确定的几位用占位符穷举。骨架推导得越准，需要穷举的位数就越少，字典体积断崖式下降。

3. 技巧三：过滤和去重参数压缩字典体积，提高命中密度

3.1 用-d参数限制相同字符连续出现

人性化的密码一般不会出现连续一串相同字符，比如aaaaab01这种，对用户来说很难记住，但穷举字典会照单全收，白白浪费空间和时间。

crunch的-d参数可以限制同一类字符的连续出现次数：

crunch 8 8 abcdefghijklmnopqrstuvwxyz0123456789 -d 2@ -o dict.txt

-d 2@的意思是：小写字母最多连续出现2个。这样aab12345会保留，aaab1234会被剔除。同理，-d 2%限制数字最多连续2个，-d 3,限制大写字母最多连续3个。

这个参数对字典体积的削减能力很强。以8位、26个小写字母字符集为例，不限制连续重复的规模是26的8次方，约2088亿条。加上限制后，那些aaaaaaab、bbbbbbbc这类人类几乎不会设置的密码被大量剔除，剩下的候选更贴近真实口令。

实操心得：不建议把所有连续重复都禁掉，因为现实中确实有人用www2024这种连续重复。一般限制到2或3次比较合适，具体看业务场景。

3.2 用-p参数做候选词排列组合

还有一类目标密码是多个单词、数字拼接的，比如liwei1990、lw2024!、chengdu2023。这种密码用纯字符穷举几乎不可能覆盖，但用-p参数做候选词排列组合就特别快。

-p参数不关心长度和字符集，它把后面给出的候选词进行全排列并拼接：

crunch 0 0 -p Li Wei 1990

输出类似：

1990LiWei 1990WeiLi Li1990Wei LiWei1990 Wei1990Li WeiLi1990

这里0 0是固定写法，因为在-p模式下长度参数实际被忽略。

如果还想把符号加进去，直接作为候选词即可：

crunch 0 0 -p Li Wei 1990 '!'

感叹号在bash里会被解释成历史命令符号，必须用单引号包起来。生成的排列会把!放在任意位置，比如LiWei1990!、Li1990!Wei等。

我通常在信息收集阶段会从以下资料里抽取候选词：

• 姓名拼音及首字母（大小写变体）
• 生日（年份、月日、完整日期）
• 电话号码后几位
• 城市、公司名缩写
• 常用网名、英文名
• 有概率出现在口令里的爱好词、团队名等

把这些候选词喂给-p，生成的组合覆盖度很惊人。这个技巧对中文互联网场景尤其好用，因为大量口令都是拼音或姓名加数字的拼接形态。

3.3 管道配合grep二次筛选

crunch自带的过滤能力之外，还可以直接接到其他文本处理工具上做二次筛选。crunch生成的字典支持stdout输出，管道是天然的筛选通道。

常见筛选场景和命令：

只保留以数字结尾的密码：

crunch 8 8 abcdefghijklmnopqrstuvwxyz0123456789 | grep '[0-9]$' > tail_num.txt

剔除包含连续三位数字的密码：

crunch 8 8 abcdefghijklmnopqrstuvwxyz0123456789 | grep -v '[0-9][0-9][0-9]' > no_3digits.txt

按行数截取前N条：

crunch 10 10 abcdefghijklmnopqrstuvwxyz | head -n 100000 > top100k.txt

这个思路的核心是：crunch负责穷举，grep负责筛掉不符合人类习惯的条目。组合起来不但更快，还能避免先把超大字典落盘再处理，节省大量磁盘空间。

注意：管道中grep会实时处理crunch的输出流，内存占用很平稳。但管道叠加多级筛选会降低生成速度，能一次写完的筛选条件就不要拆成多条管道逐级过滤。

4. 技巧四：联动hashcat规则链，用几万条基础词爆出百万级成果

4.1 为什么推荐“小字典+规则链”

很多人在生成字典时容易犯一个错误：为了“全面”生成几个GB甚至几十GB的超大字典，结果写盘慢、爆破慢、还占满整个测试机硬盘。实际上，现代口令爆破的主流思路早就变成了“基础字典+规则链”。

规则链的原理很简单：拿每一条基础密码当种子，按规则自动产生变体。比如基础词admin，经过“首字母大写+尾部加两位数字+字母o替换为0”这套规则后，会变成Admin00、Adm1n00等。人脑里常见的密码变形规律，一套规则就覆盖了。

hashcat自带规则文件的位置在/usr/share/hashcat/rules/，常用几个：

• best64.rule：官方精选，覆盖最常见的64种变形
• leetspeak.rule：字母转数字的l33t规则
• rockyou-30000.rule：从rockyou泄露库中统计出的高频规则
• d3ad0ne.rule：比较激进，变体量很大

4.2 实战用法：crunch出基础词，hashcat出变体

流程分三步。先用crunch生成一批基础词，不管多少，能贴题就行。比如我们通过前面的模式匹配生成一个只有几千条的基础字典：

crunch 0 0 -p Li Wei 1990 '!' -o base.lst

然后用hashcat的--stdout模式把规则跑出来，重定向到最终字典：

hashcat --stdout -r /usr/share/hashcat/rules/best64.rule base.lst > expanded.txt

这一步会把base.lst里的每条词按best64.rule生成几十上百条变体，最终expanded.txt可能直接膨胀到几十万行。

如果你在爆破的是哈希值而不是在线服务，还可以跳过落盘步骤，直接让hashcat读取基础字典，配合规则现场扩展：

hashcat -m 22000 hash.hc22000 base.lst -r /usr/share/hashcat/rules/best64.rule -O -w 3

这个例子里的-m 22000对应WPA握手包，如果是NTLM哈希换成-m 1000，其他哈希类型查hashcat帮助文档就行。用这套流程，你不需要让字典“覆盖所有可能性”，只需要让基础词加规则覆盖目标最可能的密码习惯，命中率和效率都比硬跑巨型字典高一个量级。

4.3 自己写规则文件，精确模拟目标习惯

除了内置规则，完全可以按目标习惯写一个规则文件。规则文件语法很直观，一个规则一行。比如：

$2$0$2$4

这行的含义是在每条密码末尾追加2024。$2表示追加字符2，$0表示追加字符0，以此类推。

想在末尾追加!，写：

$!

把基础词首字母大写，写：

c

比如做一份针对“姓名组合加年份”的定向规则：

$1$9$9$0 $2$0$2$3 $2$0$2$4 c$1$9$9$0

然后配合基础词跑：

hashcat --stdout -r my_rule.rule base.lst > target_dict.txt

基础词只有几个，规则也只有几行，最终字典能把目标最可能的密码习惯全部包含进去。

实操心得：规则链最大的优势是同样的磁盘空间，更大的覆盖面。一个10MB的基础字典经过规则扩展后，在爆破时等价于几百MB甚至几GB的巨型字典，但无需落盘，速度还更快。这是我现在最推荐的生产套件。

5. 技巧五：输出控制与断点续传，解决字典生成失控问题

5.1 生成前先估算体积，按需分卷和压缩

crunch字典生成失控是新手最常见的翻车点。明明以为生成几百MB，结果跑到一半磁盘爆了。所以在任何生成命令执行前，先算一下总组合数。

组合数公式很简单：密码固定长度L、字符集大小C，总数就是C的L次方。比如长度8、字符集62（大小写+数字）的总数是62的8次方，约2.18乘10的14次方。这个量级落盘完全是灾难，必须提前规划。

crunch支持按体积或按行数分卷。按字节大小分卷：

crunch 8 8 abcdefghijklmnopqrstuvwxyz0123456789 -b 100mb -o START

生成的每个分卷文件叫crunch-0.txt、crunch-1.txt……每个100MB。-o START是固定写法，crunch会按指定体积自动切分多个文件。

按行数分卷：

crunch 8 8 abcdefghijklmnopqrstuvwxyz0123456789 -c 5000000 -o START

每个分卷500万行。分卷的好处是后续处理、排序、分发到多台机器都方便。

如果只是最终存档，建议直接用压缩输出：

crunch 8 8 abcdefghijklmnopqrstuvwxyz0123456789 -o dict.txt -z gzip

会生成dict.txt.gz。实测字典文本压缩率很高，几个GB的纯文本经常能压到几百MB。crunch支持gzip、bzip2、lzma、7z等格式，对应参数是-z gzip、-z bzip2等。

5.2 断点续传与多终端并行

跑一个大字典跑到三分之一，不小心Ctrl+C了。重新跑又得从头开始，那种感觉真的不好受。crunch虽然没有“暂停继续”功能，但可以通过-s参数指定从哪个字符串开始生成，变相实现断点续传。

比如你之前在aaaaaa前的条目已经生成完了，现在想从babcde继续：

crunch 6 6 abcdefghijklmnopqrstuvwxyz -s babcde -o part2.txt

这样crunch会跳过babcde之前的所有组合，直接从babcde开始生成剩余部分。

配合重定向符号还可以实现真正的追加续写。之前生成的字典有一部分存在dict.txt里，现在新跑的区间追加到文件末尾：

crunch 6 6 abcdefghijklmnopqrstuvwxyz -s babcde >> dict.txt

注意这里是>>而不是>，用>会覆盖之前生成的内容。我踩过一次这个坑，一个跑了半小时的字典被一条>命令直接清零。

多终端并行也基于同样的逻辑。把字符集或起始字符串按区间切分，每个终端跑一段。比如并行生成8位小写字母字典，分成两个区间：

终端A：

crunch 8 8 abcdefghijklmnopqrstuvwxyz -s aaaaaaaa -e mzzzzzzz -o dict_a.txt

终端B：

crunch 8 8 abcdefghijklmnopqrstuvwxyz -s naaaaaaa -o dict_b.txt

-e参数指定结束字符串。终端A跑a开头到m开头的区间，终端B从n开头跑到z开头，互不干扰。这种方法在有多核CPU或几台机器时可以成倍缩短生成时间。

实操心得：多终端并行还有一个常用变体，不追求覆盖全集，而是让不同终端各自生成不同“风格”的子域。比如一个跑纯数字、一个跑小写+数字、一个跑带符号，量体裁衣，定向爆破时更实用。

6. 实操中容易翻车的几个细节：报错排查与效率心得

6.1 高频报错对照速查

日常使用中crunch的几个报错和坑，我整理成了一张速查表，对号入座就能解决。

以上每条我都在实际测试环境里遇到过，有些甚至踩了好几次才反应过来。比如-l @那个坑，当时为了生成包含@符号的口令，跑了半天发现生成的全是小写字母组合，核对帮助文档才意识到需要-l参数。这类问题不值得别人提醒第二遍，把命令检查清单拉出来逐项比对是最稳的。

6.2 我对字典“命中率”的几点亲测体会

最后分享几个我在多次授权测试中形成的心得和习惯。

第一个心得：字典兵贵精不贵多。很多人总觉得字典越大越安心，实际在线爆破场景中，一个10万条的高质量定向字典比1000万条的通用字典命中率高出很多，因为前者每一条都贴合目标画像。用前面的技巧生成几千条精确候选，远比下载几个GB的通用字典直接跑有效。

第二个心得：信息收集的质量直接决定字典上限。crunch只是个生成工具，真正决定命中率的是你对目标的画像是否准确。姓名、生日、爱好、工作、常用平台，这些信息整理得越细，候选词越准，后面所有技巧发挥的作用越大。

第三个心得：把生成流程沉淀成脚本。我现在通常把“候选词整理—crunch生成—规则扩展—去重压缩”整套流程写成一个shell脚本，参数化目标信息。一次配置，后续每次测试改改变量就能直接跑。这不仅省时间，还能避免手动敲命令时漏掉关键参数。

最后再分享一个实际使用中的小细节：crunch生成完字典后，我习惯先用wc -l看看行数是否和估算的匹配，再随机抽查头几十行确认格式正确。这十几秒的检查能避免整个字典因为一个参数错误全部作废，生成大字典时尤其值得把这一步固化到流程里。