1. 为什么 John the Ripper 值得反复复习1.1 从一次内部演练说起前阵子帮一个朋友做内部安全演练的复盘拿到一批脱敏后的哈希样本要求评估口令强度。我第一反应不是打开什么花哨的图形化工具而是直接敲下john命令。原因很简单John the Ripper圈内习惯叫 John 或 JtR是那种你越用越顺手的工具它不挑环境、不挑格式、不挑场景从最基础的 MD5 到各种系统口令文件它都能接得住。很多人第一次接触 John 是在 CTF 比赛里拿到一个 shadow 文件或者一段哈希题目提示破解口令这时候 John 几乎是条件反射式的选择。但真正把它用透的人不多大部分人停留在john --wordlistxxx hash.txt这一条命令上遇到稍微复杂一点的情况就卡住了。这篇内容就是把我这些年反复用 John 的经验做一次系统梳理从原理到实操从字典策略到规则引擎尽量把每个环节讲透。John the Ripper 本质上是一个离线口令审计工具它的工作对象是各种哈希值而不是在线登录接口。这个定位非常关键因为它决定了它的使用场景你手里必须先有哈希才能谈破解。它解决的问题是——给定一批哈希尽可能还原出对应的明文口令从而评估口令策略的强度。适合谁看安全从业者、CTF 选手、系统管理员以及任何需要做口令强度评估的人。哪怕你完全没接触过跟着下面的步骤也能跑起来。1.2 核心关键词速览在展开之前先把几个高频词的含义对齐一下避免后面理解偏差哈希Hash口令经过单向函数运算后的固定长度字符串比如 MD5、SHA1、NTLM。单向意味着不能直接反推只能靠猜。爆破Cracking用大量候选口令逐个计算哈希和目标比对命中即还原。字典攻击候选口令来自一个预先准备好的词表按顺序尝试。规则引擎在字典基础上做变形比如大小写切换、追加数字、替换字符。掩码攻击按字符集和长度穷举适合已知口令结构的情况。盐值Salt部分哈希算法会加盐同一个口令在不同盐下哈希不同增加破解难度。这几个概念贯穿全文后面每个实操环节都会反复用到。2. John 的整体设计与版本选型2.1 两个版本别选错John 目前主要有两个分支很多人下载的时候没注意结果用起来各种别扭版本特点适用场景John the Ripper jumbo社区维护支持格式极多功能全绝大多数场景强烈推荐John the Ripper core官方精简版格式支持少只做基础测试或特定合规环境我个人的建议是无脑选 jumbo。它支持的哈希格式数量是 core 版的几十倍规则引擎、掩码、外部模式这些高级功能也都在 jumbo 里。Kali Linux 默认自带的john就是 jumbo 版本所以如果你用的是 Kali直接开箱即用不用额外折腾。提示判断当前版本是不是 jumbo可以执行john --listbuild-info输出里会明确标注。如果只显示很少的格式那大概率是 core 版。2.2 为什么它的架构值得研究John 的设计思路很务实把哈希识别和破解策略解耦。你给它一个文件它先自动嗅探里面是什么格式的哈希然后根据你指定的模式字典、掩码、规则去尝试。这种解耦带来的好处是你不需要为每种哈希写不同的脚本一套命令逻辑走天下。它的核心组件大致分三层格式层负责识别和计算各种哈希比如raw-md5、nt、sha512crypt。模式层负责生成候选口令包括字典、掩码、增量、外部模式。调度层负责把候选口令分发给计算单元管理进度和会话。理解这三层你在遇到问题时就能快速定位是格式没识别对还是候选口令生成策略不对还是资源调度出了问题。这比盲目试命令高效得多。2.3 安装与基础环境确认在 Kali 上基本不用装直接john就能用。如果是其他发行版源码编译是最稳的方式因为能确保拿到 jumbo 版git clone https://github.com/openwall/john.git cd john/src ./configure make -s clean make -sj4编译完成后可执行文件在john/run/目录下。把它加到 PATH 里或者直接用绝对路径调用。编译过程如果报缺库通常是缺 OpenSSL 开发包装上即可。注意不要随便从不明来源下载所谓的john 破解版这类工具本身涉及安全敏感操作来源不明的二进制风险极高。用官方仓库或发行版自带的版本最稳妥。3. 哈希识别与格式处理的核心细节3.1 自动识别到底靠不靠谱John 最省心的一点是自动识别哈希格式。你把一段哈希丢进文件直接john hash.txt它会自己判断这是什么。原理是它内置了大量格式的指纹规则比如长度、前缀、字符集特征。但自动识别不是万能的。我踩过的坑里最常见的就是同长度不同算法的情况。比如 32 位十六进制字符串可能是 MD5也可能是 NTLM还可能是其他算法。John 有时候会猜错导致你跑半天没结果。这时候就要手动指定格式john --formatraw-md5 hash.txt john --formatnt hash.txt--format参数是排查问题的第一把钥匙。当你发现 John 识别出的格式和你预期不符或者跑起来速度异常先检查这个。3.2 常见哈希格式对照下面这张表是我平时查得最勤的建议收藏哈希类型典型长度格式标识常见来源MD532 位 hexraw-md5Web 应用、老系统SHA140 位 hexraw-sha1部分应用SHA25664 位 hexraw-sha256现代应用NTLM32 位 hexntWindows 口令LM32 位 hexlm老 Windowsbcrypt60 字符bcrypt现代 Web 框架sha512crypt长字符串sha512cryptLinux shadowLinux 的/etc/shadow文件是最典型的场景里面的哈希通常带$6$前缀sha512crypt或$5$sha256crypt。John 能直接吃整个 shadow 文件配合unshadow命令把 passwd 和 shadow 合并后处理。3.3 处理带盐哈希的注意事项带盐的哈希是新手最容易懵的地方。盐值的存在意味着同一个口令在不同用户下哈希不同所以你不能拿一个彩虹表通杀。John 处理带盐哈希时会把盐值一起纳入计算这是它比简单脚本强的地方。但要注意带盐哈希的破解速度会明显下降因为每个候选口令都要针对每个盐值单独计算。如果你有一批带盐哈希John 会逐个处理这时候字典质量比数量更重要。实操心得遇到带盐哈希先别急着上大字典。先用小字典加规则跑一轮看看有没有弱口令往往比直接上几十 G 的字典更快出结果。4. 破解模式全解析与实操步骤4.1 字典模式最常用也最讲究字典模式是绝大多数人的起点john --wordlist/usr/share/wordlists/rockyou.txt hash.txtrockyou.txt是经典字典Kali 自带。但字典模式的效果完全取决于字典质量不是越大越好。一个 10G 的杂牌字典可能不如一个 100M 的精炼字典命中率高。我的字典策略通常是分层第一层常见弱口令 Top 1000秒出结果。第二层rockyou 这类通用字典覆盖大部分弱口令。第三层针对目标定制的字典比如公司名、人名、年份组合。定制字典这块crunch和CeWL是两个好帮手。CeWL能爬取目标网站提取关键词crunch能按规则生成组合。比如你知道目标口令可能是公司名年份就可以定向生成。4.2 规则模式让字典威力翻倍规则模式是 John 的杀手锏。它在字典基础上做变形比如john --wordlistrockyou.txt --rules hash.txt--rules会启用默认规则集把password变成Password、password123、pssword等各种变体。这一步能把字典的有效覆盖率提升好几倍。John 的规则语法很灵活你可以自己写规则文件。比如常见的变形c首字母大写$1末尾追加数字 1sa把 a 替换成 自定义规则文件用--rules规则文件名加载。我建议新手先用默认规则熟悉后再自己写。注意规则模式会显著增加候选口令数量跑之前先估算一下时间。字典 100 万条规则放大 10 倍就是 1000 万次计算速度慢的机器可能要跑很久。4.3 掩码模式已知结构时的利器当你对口令结构有把握时掩码模式效率极高。比如你知道口令是 8 位纯数字john --mask?d?d?d?d?d?d?d?d hash.txt?d代表数字?l小写字母?u大写字母?a全部字符。掩码模式本质是受控穷举比无脑全字符集穷举聪明得多。实际场景里掩码常和已知信息结合。比如你知道某系统口令是姓名拼音4位数字就可以用掩码限定结构大幅缩小搜索空间。4.4 增量模式最后的兜底增量模式incremental是 John 的全字符集穷举从短到长逐步尝试john --incremental hash.txt这个模式非常慢只适合短口令或者作为最后手段。我一般只在其他模式都失败、且确认口令很短的情况下才用。默认的增量模式字符集可以调整在配置文件里改Incremental段。4.5 四种模式对比与选择建议模式速度适用场景前提条件字典快通用弱口令有好字典规则中字典变形字典规则掩码中快已知结构了解口令格式增量慢短口令兜底无其他线索选择逻辑很简单有线索就用掩码没线索先字典加规则实在不行再增量。别一上来就增量那是跟自己过不去。5. 会话管理与性能调优实战5.1 会话保存与恢复John 默认会自动保存会话中断后可以用--restore恢复john --restore这个功能在跑大字典时特别重要。我遇到过跑了一半机器重启的情况如果没有会话保存就得从头再来。John 的会话文件默认在~/.john/目录下可以手动备份。实操心得跑长时间任务前先确认会话目录有写权限。有些环境权限受限会话保存失败中断后无法恢复白跑几小时。5.2 多核与 GPU 加速John jumbo 支持 OpenMP 多线程编译时如果启用了 OpenMP运行时会自动利用多核。可以用--forkN手动指定进程数john --fork4 --wordlistrockyou.txt hash.txtGPU 加速方面John 本身对 GPU 的支持不如 Hashcat 那么成熟但 jumbo 版有一些格式支持 OpenCL。如果你的场景对速度要求极高且哈希类型是 GPU 友好的如 NTLM、MD5可以考虑用 Hashcat 做主力John 做补充。5.3 显示已破解结果跑完之后用--show查看结果john --show hash.txt这个命令会列出所有已破解的哈希和对应明文。注意--show只显示当前会话或已保存的结果如果换了目录或清了会话可能显示不全。5.4 性能调优的几个关键点字典顺序把最可能命中的口令放前面早出结果早收工。规则精简规则不是越多越好冗余规则会拖慢速度。格式确认格式选错速度再快也是白跑。资源分配多核机器用--fork但别开太多导致内存爆掉。6. 常见问题排查与避坑实录6.1 问题速查表现象可能原因解决方法跑很久没结果格式识别错误用--format手动指定速度异常慢带盐哈希或规则过多精简规则确认哈希类型提示无可用哈希文件格式不对检查文件内容去除多余字符会话无法恢复权限或会话文件损坏检查~/.john/权限内存占用过高fork 数过多减少--fork数量6.2 几个我踩过的坑坑一哈希文件里混入了非哈希内容。有次我从日志里复制哈希连带了一些说明文字John 直接报错。后来养成习惯哈希文件里只放纯哈希一行一个。坑二shadow 文件没合并。直接拿 shadow 文件跑John 提示缺少用户信息。正确做法是先用unshadow passwd shadow combined.txt再跑 combined。坑三规则文件路径写错。--rules后面跟的是规则名或路径写错了 John 会用默认规则你以为用了自定义规则其实没有。跑之前用--listrules确认一下。坑四忽略了哈希的编码。有些哈希带特殊字符或换行符复制时容易出问题。用xxd或cat -A检查一下文件内容确保干净。6.3 CTF 场景下的实战技巧CTF 里 John 的用法和实战略有不同题目往往有明确提示。比如题目说口令是 4 位数字那就直接掩码?d?d?d?d几秒钟出结果。如果题目给的是特殊格式的哈希先用john --listformats查一下支持不支持不支持就得换工具或手写脚本。CTF 里常见的还有哈希长度扩展、加盐绕过这类考点John 本身不直接处理这些逻辑需要你先理解题目意图把哈希处理成 John 能吃的格式再跑。提示CTF 中遇到 John 跑不出的情况先别怀疑工具回头看看题目是不是有额外提示比如口令长度、字符集范围。这些信息能大幅缩小搜索空间。7. 字典与规则的进阶玩法7.1 打造自己的字典体系通用字典能解决 60% 的问题剩下 40% 靠定制。我的字典体系分三类通用层rockyou、weakpass 这类公开字典。行业层针对特定行业的口令习惯比如金融、医疗。目标层针对具体目标的定制字典用 CeWL 爬取关键词用 crunch 生成组合。目标层字典的命中率最高但准备成本也最高。实际工作中我会先跑通用层根据结果决定要不要投入时间做目标层。7.2 规则文件的编写思路John 的规则语法基于字符操作核心是对字典里的每个词做变换。写规则时我遵循两个原则覆盖常见变形大小写、数字追加、符号替换、键盘邻近键。控制膨胀倍数规则太多会导致候选口令爆炸一般控制在 10 倍以内。一个简单的自定义规则示例c $1 $2 $! sa se3这几条规则分别实现首字母大写、追加 1、追加 2、追加感叹号、a 替换 、e 替换 3。组合起来能覆盖不少真实口令。7.3 字典去重与排序字典质量比数量重要。跑之前用sort -u去重能减少无效计算。如果字典特别大可以先按长度排序短口令优先跑因为短口令命中率通常更高。8. 与其他工具的配合使用8.1 John 与 Hashcat 的分工Hashcat 在 GPU 加速上更强John 在格式支持和易用性上更好。我的习惯是GPU 友好的哈希用 Hashcat格式冷门的用 John。两者可以共享字典和规则文件切换成本很低。8.2 与信息收集工具的联动John 本身不做信息收集但它的效果高度依赖前期信息。用 CeWL 爬取目标网站关键词用 theHarvester 收集人名和邮箱这些信息都能转化成字典素材。信息收集做得越细John 的命中率越高。8.3 在自动化流程中的定位在自动化安全评估流程里John 通常作为口令强度验证环节的工具。前面用信息收集和漏洞扫描拿到哈希中间用 John 做破解验证后面根据结果生成报告。它的命令行特性很适合脚本化调用--show的输出可以解析成结构化数据。9. 一些个人体会用 John 这些年最大的感受是工具本身不难难的是策略。同样一个哈希有人几分钟出结果有人跑一天没动静差别不在命令敲得多熟而在字典选得对不对、规则写得合不合理、格式判断得准不准。我见过太多人一上来就--incremental然后抱怨工具慢。其实 John 的设计已经给了你足够的灵活性关键是你要根据手里的线索去选择最合适的模式。有结构信息就用掩码有字典就用规则什么都没有才考虑穷举。另外别忽视会话管理和结果保存。跑长任务前做好这些准备能省下大量重复劳动。最后再分享一个小技巧john --test可以测试当前机器的破解速度跑大任务前先测一下心里有个时间预期避免盲目等待。