John the Ripper中LM格式在目标编码变更时的测试失败问题分析

问题背景

John the Ripper密码分析工具中的LM哈希格式最近在添加了包含8位字符的测试向量后，出现了在不同DOS代码页下自测试失败的问题。具体表现为当使用某些DOS代码页作为目标编码时，测试无法通过。

问题根源

问题的核心在于新添加的测试向量中使用了两个特殊字符：

1. 德文字符"Ü"（对应8位编码）
2. 连续字符"\xaa\xaa..."（对应"¬"符号）

当这些字符被重新编码到某些DOS代码页时，会被识别为小写字符，导致John尝试对它们进行大小写转换。这种转换的结果显然是不正确的，从而引发了测试失败。

技术细节分析

编码转换的影响

John the Ripper在处理不同编码时有一套复杂的转换逻辑。在自测试阶段，initUnicode()函数会被提前调用，以确保能够正确处理8位字符。当测试向量中的字符被重新编码到某些DOS代码页时：

1. "Ü"和"\xaa"在某些代码页中被转换为小写形式
2. 系统自动尝试对这些"小写"字符进行大小写转换
3. 转换后的结果与预期不符，导致测试失败

测试向量的选择考量

原始的测试向量选择有其特定目的：

• "\xaa"（0xaa）被选为0x55或"U"的对应物
• 这种选择是为了全面测试bitsliced实现的所有部分

解决方案探索

开发团队探讨了多种解决方案：

1. 使用通用字符替代：寻找在所有支持的DOS代码页中表现一致的字符，如"°"（"\xf8"）或某些线条绘制字符

   • 优势：这些字符在大多数DOS代码页中表现一致
   • 挑战：CP868等特殊代码页缺少这些字符

2. 禁用自测试时的大小写转换

   • 问题：可能导致无法测试包含小写字符的向量
   • 潜在性能影响需要评估

3. 选择不被视为小写的代码点

   • 即使在不同编码中代表不同字符，只要不被识别为小写即可

最终解决方案

经过测试，发现使用"\xf8"（度符号）可以在所有支持的代码页中正常工作。因此：

• 将"\xaa\xaa\xaa\xaa\xaa\xaa\xaa"替换为"\xf8\xf8\xf8\xf8\xf8\xf8\xf8"
• 同时考虑将对应的"U"替换为0x07

这种修改既解决了编码转换问题，又保持了测试向量的有效性。

临时解决方案

在问题完全修复前，用户可以使用--skip参数跳过有问题的测试。

技术启示

这一问题的解决过程展示了密码分析工具中几个关键技术点：

1. 编码处理的重要性：在多语言环境下，字符编码处理必须谨慎
2. 测试向量设计：测试案例需要考虑各种边界条件和环境变量
3. 兼容性考量：支持多种历史编码系统(DOS代码页)带来的复杂性

该问题的解决不仅修复了当前的自测试失败，也为未来处理类似编码问题提供了参考方案。