John the Ripper项目中的32位系统下WoWSRP格式内存问题分析

在John the Ripper密码恢复工具的开发过程中，开发团队发现了一个在32位Linux系统上特定条件下的内存问题。这个问题涉及到WoWSRP格式（Battle.net认证协议）的实现，特别是在使用GMP数学库而非OpenSSL的情况下。

问题现象

当在32位Linux系统上编译John the Ripper时（使用--without-openssl选项），运行测试命令john -te=0会出现内存错误。具体表现为：

Testing: WoWSRP, Battlenet [SHA1 32/32 GMP-exp]... (2xOMP) *** glibc detected *** malloc(): memory corruption: 0xb6e0af10 ***
Aborted

有趣的是，单独测试WoWSRP格式时却能通过测试。这表明问题可能与格式之间的交互有关。

问题定位

通过进一步测试，开发人员发现当同时测试AFS和WoWSRP格式时，问题可以稳定复现：

$ OMP_NUM_THREADS=1 ../run/john -te=0 -form=AFS,WoWSRP
Testing: AFS, Kerberos AFS [DES 48/64 4K MMX]... PASS
Testing: WoWSRP, Battlenet [SHA1 32/32 GMP-exp]... Segmentation fault

这表明问题可能与AFS格式使用的MMX指令集有关，影响了后续WoWSRP格式的执行。

根本原因分析

深入分析后发现，问题的根源在于32位x86架构下GMP数学库使用了x87浮点单元(FPU)进行计算，而AFS格式使用了MMX指令集。MMX与x87 FPU共享寄存器空间，当MMX指令执行后没有正确清理状态(EMMS指令)，就会导致后续使用FPU的GMP库出现计算错误和内存问题。

解决方案

开发团队提出了两种解决方案：

1. 强制使用EMMS指令：在x86.S汇编文件中添加EMMS宏定义，确保MMX状态被正确清理。

+++ b/src/x86.S
@@ -15,6 +15,8 @@
 
 #include "arch.h"
 
+#define EMMS
+
 #ifdef UNDERSCORES
 #define DES_IV                         _DES_IV

2. 在测试循环中添加EMMS调用：在bench.c文件中，在格式测试完成后显式调用emms()函数清理MMX状态。

+++ b/src/bench.c
@@ -1080,6 +1081,7 @@ next:
                ldr_free_db(test_db, 1);
                fmt_done(format);
 #ifndef BENCH_BUILD
+               emms();
                if (options.flags & FLG_MASK_CHK) {
                        mask_done();
                        mask_destroy();

技术背景

这个问题涉及到x86架构的几个重要特性：

1. MMX技术：Intel引入的多媒体扩展指令集，使用浮点寄存器作为64位整数寄存器。
2. x87 FPU：传统的浮点运算单元，与MMX共享寄存器空间。
3. EMMS指令：用于清理MMX状态，将寄存器恢复为FPU可用状态。

在密码学计算中，GMP库在32位系统上常使用x87 FPU进行高精度数学运算，而密码哈希函数可能使用MMX指令进行优化。如果两者混用而没有正确状态管理，就会导致计算错误。

影响范围

这个问题特定于：

• 32位x86架构
• 使用GMP而非OpenSSL的编译配置
• 涉及MMX指令的格式(如AFS)与使用GMP的格式(如WoWSRP)连续测试的情况

结论

这个案例展示了在密码学工具开发中底层架构细节的重要性。即使是高级的密码算法实现，也可能因为底层指令集的微妙交互而产生问题。John the Ripper团队通过添加适当的EMMS指令调用，确保了MMX和FPU状态的正确管理，解决了这个内存问题。

对于开发者而言，这个案例强调了在多格式密码恢复工具中，不同加密算法实现之间的交互测试的重要性，特别是在涉及底层指令集优化的场景下。