从Hook NewStringUTF到算法还原：一次完整的Android SO层登录协议逆向复盘-洪萨配资

从Hook NewStringUTF到算法还原：Android SO层登录协议逆向全解析

在移动应用安全研究领域，登录协议的逆向分析始终是技术攻坚的核心战场。当面对一个经过深度混淆的Android应用，如何从黑盒状态逐步拆解其通信协议，不仅考验工程师的技术储备，更体现系统性思维的重要性。本文将完整呈现一次真实的SO层登录协议逆向过程，重点展示如何通过动态分析与静态分析相结合，层层递进地破解DES/CBC加密与MD5签名机制。

1. 逆向工程的方法论框架

逆向工程绝非盲目猜测，而是需要建立科学的分析框架。在Android平台，完整的协议逆向通常遵循"定位-拦截-解析-验证"四步循环：

协议特征识别：通过抓包分析确定可疑加密字段
关键函数定位：利用JNI调用链追踪加密入口
算法特征识别：结合动态调试与静态分析识别算法类型
参数重构验证：通过参数注入验证算法准确性

以登录协议为例，典型的技术路线如下图所示：

[抓包分析] → [JNI Hook定位] → [SO层分析] → [算法还原] ↑____________验证反馈___________↓

2. 动态Hook技术实战

2.1 JNI函数Hook突破点

Java Native Interface(JNI)是Java与Native代码交互的关键通道，其中NewStringUTF函数常作为加密结果的返回通道。通过Frida hook该函数，可以快速定位加密逻辑的入口位置：

function hookJNIStringOutput() { const libart = Process.findModuleByName("libart.so") const symbols = libart.enumerateSymbols() symbols.forEach(symbol => { if (symbol.name.includes("NewStringUTF") && !symbol.name.includes("Check")) { Interceptor.attach(symbol.address, { onEnter(args) { console.log(`[+] Encrypted output: ${args[1].readCString()}`) console.log(Thread.backtrace(this.context, Backtracer.FUZZY) .map(DebugSymbol.fromAddress).join('\n')) } }) } }) }

关键输出示例：

[+] Encrypted output: FfQn1pwmgRY= 0x7854e3a4 libnativehelper.so!0x12a4 0x7854e2b8 libappcore.so!0x34d0 0x7854e1cc libappcore.so!0x28fc

2.2 调用栈分析与SO定位

通过堆栈回溯可以确定加密逻辑位于libnativehelper.so的0x12a4偏移处。在IDA中加载该SO文件，跳转到对应位置后可见：

v19 = (*env)->NewStringUTF(env, encodedOutput); sub_1FEC(&inputBuffer, &encodedOutput);

逆向经验表明，这种模式通常是加密后接编码的典型结构。进一步分析sub_1FEC函数，发现以下特征字节：

ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/

这明显是Base64编码表，验证了初步判断。此时需要向上追踪inputBuffer的生成逻辑。

3. 加密算法深度解析

3.1 DES/CBC模式识别

在调用链上层发现关键函数sub_28FC，其参数结构具有典型对称加密特征：

参数位置	内容类型	示例值
arg1	明文输入	"123456"
arg2	输出缓冲区	0x15f427d69c268116
arg3	密钥指针	指向硬编码密钥
arg4	初始化向量	0xEFCDAB9078563412

算法特征识别要点：

密钥调度：观察到的sub_2DF4函数包含56次位操作，符合DES子密钥生成特征
加密轮数：16轮Feistel结构明显可见
操作模式：IV的存在暗示CBC模式

验证脚本示例：

from Crypto.Cipher import DES from binascii import unhexlify iv = unhexlify('EFCDAB9078563412') key = unhexlify('隐藏的实际密钥') cipher = DES.new(key, DES.MODE_CBC, iv) plaintext = b'123456' print(cipher.encrypt(plaintext).hex())

3.2 MD5签名机制破解

签名参数sign的分析采用不同的方法。通过Hook发现其生成函数包含以下魔数：

var0 = 0x67452301; var1 = 0xEFCDAB89; var2 = 0x98BADCFE; var3 = 0x10325476;

这正是MD5算法的初始化常量。进一步动态追踪发现签名明文由以下元素拼接：

username + password + captcha + timestamp + "固定盐值"

验证时需注意：

字符串拼接顺序可能影响最终结果
某些参数可能经过URL编码
时间戳可能是Unix时间或特定格式

4. 对抗检测的高级技巧

4.1 文件路径检测绕过

现代应用常通过/proc/self/maps检测注入工具。创新性的解决方案是拦截文件读取操作：

Interceptor.replace(Module.findExportByName('libc.so', 'open'), new NativeCallback((pathPtr, flags) => { const path = pathPtr.readUtf8String(); if (path.includes('maps')) { // 返回伪造的文件描述符 return createFakeMaps(); } return originalOpen(pathPtr, flags); }, 'int', ['pointer', 'int']));

4.2 反调试对抗策略

常见检测手段及应对方案：

检测类型	绕过方法	实现难度
ptrace占位	动态修改PTRACE_TRACEME返回值	★★☆☆☆
端口扫描	修改frida-server默认端口	★☆☆☆☆
线程名检测	Hook pthread_create修改线程名	★★★☆☆
D-Bus检测	拦截dbus_message_new_method_call	★★★★☆

5. 工程化解决方案

完整的协议逆向应当产出可复用的工具链，推荐架构：

[协议分析模块] ├─ 抓包拦截 ├─ 算法识别 └─ 参数生成 [对抗检测模块] ├─ 环境检测 └─ 反制措施 [自动化测试] ├─ 用例管理 └─ 回归验证

实际项目中，我们使用Python构建了自动化分析平台，主要组件包括：

class ProtocolAnalyzer: def __init__(self, apk_path): self.frida_scripts = load_frida_scripts() self.algorithm_db = AlgorithmDatabase() def start_analysis(self): self._hook_jni_functions() self._monitor_crypto_apis() def generate_sdk(self): return ProtocolSDK( encrypt_func=self._des_encrypt, sign_func=self._md5_sign )

在最近一次金融类App的分析中，这套方法论成功还原了包括RSA+AES+HMAC的三层加密体系，整个过程耗时约32人时。其中最关键的是准确识别了密钥派生函数中使用的PBKDF2算法，这提醒我们在逆向过程中要特别注意：