移动安全实验室：用Unidbg动态分析小红书核心加密协议（附Hook脚本）

移动应用逆向工程实战：Unidbg动态解析小红书加密协议

在移动应用安全研究领域，算法黑盒分析一直是技术攻坚的重点难点。当静态分析遇到复杂混淆或白盒加密时，动态执行环境就成为破解协议的关键工具。本文将深入探讨如何利用Unidbg模拟执行框架，配合Frida动态插桩技术，完整还原小红书核心加密协议的生成流程。

1. 逆向工程环境搭建与工具链配置

构建高效的动态分析环境是协议逆向的基础。我们推荐以下工具组合：

• Unidbg 0.9.6：支持ARM32/64指令集的跨平台模拟执行框架
• Frida 15.2.3：实时函数Hook与内存操作工具
• IDA Pro 7.7：交互式反汇编与调试器
• Jadx 1.4.7：Java反编译工具链

关键环境配置参数如下表所示：

安装依赖时需特别注意NDK版本兼容性：

# Ubuntu环境下工具链安装 sudo apt install -y android-sdk-platform-tools pip install frida-tools==12.1.1

提示：建议使用Docker容器隔离实验环境，避免宿主系统污染

2. 目标SO文件初步分析

小红书核心加密逻辑通常封装在libsecurity.so等动态库中。首先需要进行基础静态分析：

• 使用readelf -h检查文件架构
• 通过strings提取关键符号信息
• IDA Pro加载后识别JNI_OnLoad等入口点

常见防护手段包括：

• 控制流扁平化混淆
• 字符串加密存储
• 动态加载关键函数
• 白盒加密算法实现

针对跳转表计算的函数地址混淆，可采用以下去花指令策略：

# IDAPython去花脚本示例 def deflow(start, end): for addr in range(start, end): if is_code(get_flags(addr)): patch_byte(addr, 0x90)

3. Unidbg动态执行关键流程

定位到doCommandNative函数后，通过Unidbg构建执行环境：

// Unidbg初始化模板 AndroidEmulator emulator = AndroidEmulatorBuilder.for32Bit() .setProcessName("com.xingin.xhs") .build(); Memory memory = emulator.getMemory(); memory.setLibraryResolver(new AndroidResolver(23));

动态分析时重点关注三个核心函数：

1. sub_41594：生成中间签名值
2. sub_11144：CRC32校验计算
3. sub_290A0：白盒AES加密层

通过Hook拦截sub_41594的参数可发现：

• 第二个参数前24字节包含原始sig3值
• 最终签名经过异或运算处理
• 参与运算的v156值为前23字节和

典型的内存数据拦截代码如下：

// Frida Hook脚本片段 Interceptor.attach(ptr(0x41594), { onEnter: function(args) { console.log(hexdump(args[1], { length: 24, header: false })); } });

4. 加密算法分层解析

4.1 CRC32校验层

sub_11144函数实现了改进版CRC32算法，特征包括：

• 多项式：0x04c11db7
• 初始值：0xFFFFFFFF
• 输入数据：9bd618开头的24字节数组
• 输出结果：e0c281e3校验码

算法验证可通过标准CRC32实现对比：

# Python CRC32验证 import binascii input_data = bytes.fromhex('9bd618...') crc = binascii.crc32(input_data) & 0xFFFFFFFF assert crc == 0xe0c281e3

4.2 白盒AES加密层

sub_290A0函数内部调用链揭示了白盒AES实现：

1. 输入数据采用PKCS#7填充
2. 使用预计算的替换表(S-Box)
3. 轮密钥混合操作
4. 字节替换与行移位

识别特征包括：

• 256字节的常量表(v27)
• 10轮循环结构
• 128位分组处理

针对白盒AES的DFA攻击需要：

// 差分故障注入关键点 void inject_fault(uint8_t *round) { round[5] ^= 0x20; // 注入单字节故障 }

4.3 双SHA256哈希层

sub_23d30函数实现了变种SHA256：

• 初始哈希值：0xBB67AE856A09E667
• 两次标准SHA256计算
• 附加salt值混合
• 输出长度扩展至32字节

哈希计算过程可通过OpenSSL验证：

echo -n "input_data" | openssl dgst -sha256 -binary | openssl dgst -sha256

5. 完整协议还原与验证

综合各层分析结果，协议生成流程如下：

1. Java层传入原始数据
2. 执行双SHA256哈希计算
3. 进行白盒AES加密
4. 生成CRC32校验码
5. 组合最终签名值

实现验证脚本时应特别注意：

• 各阶段字节序处理
• 内存数据对齐方式
• 异常处理边界条件
• 性能优化策略

以下是协议还原的Python伪代码：

def generate_signature(data): # 阶段1: 双SHA256 hash1 = sha256(data + salt).digest() hash2 = sha256(hash1).digest() # 阶段2: 白盒AES padded = pad(hash2, AES.block_size) cipher = WhiteBoxAES(key_tables) encrypted = cipher.encrypt(padded) # 阶段3: CRC32 crc = crc32(encrypted[:24]) # 阶段4: 最终组合 sig = xor(encrypted[:24], crc) return sig

在实际测试中发现，当输入数据超过512字节时，协议会启用分块处理模式，这需要额外注意缓冲区管理策略。对于性能敏感的场景，可以考虑将关键算法移植到Native层实现，相比纯Java实现可获得3-5倍的性能提升。