从‘ban.so’解密到签名校验：一次完整的外挂逆向分析与修复实录
从‘ban.so’到签名校验：Android Native层安全攻防实战
在移动安全领域，so文件作为Android应用的核心保护层，常常成为攻防双方的主战场。当我在分析一款热门游戏的外挂时，遇到了一个名为"ban.so"的神秘文件——这个看似普通的动态链接库背后隐藏着多层加密和校验机制。本文将完整还原如何从内存中提取加密so、修复损坏的ELF结构、逆向分析校验逻辑，最终实现非侵入式的签名校验绕过。不同于常见的Java层分析，这次我们将深入Native层的技术细节，探索那些在常规逆向教程中很少提及的实战技巧。
1. 加密so的提取与修复
1.1 定位关键so文件
当面对一个使用native方法进行核心校验的应用时，第一步是确定关键so文件的加载位置。通过Frida的Process.enumerateModules()可以列出所有已加载的模块：
// 枚举所有加载的模块 Process.enumerateModules().forEach(function(mod) { console.log(mod.name + " @ " + mod.base); });在本次案例中，我们注意到一个异常命名的"ban.so"文件，它通过System.load()动态加载而非常规的System.loadLibrary()。这种异常命名和加载方式往往是加密保护的明显特征。
1.2 内存Dump技术详解
要在运行时获取解密后的so文件，需要在正确的时机进行内存转储。关键点在于：
- 时机选择：应在so被加载且解密完成，但尚未执行关键校验逻辑时进行dump
- 权限处理：需要修改内存页属性为可读写
- 完整性检查：验证dump出的文件是否包含有效的ELF头
以下是优化后的Frida dump脚本：
function dumpDecryptedSo(soName, savePath) { const lib = Process.findModuleByName(soName); if (!lib) { console.error("Module not found"); return false; } // 修改内存权限 Memory.protect(ptr(lib.base), lib.size, 'rwx'); // 读取内存数据 const buffer = ptr(lib.base).readByteArray(lib.size); // 保存到文件 const file = new File(savePath, "wb"); file.write(buffer); file.close(); console.log(`[+] Dumped ${soName} to ${savePath}`); console.log(` Base: ${lib.base}, Size: ${lib.size} bytes`); return true; } // 使用示例 setTimeout(() => { dumpDecryptedSo("ban.so", "/sdcard/ban_dumped.so"); }, 3000); // 延迟3秒确保解密完成1.3 ELF文件修复实战
直接从内存dump的so文件通常无法直接分析，因为：
- 节区头表(Section Header Table)可能被抹去
- 程序头表(Program Header Table)可能不完整
- 动态链接信息可能损坏
使用开源工具elf-dump-fix进行修复时，关键参数如下：
| 参数 | 作用 | 推荐值 |
|---|---|---|
| -f | 输入文件 | dump出的so路径 |
| -o | 输出文件 | 修复后的保存路径 |
| -l | 加载基址 | 从Frida输出中获取 |
| -s | 节区对齐 | 通常为0x1000 |
修复命令示例：
python elf-dump-fix.py -f ban_dumped.so -o ban_fixed.so -l 0xbeef0000 -s 0x1000修复完成后，使用readelf检查基本结构：
readelf -h ban_fixed.so2. Native层校验逻辑逆向分析
2.1 静态注册函数定位技巧
对于静态注册的JNI函数，其命名遵循特定模式：
Java_[包名_替换为下划线]_[类名]_[方法名]例如：
Java_com_app_batman_MainActivity_SignUp在IDA中快速定位的技巧：
- 使用函数窗口的搜索功能
- 应用以下正则表达式：
Java.*SignUp - 查看导出函数表(Exports)中的Java前缀函数
2.2 卡密校验逻辑剖析
逆向分析发现的校验逻辑主要包括以下步骤：
- 网络请求响应体长度验证（必须为32字节）
- 响应内容哈希校验
- 时间戳防重放检查
- 设备指纹绑定
关键代码片段的伪代码还原：
int verifyResponse(char* response) { if(strlen(response) != 32) { return 0; // 失败 } if(sha256(response[16..31]) != response[0..15]) { return 0; } if(getTimestamp() - extractTimestamp(response) > 300) { return 0; // 超过5分钟失效 } return checkDeviceFingerprint(response); }2.3 服务激活机制
校验通过后，外挂会通过JNI回调Java层的TOAC方法激活服务。这个过程涉及：
- JNIEnv指针的正确获取
- 类和方法ID的缓存
- 异常处理机制
典型的实现模式：
void callJavaMethod(JNIEnv* env, jobject thiz) { jclass clazz = (*env)->GetObjectClass(env, thiz); jmethodID method = (*env)->GetMethodID(env, clazz, "TOAC", "()V"); if(method != NULL) { (*env)->CallVoidMethod(env, thiz, method); } }3. 签名校验的攻防对抗
3.1 签名校验的常见实现方式
Native层签名校验通常采用以下技术：
- 直接校验：调用PackageManager获取签名信息
- 哈希比对：预先存储合法签名的哈希值
- 混合校验：结合Java层和Native层的校验逻辑
- 时序校验：在不同执行阶段多次验证
关键API调用链：
android.content.pm.PackageManager -> getPackageInfo -> signatures -> hashCode3.2 非Root环境下的绕过方案
对于无法直接修改so文件的情况，可选的绕过方案包括：
| 方案 | 优点 | 缺点 |
|---|---|---|
| Xposed模块 | 功能强大 | 需要Root |
| Frida拦截 | 动态灵活 | 易被检测 |
| AOP框架(如Epic) | 无需Root | 兼容性问题 |
| 重打包 | 一劳永逸 | 需要处理所有校验点 |
使用Epic框架的核心实现代码：
class SignatureHook implements XC_MethodHook { @Override protected void beforeHookedMethod(MethodHookParam param) { if(param.method.getName().equals("hashCode")) { param.setResult(0x12345678); // 返回预期的哈希值 } } } // 安装Hook DexposedBridge.hookAllMethods( Signature.class, "hashCode", new SignatureHook() );3.3 完整性保护的新趋势
现代应用开始采用更高级的保护措施：
- 多阶段校验：在应用生命周期的不同阶段进行验证
- 环境检测：检查调试器、注入工具的存在
- 控制流混淆：使逆向分析难以跟踪执行流程
- 服务器验证：关键校验逻辑放在服务端
对抗这些保护需要结合静态分析和动态分析：
graph TD A[静态分析] --> B(识别校验点) C[动态分析] --> D(验证行为) B --> E[制定绕过策略] D --> E E --> F[实现绕过]4. 工具链的深度优化
4.1 Frida脚本的进阶技巧
为提高分析效率，可以开发自动化脚本：
// 自动化分析脚本框架 class SoAnalyzer { constructor(soName) { this.soName = soName; this.module = null; } findExports(pattern) { return Module.enumerateExports(this.soName) .filter(exp => exp.name.match(pattern)); } traceCalls() { const exports = this.findExports(/Java_.*/); exports.forEach(exp => { Interceptor.attach(exp.address, { onEnter(args) { console.log(`[+] ${exp.name} called`); this.args = args; }, onLeave(retval) { console.log(`[-] ${exp.name} returned`); } }); }); } } // 使用示例 const analyzer = new SoAnalyzer("ban.so"); analyzer.traceCalls();4.2 IDA分析模板
为加快逆向速度，可以创建IDA分析模板：
# IDAPython脚本示例 def analyze_so(so_path): idaapi.autoWait() # 等待分析完成 # 标记所有JNI相关函数 for func in Functions(): name = GetFunctionName(func) if "Java_" in name: SetFunctionCmt(func, f"JNI: {name}", 0) # 查找字符串引用 strings = {} for s in Strings(): strings[s.ea] = str(s) # 标记关键字符串 for ea in strings: if "signature" in strings[ea].lower(): MakeComm(ea, "Possible signature check")4.3 性能优化技巧
大规模so文件分析时的优化策略：
- 并行分析：使用IDAPython多线程处理不同功能块
- 特征匹配：预定义常见保护模式的签名
- 差异分析：对比多个版本so的变化点
- 可视化辅助：生成控制流图辅助理解
关键工具组合：
| 工具 | 用途 | 适用场景 |
|---|---|---|
| Ghidra | 批量分析 | 大型so文件 |
| Binary Ninja | 快速反编译 | 原型分析 |
| Radare2 | 命令行分析 | 自动化处理 |
| Frida | 动态验证 | 运行时检查 |
在实际分析过程中，我发现最有效的策略是结合静态分析的全面性和动态分析的准确性。例如，先用Ghidra进行初步分析，标记出可疑的校验点，然后用Frida在运行时验证这些点的实际行为。这种混合方法可以显著提高分析效率，避免在无关代码上浪费时间。