Hashcat 8.0.0 史上最大更新炸场：11 大特性 + 146 新算法，密码破解之王彻底重构

原创

网安之家
网安之家

网安之家-CyberHomestead

2026年10月30日 09:00
湖北

去阅读

KLEIN BLUE

编译说明（编辑添加，非原文内容）：本文为 hashcat 官方博客《hashcat 8.0.0 - Release Notes》的全文中文编译，严格忠实原文、未做任何增删改，仅用于密码安全审计、授权渗透测试与安全研究学习场景。

KLEIN BLUEhashcat 8.0.0 - 发布公告

hashcat 开发团队很高兴地宣布 hashcat 8.0.0 正式发布。

这是 hashcat 历史上最大的一次更新。此前没有任何一个版本改动过如此多的文件（4,091 个），也没有任何一个版本积累过如此多的更新日志条目（748 条）。它带来了 11 项重大特性、4 种新攻击模式、146 个新哈希模式和 306 项 bug 修复，共有 63 人参与贡献，其中 43 人是首次贡献者。

在这 11 项重大特性中，有 3 项格外突出：

• PCFG 攻击。 概率型攻击，优先尝试最可能的密码。hashcat 可以在它的密钥空间中任意寻址，因此这类攻击终于能在分布式环境中工作

• Hash Recipes（哈希配方）。 在命令行上描述一个自定义哈希，然后以 GPU 速度破解它，不用再等谁给它写一个哈希模式

• FPGA 支持。 hashcat 第一次跑上了 FPGA，首期支持 7 种板卡上的 bcrypt

下表将本版与 v7.1.2 对比。第一张表统计 hashcat 本身的变化，第二张统计 GitHub 上围绕它发生的事。

hashcat v8.0.0	自 v7.1.2 以来
重大特性	11
重构	5
新攻击模式	4
新哈希模式	146
新哈希原语	26
修复的 bug	306
性能改进	83
更新日志条目	748
新增行数	439,469
删除行数	229,313

GitHub 上	自 v7.1.2 以来
新贡献者	43
回归贡献者	20
关闭的 issue	214
新开的 issue	141
合并的 pull request	364

如果你要升级一个现有环境，请先读第 5 节\"升级之前\"。

1. 新攻击

◦ 1.1 PCFG，攻击模式 4

◦ 1.2 账号感知的关联攻击，攻击模式 9

◦ 1.3 表攻击，攻击模式 5

◦ 1.4 掩码中的词表，攻击模式 12

◦ 1.5 每种攻击模式中的规则

◦ 1.6 Feed 插件，攻击模式 8

◦ 1.7 Lookup：攻击在哪里命中一个密码

2. 没有哈希模式的哈希

◦ 2.1 Hash Recipes（哈希配方），哈希模式 4000

◦ 2.2 Python 桥

◦ 2.3 Rust 桥

3. FPGA 支持

4. 大规模与分布式作业

◦ 4.1 可寻址词表

◦ 4.2 多张词表，一个密钥空间

◦ 4.3 分布式攻击中的 Lookup

◦ 4.4 Brain 服务器

◦ 4.5 大型哈希列表

◦ 4.6 共享机器与存储

5. 升级之前

6. 新算法

7. 性能

8. 用户体验与平台

9. Bug 修复

10. 幕后

11. 下一步更新的计划

12. 贡献者名单

13. 结语

关于 AI 的一点说明

本版的许多改动是在 AI 编码智能体的协助下写成的，我们认为这是好事。AI 生成的代码已经达到真正有分量的质量水平，越来越多的贡献者在自己的 pull request 里使用它。作为维护者，我们自己也不得不借助 AI 来审查它们。现在，每个 pull request 都由我们自己的 AI 智能体以其最高推理档位检查一遍。

为了让 AI 智能体的贡献易于审查，我们在仓库里加了 AGENTS.md。它向智能体讲明人类贡献者早已知道的事：如何构建和测试；以及一个事实——编译通过的内核，还不等于能用的内核。它还规定了 pull request 里的每一份输出都必须来自真实运行，以及保持 pull request 短小的价值。用 AI 智能体写成的贡献是受欢迎的，只要它们遵守 AGENTS.md 和 CONTRIBUTING.md。

01新攻击

本节介绍 hashcat 生成密码候选的新策略。hashcat v8.0.0 新增 4 种攻击模式，并扩展了现有的关联攻击（association）。这一切在底层都建立在一个新设计之上：feed 插件。我们在本节末尾解释它们的工作方式。

1.1. PCFG，攻击模式 4

PCFG 是概率上下文无关文法（Probabilistic Context-Free Grammar）的缩写。PCFG 攻击从一个用真实密码训练出的模型生成密码候选，并且从最可能的那些开始。训练好的模型称为规则集（ruleset）。这是 PCFG 工具所用的术语，我们沿用这个词以保持与它们的兼容。PCFG 规则集与你用 -r 加载的 hashcat 规则毫无关系。

长期以来，PCFG 攻击一直是 hashcat 够不着的东西。问题在于，PCFG 的密钥空间无法寻址。hashcat 需要这个能力来把一次攻击拆分到多个设备、恢复会话，或在分布式环境中分发任务。此前唯一的选择，是把候选通过 stdin 管道喂进 hashcat，或者把 PCFG 当作慢速候选生成器来跑。

hashcat v8.0.0 改变了这一点。hashcat 可以在不生成候选的情况下统计一条文法的候选数量，并能跳到密钥空间的任意位置。于是，攻击周边的一切都如你所期望地工作：

• 密钥空间、-s、-l、恢复、多设备与 brain

• 分布式破解框架与你自己的脚本

如果不选择规则集，hashcat 会使用内置的 \"default-passwords\" 规则集，所以这就是你起步所需的全部：

$ ./hashcat -m 1000 -a 4 hash.txt

而且它很快。在一张 RTX 4090 上，PCFG 攻击以纯内核跑 NTLM 达到 18.7 GH/s。对快速哈希，这类攻击在 GPU 上是全加速的。PCFG feed 直接在 GPU 上把基础词展开成候选，因此大多数候选根本不必跨越 PCIe 总线。文法还包含一个 OMEN 部分——一个为任何已学形状都描述不了的密码准备的马尔可夫模型。这部分同样跑在 GPU 上。如果你想把它去掉，设 omen=0。

有一个取舍你应该知道。为了让寻址成为可能，hashcat 把概率取整到小步阶。这让候选的顺序接近真实概率顺序，但不完全相同。我们测量了相对 pcfg\_cracker（后者保持精确顺序）的代价：同样的规则集、example0.hash 的 6,494 个 MD5 哈希、1000 万到 10 亿的猜测量之间，hashcat 找到了 pcfg\_cracker 所找到的 94% 到 97%。作为回报，hashcat 仅在 CPU 上生成候选的速度就快了 60 多倍。在 GPU 上，它更是另一个量级。

寻址同样很快。跳到密钥空间第 10 亿个位置并从那里打印前 5 个候选，用时不到 2 秒：

$ time ./hashcat -a 4 --stdout -s 1000000000 -l 5``02139305``02139306``02139307``02139308``02139309``real 0m1.883s

1.1.1. 掩码：一个形状，或一个片段

如果你对密码的形状有所了解，可以给 PCFG 攻击一个掩码。它与暴力破解掩码的重要区别在于：这个掩码不过滤已生成的候选，而是在文法内部生效，装不下的形状在生成任何东西之前就被淘汰。这些形状不占用任何密钥空间。剩下的候选保持文法给它们的概率，所以出现的顺序与不加掩码时相同，只是把其余的剔除了。

看看只放行以 \"cat\" 结尾的候选会发生什么：

$ ./hashcat -a 4 --stdout -l 10 mask=?a?a?a?acat``wildcat``coolcat``bearcat``Wildcat``allycat``bluecat``babycat``nyancat``hellcat``Coolcat

最可能的排在前面，比如 \"wildcat\" 和 \"coolcat\"——这中间没有任何词表参与，每个词都来自文法本身。

掩码也可以在中间放一个片段。这里 \"red\" 位于第 3 到第 5 位。注意候选来自多种不同的形状，而且这里的 \"red\" 与颜色毫无关系：

$ ./hashcat -a 4 --stdout -l 10 mask=?a?ared?a?a``paredes``heredia``firedog``boredom``jared12``jared11``Paredes``firedup``zgredek``coreduo

同一个掩码在暴力破解下有 4.6 倍的候选量，而且不按可能性顺序生成：

$ ./hashcat -a 3 --total-candidates ?a?ared?a?a``81450625``$ ./hashcat -a 4 --total-candidates mask=?a?ared?a?a``17876251

掩码使用与攻击模式 3 相同的语法，包括自定义字符集 -1 到 -8。

一些 beta 测试者说，-a 4 现在是那个更好的 -a 3。

1.1.2. Hints：只攻一个人

训练出的文法描述了密码形成的两个方面：密码是什么形状，以及由哪个词来填这个形状。有时你已经知道那些词。假设你在破解一个人的密码，而旧的泄露数据给了你这个人用过的 33 个密码。在真实的密码历史中，大约一半的密码通常聚集在几个习惯周围。这里，这个人喜欢随机字符串。其中一个单独使用，也作为每个网站的基底，后面接 \"!!\" 和网站名。他自己的名字会带上 \"123!@#\"、\"!\" 或 \"#1\" 之类的装饰，还有一次是倒着写的。与他亲近的人的名字，比如他妹妹 Luna，只以原样、首字母大写或加日期的形式出现。家乡维也纳（Vienna）的名字遵循同样的模式。剩下的是两个方向的离群值：压力之下选的 \"123456\" 这类简单密码、\"1qaz2wsx\" 这类键盘走位、一长串数字、一个社会安全号、电话号码，以及 \"0412\" 或 \"04121989\" 这类日期和 PIN 码。你不知道的，是他今天用的密码。

内置的 \"hints\" 规则集就是为此而生。它保留了从真实密码学到的形状，但把词留空。你提供词，文法把它们放进真实密码拥有的那些形状。把你知道的写进一个文件，每行一个词。每个词后面可以加一个制表符和一个权重，表示你认为它有多可能。这些权重不需要精确。这里就是手写的粗略猜测，习惯在前，离群值在后：

$ pr -T -3 -w 84 -e20 passwords.txt``kqmvtrzw    0.4    Marco1975 0.05 123456    0.01``jason123!@#    0.3    vienna 0.05 qwerty123    0.01``Jason2024!    0.3    Vienna2019 0.05 1qaz2wsx    0.01``Tz9$Lq2&Wm5!    0.25    jason#1 0.05 zxcvbnm    0.01``luna    0.2    nosaj123!@# 0.05 password    0.01``Luna1993    0.2    04121989 0.02 Winter2022!    0.01``luna0612    0.15    0412 0.02 2580    0.01``daniela    0.1    kqmvtrzw!!gmail 0.02 1234567890    0.01``Daniela1989    0.1    kqmvtrzw!!paypal 0.02 987-65-4325    0.01``daniela0809    0.1    kqmvtrzw!!ebay 0.01 555-0137    0.01``marco75    0.05    kqmvtrzw!!netflix 0.01 015209876543    0.01

hints 规则集会尝试每个旧密码：原样使用、加数字和符号扩展、做大小写变化、以及与另一个旧密码以两种顺序拼接。它把这些全部混进一条流里，按这些模式在真实密码中出现的可能性排序：

$ ./hashcat -a 4 --stdout -l 63 hints hintfile=passwords.txt | pr -T -3 -w 84``kqmvtrzw    luna123 kqmvtrzwtz9$lq2&wm5!``jason123!@#    luna1993123 kqmvtrzwluna``jason2024!    kqmvtrzw1 kqmvtrzwluna1993``tz9$lq2&wm5!    Jason123!@# jason123!@#kqmvtrzw``luna    Jason2024! jason2024!kqmvtrzw``luna1993    Tz9$lq2&wm5! tz9$lq2&wm5!kqmvtrzw``luna0612    Luna lunakqmvtrzw``daniela    Luna1993 luna1993kqmvtrzw``daniela1989    kqmvtrzw12 04121989``daniela0809    kqmvtrzw11 0412``kqmvtrzw123    luna0612123 kqmvtrzw!!gmail``marco75    daniela123 kqmvtrzw!!paypal``marco1975    daniela1989123 Luna0612``vienna    daniela0809123 Daniela``vienna2019    jason123!@#1 Daniela1989``jason#1    jason2024!1 Daniela0809``nosaj123!@#    tz9$lq2&wm5!1 KQMVTRZW``Kqmvtrzw    luna1 kqmvtrzw13``jason123!@#123    luna19931 kqmvtrzw10``jason2024!123    kqmvtrzwjason123!@# kqmvtrzw01``tz9$lq2&wm5!123    kqmvtrzwjason2024!

这个顺序是训练出来的。一个词后面跟 3 位数字排在两个词拼接之前。这是因为在真实密码中前者是更常见的形状，而不是因为有人为它写了一条规则。

如果你还知道一些形状信息，掩码可以进一步收窄。加日期的习惯让 \"Luna2026\" 成为他今天所用密码的好猜测。加上掩码后，它是 --stdout 流中的第 1,484 个候选。下面是加了掩码后生成的前 9 个候选：

$ ./hashcat -a 4 --stdout -l 9 hints hintfile=passwords.txt mask=?u?l?l?l?d?d?d?d | pr -T -3 -w 84``Luna1993    Luna2000 Luna2012``Luna0612    Luna2010 Luna2003``Luna1234    Luna2002 Luna2001

关于 hints 还有几点值得知道：

• 对少数几个词，命令行上的 hintwords=daniela,jason,1989 也能用

• 每个 hint 词在一个候选中最多出现一次，因为基于某个事实的密码通常只包含这个事实一次。设 hintrepeat=1 允许重复

• 没有概率的词按位置加权。默认第一个词算最可能的。hintrank=flat 让所有词权重相同。hintrank=linear 让每个词的权重是前一个的一半

• 每个候选都包含你的词之一。这个攻击的上限就是你知道多少

• hint 攻击生成候选的速度慢于默认规则集，因为 hint 词必须放在宿主端。对单个人目标的攻击，这几乎无关紧要。想要速度回来，-r 依然在 GPU 上放大

• 词会重复的位置被跳过，但仍计入位置。这就是状态里 \"Rejected\" 数量很大的原因，也是上面 -l 63 打印出 62 个候选的原因

如果你训练自己的文法，tools/pcfg_hints.py 能把它变成一个 hint 规则集。关联攻击用的也是同一个规则集，词取自每条哈希。详见 1.2 节。

1.1.3. 规则集与设置

hashcat 自带 2 个规则集：\"default-passwords\" 和 \"hints\"。你可以用 pcfg\_cracker 训练自己的规则集，因为 hashcat 直接读取它的规则集格式。我们 wiki 的 PCFG 攻击页面还列了另外 2 个训练器：pcfg-go 和 hpcfg。如果你命名多个规则集，它们会一起跑。用 weights=2:1 可以把份额向你更信任的那个倾斜：

$ ./hashcat -m 0 -a 4 hash.txt default-passwords my-ruleset weights=2:1

如果你知道密码长度，设 pwmin 和 pwmax。这些限制在统计密钥空间时就生效，范围外的候选根本不会生成。-r 和 -g 的规则让攻击保持在 GPU 引擎上，--debug-mode 6 打印一个 PCFG 候选的布局。

全部设置见 docs/hashcat-pcfg.md。

1.2. 账号感知的关联攻击，攻击模式 9

当你对每条哈希有所了解（比如用户名）时，关联攻击一直很强。缺点是你得自己构建词表，每条哈希对应一个词。hashcat v8.0.0 之后不再需要，因为 hashcat 现在直接从哈希文件里读词。

用户名会按分隔符、大小写变化、字母与数字交界处拆分。对 passwd 行，hashcat 还会读出真实姓名和主目录的最后一段。除此之外，哈希模式还能添加自己的 hints。

默认情况下，攻击按以下顺序经历 3 个阶段：

阶段	候选
1	账号词
2	账号词 + rockyou-30000.rule 的前 1k 条规则
3	PCFG hints 规则集，见 1.1.2 节

PCFG 阶段把 hint 攻击的威力带给列表中的每个账号，各自有各自的词、各自的盐。注意这个阶段永不结束。想要有界攻击，就指定你要的阶段。下面这条跑完账号词、再跑规则，然后停止：

$ ./hashcat -m 500 -a 9 hash.txt phases=words,rules

WPA 是自带 hints 的哈希模式的好例子。抓包里没有账号名，但模式 22000 会提供人起的所有网络名（SSID），还提供 2 个 MAC 地址，各写成 12 位十六进制：

$ ./hashcat -m 22000 -a 9 handshakes.hc22000

旧的\"每哈希一词\"形式原样可用。请注意关联攻击仍然要求每条哈希一个盐。详见 docs/hashcat-association.md。

1.3. 表攻击，攻击模式 5

表攻击回来了，而且回归的是它在 hashcat-legacy 时代的原攻击模式编号。

给不熟悉的人解释：表攻击把词中的一个 token 替换成另一个 token。token 是一个或多个字节，所以多字节字符也行，emoji 都可以。替换可以比 token 长或短，甚至为空。表文件每行一条规则：要替换的 token、一个制表符、以及放回原位的替换内容。

一张表可以描述任何一群被人们互相替换的东西。可以是大小写、leetspeak、emoji 或键盘布局，也可以是运动、品牌、乐队、颜色、汽车品牌、足球俱乐部、城市、名字、月份、星期，或任何能归成一组的东西。hashcat 自带 leetspeak、大小写切换、emoji、运动和键盘布局的表。键盘布局表把一种布局映射到另一种。多张表可以组合，组合在设备上运行。

表就是一个纯文本文件，每行一条规则：要替换的 token、一个制表符、它的替换。同一个 token 可以出现在多行，每行一个不同替换。hashcat 会在 token 出现的每个位置独立选择，并尝试这些选择的所有组合。这是内置 leetspeak 表的前几条规则：

a 4``a @``e 3``g 9``i 1``i !``l 1``o 0``s $``s 5

\"s\" 的两条独立规则，就是这样把 \"password\" 变成 \"pa$$word\"、\"pa55word\"，以及混合的 \"pa$5word\" 和 \"pa5$word\"。

表还能交换整个词。假设你的词表里有 \"ilikefootball\" 和 \"football123\" 这 2 个词：

$ cat words.txt``ilikefootball``football123

一张把 football 换成其他运动的表，需要为每种运动写一行：

football baseball``football basketball``football hockey``football tennis``football golf``football rugby``football cricket``football volleyball``football cycling``football skiing

运动只是个例子。同样的道理适用于乐队、城市、书名，或你攻击的对象在乎的任何东西。hashcat 自带一张更大的 tables/sports.table，把每种运动与其余每种运动两两配对。

这张表把 2 个词里的 football 替换成每一种运动：

$ ./hashcat -a 5 --stdout words.txt sports.table identity=0 template=1 | pr -T -4 -w 91``ilikebaseball       ilikerugby      baseball123     rugby123``ilikebasketball       ilikecricket      basketball123     cricket123``ilikehockey       ilikevolleyball      hockey123     volleyball123``iliketennis       ilikecycling      tennis123     cycling123``ilikegolf       ilikeskiing      golf123     skiing123

这里 identity=0 去掉了未变化的词，template=1 去掉了没匹配到表中任何 token 的词。这样，词表就成了一组模板。没有 template=1 的话，跑一遍 rockyou 会有 96% 的时间浪费在不指任何运动的词上。

默认尝试替换的每一种组合。用 single=1 则改为一次只试一个替换。maxperm 和 cap=N 可以限制工作量。全部设置见 docs/hashcat-table.md。

1.4. 掩码中的词表，攻击模式 12

攻击模式 12 把词表带进掩码。新增以下 2 个占位符：

掩码	候选
?w	第一个词表，可出现在掩码任意位置
?q	第二个词表
?w?d?d	每个词后面跟 2 位数字
?w?q	2 个词表拼接

?w 借自 JtR，在那里它代表混合掩码中的词。我们还加了 ?q 表示第二个词表——这是 JtR 没有的功能。?w 必须有，?q 可选。字面文本和掩码 token 可以出现在词的任意一侧。只要每个掩码都含 ?w，掩码文件就能用。增量模式不可用，因为缩短掩码可能把词弄丢。见 --help 中的\"Attack-Mode 12 Markers\"表。

这不只是一个新攻击模式。组合攻击和两种混合攻击现在也跑在这个引擎上，候选顺序和密钥空间与从前一致。

1.5. 每种攻击模式中的规则

此前，-r 指定的规则文件只在直攻（straight）和关联攻击中生效。hashcat v8.0.0 起，它们在组合、暴力、PCFG、表和混合攻击中同样生效，掩码中的词表也一样。掩码文件、增量、Markov 设置和自定义字符集照旧工作。

有一点要记住。启用规则后，基础候选来自宿主，规则在设备上跑。发生这种情况时 hashcat 会显示警告：

$ ./hashcat -m 1000 -a 3 -r rules/rockyou-30000.rule hash.txt ?a?a?a?a?a?a``ATTENTION! The mask is being generated on the host.``No kernel both walks a mask and applies a rule, so a mask attack given rules builds``its candidates on the host and the rules amplify them on the device.``...``Guess.Base.......: Feed (mask)``Guess.Mod........: Rules (rules/rockyou-30000.rule)``Speed.#01........:  8234.2 MH/s (80.41ms) @ Accel:711 Loops:115 Thr:64 Vec:1

这与规则在攻击模式 0 中的既有分工相同：词表来自宿主，规则在设备上跑。在同一张 RTX 4090 上，攻击模式 0 配 rockyou.txt 和同一规则集跑出 6.8 到 6.9 GH/s，所以掩码加规则反而略快。更大的规则集能赢回更多速度，因为每个基础候选做的活更多。不用规则的攻击依然在设备上生成候选。PCFG 是例外：它的规则跑在设备引擎内部，所以 PCFG 攻击加规则不丢速度。

调试输出现在也会指出是哪条规则命中的——在组合、暴力、混合攻击和掩码词表中都是如此，一如它在直攻中一贯的表现。

1.5.1. 更多规则功能

用 --rules-concat 可以把多个规则文件串成一条序列。规则数是相加，而不是像堆叠 -r 那样相乘。

$、^、i、v 和 o 的规则操作数现在直接接受非 ASCII 字符，不用再一个字节一个 \\xHH 转义。另外新增了 5 个规则函数：

规则	作用
h	把整个密码转成小写十六进制
H	把整个密码转成大写十六进制
S	逐字符切换大小写，同 JtR
vNX	每 N 个字符插入一个字符 X
BNX	在位置 N 加上 X 的字节值

1.6. Feed 插件，攻击模式 8

上面所有攻击共享一个设计，值得单独一节。在 hashcat v8.0.0 里，候选生成器以名为 feed 的插件形式运行。feed 按名字选择，hashcat 为每台设备各跑一个实例。与你通过 stdin 管道喂进 hashcat 的生成器不同，feed 参与密钥空间计算、任务分发、恢复、状态与调试输出。

feed 还能把基础词交给设备，让 GPU 把它们展开成候选。这样 feed 就成了放大器。PCFG 和表攻击正是靠它在快速哈希上达到 GPU 速度。词表和掩码本身就是 feed。这是一个按名字选择的词表 feed，上面叠着规则：

$ ./hashcat -m 1000 -a 8 hash.txt wordlist example.dict -r rules/dive.rule``...``Guess.Base.......: Feed (example.dict)``Guess.Mod........: Rules (rules/dive.rule)``Candidate.Engine.: Device Generator

hashcat v8.0.0 包含以下 feed：

• 词表、stdin、掩码、混合与关联

• PCFG 与表

• 随机生成（Rust 编写，Rust 可用时构建）

词表 feed 也为直攻、组合和混合攻击以及掩码词表供应字典，也供给关联攻击的词表形式。

既然 stdin 现在是 feed，stdin 攻击也支持 -s、-l 和 --restore——只要你再次给它同一条流。管道没有密钥空间，所以状态栏过去只显示一个计数。如果你知道流有多少行，用 --stdin-count 给出该数，状态栏就会显示进度和预计完成时间。而且每种 feed 攻击都能在不带 -r 或 -g 的情况下用 --debug-mode，此时 \"Finding-Rule\" 字段描述的是 feed。

想写自己的 feed，用 C 或 Rust 都行。文档和示例 feed 都已附带。docs/hashcat-generic-attack-mode.md 讲怎么用 feed，docs/hashcat-generic-attack-mode-development-guide.md 讲怎么写 feed。Rust 见 docs/hashcat-rust-plugin-quickstart.md。我们很好奇社区会拿它造出什么。

1.7. Lookup：攻击在哪里命中一个密码

有时你想知道一次攻击是否覆盖某个密码，以及它落在攻击的哪个位置。也许你用一次攻击破解了一个哈希，想知道更便宜的攻击是否也能找到它。或者你知道一个测试账号的密码，想先确认攻击能覆盖它，再把整个周末的 GPU 时间投进去。此前唯一的办法，是直接跑攻击，或者用 --stdout 生成全部候选再翻输出。

hashcat v8.0.0 的 --lookup 直接给你这个信息。你给它密码，hashcat 算出攻击在哪里产出它，打印结果然后退出。它不需要哈希文件，也不打开任何设备。以掩码攻击为例：

$ ./hashcat -a 3 --lookup=Summer2026 '?u?l?l?l?l?l?d?d?d?d'``lookup: 'Summer2026'``lookup: mask ?u?l?l?l?l?l?d?d?d?d reaches it``lookup: base word 133771000 of 175760000, 76.1100% into the run``lookup: this run reaches it at -s 133771000, because -a 3 counts -s in base words``lookup: -s 133771000 -l 1 runs the one cell of 17576 candidates that holds it, where it is number 4162

答案会显示密码落在攻击的哪个深度，并给出命中它的精确 -s 值。配合 -s 和 -l 1，你可以只跑攻击的那一小片，比如确认一个哈希确实在那里被破解。掩码的结果立等可取，因为 hashcat 能直接算出位置。词表则要对它的词过一遍，长扫描时带进度条和预计完成时间。

--lookup 适用于直攻、组合、暴力、PCFG 和混合攻击，也适用于掩码词表。在混合和组合攻击中，它还会显示密码在词表与掩码之间、或两个词表之间是怎么切分的。而当攻击根本不可能产出某个密码时，hashcat 会连同原因一起显示：

$ ./hashcat -a 6 --lookup=hashcat2026 example.dict ?d?d?d?d``lookup: 'hashcat2026'``lookup: nothing in this run produces it``lookup: no way of cutting it leaves a word this wordlist holds and a mask value beside it

到了 PCFG 这里，答案走得更远。hashcat 会点名产出该密码的结构，并展示这个结构的每个槽位是怎么填的：

$ ./hashcat -a 4 --lookup='Sarah1992!'``lookup: 'Sarah1992!'``lookup: derived by structure A5Y1O1, at cost 34 of costmax 64``lookup: A5=sarah C5=ULLLL Y1=1992 O1=!``lookup: base word 254973 of 12747516827886, 0.0000% into the run, which is candidate 889622229 of 34935457766817424``lookup: this run reaches it at -s 254973, because the device engine counts -s in base words``lookup: -s 254973 -l 1 runs the one cell that holds it

这里，\"Sarah1992!\" 由一个首字母大写的 5 字母词、一个年份和一个符号组成。如果密码够不着，hashcat 会解释原因。文法可能根本产不出它；掩码、omen=0、长度限制或重复的 hint 词可能排除了它；或者它超出了 costmax。后一种情况下，hashcat 会显示能到达它的 costmax 值。对 PCFG，你也可以用规则集设置 lookup= 问同样的问题。

几点注意。--lookup 不能与规则同用，因为规则无法反推。表、feed 和关联攻击暂不支持。密码可以用 $HEX[...] 形式给出。

02没有哈希模式的哈希

迟早有一天，你会撞上一个没有任何哈希模式覆盖的哈希。也许某个 Web 应用的加盐方式自成一派，也许某个厂商决定哈希两次。此前的选项是：写一个新哈希模式（连同它的内核），或者退回到慢得多的通用插件。hashcat v8.0.0 给了更好的答案。哈希配方会被编译进 GPU 内核，是大多数方案的正确选择；Python 桥在 CPU 上跑任意 Python 代码，兜住其余一切。

2.1. Hash Recipes（哈希配方），哈希模式 4000

用哈希模式 4000，你在命令行上描述这个哈希：

$ ./hashcat -m 4000 --hash-recipe 'md5(md5(salt) . pass)' hash.txt wordlist.txt

就这么多。hashcat 在启动时把配方编译进内核。大多数配方跑出接近内置纯内核的速度，有些甚至更快。在 Radeon Pro W7800 上，配方在直攻和暴力攻击中跑在原生内核的 1% 到 5% 以内。比如配方 hmac_sha256(salt, pass) 在 RTX 4090 上跑 7.67 GH/s，而模式 1460 的原生纯内核是 4.71 GH/s。

配方使用哈希表达式语言 hx 的语法。覆盖面非常广：

• 哈希函数：MD4、MD5、SHA-1、SHA-2、SHA-3、Keccak、RIPEMD-160、RIPEMD-320、BLAKE2、SM3、Whirlpool、Streebog、GOST R 34.11-94、MD6、LM 和 MySQL323，外加 26 个此前任何 hashcat 都算不了的函数族，6.1 节列出。大多数族还有 HMAC 形式

• PBKDF2、AES 和 DES，用于派生密钥以及加密、解密或解包数据

• 变换（transform），如 upper、rev、pad，作用于密码、盐、摘要、循环变量和派生密钥

• 以 hex 或 base64 存储的盐，用 fromhex 和 frombase64 解码

• 可切片的摘要，或重编码为 hex/base64

• 跨多条语句使用的变量，外加循环和对计算值的操作，包括 xor、and、or

• 第二盐、pepper 和用户名，从哈希行读入

• 8 字节起的结果，raw 或编码，以及带固定前缀（如 {SHA}）的哈希行

模式 4000 现在覆盖 hx 的大部分：hx 目录中 1005 个表达式，编译得了 903 个。

一些例子：

配方	它是什么
md5(md5(salt) . md5(pass))	MyBB 和 IPB 论坛，模式 2811
sha1(salt . md5(pass))	一个哈希两次的 Web 应用
md4(utf16le(pass))	用配方写出的 NTLM
hmac_sha256(salt, upper(pass))	带变换密钥的 HMAC
trunc(sha512(pass), 32)	截断到 32 个十六进制字符的摘要

配方不限于密码和盐。它能从哈希行读更多字段，也能对计算值做文章：

从哈希行取字段	对计算值操作
sha256(pass . fromhex(salt))	md5(xor(sha1_bin(pass), salt))
md5(pass . frombase64(salt))	hex(rev(md5_bin(pass)))
md5(pass . user)	h = md5(salt); md5(h . pass)
sha256(salt . pass . pepper)	sha1(utf16be(pass))

配方也不限于快速哈希。配方可以循环，迭代计数从每条哈希行读取，如 for i = 1 to iter { h = md5_bin(h . pass) }。它能用 PBKDF2 派生密钥，能用 AES 解密或解包数据。它可以以比较收尾——与常量比，或在配方的两个计算值之间比。这样一来，phpass、PBKDF2 哈希和 1Password agilekeychain 这类慢格式也能以配方运行，只要哈希行写成模式 4000 读得懂的形式。

拿一个 hashcat 没有哈希模式的方案试试，sha1(salt . md5(pass))：

$ ./hashcat -m 4000 --hash-recipe 'sha1(salt . md5(pass))' -a 3 hash.txt '?u?l?l?l?l?l20?d?d!'``...``Status...........: Cracked``Hash.Mode........: 4000 (Hash Recipe, see --hash-recipe)``Guess.Mask.......: ?u?l?l?l?l?l20?d?d! [11]``Speed.#02........: 10622.5 MH/s (7.32ms) @ Accel:474 Loops:45 Thr:1024 Vec:1``Progress.........: 3875508000/30891577600 (12.55%)``Candidate.Engine.: Device Generator

在 RX 7900 XTX 上，\"Autumn2026!\" 1.3 秒破解，含启动时间。第一次运行约需 4 秒，因为要构建配方的内核。一张 RTX 4090 用同一配方跑出 21 GH/s。许多自定义方案现在可以用一个配方顶替专用哈希模式。

完整配方语言见 docs/hashcat-hash-recipe.md。

如果你玩 JtR，还有更多。JtR 把许多格式写成 $dynamic_N$ 哈希。用 --dynamic-x，hashcat 从第一条哈希读出格式并用匹配的配方运行，-m 和 --hash-recipe 都不用给。这覆盖了 JtR 内置 409 个 dynamic 格式中的 407 个，以及 JtR dynamic.conf 中的全部 58 个格式。只有 phpass 和 HTTP digest 认证没进。用 -O 时，存在优化内核的格式会改跑带优化内核的哈希模式。hashcat 不认识的格式（比如来自你自己的 dynamic.conf）依然可用 -m 4000 加一个描述其计算的配方加载。

2.1.1. 新哈希模式，现在只是一个模块

配方也改变了我们写哈希模式的方式。以前，加一个新哈希模式需要一个模块、至多 4 个纯内核，还有优化内核。现在模块只要报出自己的配方，配方顶替纯内核。这是模式 10，md5($pass.$salt)：

staticconstchar *HASH_NAME      = \"md5($pass.$salt)\";``staticconstchar *HASH_RECIPE    = \"md5(pass . salt)\";

我们把许多现有哈希模式的纯内核转换了过来：

配方转换
快速模式	182
PBKDF2 与迭代模式	47
删除的内核文件	567
删除的行数	111k

快速模式包括 MD5、NTLM、DCC、Whirlpool、SHA-3、Keccak、Streebog 以及 HMAC-MD5、HMAC-SHA1、HMAC-SHA256、HMAC-SHA512 模式。PBKDF2 与迭代模式包括 PBKDF2-HMAC-SHA256 及构建其上的格式，如 macOS、GRUB 2、Django、Cisco-IOS $8$，还有 phpass、Drupal7、SAP CODVN H、AIX 和 SCRAM 格式。

从用户视角，什么都没变。每个被转换哈希模式的哈希格式、解析器、自检和优化内核保持原样。如今只以存储配方运行的哈希模式搬进了自己的编号区段，从 40000 起，旧编号继续可用，详见 5.7 节。对我们而言，这意味着修一处原语（如 MD5 或 PBKDF2），所有配方模式同时受益。如果你要从这些族写一个新的快速哈希模式，现在只需要一个解析哈希行、报出配方的模块。见 docs/hashcat-plugin-development-guide.md 的\"Kernel: fast hash type (recipe)\"。

2.2. Python 桥

Python 桥在 hashcat v7.0.0 引入，是在 Python 里快速添加哈希匹配逻辑的途径。v8.0.0 里，它变得更容易部署，也快得多。

模式 73000 现在为每个 CPU 线程启动一个普通 Python worker 进程并把候选发给它。Windows、macOS 和 Linux 都可用，也不再需要 free-threaded Python 构建。hashcat 运行 PATH 里的 python3，Windows 上是 python。这样，虚拟环境和 pyenv 无需任何额外步骤即可工作。想用别的解释器，用 --bridge-parameter2 指定。hashcat 构建也不再需要 Python 头文件。

Python 桥，28 CPU 线程	之前	现在
SHA-256 Python 插件	16 kH/s	611 kH/s
每次启动的候选数	8	1k

这些数字来自 i7-14700K。hashcat 自带的 Python 插件提升了 10%。

写插件也更简单了：

• 插件就是一个普通的 Python 模块，带 calc_hash() 和 ST_HASH/ST_PASS 自检对

• init() 和 term() 钩子可选，kernel_loop()、hcsp 和 hcmp 已移除

• calc_hash() 抛异常时攻击停止。异常的 traceback 也会打印，错误不再被无声吞掉

• 调试时把插件当普通模块 import，无需 hashcat

状态栏会显示在用的解释器。make install 现在也安装 Python 目录，安装后模式 73000 在任何工作目录都能跑。

请注意模式 72000 已移除，若干插件钩子有变。升级步骤见 5.8 节与 docs/hashcat-python-plugin-development-guide.md。

2.3. Rust 桥

Rust 桥现在共享 hashcat-sys crate，Rust/bridges 下的每个 crate 都构建进 bridges/subs。模式 74000 在宿主与设备之间只拷贝输出摘要，自动调优能将其启动规模放到 16k 候选。Rust 插件要求 Cargo 1.85。入门见 docs/hashcat-rust-plugin-quickstart.md。

03FPGA 支持

hashcat 传统上专注 GPU 和 CPU。hashcat v8.0.0 改变了这一点。hashcat 现在能在 FPGA 上破解 bcrypt，即哈希模式 75000。

我们在 hashcat v7.0.0 引入 Assimilation Bridge 时，FPGA 就是它的初心，FPGA 插件当时就在我们的计划清单上。FPGA 板卡现在经由这座桥以设备身份出现在 hashcat 中。你用的还是同一套攻击、规则和掩码，同样的恢复与状态，与 GPU 上无异。每块板有针对启动规模的独立自动调优和自己的温度看门狗。板卡健康状况的报告方式与 GPU 相同。每块板显示温度，有自己的温度上限。

FPGA 算哈希，常规后端设备生成候选。CPU OpenCL 运行时足矣，所以无头主机可以完全没有 GPU。FPGA 支持目前限 Linux。

3.1. bcrypt 对 GPU 做了什么

bcrypt 能让 GPU 显得忙碌，却用不上它的大部分，功耗就是证据。在 RTX 4090 上，下面两行运行都显示 99% 利用率，但 bcrypt 只拉了这张卡 450 W 上限的四分之一左右：

RTX 4090	速度	功耗	峰值	频率	温度
MD5	59 GH/s	434 W	441 W	2.7 GHz	71 C
bcrypt cost 10	7.8 kH/s	117 W	118 W	2.8 GHz	37 C

所以\"99% 利用率\"只告诉你有个内核在跑，不告诉你这个内核用掉了芯片的多少。FPGA 没有这个问题，因为整颗芯片都可以配置成 bcrypt 核，每个核带自己的 S-box。

3.2. 我们构建了什么

bcrypt 计算核来自 JtR，即 Denis Burykin 写的 ZTEX bcrypt 核。我们修改了这个核，并写了它周围的一切。src/fpga/bcrypt/PROVENANCE.md 逐文件列出每处改动。

每核两哈希。 在 YPCB 上，每核一哈希的设计在 450 核时耗尽 block RAM，而约三分之一的逻辑单元闲置。于是我们改成让每核跑 2 个独立哈希、逐周期交错。一个哈希等上一步结果时，核在算另一个。每个寄存器变成 2 级链，哈希编号作为每个存储器的最高地址位加入。多出的这一级在轮循环内放了第二个寄存器，这让核能以设计中其余部分两倍的时钟跑，因此每个哈希保住全速。核的 S-box 存储原本空了一半，所以第二个哈希不费任何 block RAM。已发布的 YPCB bitstream 在 380 核上同时跑 760 个哈希，设计 115 MHz，核 230 MHz。

核以外的一切。 设计的其余部分为 hashcat 而写：

• feeder 接收密码，在 FPGA 上展开 bcrypt 密钥，再流送给空闲核。发送密码而非展开后的密钥，让一条记录保持约 16 字节而不是 128

• 大多数板卡上，每核旁的小比较器在候选到达主机前就丢掉不可能命中的。单哈希单盐时，这约是 98%

• 每批都带一个已知答案，算错摘要的核会被检出并点名

• 每个核的 S-box 可放 block RAM 或逻辑单元，阵列可以同时吃满一颗芯片的两种资源

• 板卡设计：基于 LiteX 和 LitePCIe 的 PCIe 外壳、ZTEX 2.13 的 USB 外壳、Arty Z7 处理器系统的设计，以及 Alveo U50 的独立 Vitis 流程

重建 bitstream 的源码在 src/fpga/，还附带一个无需板卡即可检查整条数据通路的仿真。

3.3. 支持的板卡

已发布 bitstream 覆盖以下 7 种板卡：

• ZC706

• YPCB-00338-1P1 (Kintex-7 480T)

• Enigma X1

• Alveo U50

• ZTEX 1.15y

• ZTEX 2.13

• Arty Z7-20

bitstream 以二进制形式在源码树之外分发。从 https://hashcat.net/bitstreams/ 下载你板卡对应的文件。

src/fpga/ 目录包含重建其中 5 种板卡 bitstream 所需的源码。Alveo U50 用独立的 Vitis 构建流程。ZTEX 1.15y 的 2 个文件是 JtR 的 Spartan-6 bitstream，原样再分发。

板卡通过 USB、以太网或 PCIe 连接。LitePCIe 驱动随 hashcat 附带，经 DKMS 构建，支持 Secure Boot 签名。各板卡的搭建见 docs/hashcat-fpga-setup.md。

3.4. 速度

以下是单个 bcrypt 哈希的速度：

Cost 10	速度
YPCB，2 块板	8.9 kH/s
Alveo U50	7.4 kH/s
YPCB，1 块板	~4.5 kH/s
ZTEX 1.15y	3.8 kH/s
Arty Z7	345 H/s
ZTEX 2.13	125 H/s

Cost 5	速度
Alveo U50	202 kH/s
Arty Z7	10.5 kH/s
ZTEX 2.13	3.5 kH/s

以及它们与 RTX 4090 在相同 bcrypt 哈希上的对比（单哈希、攻击模式 3 或词表）。请注意，FPGA 与 GPU 的数字来自相隔 2 天的两次独立运行：

Cost 10	速度	相对
RTX 4090	7.8 kH/s	1.00x
YPCB，2 块板	8.9 kH/s	1.15x
Alveo U50	7.4 kH/s	0.96x

Cost 5	速度
RTX 4090	238 kH/s
Alveo U50	202 kH/s

一个在 2 块 YPCB 板上跑 PCFG 攻击的简短例子。目标是 \"blowfish\"（8 个字母的密码）的 bcrypt cost 10 哈希：

$ ./hashcat -m 75000 -a 4 -d 1,2 hash.txt mask=?l?l?l?l?l?l?l?l

3.5. 扩展性

FPGA 板卡几乎不吃带宽，所以它们能像当年的 GPU 矿架那样扩展。例如华硕 H370 Mining Master 主板有 20 个 PCIe x1 转接口。蓝色插座看着像 USB，但每一个都用 USB 3 线缆把一条 PCIe 通道引到转接卡上，每张转接卡插一块卡。也就是一块主板约 20 张卡。

04大规模与分布式作业

如果你在许多设备或许多节点上跑 hashcat，或者要对付非常大的哈希列表，这一节是为你写的。

4.1. 可寻址词表

分布式环境里，每台设备或节点分到密钥空间的一段。用词表时，这意味着要把分到的范围之前的每一行都读一遍，只为找到范围的起点。词表大、范围又靠后时，这可能要花不少时间。

hashcat 现在为每张词表建一个寻址数据库（seek database），设备可以直接从分到的范围附近开始。首次运行建库，之后的每次寻址都是瞬时的。下面是寻址到 rockyou.txt（共 1430 万行）第 1400 万行的示例：

$ time ./hashcat -a 0 --stdout -s 14000000 -l 3 rockyou.txt``05448708072``05448704298``054487-9``real 0m0.137s

只要格式允许，hashcat 还能直接在压缩词表里寻址。词表、哈希列表和规则现在除 gzip 和 xz 外也接受 zstd：

格式	制作方式	寻址
xz，多块	xz -T0	直接
zstd，多帧	pzstd	直接
xz，拼接流	cat a.xz b.xz	直接
xz 或 zstd，单流	xz 、zstd	从头开始
gzip	gzip	从头开始

4.2. 多张词表，一个密钥空间

hashcat 一直接受一次攻击里放多张词表或整个目录。但直到现在，--skip、--limit 和 --keyspace 拒绝与之配合。掩码文件和 --increment 同样如此。分布式环境里，每张词表、每个掩码都得变成单独一个作业。

hashcat v8.0.0 里，它们共同构成一个密钥空间。直攻和混合攻击的多词表、整目录都适用，组合攻击的左侧现在也接受目录。掩码文件、或 --increment 的各长度，同样构成一个密钥空间。--skip、--limit 和 --keyspace 覆盖完整队列。这意味着你可以下发一个大作业，每个节点分到自己的那一片——哪怕这一片从一张词表开始、到下一张结束。

一个装着 example.dict（128,416 行）和 rockyou.txt 的目录。密钥空间覆盖两个文件，一个范围可以从一个文件跨到下一个：

$ ./hashcat -a 0 --keyspace wordlists``14472808``$ ./hashcat -a 0 --stdout -s 128414 -l 4 wordlists``zzzzzzzzzz``zzzzzzzzzzz``123456``12345

目录内文件按名称排序，每个节点看到的顺序一致。词表密钥空间现在按物理行计数，hashcat 用不了的行记为 reject。这样，后面的密钥空间位置就不会漂移。

4.3. 分布式攻击中的 Lookup

分布式攻击中，每个节点只跑自己那段密钥空间。想知道哪一段覆盖某个密码、或想单独重跑那一小段，--lookup 提供这个信息。它能横跨整个词表目录，并点名藏着该密码的词表：

$ ./hashcat -a 0 --lookup=sunshine1 wordlists``lookup: 'sunshine1'``lookup: word 129056 of 14472808, in wordlists/rockyou.txt``lookup: 0.8917% into the run``lookup: this run reaches it at -s 129056, because -a 0 counts -s in words``lookup: -s 129056 -l 1 runs the one word

若每个节点跑等长范围，-s 值就能定位覆盖该密码的节点。混合、掩码和 PCFG 攻击同理。更多例子见 1.7 节。

4.4. Brain 服务器

Brain 服务器换上了新数据库。此前一个 brain 会话就是一个大排序数组。客户端每次提交都要把自己的批次合并进整个数组，数据库越大，每次提交越慢。而且一次提交进行时，其他所有客户端都得等。

服务器现在把数据库切成 1024 个分片，每片有自己的锁。提交的代价只取决于批次大小，不再取决于数据库大小。3 亿条目时结果如下：

Brain，3 亿条目	之前	现在
提交	923 ms	12 ms
查找	598 ms	45 ms
单个客户端最长等待	2.6 s	39 ms
吸收 3 亿候选	1113 s	56 s
数据之外的内存开销	26%	1.3%

服务器现在为其数据保留一段地址范围。这对大会话省下处理时间和内存，但要求不受限的虚拟地址空间；不需要物理内存背书整个保留范围。

客户端现在默认对范围和候选去重。状态栏把 brain 拒绝细分为\"已被别处保留的范围\"和\"服务器已见过的候选\"。

4.4.1. 用先前攻击喂 Brain

假设你已对一个昂贵目标（比如 bcrypt 哈希列表）跑过一次攻击，但没用 brain。现在你想让 brain 保证下次攻击不再重复测那些候选。此前把它们送进 brain 的唯一办法，是以 brain 客户端身份把同一个攻击按原来那慢速再跑一遍。

用新的 --brain-feed 选项，把先前攻击的候选用 --stdout 直接管道进 brain。不计算任何哈希，所以是几秒而不是几天的事。brain 会话通常从哈希列表算出，而 feeder 没有哈希列表。所以先在哈希列表上启动一次 brain 客户端，从它的状态里读出会话：

Session..........: hashcat (Brain Session/Attack:0x65127819/0x88786d89)

然后把先前攻击喂进该会话：

$ ./hashcat --stdout example.dict -r rules/best66.rule | ./hashcat --brain-feed --brain-password mypassword --brain-session 0x65127819``Feeding brain session 0x65127819, reading candidates from stdin.``Fed 8475456 candidates from 8475456 lines into brain session 0x65127819, 1703038 were already known.

这 850 万候选 2 秒内进了库。其中一些已知，多为规则产生的重复项。从现在起，这张哈希列表上的每个 brain 客户端都会跳过它们——无论哪个攻击产出它们。喂库期间服务器持续运行，其他客户端可以继续破解。

对昂贵哈希这才划算。少于 1024 个盐的快速哈希，brain 根本不存候选，因为测一个候选比查 brain 数据库更便宜。见 5.2 节。

Brain 同时升级到协议版本 2，带来新的候选身份和拉伸 SHA-256 认证。升级 brain 环境前请先读 5.2 节。详见 docs/hashcat-brain.md。

4.5. 大型哈希列表

大型哈希列表在本版得到了大量关照。hashcat 现在同时按哈希列表和设备来定 bitmap 过滤器的大小，过滤器探测混合每个摘要的全部 4 个字。此外，每个 CPU 核心都参与哈希列表的计数、解析、排序、去重和索引。例如，500 万带盐哈希的加载从 7.0 秒缩到 1.2 秒。

加载耗时，7950X	之前	现在
5M NTLM	3.3 s	0.19 s
10M NTLM	7.1 s	0.36 s
50M NTLM	40 s	1.7 s

NTLM，RTX 4090	之前	现在
1k 哈希	93 GH/s	129 GH/s
100k 哈希	90 GH/s	116 GH/s
50M 哈希	1.1 GH/s	58 GH/s

在 RX 7900 XTX 上，5000 万 NTLM 哈希从 1.0 GH/s 提到 24.9 GH/s。

大列表还有更多改进：

• 重复哈希共享同一份明文存储，省时省内存

• outfile 和 potfile 每次启动只锁一次、刷一次，无盐 potfile 查找改用摘要前缀桶

• LM 两半的配对现在近乎线性，不再是平方级

• 如果另一个运行已破解整张哈希列表，hashcat 会跳过 bitmap、内核构建、设备缓冲和自动调优

• 加载大 potfile 对 BitLocker、7-Zip、KeePass、WinZip 这类大盐数据哈希模式不再是数小时的事

• 超过 4 GB 的哈希列表现在寻址正确

4.6. 共享机器与存储

如果多个运行共享一台机器，现在可以用 HASHCAT_DEVICE_MEM_LIMIT 和 HASHCAT_HOST_MEM_LIMIT 给每个进程设内存预算（单位 MiB）。

所有可重建数据现在都住在 cache 下：编译好的内核在 cache/kernels，feed 数据（如寻址数据库）在 cache/feeds/<feed>。用 --cache-path 可以把它们全部搬到共享存储。

这什么时候有用？假设你有一个 20 台计算节点的池子，都从网络共享读同一批词表。把每个节点的 --cache-path 指到共享上的同一目录。第一个需要某词表寻址数据库的节点建库，其余 19 个直接用。寻址数据库按词表内容而非路径命名，所以即使各节点挂载路径不同也能找到。GPU 与驱动相同的节点以同样方式共享编译好的内核。每个文件先以临时名写入再改名，因此一个节点永远不会读到另一个节点还在写的文件。

只读存储上，feed 缓存退回内存。共享同一内核缓存条目的设备只编译一次。

05升级之前

升级现有环境前请先读完本节。hashcat v8.0.0 的多数变化是改进，但其中一些改变了你可能依赖的行为。

5.1. --restore 改为打印存储的命令，而不是执行它

恢复文件保存着其会话的完整命令行。以前 --restore 会读出这条命令行并执行它。为防命令注入，现在不再如此（CVE-2026-68766）。

hashcat v8.0.0 起，--restore 打印存储的命令。命令已为你的 shell 加好引号，并附上 --restore-position。读一遍，确认无误后自己运行：

$ ./hashcat --session mysession --restore``...``A restore file holds the whole command line of the session it belongs to, and hashcat does``not run it for you. What this one holds is below.``Read it, then run it yourself if it is what you expect:``./hashcat --restore-position --restore-file-path=/tmp/hashcat/mysession.restore -d 2 -m 1000 -a 3 --session mysession --runtime 5 hash.txt '?a?a?a?a?a?a?a?a'``Everything on that line except the two restore options came out of the restore file.

如果命令无法为你的 shell 安全加引号（比如含不可打印字节），hashcat 改为打印转义过的参数列表。

5.2. Brain

• Brain 协议升级到版本 2，改变候选身份并使用拉伸 SHA-256 认证。客户端与服务器要一起升级。版本不匹配时双方版本号都会报出

• 已有 brain 数据库保留在盘上，但不会被加载，因为会话 ID 变了。复用 --brain-session 值将以空的去重数据开始

• 客户端现在默认特性值 3，对范围和候选都去重。盐少于 1024 的内核内模式跳过候选存储，但保留范围预定。显式设置可覆盖

• 仅预定范围的客户端不再强制 -S，快速哈希得以继续在设备上跑。这条路径用 --brain-client-features=2。默认仍然启用 -S

• 攻击身份现在包含 -S 是否激活，旧的覆盖记录不再加载。这一特定变化不触及候选身份数据库

• 攻击身份现在只包含所选哈希模式的选项，见 5.10。这改变每个哈希模式的身份

5.3. 分布式作业与监控工具

如果你在 hashcat 之上跑分布式破解框架或自己的脚本，请检查这些：

• 直攻与混合攻击现在把多个输入算作一个密钥空间，--skip、--limit 和 --keyspace 覆盖完整队列

• 密钥空间位置按基础词计数。规则和剩余掩码位随后展开

• 分轮字典攻击（包括多阶段关联攻击）拒绝 --skip、--limit 和 --keyspace。--limit 还与 --loopback 冲突，两个范围选项在跨多掩码 --restore 时冲突

• 退出码现在标明原因，包装器能区分坏任务与坏环境。错误的攻击命令（坏选项或不存在的路径）以 -2 退出；被点名的文件内容不可用（空或损坏的哈希列表）以 -12 退出；两者过去都是 -1。无法加载、报错或 panic 的桥或桥插件以 -13 退出。-2 不再代表 GPU 看门狗警报——hashcat 从未触发过它。每个码见 docs/exit_status_code.txt

• hashcat 只从终端读按键。通过管道发 s、c 或 q 的包装器不能再以此暂停、存档或退出运行

• 进度现在按请求的范围计量。CURKU 和 Restore.Point 字段仍指完整密钥空间。监控工具必须停止给 PROGRESS 加 --skip

5.4. 变更的默认值与路径

领域	现在
负载配置档 -w	接受但忽略。每次运行都用原配置档 3
独显旁的核显	关闭，除非你用 -d 选中
-d 选的设备失效	运行停止。--force 让其余设备继续
potfile 与会话	安装版使用 XDG 配置目录
内核缓存	cache/kernels ，feed 数据在 cache/feeds/<feed>
键盘布局	tables/layouts/*.table 取代 layouts/*.hckmap
.hctune 第二列	指攻击内核 0、1、3 或 4，不再是攻击模式
Brain 客户端	对范围和候选去重，见 5.2

旧的 $HOME/.hashcat 文件不会自动迁移。hashcat 会同时显示新路径与旧路径。旧格式的自定义键盘布局文件仍可用。如果你有清内核缓存的脚本，请更新路径。注意配置档 3 可能降低桌面响应性。

5.5. 移除与更名

移除或更名	现在
.zip 输入	词表、哈希、规则不再支持。gzip、xz 和 zstd 可用
-c 、--segment-size	随分段词表读取器一起移除
--backend-devices-keepfree	移除。hashcat 检查空闲内存或探测分配
--hccapx-message-pair	更名 --eapol-message-pair。旧名仍可用
OpenCL 1.0 和 1.1、加速器	不再支持。-D 3 会报告移除
模式 72000	移除。改用模式 73000

HASHCAT_NO_AMD_FREE_MEM=1 跳过 AMD 空闲内存查询，退回桌面保留值。用 --dynamic-x 时，除非你设了 -m，hashcat 现在从第一个 $dynamic_N$ 标签读格式并以模式 4000 的哈希配方运行，见 2.1 节。PCFG 设备引擎拒绝 -j 和 -k，它们在宿主生成路径下仍然可用。

5.6. 运行时库与最低版本

hashcat 现在只在需要时加载 zlib、liblzma 和 libzstd。缺库时，用到相应功能才会报告。组合、暴力、混合攻击、掩码词表和 --benchmark 需要 liblzma 来读 hashcat.hcstat2。模式 11600 需要 liblzma 和 zlib 来验证 LZMA 与 DEFLATE 归档。见 docs/hashcat-compression-libraries.md。

编码转换只在需要时加载 iconv。Windows 上 hashcat 用原生转换函数，它们不支持 EBCDIC、ISO-2022、//TRANSLIT 和 //IGNORE。

后端最低版本变了：

组件	最低版本
CUDA 驱动与 NVRTC	12.0
HIP 运行时，Linux 与 Windows	6.2.0
macOS，Metal 与 Apple OpenCL	13.0
OpenCL 平台与 OpenCL C	1.2
PoCL	5.0，配 LLVM 10.0
Intel CPU OpenCL 运行时	2020
AMD OpenCL 驱动	3000
NVIDIA OpenCL 驱动	500

低于 CUDA 或 HIP 下限时，hashcat 停用该后端并退回 OpenCL。低于其他下限时，hashcat 跳过该设备，除非用 --force 覆盖。最低版本列于 docs/hashcat-requirements.md。

5.7. 哈希模式格式

• 74 个只以存储配方运行的哈希模式换到 40009 至 40082 的编号区段，例如 15100 现在是 40038。旧编号仍可用，hashcat 会报出你用的编号，脚本和输出解析器不用改。-hh、--example-hashes 和 --identify 等列表显示新编号。docs/hashcat-hash-recipe.md 列出每个被移动模式的两个编号。brain 客户端分别用旧编号和新编号给出同一个被移动模式时，不共享 brain 会话。不带 -m 自动识别到的哈希按新编号计

• 模式 22000 和 22001 现在把原始哈希行写进 outfile 和 --show。--outfile-check-dir 能对 PMKID 和 EAPOL 读这些行。这两个模式的哈希列表重新改为单线程加载

• 模式 22001 现在每条哈希用 1240 字节盐数据（原为 956），以容纳 802.11r 字段。与模式 22000 的用量相同。大哈希列表需要更多宿主和设备内存

• 模式 29700 的密钥文件哈希现在要求 64 个十六进制字符。旧 potfile 条目仍算已破解并显示为 $HEX[...]

• 模式 5500（NetNTLMv1）拒绝最后一个密文块与挑战对不上的行。这样的行永远破不出来

• --outfile-json 行改用带空格的风格，{ \"hash_hex\": ... }。解析器无感，但字节级精确匹配会受影响

5.8. Python 桥插件

• 模式 72000 移除。相同哈希格式与插件接口改用 -m 73000

• 插件不再需要 kernel_loop()。init() 和 term() 可选，hcsp 和 hcmp 已移除。calc_hash() 和 extract_esalts() 照旧保留

• 插件必须定义 ST_HASH 和 ST_PASS。缺自检值时 hashcat 拒绝启动

• calc_hash() 内的异常会停止攻击。插件必须自行处理无法哈希的候选，而不是依赖旧的 \"invalid-password\" 兜底

• hcshared.dump_hashcat_ctx()、hcshared.load_ctx() 和 Python/example.ctx 已移除。调试就把插件当普通模块 import

• hcshared 的盐字段 getter 现在读固定的 salt_t 字段。get_salt_buf() 仍读扩展盐

• 每个 worker 保留自己的盐副本。2 万盐、28 worker 约占 4.7 GB。内存紧张就少跑几个 worker

5.9. 插件开发者与打包维护者

• 插件接口版本升至 800。为 v7.1.2 构建的自定义插件需要移植和重编。docs/hashcat-plugin-development-guide.md 描述核心库契约与移植的每一步

• Linux 与 macOS 上 SHARED=1 成为默认。Android、BSD、CYGWIN 和 MSYS2 保持 SHARED=0。Windows 发布版是共享的，但 Windows 原生构建要用共享插件需显式 SHARED=1

• 模块、桥和 feed 链接到其插件目录上层的 libhashcat.so.8、libhashcat.8.dylib 或 hashcat.dll。发布时把核心库放在前端旁边

• 移植模块时，现在要删除 module_dictstat_disable，并设置 module_hash_hints、module_hash_recipe、module_kern_bits 等新钩子。带额外参数的 init 和 term 钩子还要传入 hashcat_ctx

• 每个模块现在在 module_init() 里设置每一个钩子，没有自己实现的钩子用 MODULE_DEFAULT。hashcat 加载模块时检查所有这些钩子。有 4 个钩子过去由 hashcat 预设，现在也由各模块设置：module_usage_notice、module_advice_notice、module_length_sort 和 module_benchmark_cost

• 内核可用性现在用 module_kern_bits() 和 KERN_BIT_* 常量，取代被移除的 16 个内核 OPTS_TYPE 标志。辅助内核槽位从上一版的 5 个增到 6 个

• hc_device_param_t 现在用数组存内核、程序和缓冲。旧的按编号成员访问要更新

• 模块可通过新的 module_benchmark_cost() 钩子在基准测试头部显示自己的 cost 参数

• 模块用新的 module_register_options() 钩子注册自己的命令行选项。没有自有选项的模块把该钩子设为 MODULE_DEFAULT。选项值用 module_option_given()、module_option_u32() 和 module_option_str() 读取

• 填 user_options_t 并调 hashcat_session_init() 的程序，现在与命令行走同一套选项检查。见 5.10

• module_extra_tuningdb_block() 现在返回 char *。返回的字符串必须是堆分配副本（由 hashcat 释放），不能是静态字符串

• 桥可设置新的可选 get_unit_tuning 回调，为单元给固定调优，跳过该单元的自动调优

• 桥入口现在接收 hashcat_ctx。桥必须设置工作项粒度和全部 7 个监控钩子。关联桥必须用 bridge_salt_pos() 和 salt_per_pw 选盐

• 原生构建现在面向构建机的 CPU。发布构建用 MAINTAINER_MODE=1，指定目标用 MCPU=<core>

• 源码构建默认 PRODUCTION=0，发布包用 PRODUCTION=1 构建。设 SOURCE_DATE_EPOCH 可让同一 commit 的任意两次构建完全一致

• USE_SYSTEM_ZLIB、USE_SYSTEM_LZMA、ENABLE_UNRAR、USE_SYSTEM_UNRAR、USE_SYSTEM_XXHASH 和 WIN_PYTHON 不再支持。请从构建脚本中移除

• 随附文件、运行时依赖和构建设置见 docs/packages.md

5.10. 选项与输入检查

hashcat 现在把所有选项组合的检查集中在一处，不再散落代码各处。如果你用脚本跑 hashcat，请检查这些：

• 矛盾的选项组合被拒绝，比如 --potfile-disable 配 --potfile-path。两个动作的组合被拒绝，-b 与 -B、--benchmark-all 或 --benchmark-json 搭配除外

• 攻击模式用不了的选项被拒绝，比如关联攻击中的 --remove，或掩码词表配 --increment

• 在所选动作或攻击模式下无效果的选项被接受并忽略。比如 -S 不再改变基准测试，--keep-guessing 不再改变 --show 或 --left

• 单独使用会产生误导的选项，没有同伴时被拒绝，比如没有 --debug-mode 的 --debug-file

• 只有部分哈希模式使用的选项（如 message pair、nonce 修正和 PIM 范围）现在归这些模块所有。把它给不使用的哈希模式会被拒绝。不带 -m 时，自动识别只考虑支持你给出的全部模块选项的哈希模式

• -n 和 -T 超出哈希模式范围的值被拒绝，不再静默丢弃

• 某模块加载失败不再影响 --help、-I、--hash-info 和自动识别，只有该模式的运行停止

• 哈希文件长得像词表、词表长得像哈希文件时，运行提前停止。哈希文件前 10,000 行没有任何可解析哈希时也提前停止。--force 可关闭这些检查

• 没有词表的直攻从 stdin 读候选。在终端上这会被拒绝，因为这通常意味着忘了给哈希文件。想手敲候选，用管道喂入，如 cat | hashcat ...

HASHCAT_OPTION_DEBUG=1 打印每条决定背后的规则。

06新算法

hashcat v8.0.0 新增 146 个哈希模式，其中 91 个是哈希配方所引入哈希函数的原始哈希模式，详见 6.1。全部按 --help 的分类列出：

模式	原始哈希
40084 到 40175	哈希配方的 91 个哈希函数，见 6.1

模式	原始哈希（加盐和/或迭代）
40004	UUID v3 (RFC 4122 name-based, MD5)
40005	UUID v5 (RFC 4122 name-based, SHA-1)

模式	原始哈希（认证）
40083	Fernet (key = SHA256($pass))

模式	通用 KDF
36100	yescrypt
36200	gost-yescrypt
36600	PBKDF2-HMAC-SHA512(utf16le($pass))
40079	phpass(md5($pass))

模式	用户自定义哈希
4000	Hash Recipe, see --hash-recipe

模式	网络协议
35300	Kerberos 5, etype 23, TGS-REP (NT)
35400	Kerberos 5, etype 23, AS-REP (NT)
37600	SASL DIGEST-MD5
37601	POP3 APOP
38000	Mikrotik RouterOS EC-SRP5 (Curve25519)
38400	Kerberos 5, etype 1/2/3, DB
38500	Kerberos 5, etype 3, TGS-REP
38600	Kerberos 5, etype 3, AS-REP
40001	OSPFv2/RIPv2 MD5 authentication

模式	数据库服务器
36601	MSSQL (2025)
40006	MySQL caching\_sha2\_password challenge-response (fast auth)

模式	操作系统
3300	MD5(Sun), SunMD5
35600	gost12512crypt [$gost12512hash$] (Unix)
36300	scryptcrypt, scrypt (Unix)
37400	RACF DES Passphrase
37500	RACF KDFAES Passphrase
38200	Cisco-IOS $14$ (MD5 (Type 5) + scrypt, Convoluted)
40002	Huawei / H3C / HPE Comware $h$6$
40080	NTLM(NTLM\_bin($pass))
75000	bcrypt $2\*$, Blowfish (Unix) [Bridged: FPGA]

模式	企业应用软件（EAS）
40081	SAP CODVN H (PWDSALTEDHASH) iSSHA-256
40082	SAP CODVN H (PWDSALTEDHASH) iSSHA-384

模式	框架
35800	Symfony Legacy SHA256

模式	论坛、CMS、电商
35500	Wordpress bcrypt(hmac-sha384($pass))
40007	MODX Evolution (uncrypt)

模式	应用数据库
40000	XCA database password

模式	全盘加密（FDE）
29491	VeraCrypt BLAKE2s-256 + XTS 512 bit
29492	VeraCrypt BLAKE2s-256 + XTS 1024 bit
29493	VeraCrypt BLAKE2s-256 + XTS 1536 bit
38300	Apple DMG (encrcdsa v2, PBKDF2-HMAC-SHA1 + AES-192 key)
38700	FreeBSD GELI
38800	OpenBSD softraid FDE (PBKDF2-HMAC-SHA1)
38810	OpenBSD softraid FDE (bcrypt-pbkdf)

模式	基于文件的加密（FBE）
38900	Google fscrypt (Argon2id)

模式	密码管理器
26150	Mozilla key4.db SHA384
34301	KeePass AESKDF (KDBX v4)
36400	KDE KWallet 4.13+ (PBKDF2-HMAC-SHA512, Blowfish)
36410	KDE KWallet < 4.13 (SHA-1, Blowfish)

模式	私钥
17050	GPG (AES-OCB-128 (SHA-1($pass)))
24430	PKCS#12 (.pfx, .p12) (SHA1 + HMAC-SHA1)
24440	PKCS#12 (.pfx, .p12) (SHA256 + HMAC-SHA256)
36800	OpenSSH Private Keys (bcrypt-pbkdf)

模式	加密货币钱包
36000	BIP39 Passphrase Recovery (ASCII, P2SH/P2PKH/P2WPKH)
37700	Cardano Eternl Wallet (PBKDF2-HMAC-SHA512, ChaCha20)

模式	RFID
36900	iClass Standard (DES + hash0 + iClass Cipher, dual-MAC)
36901	iClass Legacy (partial div\_key + iClass Cipher, dual-MAC)
37000	MIFARE Ultralight C 3DES Key Recovery

6.1. 配方中的新哈希函数

哈希模式 4000 带来一整批此前任何 hashcat 版本都算不了的哈希函数。每一个都能在配方里使用——单独用，或与配方其他能力组合。每个还各有一个原始哈希模式（40084 到 40175），只哈希密码。MD6-256 保留现有模式 34600：

函数族	配方名称
MD2	md2
SHA-0	sha0
RIPEMD	ripemd
RIPEMD-128 和 RIPEMD-256	rmd128 , rmd256
HAVAL	hav128 to hav256_5
Tiger, Tiger2 和 TTH	tiger , tiger2, tth
Snefru	sne128 , sne256
PANAMA	panama
HAS-160	has160
RadioGatun	radiogatun32 , radiogatun64
Whirlpool-0 和 Whirlpool-T	wrl0 , wrl1
MDC-2	mdc2

SHA-3 候选	配方名称
BLAKE	blake224 to blake512
Blue Midnight Wish	bmw224 to bmw512
CubeHash	cube224 to cube512
ECHO	echo224 to echo512
EDON-R	edon256 , edon512
Fugue	fugue224 to fugue512
Groestl	groestl224 to groestl512
Hamsi	hamsi224 to hamsi512
JH	jh224 to jh512
Luffa	luffa224 to luffa512
Shabal	shabal224 to shabal512
SHAvite-3	shavite224 to shavite512
SIMD	simd224 to simd512
Skein-512	skein224 to skein512

除 Fugue、Hamsi、RadioGatun、TTH 和 MDC-2 外，每个函数族都有 HMAC 形式，如 hmac_groestl256(salt, pass)。一个普通 Groestl-256 哈希，一条命令的事：

$ ./hashcat -m 4000 --hash-recipe 'groestl256(pass)' hash.txt wordlist.txt

6.2. 现有哈希模式的变更

• 模式 23800（RAR3）为两条编码路径和全部 6 种标准过滤器启用新的内置解码器。它会统计到达其不支持结构的候选。这同时去掉了 C++ 编译器依赖

• 模式 11600（7-Zip）支持 ZSTD 压缩。用它的哈希需要 libzstd

• 模式 22000 和 22001 在 PMKID 和 EAPOL 之外，接受 hcxpcapngtool 的 802.11r FT 记录类型 03 和 04

• 模式 11000 接受 56 到 64 字节的 PrestaShop 盐。其优化内核已移除，因为处理不了这些更长的盐

• 模式 10000、10900、12000、12100、20200、20300 和 20400 接受 8 位迭代计数（此前接受 6 位）

• 模式 31900（MetaMask）对迭代数不是默认 5000 的 vault，读写可选的 rounds= 字段

• GPG (CAST5 (SHA-1($pass))) 接受非零 IV 和 s2ktype 3

• JtR 的 dynamic 格式以哈希配方运行，见 2.1 节。--show、--left 和 --remove 保留 JtR 原始哈希拼写

• GOST R 34.11-94 (6900)、SHA-3 与 Keccak（17300 到 18000）、MD6-256（34600）和 vBulletin >= v3.8.5（2711）此前只有优化内核。不带 -O 时，它们现在跑哈希配方，并接受最长 256 字节的密码

• 模式 34300 更名\"KeePass Argon2 (KDBX v4)\"，以区别于新的模式 34301

• 模式 8500、14200、16000、22001、27000 和 27100 声明仅 ASCII 密码。其他明文显示为 $HEX[...]

• 用法提示现在覆盖 124 个哈希模式，并点名提取哈希的工具

6.3. 提取工具

tools/ 目录新增 8 个提取工具：

工具	哈希模式	提取自
rar32hashcat.py	23800	RAR3 归档
gpg-ocb-aes2hashcat.py	17050	GnuPG private-keys-v1.d
routeros2hashcat.py	38000	RouterOS 备份与配置存储
pkcs12_to_hashcat.py	24430, 24440	.pfx 和 .p12 文件
geli2hashcat.py	38700	GELI provider、磁盘镜像、备份
krb5db2hashcat.py	38400	Kerberos 数据库
openbsd_softraid2hashcat.py	38800, 38810	OpenBSD softraid CRYPTO 卷
fscrypt2hashcat.py	38900	fscrypt protector 文件

另有 3 个提取工具更新。mozilla2hashcat.py 读取 Firefox 146 的 key4.db 文件，供模式 26150 使用。metamask2hashcat.py 既读 persist-KeyringController 下的 vault，也读 persist-root 下的。bitwarden2hashcat.py 在活动账号下读取模式 23400 的密钥哈希与 KDF 迭代数。

07性能

这一节一直是我们最爱写的。调优 hashcat 非常有意思。本版的收益来自 3 个方向：各哈希模式的单独优化、新的自动调优（autotune）、以及不再为从未用过的缓冲浪费内存。老规矩，结果取决于设备、运行时和工作负载。

7.1. 更快的破解

哈希模式	硬件	提升
PKZIP, 17200	RTX 4090	13.8x
PKZIP, 17200	RX 7900 XTX	4.4x
PKZIP, 17200	Arc A770	12.1x
Raw private keys, 30901, -a 3	RTX 4090, RX 7900 XTX, Arc A770	32x 到 58x
Raw private keys, 30903, -a 3	RTX 4090, RX 7900 XTX, Arc A770	5x 到 18x
Raw private keys, 30902, 30905, 30906	RTX 4090, -a 3	35x 到 45x
RACF KDFAES, 14200	Arc A770	10.9x
RACF KDFAES, 14200	RX 7900 XTX	+34%
Radmin3, 29200	RTX 4090, RX 7900 XTX	8.2x 到 11x
Electrum Wallet, 21800	Arc A770	6.6x
QNX SHA-512, 19200	Arc A770	4.2x
NetNTLMv1, 14000, -a 3	RTX 4090	+17% 到 +24%
NetNTLMv1, 14000, -a 3	Arc A770	+53% 到 +86%
NetNTLMv1, 14000, -a 3	Metal	2.9x 到 3.8x
LM, 3000, -a 3	Arc A770	8.7x
LM, 3000, -a 3	Radeon Pro W5700X, Metal	2.4x 到 2.6x
LM, 3000, -a 3	RTX 4090	+23%
descrypt, 1500, -a 3, 64 盐	RTX 4090, RX 7900 XTX, Arc A770	1.8x 到 4x
descrypt, 1500, -a 3, 单哈希	Arc A770	2.5x
8 个 AES 模式, 16600 到 23003	RTX 4090	1.2x 到 1.9x
8 个 AES 模式, 16600 到 23003	RX 7900 XTX	1.3x 到 2.6x
8 个 AES 模式, 16600 到 23003	Arc A770	1.1x 到 1.9x
RAR3-hp, 12500	RTX 4090, RX 7900 XTX, Arc A770	1.2x 到 2.4x
SAP CODVN H isSHA512, 40078	RTX 4090	2.1x
Mozilla key3.db, 26000	RX 7900 XTX	1.9x
Mozilla key3.db, 26000	Arc A770	1.7x
PBKDF2-HMAC-SHA512 模式	Arc A770	1.7x 到 1.9x
JWT, 16500	Arc A770	2.4x
DPAPI masterkey file v2, 15900	Arc A770	2.3x
Perl Mojolicious cookie, 16501	Arc A770	1.9x
Perl Mojolicious cookie, 16501	RX 7900 XTX	1.4x
KeePass Argon2, 34300	Arc A770	1.8x
SAP CODVN F/G, 7800, 7801	RX 7900 XTX	1.6x
PDF 1.7 Level 8, 10700	RX 7900 XTX	1.5x
Whirlpool, 6100	Arc A770	1.5x
TrueCrypt boot-mode, 29341	Arc A770	1.5x
MS-AzureSync PBKDF2-HMAC-SHA256, 40037	Arc A770	1.5x
Streebog 模式, HIP	RX 7900 XTX	+7% 到 +57%
VeraCrypt Streebog 模式, HIP	RX 7900 XTX	+16% 到 +85%
md5crypt, 500, 优化	RTX 4090, RX 7900 XTX, Arc A770	+9% 到 +37%
MD5, 0, 优化组合	AMD, NVIDIA, Intel	+10% 到 +92%
RC4 模式 9700, 9800, 10500	RTX 4090	+21% 到 +33%
SM3, 31100, -a 3, 优化	RTX 4090	+19%
scrypt 模式 8900, 22700, 27700, 28200	RTX 3070	+18%
scrypt 模式 8900, 22700, 27700, 28200	RTX 4090	+11%
Argon2 模式, AMD OpenCL	RX 7900 XTX	+2% 到 +79%
41 个 UTF-8 到 UTF-16 模式	GPU	+2.3% 到 +9.0%
MD5, 0, -a 3, 优化	Apple M3 Max	+8.7% 到 +10.2%
NTLM, 1000, -a 3, 优化	Apple M3 Max	+9.1% 到 +9.5%

多数行对比的是 v7.1.2 与 v8.0.0 在单哈希下 tools/benchmark_deep.pl 的运行结果。并非每个模式都变快了。有些比 v7.1.2 慢，多数在 Arc A770 上。

小词表配大量规则时，现在每台设备都有活干。以前，最后的基础词整波整波地分给头几台设备，其他设备干坐。慢哈希过去每次启动只跑一条规则，启动规模一直上不去。5 万词、15 万规则时，模式 12700 现在在 2 张 RTX 4090 上 17 秒收工，而不是在其中一张上 60 秒。惯用的变通办法——每卡一个 hashcat 实例——约要 31 秒。在 2 张 RX 7900 XTX 上，同一运行从 51 到 57 秒降到 14 秒。

还有几项改进放不进表格里：

• 按长度排序候选，在 19 个主动加入的哈希模式中把吞吐提高 50% 到 200%。--length-sort-disable 可关闭

• 自动调优现在能到慢哈希的完整 accel 1024。过去停在 711，压住了那些全 accel 跑得最好的模式

• 短启动不再在宿主读回破解数时让 GPU 空转——这在 CUDA 上每次启动最高损失 0.8 ms

• 小于一次启动的慢哈希批次现在摊到每个计算单元上，小词表和每张词表的结尾因此提速

• scrypt 的 TMTO 值超过 2 时，喂不饱的高内存 GPU 吞吐提高 5% 到 46%

• RTX 4090 上，计数 3 以上的规则 Z 在优化内核里快约 40%；同一张卡上，计数 2 以上的规则 z 在纯内核里最快快 2.3 倍

• 候选准备现在与设备工作重叠，管道输入改为成块到达。这些变化帮到多设备攻击

• 大规则文件加载更快、更省内存，--stdout 下的规则处理用满每个宿主核心

7.2. 自动调优

自动调优过去在每个步阶都实跑一次内核来找对启动规模。对慢哈希模式尤其如此——这意味着在攻击根本不会用到的规模上干等很多次启动。hashcat v8.0.0 里，自动调优从设备自己报告的信息出发：

自动调优	v7.1.2	v8.0.0
线程数	用计时启动逐步搜索	CUDA 与 HIP 上做占用率查询
测量	每个步阶一次启动	少量探测，每次规模由上一次决定
启动规模	凑一个目标时长	以整数波次凑足目标时长
同型号设备	每台各调一次	只调一次，结果共享
重复轮次	重新调优	复用结果

从用户视角，这意味着攻击开始前的等待更少，且攻击避免了过小的启动。在等价设备与关联轮次之间，自动调优耗时减少 32%。跨词表队列、掩码文件和增量复用结果帮助更大：

掩码文件	之前	现在
30 掩码	71 s	6 s
200 掩码	243 s	4 s

由此，hashcat 不再读取负载配置档，每次运行都用配置档 3，详见 5.4 节。想看自动调优在干什么，设 HASHCAT_AUTOTUNE2_VERBOSE，它会打印探测耗时、代价模型和选定的启动。

7.3. 内存

• 移除未使用的事件积压，每次攻击省 160 MiB 内存

• 在设备上生成候选的掩码攻击，不再为宿主构建的候选分配它们从不使用的设备和宿主缓冲

• 压缩候选缓冲按哈希模式的最大密码长度定容。-m 0 -a 0 -O 下，宿主分配从 2583 MB 降到 1305 MB

• 寄存器溢出预留按常驻工作项定容，RTX 4090 上模式 0 的预留削减 99%

• 统一内存设备只预留需要的宿主缓冲，而不是半个池子

• Argon2 缓冲跟随攻击规模而不是自检规模

• Markov 字符集缓冲按最长掩码定容，不再是全部 256 位。8 字符掩码现在需要 2 MB 而非 67 MB——宿主如此，每台设备亦然

08用户体验与平台

8.1. 更少的等待

没人喜欢等攻击启动。以下是 hashcat v8.0.0 帮你省时间的一些地方：

之前与之后	之前	现在
模式 2600，Intel CPU 首跑	12 min	44 s
模式 1410，Intel CPU 首跑	10 min	3 min
--keyspace 探测，4 字符	543 ms	22 ms

这两个 Intel CPU 运行的时间几乎全部花在编译内核上，之后的破解速度不变。

启动耗时（首个候选之前）	节省
冷启动模式 0，跳过核显	26%
冷内核构建，ROCm 7.0.1	42%
后端信息，ROCm 7.0.1	70%

每次运行的收尾也快约 0.6 秒。跨 200 个掩码的 --keyspace 探测快 9 倍。被排除的 CUDA 设备不再为了查个内存就创建上下文。

8.2. 控制与反馈

现在你可以把运行中的攻击在密钥空间里前后挪。按 \"r\" 或 \"a\"、左右方向键、或 \"<\" 和 \">\" 回退或前进；按住不放移动更快。还可以按 \"e\" 在攻击运行中修改 --runtime 上限。暂停中的攻击对退出和恢复的响应也更快了。

提示信息也更清楚了：

• 解析错误会显示出错的文本和期望的格式，并点名命令行里给的哈希

• 出错后多一行指明原因所在，比如是攻击命令还是任务

• 状态行不再等待运行中的内核构建候选预览——那会拖住它最多整整一次启动，PCFG 攻击尤甚

• 攻击前的 --outfile-check-dir 扫描会报告起止和移除的哈希，并在 --task-time-breakdown 中有自己的行

• hashcat 会察觉哈希文件与词表装反了，点出两个文件的名字，在加载任何东西之前停下。自动识别不再因为词表里几个词恰好能当哈希解析就选中一个模式

• 词表的初始扫描以 MiB/s 显示吞吐

• 状态栏把词表标为 feed，候选未在设备上放大时显示\"Host Generator + PCIe\"

• 大设备集改用汇总的候选窗口、桥速度和分组温度，不再每次刷新都一行一个单元

• 诊断信息显示 NVIDIA 降频原因和接受的 -u 范围。HASHCAT_MEMORY 显示各设备内存预算，-I 显示缓存大小和桥单元

• Tab 补全覆盖 PCFG、表、feed 攻击与掩码词表、--lookup、--cache-path、自定义字符集 5 到 8，以及所有调试模式

8.3. 新选项

选项	作用
--json	所有结构化输出以 JSON 发出，含基准测试
--benchmark-json	仅基准测试以 JSON 发出，并开启 -b
-B , --benchmark-pure	基准测试纯内核。-b 仍测优化内核
--hash-recipe	为模式 4000 描述哈希，见 2.1 节
--lookup	找出候选在攻击中的位置，见 1.7 节
--rules-concat	把规则文件串成一条序列
--hash-copy	outfile、potfile 和状态保留已破解哈希的输入拼写
--encrypt-with-pubkey	用至少 3344 位的 RSA 密钥加密恢复出的明文
--task-time-breakdown	显示各阶段耗时与峰值内存
--pipeline-stats	显示每台设备的供料、拷贝、传输与循环计时
--cache-path	搬移所有缓存，见 4.6 节
--brain-feed	把 stdin 的候选加进运行中的 brain 服务器
--stdin-count	为 stdin 攻击显示进度与完成时间，见 1.6 节
--length-sort-disable	关闭按长度排序候选

--encrypt-with-pubkey 值得单独说一句。它面向\"恢复出的密码不得以明文存放\"的场景。只有使用该选项时 hashcat 才加载 OpenSSL 3。它会在状态里隐藏明文，并拒绝明文输出与恢复选项。见 docs/hashcat-encrypted-plains.md。

8.4. 基准测试

默认 -b 清单现在包含 yescrypt、gost-yescrypt、scryptcrypt、KeePass KDBX4 和 Kerberos 5 etype 23 AS-REP。MyBB 取代 vBulletin，冗余的 md5($pass.$salt) 模式已移除。结果现在标明所用内核。每条结果头部显示 Argon2 (m, t, p)、scrypt (N, r, p)、yescrypt (N, r, p, t) 和 bcrypt (cost) 的真实 cost 参数，而不是单个迭代计数。

8.5. 平台

在搭载 macOS 26 的 Apple Silicon Mac 上，hashcat 现在使用 Metal 4——Apple GPU 计算接口的最新版。编译好的管线缓存在 cache/kernels，之后的启动跳过编译。较老的 Mac 和其他 Metal 设备保持 Metal 3 路径，-I 会显示每台设备用哪个版本。Apple Silicon 构建现在默认原生 arm64。需要通吃 Apple Silicon 与 Intel Mac 的单一二进制，MACOS_UNIVERSAL_BINARY=1 依然能编。

hashcat 现在也能构建 Android 版（在 Termux 下运行），以及小端 LoongArch、PowerPC 和 MIPS 系统。OpenBSD 上用基础系统自带的编译器构建，无需额外编译器包。

hashcat 现在自行寻找系统里最新的 NVRTC、HIPRTC 和 HIP 运行时库。在 Linux 上，这意味着装运行时包就够。HIP 还会根据加载的运行时选择接口，所以同一个 hashcat 二进制既能跑在 AMD 的 ROCm 上，也能跑在海光的 DTK——海光加速器的 HIP 栈——上。

Windows 上，hashcat 现在向控制台写 UTF-8，看非 ASCII 字符不用再 chcp 65001。路径和参数处处保留 Unicode 字符，超过 260 字符的路径也能用。Windows 二进制还带上了原生版本信息。

8.5.1. Mesa Rusticl 下的 AMD GPU

Rusticl 是 Mesa 的 OpenCL 驱动，Mesa 是多数 Linux 发行版自带的开源图形栈。hashcat 现在能在 rusticl 下跑 AMD GPU，温度、风扇和频率读数与 AMD 自家驱动一致。它已经是货真价实的备选。RX 7900 XTX 上，rusticl 跑 Streebog 比 AMD 自家 OpenCL 快 62%。

其余大多数哈希在 rusticl 下仍偏慢，主因是循环移位（rotations）。哈希函数不停地把字按固定量循环移位，而 Mesa 的编译器把每一次移位编译成 2 条指令而非 1 条。我们给 Mesa 提了修复——merge request 44096——正在等 review。带上这个修复，同一张卡上 SHA-256 快 36%、SHA-1 快 32%、NTLM 快 22%、SHA-512 快 13%。修复落地后，rusticl 在 NTLM 和 MD4 上反超 AMD 自家 OpenCL。加上本版已包含的一处我方改动，Whirlpool 跑到 2206 MH/s，对比 AMD 自家 OpenCL 的 1875 MH/s。

09Bug 修复

306 个修复 bug 没法在此一一列出，完整清单在 docs/changes.txt。但其中一些值得你注意。

9.1. 旧版本漏掉的密码

在下列情况下，旧版 hashcat 漏掉过密码：

哈希模式	漏掉了什么
22000, 22001 (WPA)	来自 PSK-SHA256（AKM 6）网络的 PMKID
22000, 22001 (WPA)	超过 256 字节的 EAPOL 帧，例如带厂商 RSN 数据的 M2
2500, 2501, 22000, 22001	密钥版本 3 握手上的 nonce 纠错
22 个 UTF-16 模式，如 NTLM 和 DCC	多数 CPU 上纯掩码攻击中的非 ASCII 密码
7700, 7701, 7800, 7801 (SAP)	改变长度的规则下的每一次破解
11700, 11800, 28000	改变长度的规则下的每一次破解
1500, -a 3	多条哈希共享一个盐的列表
72000, 73000	一个盐挂多条哈希时，列表的大部分
70000, 73000, 74000 在 -a 9 下	除一条外，全部哈希
14500	128 或 192 位密钥列表中，除第一条外的全部哈希
23001, 23002, 23003 (SecureZIP)	共享 IV 前缀的哈希中，除一条外的全部
34200, 34201, 34211 (MurmurHash64A)	纯组合与混合攻击中较短的候选
200 (MySQL323)	含空格或制表符的密码
6900	空密码
Argon2 模式	混合并行度的哈希，AMD 与 NVIDIA OpenCL 之外
-a 9 下的 Argon2 模式	混合内存代价列表中的哈希
8300 (DNSSEC)	大写字母写就的域名
7800, 7801 (SAP)	超过 119 字节的 SHA-1 消息
SNMPv3 模式	短于 13 字节、或 18 到 32 字节长的 Engine ID
32500，CPU 上向量宽度 4	每 4 个候选里的 3 个
12150	向量宽度大于 1（CPU 默认）时的候选
Apple 的 Intel GPU 驱动	-a 0 纯内核里每个奇数工作项

如果你用 v7 攻击过其中某个哈希模式，重跑一次也许是值得的。

9.2. 安全修复

这些修复关闭了 v7.1.2 及更早版本中的安全问题：

问题	修复内容
CVE-2026-68766	经恢复文件注入的选项，见 5.1 节
CVE-2026-68767	一条填满读取缓冲的输入行在缓冲外多写了一个字节
CVE-2026-68768	过长的用户名、哈希或明文溢出 outfile 行
Brain 服务器	任何能连上其端口的主机都能在无密码的情况下让它停摆

brain 服务器问题影响自 v5.0.0 起的每个版本。

9.3. 其他值得注意的修复

• 自动调优在所有设备上失败时，hashcat 曾以 0 退出。现在以 -10 退出

• Windows 上，按名称加载的库会在工作目录里搜索。hashcat.exe 旁的库仍会加载

• 子进程现在关闭 hashcat 的文件句柄和 brain 套接字，Python worker 不再继承 potfile 或活着的 brain 连接

• 内核缓存写入现在用临时文件加原子改名，其他进程不再可能读到写了一半的内核

• 内核缓存键现在包含源码内容，改过的内核会被重编

• 组合与混合输出不再在 256 字符处截断明文

• Metal 后端过去既不释放 command buffer 也不释放 encoder，内存随运行时长一直涨

• Windows 的路径和参数丢失 Unicode 字符，破坏过安装路径、掩码、规则和 potfile

9.4. 按领域

64 个修复是内存安全修复，多数在哈希解析器里：

领域	修复数
内存安全：哈希解析与编码	41
内存安全：候选、规则与掩码	11
内存安全：服务与接口	12
哈希模式与内核	67
后端：OpenCL、调优与内存	28
接口与状态	28
后端：桥与硬件监控	26
攻击模式与候选	18
工具与测试	16
哈希列表、potfile 与 outfile	15
后端：Metal 与资源生命周期	13
Windows	13
构建与打包	10
Brain	8

10幕后

本节主要写给打包维护者、插件开发者，以及所有对 hashcat 内部如何运转感到好奇的人。

10.1. 构建系统

hashcat 现在是一个共享核心库。哈希模式模块、桥和 feed 全部链接 libhashcat，核心导出定义明确的插件 API。宿主哈希与密码函数仍对插件可用，即使没有任何内置插件使用它们。插件还能接收桥参数、描述多部件单元，并使用核心的设备分配、编译和启动函数。

内置的 zlib、LZMA、UnRAR 和 xxHash 副本全部移除。hashcat 现在用系统 zlib 和 LZMA，用自己的 RAR3 解码器顶替 UnRAR，并用自家非加密 64 位哈希 paw64 顶替 xxHash。paw64 通过此类哈希函数标准测试套件 SMHasher3 的全部 188 项测试，比 xxHash 快 1.6 倍。附带效果：不再需要 C++ 编译器。

发布构建启用链接时优化。共享核心还让解包后的发布体积缩小约 73%。构建也可复现：设好 SOURCE_DATE_EPOCH，同一 commit 的任意两次构建完全一致。

体积的大头消失在模块里。v7.1.2 中每个模块都自带共享代码的一份拷贝，现在它们都链接同一个核心库。模块从 582 个增至 728 个，占用的空间却只有原来的一小部分：

解包体积	v7.1.2	v8.0.0
Linux 模块	183 MB	14 MB
Windows 模块	167 MB	32 MB
核心库，Linux	-	3.9 MB
核心库，Windows	-	3.9 MB

给打包维护者：

• 开发安装包含公开插件头文件和无版本号的 libhashcat.so

• make install 包含 feed、规则、PCFG 规则集和 Python 目录

• hashcat_binaries 容器交叉构建发布版，并新增 Ubuntu 26.04 的 CUDA 和 AMD 镜像。docker/patches 里的补丁打不上就构建失败

• CI 每次推送都构建 FreeBSD 和 Linux ARM64，每周构建 OpenBSD、NetBSD 和 DragonFlyBSD。tools/test_package.sh 在上传前检查每个产物

• docs/packages.md 列出随附文件、运行时依赖和构建设置

10.2. 内核源码

每个内核都要 include 的 inc_common.cl 从约 3.9 万行缩到约 5400 行。约 1.2 万个手敲索引被 3 个经过验证的宏取代。内核选择集中到一处，还腾出 16 个选项位给未来的标志。快速内核只为攻击要读的数据保留常量内存，掩码攻击拿回 64 KB 预算中的 28 KB，组合攻击拿回 32 KB。

每个内核算的都和从前一字不差，但构建快得多：

内核构建，RX 7900 XTX	之前	现在
空内核	3.0 s	0.2 s
模式 0，-a 3 纯	7.6 s	0.6 s
模式 500，优化	7.5 s	0.4 s
模式 1700，-a 3 纯	37 s	3.5 s
OpenCL 启动	14 s	8.2 s

OpenCL 的哈希与 HMAC 辅助函数现在只读输入长度以内的字，插件不再需要把输入补齐到整块。

10.3. 测试框架

测试框架不再需要 Perl。它现在完全用 Python 写——从测试模块到取代旧 shell 脚本的 tools/test.py。该脚本跑 test、edge 和 coverage 套件，还能用 -j 并行。测试套件需要 Python 3.10 或更新版本，所用包的版本钉在 tools/requirements.txt。失败的运行会把它的哈希文件和字典留在日志目录，你可以凭上传的日志复现。

生成的测试密码过去是纯 ASCII，现在包含多字节 UTF-8 字符，测试因此也覆盖含 ASCII 之外字符的密码。许多真实密码就含这些字符。

测试模块	v7.1.2	v8.0.0
数量	462	544
语言	Perl	Python

覆盖	模式数
真实容器	105
独立 oracle	29
-M 快速选择	24

edge 套件覆盖每个哈希模式的全部攻击模式、内核类型、目标类型和向量宽度，包括 PCFG、feed、关联攻击和掩码词表。容器测试创建真实的 LUKS、TrueCrypt、VeraCrypt、GPG、PKZIP、RAR、7-Zip、PDF 和 OpenSSH 文件并破解它们。--bridge 选项经 Python 桥破解每个模式自己的测试 oracle，用参考实现校验解析器。多哈希运行现在在模式允许的地方，让 2 对不同的哈希共享一个盐。这套测试在已发布的哈希模式里抓到了真 bug，详见 9.1 节。

tools/test_options.py 单独和成对地测试每个选项。运行崩溃、开始挂起、或接受了过去会拒绝的组合时，它会报失败。

除此之外，每周一次的 CI 运行覆盖优化与纯内核、Python 桥和容器。

10.4. 文档与许可

本版新增文档：

文档	内容
SECURITY.md	如何报告漏洞
CONTRIBUTING.md	贡献规则与代码风格
AGENTS.md	AI 编码智能体指引
docs/hashcat-requirements.md	每个后端的最低版本
docs/packages.md	随附文件与依赖
docs/hashcat-rust-plugin-quickstart.md	Rust 桥与 feed
docs/plugin-development-workshop/	编写哈希模式的练习
docs/hashcat-pcfg.md	PCFG 攻击
docs/hashcat-table.md	表攻击
docs/hashcat-association.md	关联攻击
docs/hashcat-hash-recipe.md	哈希配方
docs/hashcat-generic-attack-mode.md	使用 feed
docs/hashcat-generic-attack-mode-development-guide.md	编写 feed
docs/hashcat-compression-libraries.md	何时需要 zlib、liblzma 或 libzstd
docs/hashcat-encrypted-plains.md	--encrypt-with-pubkey
docs/hashcat-task-time-breakdown.md	--task-time-breakdown

README.md 也修订了。GitHub 的 issue 报告现在用表单，版本、命令行、输出和操作系统各有独立字段。

我们补上了内置 Argon2、scrypt-jane、yescrypt 和 PPMd 代码，以及 Windows 版 liblzma 和 libzstd 库的许可证文本。

10.5. 环境变量

少量环境变量让你看清 hashcat 内部，或把新行为关回旧状态。多数用户永远用不上，但遇到麻烦时，它们能帮我们帮你：

变量	作用
HASHCAT_DEVICE_MEM_LIMIT	每进程设备内存预算，单位 MiB
HASHCAT_HOST_MEM_LIMIT	每进程宿主内存预算，单位 MiB
HASHCAT_MEMORY	打印每台设备内存预算的花销明细
HASHCAT_AUTOTUNE2_VERBOSE	打印自动调优探测、代价模型与启动
HASHCAT_PIPE=N	每 N 次启动打印一次 --pipeline-stats，而非 50
HASHCAT_PIPE_SYNC	与设备同步地准备候选
HASHCAT_CLSHARE=0	给 OpenCL 克隆独立的上下文与程序
HASHCAT_SALT_INNER=1	先让每个放大项对所有盐过一遍
HASHCAT_FORCE_NO_INLINE	用 FORCE_NO_INLINE 构建内核
HASHCAT_NO_AMD_FREE_MEM=1	用桌面保留值，不用 AMD 的空闲内存查询
HASHCAT_OPTION_DEBUG=1	打印每条选项检查背后的规则，见 5.10
HASHCAT_MODULE_CACHE_DISABLE=1	关闭模块选项缓存

11下一步更新的计划

• 我们将在 v8.1.0 重新设计带盐哈希列表的主循环。如今，hashcat 对一个盐跑许多候选，然后换下一个盐。这个顺序源自大哈希列表多为无盐（如裸 MD5）的年代。如今大列表多为带盐，且多数盐只挂一条哈希。反过来让许多盐对同一批候选跑，某个盐可能早早破解并立即退出列表，剩余的运行随之变便宜。我们会在 GPU 上实测两种顺序，并把循环做得足够灵活、能在两者间选择

• 我们计划支持云 FPGA，比如 AWS EC2 F2 实例，按小时租板卡而不是买板卡

• 我们将改变模块钩子的工作方式。如今每个模块在 module_init() 里列出所有钩子，不用的设为 MODULE_DEFAULT。于是每加一个新钩子，就得动 700 多个模块里的每一个——本版为 module_register_options() 就这么干了一遍。hashcat v8.1.0 起，加钩子将不再需要碰每个现有模块

12贡献者名单

我们要感谢以下为 hashcat 8.0.0 做出贡献的人：

名字	名字	名字	名字	名字
0xVavaldi	4RH1T3CT0R7	ahmed-alnassif	albaropereyra22	AlbertVeli
AmmoniaAvenue	AndrewWestberg	aurabirb	b8vr	bandrel
bbrtj	bernardladenthin	bishwabikash	blurbdust	Br0kenUK
c0rs	carlosrodfern	Chick3nman	Coontzy1	dev-goalz
Deztryoz	DJStompZone	Foxushka	fse-a	fukc-gihtub
golem445	gqxw2tjbxb-prog	holly-o	hops	Igloo-Garage
ImArjunJ	jeffmcjunkin	jengelh	jessevz	jsteube
JustGuardian	kozmer	lql341	Lyapsus	maede97
matrix	mimi89999	MisterMaluco	mohammedjhaish	MRX-72
Naster17	npinto	Oblivionsage	PenguinKeeper7	pwrbob
racerxdl	raulperdomo	RealEnder	roycewilliams	shadowshan125
Shooter3k	skippdot	Spoonman1091	Suyun114	Svenja240602
thatux	toor11	valpackett	VladDBA	whoot
zyronix

这些是 GitHub 账号名，主页在 https://github.com/ 后接名字。

其中一些人对此版的塑造尤为关键：

• blurbdust 提交了首个经 LiteX 在 FPGA 上跑 bcrypt 的 pull request，并向 openFPGALoader、LiteX 和 litex-boards 加入 YPCB-00338-1P1 板卡与 BPI flash 支持——hashcat 的 FPGA 支持正是构建其上

• Br0kenUK 提出了 hints 规则集背后的点子，并找到了折叠 AES 密钥扩展表，让 8 个哈希模式提速最高 93%

• Chick3nman 加了 11 个哈希模式，其中有 GPU yescrypt、RACF、iClass、MIFARE Ultralight C 和 SAP CODVN H；加了 3 个新规则函数；修了十几处崩溃、溢出和挂起

• jessevz 加了 KWallet 哈希模式，让 brain 客户端预定密钥空间时不再强制 -S，压低了候选队列成本，并为 --lookup 能回答的每种攻击模式写了测试

• jsteube 找到让 PCFG 可寻址的方法，写了 PCFG 引擎、哈希配方引擎、FPGA 生态、表攻击、?w 支持、新的 --lookup 功能和 feed 插件，并 review 和合并了各路 pull request

• matrix 全程送出 136 个 pull request：hashcat-toolchain 构建容器与大量 CI 及平台构建、Metal 4 支持、--rules-concat、4 个新哈希模式、PCFG 设备引擎的提速与修复，以及一长串内存安全与泄漏修复

• PenguinKeeper7 加了 WordPress bcrypt、phpass(md5) 和 Symfony Legacy 哈希模式与 --hash-copy 选项，并提速了直攻与组合攻击下的 MD5

• Shooter3k 维护着一个 fork，其点子被本版吸收：掩码与混合攻击中的规则、运行中攻击在密钥空间里前后挪、任务耗时分解、多字节规则操作数、Windows 上的 UTF-8 输出，以及许多搁置已久的修复

• thatux 写了 tools/test.py 并把所有测试模块迁到 Python，搭起真实测试容器和 sanitizer 与 fuzzing 构建，修掉它们抓出的 bug。thatux 还加了 --json、--seekdb-path、按长度排序的候选和每个模块的用法提示

13结语

hashcat v8.0.0 带来多项重大特性，说实话，它们本可以撑起好几个版本。但每一项都在各自的角度上举足轻重：大规模分布式作业、以生成器插件为基座面向未来的根基、更易打包的重构核心，以及一长串 bug 修复。它们同批抵达，节奏快得没给中间再插一个版本留出喘息。

有人问我新特性里哪一项最重要。我真能答得上来：PCFG 和哈希配方。它们都是为用户而生的，不是为开发者。

叠了掩码的 PCFG 好过裸掩码。掩码攻击跑得更快，但 PCFG 的概率顺序轻松补回差距——幅度大到我给不出一个数。

但 PCFG 的意义远超掩码。PCFG 本身不新鲜，新鲜的是它在 hashcat 里跑在 GPU 上。而且因为 hashcat 能在它的密钥空间里任意寻址，你现在可以把一次 PCFG 攻击拆到许多台机器上，与其他任何攻击无异。如果你天天用 hashcat，词表和规则攻击打空之后，你最可能启动的就是一次 PCFG 攻击。你可以让它无人值守地跑着，心里踏实——因为它不是无脑暴力破解。

哈希配方简单又快，很可能是模块开发的下一个大事。我们也许还需要扩展语言去覆盖更多用例，但它现在就能做的事同样难以量化。hashcat 不再\"只\"支持 700 个哈希模式——它支持的是无限多个。

我要真诚感谢所有让这个版本落地的贡献者、测试者和支持者。你们知道自己是谁。谢谢。

附一 · 文档结构索引（编辑添加，树格式）

hashcat 8.0.0 - Release Notes               # 官方发布公告（本文正文所译）``├── 开篇数据                                 # 4,091 个文件改动 / 748 条日志 / 63 位贡献者``│   ├── hashcat 本体变化表                   # 11 特性 / 4 攻击模式 / 146 哈希模式 / 306 修复``│   └── GitHub 社区数据表                    # 43 新贡献者 / 364 个合并 PR``├── 关于 AI 的一点说明                       # AGENTS.md 与 AI 审查流程``├── 1. 新攻击``│   ├── 1.1 PCFG，攻击模式 4                 # 概率攻击 + 可寻址密钥空间``│   │   ├── 1.1.1 掩码：一个形状，或一个片段``│   │   ├── 1.1.2 Hints：只攻一个人``│   │   └── 1.1.3 规则集与设置``│   ├── 1.2 账号感知的关联攻击，攻击模式 9``│   ├── 1.3 表攻击，攻击模式 5               # token 替换引擎回归``│   ├── 1.4 掩码中的词表，攻击模式 12        # ?w / ?q 占位符``│   ├── 1.5 每种攻击模式中的规则``│   │   └── 1.5.1 更多规则功能（h/H/S/vNX/BNX）``│   ├── 1.6 Feed 插件，攻击模式 8            # 候选生成器插件化``│   └── 1.7 Lookup：攻击在哪里命中一个密码``├── 2. 没有哈希模式的哈希``│   ├── 2.1 Hash Recipes，哈希模式 4000      # 命令行描述哈希，编译进 GPU 内核``│   │   └── 2.1.1 新哈希模式，现在只是一个模块``│   ├── 2.2 Python 桥                        # 模式 73000，提速约 38 倍``│   └── 2.3 Rust 桥                          # 模式 74000``├── 3. FPGA 支持                             # 哈希模式 75000，7 种板卡``│   ├── 3.1 bcrypt 对 GPU 做了什么``│   ├── 3.2 我们构建了什么                   # 每核两哈希 + feeder/比较器``│   ├── 3.3 支持的板卡``│   ├── 3.4 速度``│   └── 3.5 扩展性                           # 一块主板约 20 张卡``├── 4. 大规模与分布式作业``│   ├── 4.1 可寻址词表                       # seek 数据库 + zstd``│   ├── 4.2 多张词表，一个密钥空间``│   ├── 4.3 分布式攻击中的 Lookup``│   ├── 4.4 Brain 服务器                     # 1024 分片，提交 923ms → 12ms``│   │   └── 4.4.1 用先前攻击喂 Brain         # --brain-feed``│   ├── 4.5 大型哈希列表                     # 50M 哈希 1.1 → 58 GH/s``│   └── 4.6 共享机器与存储                   # --cache-path``├── 5. 升级之前（必读）``│   ├── 5.1 --restore 改为打印命令           # CVE-2026-68766``│   ├── 5.2 Brain（协议 v2）``│   ├── 5.3 分布式作业与监控工具``│   ├── 5.4 变更的默认值与路径``│   ├── 5.5 移除与更名``│   ├── 5.6 运行时库与最低版本``│   ├── 5.7 哈希模式格式（40000+ 编号区段）``│   ├── 5.8 Python 桥插件``│   ├── 5.9 插件开发者与打包维护者           # 插件接口版本 800``│   └── 5.10 选项与输入检查``├── 6. 新算法                                # 146 个新模式全表``│   ├── 6.1 配方中的新哈希函数               # 26 个函数族（40084–40175）``│   ├── 6.2 现有哈希模式的变更``│   └── 6.3 提取工具                         # 8 个新工具 + 3 个更新``├── 7. 性能``│   ├── 7.1 更快的破解                       # PKZIP 13.8x / 私钥最高 58x``│   ├── 7.2 自动调优                         # 快 32%，掩码文件 243s → 4s``│   └── 7.3 内存``├── 8. 用户体验与平台``│   ├── 8.1 更少的等待``│   ├── 8.2 控制与反馈                       # 运行中可在密钥空间前后挪``│   ├── 8.3 新选项                           # --json / --lookup / --encrypt-with-pubkey``│   ├── 8.4 基准测试``│   ├── 8.5 平台                             # Metal 4 / Android / 海光 DTK``│   └── 8.5.1 Mesa Rusticl 下的 AMD GPU``├── 9. Bug 修复                              # 306 个``│   ├── 9.1 旧版本漏掉的密码                 # 22 类场景，建议重跑 v7 攻击``│   ├── 9.2 安全修复                         # CVE-2026-68766/68767/68768 + brain``│   ├── 9.3 其他值得注意的修复``│   └── 9.4 按领域                           # 64 个内存安全修复``├── 10. 幕后``│   ├── 10.1 构建系统                        # 共享核心库，发布体积 -73%``│   ├── 10.2 内核源码                        # inc_common.cl 39k 行 → 5.4k 行``│   ├── 10.3 测试框架                        # 全 Python，544 个测试模块``│   ├── 10.4 文档与许可``│   └── 10.5 环境变量``├── 11. 下一步更新的计划                     # v8.1.0 主循环重设计 / 云 FPGA``├── 12. 贡献者名单``└── 13. 结语                                 # PCFG 与哈希配方，为用户而生

---