1. 逆向工程中的编码陷阱解析这道CTF题目表面看似简单的RC4加解密实则暗藏了多个编码层面的陷阱。我们先从文件结构分析入手用IDA Pro加载程序后发现主要逻辑集中在main函数和两个关键子函数加密函数sub_401005和解密函数sub_401080。程序运行时会先检测输入格式if ( argc ! 3 || strlen(argv[1]) ! 16 || atoi(argv[2]) 0 )这告诉我们两个关键信息第一参数必须是16字节字符串第二参数必须是正整数。这种限制条件在CTF中往往暗示着某种加密算法的密钥长度要求。1.1 RC4算法特征识别在加密函数中观察到典型的RC4特征for ( i 0; i 256; i ) { S[i] i; K[i] key[i % key_len]; }这是标准的KSAKey-scheduling algorithm初始化过程。继续往下看while ( *input ) { j; i (i 1) % 256; j (j S[i]) % 256; swap(S[i], S[j]); *output S[(S[i] S[j]) % 256] ^ *input; }这正是PRGAPseudo-random generation algorithm的经典实现通过异或操作产生密文。至此我们可以确认程序使用了标准RC4算法。1.2 Unicode编码的隐藏陷阱题目真正的难点出现在解密阶段。当我们用常规RC4解密脚本处理时发现得到的明文始终不正确。通过动态调试发现程序在加密前对输入做了Unicode转换MultiByteToWideChar(0xFDE9u, 0, input, -1, wide_str, 256);这个Windows API调用将输入的ANSI字符串转换为宽字符UTF-16LE导致实际加密的是转换后的Unicode序列。这就是为什么直接解密会失败——我们忽略了编码转换这一关键步骤。2. 完整解题步骤拆解2.1 密钥提取与验证根据程序逻辑有效密钥需要满足长度为16字节的字符串第二参数为任意正整数实际未参与加密通过分析字符串引用发现硬编码的疑似密钥this_is_not_flag。用该密钥尝试解密失败后意识到可能需要通过逆向找到真正的密钥生成逻辑。在sub_401080函数中发现密钥被修改mov byte ptr [eax3], 5Fh mov byte ptr [eax7], 5Fh这会将密钥第4和第8个字符强制改为下划线(0x5F)。修正后的有效密钥变为thi_is_n_t_flag。2.2 解密脚本编写要点正确的解密流程应该是用修正后的密钥初始化RC4对密文进行常规RC4解密将解密结果按UTF-16LE解码Python实现关键代码def rc4_decrypt(key, cipher): # 标准RC4实现 S list(range(256)) j 0 for i in range(256): j (j S[i] key[i % len(key)]) % 256 S[i], S[j] S[j], S[i] # PRGA解密 plain [] i j 0 for byte in cipher: i (i 1) % 256 j (j S[i]) % 256 S[i], S[j] S[j], S[i] plain.append(byte ^ S[(S[i] S[j]) % 256]) return bytes(plain) # 处理Unicode编码 decrypted rc4_decrypt(bthi_is_n_t_flag, ciphertext) final_flag decrypted.decode(utf-16le)2.3 动态调试技巧当静态分析遇到困难时动态调试可以快速验证猜想在MultiByteToWideChar调用后设断点查看内存中的Unicode字符串在RC4加密完成后检查密文缓冲区对比不同输入产生的密文模式使用x32dbg观察发现输入AAAA加密后实际处理的是UTF-16LE格式的0x41004100序列这解释了为什么常规解密会失败。3. 常见错误与排查方法3.1 典型错误模式忽略编码转换直接解密得到乱码解决方法检查是否有MultiByteToWideChar/WideCharToMultiByte调用密钥修正遗漏使用原始硬编码密钥失败解决方法跟踪密钥使用过程注意运行时修改字节序问题UTF-16解码结果异常解决方法尝试LE/BE两种字节序Windows平台通常用LE3.2 调试日志分析在解密脚本中添加中间输出print(f解密后hex: {decrypted.hex()}) print(f尝试ASCII解码: {decrypted.decode(ascii, errorsreplace)})当看到解密结果包含大量0x00字节时就应该考虑Unicode编码的可能性。4. 密码学题目通用解法框架通过本题可以总结出密码学逆向题的通用分析流程算法识别查找经典算法特征RC4的KSA/PRGAAES的S盒等识别自定义变异魔改S盒、额外置换等输入输出追踪记录数据转换链如输入→编码→加密→输出特别注意编码转换API调用密钥处理分析硬编码密钥的运行时修改密钥派生函数PBKDF2等的识别动态验证使用已知输入测试加密结果对比理论加密结果与实际输出这种分析方法不仅适用于RC4对AES、DES等对称加密算法的题目同样有效。关键在于建立完整的数据流视图不遗漏任何转换环节。
1. 逆向工程中的编码陷阱解析这道CTF题目表面看似简单的RC4加解密实则暗藏了多个编码层面的陷阱。我们先从文件结构分析入手用IDA Pro加载程序后发现主要逻辑集中在main函数和两个关键子函数加密函数sub_401005和解密函数sub_401080。程序运行时会先检测输入格式if ( argc ! 3 || strlen(argv[1]) ! 16 || atoi(argv[2]) 0 )这告诉我们两个关键信息第一参数必须是16字节字符串第二参数必须是正整数。这种限制条件在CTF中往往暗示着某种加密算法的密钥长度要求。1.1 RC4算法特征识别在加密函数中观察到典型的RC4特征for ( i 0; i 256; i ) { S[i] i; K[i] key[i % key_len]; }这是标准的KSAKey-scheduling algorithm初始化过程。继续往下看while ( *input ) { j; i (i 1) % 256; j (j S[i]) % 256; swap(S[i], S[j]); *output S[(S[i] S[j]) % 256] ^ *input; }这正是PRGAPseudo-random generation algorithm的经典实现通过异或操作产生密文。至此我们可以确认程序使用了标准RC4算法。1.2 Unicode编码的隐藏陷阱题目真正的难点出现在解密阶段。当我们用常规RC4解密脚本处理时发现得到的明文始终不正确。通过动态调试发现程序在加密前对输入做了Unicode转换MultiByteToWideChar(0xFDE9u, 0, input, -1, wide_str, 256);这个Windows API调用将输入的ANSI字符串转换为宽字符UTF-16LE导致实际加密的是转换后的Unicode序列。这就是为什么直接解密会失败——我们忽略了编码转换这一关键步骤。2. 完整解题步骤拆解2.1 密钥提取与验证根据程序逻辑有效密钥需要满足长度为16字节的字符串第二参数为任意正整数实际未参与加密通过分析字符串引用发现硬编码的疑似密钥this_is_not_flag。用该密钥尝试解密失败后意识到可能需要通过逆向找到真正的密钥生成逻辑。在sub_401080函数中发现密钥被修改mov byte ptr [eax3], 5Fh mov byte ptr [eax7], 5Fh这会将密钥第4和第8个字符强制改为下划线(0x5F)。修正后的有效密钥变为thi_is_n_t_flag。2.2 解密脚本编写要点正确的解密流程应该是用修正后的密钥初始化RC4对密文进行常规RC4解密将解密结果按UTF-16LE解码Python实现关键代码def rc4_decrypt(key, cipher): # 标准RC4实现 S list(range(256)) j 0 for i in range(256): j (j S[i] key[i % len(key)]) % 256 S[i], S[j] S[j], S[i] # PRGA解密 plain [] i j 0 for byte in cipher: i (i 1) % 256 j (j S[i]) % 256 S[i], S[j] S[j], S[i] plain.append(byte ^ S[(S[i] S[j]) % 256]) return bytes(plain) # 处理Unicode编码 decrypted rc4_decrypt(bthi_is_n_t_flag, ciphertext) final_flag decrypted.decode(utf-16le)2.3 动态调试技巧当静态分析遇到困难时动态调试可以快速验证猜想在MultiByteToWideChar调用后设断点查看内存中的Unicode字符串在RC4加密完成后检查密文缓冲区对比不同输入产生的密文模式使用x32dbg观察发现输入AAAA加密后实际处理的是UTF-16LE格式的0x41004100序列这解释了为什么常规解密会失败。3. 常见错误与排查方法3.1 典型错误模式忽略编码转换直接解密得到乱码解决方法检查是否有MultiByteToWideChar/WideCharToMultiByte调用密钥修正遗漏使用原始硬编码密钥失败解决方法跟踪密钥使用过程注意运行时修改字节序问题UTF-16解码结果异常解决方法尝试LE/BE两种字节序Windows平台通常用LE3.2 调试日志分析在解密脚本中添加中间输出print(f解密后hex: {decrypted.hex()}) print(f尝试ASCII解码: {decrypted.decode(ascii, errorsreplace)})当看到解密结果包含大量0x00字节时就应该考虑Unicode编码的可能性。4. 密码学题目通用解法框架通过本题可以总结出密码学逆向题的通用分析流程算法识别查找经典算法特征RC4的KSA/PRGAAES的S盒等识别自定义变异魔改S盒、额外置换等输入输出追踪记录数据转换链如输入→编码→加密→输出特别注意编码转换API调用密钥处理分析硬编码密钥的运行时修改密钥派生函数PBKDF2等的识别动态验证使用已知输入测试加密结果对比理论加密结果与实际输出这种分析方法不仅适用于RC4对AES、DES等对称加密算法的题目同样有效。关键在于建立完整的数据流视图不遗漏任何转换环节。
