安卓逆向04. Native 逆向、JNI 定位与 so 分析

本章目标是理解 Android App 中的 Native 层：如何发现.so，如何定位 JNI 入口，如何用静态工具分析二进制，如何用 Frida 在授权 Demo 上观察 Native 函数行为。

1. 为什么需要 Native 逆向

很多 App 会把关键逻辑放到 Native 层：

Native 层不是绝对安全，只是提高分析门槛。只要逻辑在客户端执行，就能被观察、调试、Hook 或模拟。

2. so 文件识别

2.1 从 APK 中发现 Native 库

unzip-lapp-debug.apk|grep"lib/.*\\.so"mkdir-pcase-reversedemo/04-nativeunzip-papp-debug.apk lib/arm64-v8a/libreversedemo.so>case-reversedemo/04-native/libreversedemo.sofilecase-reversedemo/04-native/libreversedemo.so

ABI 说明：

分析时要确认设备运行的是哪个 ABI 的 so。Hook 地址、寄存器和调用约定会受架构影响。

2.2 基础命令

readelf-hlibreversedemo.so readelf-slibreversedemo.so|grepJava_ readelf-dlibreversedemo.so strings libreversedemo.so|head-100nm-Dlibreversedemo.so|grepJava_

检查重点：

3. JNI 定位方法

3.1 静态注册 JNI

Java/Kotlin：

classNativeGuard{externalfunnativeCheck():Booleancompanionobject{init{System.loadLibrary("reversedemo")}}}

Native：

extern"C"JNIEXPORT jboolean JNICALLJava_com_example_reversedemo_NativeGuard_nativeCheck(JNIEnv*,jobject){returntrue;}

静态注册特点：

• 函数名包含Java_包名_类名_方法名。
• readelf -s或nm -D可能直接看到符号。
• jadx 中能从System.loadLibrary和external fun反向定位。

3.2 动态注册 JNI

Native 代码可能通过RegisterNatives注册：

staticJNINativeMethod methods[]={{"nativeCheck","()Z",(void*)native_check_impl}};

动态注册特点：

• 导出符号里可能看不到完整 Java 风格函数名。
• 需要找JNI_OnLoad、RegisterNatives、方法名字符串。
• Ghidra 中可通过字符串交叉引用定位实现函数。

4. Ghidra 基础分析流程

4.1 导入和自动分析

1. 新建 Ghidra Project。
2. Importlibreversedemo.so。
3. 选择默认分析器，执行 Auto Analyze。
4. 在 Symbol Tree 中查看 Exports、Functions、Strings。
5. 搜索nativeCheck、JNI_OnLoad、/system/bin/su、frida、TracerPid。

4.2 重点窗口

4.3 Demo：分析 root 检测

示例 Native 逻辑：

boolhas_su(){returnaccess("/system/bin/su",F_OK)==0||access("/system/xbin/su",F_OK)==0;}

在 Ghidra 中：

1. 搜索字符串/system/bin/su。
2. 查看交叉引用。
3. 进入引用函数。
4. 看是否调用access、stat、open。
5. 重命名函数为check_su_path。
6. 记录返回值含义。

报告写法：

## Native root 检测 - so：`libreversedemo.so` - 字符串：`/system/bin/su`、`/system/xbin/su` - 调用：`access(path, F_OK)` - 逻辑：任一路径存在则认为环境风险较高 - 风险：如果直接阻断业务，可被 Hook `access` 或修改返回值绕过 - 建议：作为风险评分信号，与服务端风控、设备完整性和行为验证结合

5. Native Frida Hook

5.1 Hook Java 层 Native 方法

最简单方式是先 Hook Java 声明的方法：

Java.perform(function(){constNativeGuard=Java.use("com.example.reversedemo.NativeGuard");NativeGuard.nativeCheck.implementation=function(){constresult=this.nativeCheck();console.log("[nativeCheck] original="+result);returntrue;};});

优点：不需要处理地址和 ABI。缺点：如果 App 在 Native 内部继续调用其他检测函数，Java 层 Hook 可能覆盖不了细节。

5.2 Hook 导出函数

constmoduleName="libreversedemo.so";constsymbol="Java_com_example_reversedemo_NativeGuard_nativeCheck";constaddr=Module.findExportByName(moduleName,symbol);console.log("nativeCheck addr="+addr);Interceptor.attach(addr,{onEnter(args){console.log("[nativeCheck] enter");},onLeave(retval){console.log("[nativeCheck] original retval="+retval);retval.replace(1);}});

验证：

5.3 Hook libc 函数观察检测路径

constaccessPtr=Module.findExportByName(null,"access");Interceptor.attach(accessPtr,{onEnter(args){this.path=args[0].readCString();},onLeave(retval){if(this.path&&this.path.indexOf("su")>=0){console.log("[access] "+this.path+" => "+retval);}}});

这个脚本用于观察 Demo 是否检查su路径。不要把这类脚本用于未授权绕过第三方 App 风控。

6. Native 防护知识点

6.1 常见检测

6.2 正确防护思路

Native 防护适合提高成本，但不能承担唯一安全结论：

• 客户端检测只作为风险信号。
• 核心权益、支付、提现、订单、身份认证必须服务端校验。
• 检测结果要和账号、设备、行为、接口频率、服务端风控合并判断。
• 防护上线后必须复测误报、兼容性、性能和可维护性。

7. 本章 Demo：Native 分析任务

7.1 任务清单

1. 从 APK 提取libreversedemo.so。
2. 用file、readelf、strings记录 ELF 信息和字符串线索。
3. 在 jadx 中找到System.loadLibrary和external fun nativeCheck()。
4. 在 Ghidra 中定位 JNI 函数。
5. 找到 root 检测字符串和access调用。
6. 用 Frida Hook Java 层nativeCheck()。
7. 用 Frida Hook Native 导出函数或 libcaccess()。
8. 输出 Native 分析报告。

7.2 验证矩阵

8. 报告模板

# Native Analysis Report ## so 信息 - 文件： - ABI： - 架构： - 导出符号： - 依赖库： ## JNI 映射 | Java 方法 | Native 函数 | 注册方式 | 证据 | ## 关键字符串 | 字符串 | 引用函数 | 推测用途 | ## 动态验证 | Hook 点 | 参数/返回值 | 行为变化 | ## 风险与建议 - 风险： - 影响： - 局限： - 修复：

9. 常见问题

10. 本章交付物

case-reversedemo/ 04-native/ 01-so-list.txt 02-readelf.txt 03-strings.txt 04-jni-map.md 05-ghidra-notes.md 06-hook-java.js 07-hook-java.log 08-hook-native.js 09-hook-native.log 10-native-report.md

11. Native 基础补强

11.1 ELF 文件结构

Android.so是 ELF 动态库。逆向时至少要理解：

命令：

readelf-hlibreversedemo.so readelf-Slibreversedemo.so readelf-llibreversedemo.so readelf-dlibreversedemo.so

11.2 ABI 与寄存器基础

Frida Hook Native 函数时，args[0]、args[1]对应底层参数。JNI 函数前两个参数通常是：

• JNIEnv *
• jobject或jclass

真实 Java 方法参数从args[2]开始。

12. JNI 深度

12.1 JNI 类型映射

12.2 JNI 方法签名

示例：

externalfunsign(path:String,body:ByteArray,timestamp:Long):String

签名：

(Ljava/lang/String;[BJ)Ljava/lang/String;

理解签名有助于：

• 识别RegisterNatives表。
• 在 Ghidra 中重命名函数。
• Hook Native 参数。
• 对照 Java 层 external 方法。

12.3 RegisterNatives 分析

动态注册常见结构：

staticJNINativeMethod gMethods[]={{"nativeCheck","()Z",(void*)native_check},{"nativeSign","(Ljava/lang/String;)Ljava/lang/String;",(void*)native_sign},};

Ghidra 查找步骤：

1. 搜索字符串nativeCheck。
2. 找交叉引用。
3. 查看附近是否存在方法名、签名、函数指针三元组。
4. 找RegisterNatives调用。
5. 追踪函数指针到真实实现。

13. Native 静态分析套路

13.1 字符串优先

优先搜索这些字符串：

13.2 导入函数优先级

13.3 控制流识别

Native 检测函数常见模式：

读取环境 -> 字符串匹配 -> 返回 true/false -> 上报 Java 层 -> 决定页面或接口行为

分析时不要只停在“有 root 检测”，要回答：

• 检测结果被谁使用。
• 是否只影响 UI。
• 是否会上报服务端。
• 是否会阻断高风险接口。
• 是否存在误报处理。

14. Ghidra 操作细化

14.1 函数重命名规则

命名后要在报告中说明“这是分析者命名，不一定是原始函数名”。

14.2 交叉引用分析

Ghidra 中对字符串按X查看引用。每个引用要记录：

## 字符串引用记录 - 字符串： - 地址： - 引用函数： - 函数输入： - 函数输出： - 推测用途： - 后续 Hook 点：

14.3 Decompiler 结果校验

反编译 C 代码可能不准确。要用以下方式交叉验证：

• 看汇编条件跳转。
• 看字符串引用。
• 看导入函数。
• 动态 Hook 参数和返回值。
• 和 Java 层调用结果对照。

15. Native Hook 深入

15.1 等待 so 加载

如果Module.findExportByName返回 null，可能 so 还没加载。

constdlopen=Module.findExportByName(null,"android_dlopen_ext");Interceptor.attach(dlopen,{onEnter(args){this.path=args[0].readCString();},onLeave(retval){if(this.path&&this.path.indexOf("libreversedemo.so")>=0){console.log("[loaded] "+this.path);}}});

15.2 按偏移 Hook

当符号被 strip 时，可用基址加偏移：

constbase=Module.findBaseAddress("libreversedemo.so");consttarget=base.add(0x1234);Interceptor.attach(target,{onEnter(args){console.log("[target] enter");},onLeave(retval){console.log("[target] retval="+retval);}});

偏移来源必须记录清楚：

• Ghidra 函数地址。
• so 加载基址。
• 架构 ABI。
• APK 版本和 so hash。

15.3 读取 jstring

JNIjstring不能直接readCString。可通过 Java API 或 Native helper 处理。简单场景建议先 Hook Java 层 external 方法，必要时再深入 Native。

记录原则：

• 如果参数读不出来，不要猜。
• 先打印指针和返回值。
• 再定位 Java 层包装方法。
• 最后处理 JNI 类型转换。

16. Native 风险库

17. Native Demo 作业

17.1 作业一：JNI 映射

任务：

1. 找到 Java 层NativeGuard。
2. 找到System.loadLibrary。
3. 提取目标 ABI so。
4. 用readelf找导出符号。
5. 用 Ghidra 定位真实函数。
6. 输出 Java 方法到 Native 函数的映射表。

17.2 作业二：root 检测分析

任务：

1. 搜索/system/bin/su。
2. 找引用函数。
3. 识别access调用。
4. Hookaccess打印路径。
5. Hook JavanativeCheck()观察返回值。
6. 写出该检测的局限。

17.3 作业三：签名函数观察

任务：

1. 在 Native 中加入一个nativeSign(String input)。
2. 用 Ghidra 找到输入字符串处理。
3. 用 Frida Hook Java external 方法。
4. 记录输入、输出和调用时机。
5. 判断密钥是否出现在客户端。

18. Native 报告评分

19. Native、JNI 与 so

Native 分析要把 Java external 方法、so 符号、JNI 注册、字符串引用、系统调用和动态 Hook 串起来。

ELF 与 so

JNI 知识

Native 防护与 Hook