分辨Java2C、JNI下沉与抽取壳apk-reverse的2000倍密度差异指南【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverse 在APK 逆向中方法体不见了可能来自Java2C、JNI 下沉或抽取壳三种完全不同的机制。本文基于 apk-reverse 项目实测数据教你用native 方法密度这一个指标快速分辨这三者——真实样本间约2000 倍的密度差异让判断不再靠猜。为什么方法体不见了有三个答案拿到一个加固的 APK反编译后发现某堆类只剩下native声明、没有方法体。新手的第一反应往往是壳把 dex 加密了我去内存里 dump 一份——但这条路线对其中一种保护永远无效因为它从头到尾都不会产生解密后的 DEX。apk-reverse 把这种情况拆成了三种形态错配一行就可能浪费几天形态dex 静态长相内存里实际有什么正确路线抽取壳看起来正常方法体是桩stub方法体在被调用时才解密填充dump 内存测stub%主动调用Java2C整个类都是native完全没有 code_item永远没有 DEX——代码以 C 编译进.so直接读.so重建 JNI 调用链JNI 下沉只有几个native声明其余是普通 Java普通 DEX定位 Java 调用点反编译一两个 native 函数 一句话判别法这个产物在生命周期内是否曾持有你关心的方法的 dex 字节码抽取壳有JNI 下沉有Java2C从来没有。完整对照表见 java2c-and-jni-sinking.md。核心指标native 密度2000 倍的差距区分 Java2C 和 JNI 下沉靠的不是看到 native 声明而是一个可测量的数字——native 方法占总方法的比例。项目用 java2c_probe.py 在真实样本上测得样本dex 方法数native 方法数native 密度JNI 下沉目标 AMASTG L2508120.04%JNI 下沉目标 BMASTG L31118230.03%带真实 JNI 库的 App2360370.03%Java2C 形态样本292482.76% 82.76% ÷ 0.03% ≈2700 倍——这就是标题里2000 倍密度差异的出处记录在 evidence-summary.md 能力矩阵中。背后的逻辑很简单JNI 下沉天然是外科手术式的——只把少数热点方法挪进 native其余代码留在 Java所以密度只有零点零几个百分点Java2C 是整体翻译——整个类的方法都被搬进.so密度直接跳到百分之几十且会有整类只剩 native 方法的类构造函数除外翻译流程实践中会把init/clinit留在 Java所以所有方法都是 native这个判据几乎不可达别用它。实操三步如何用 apk-reverse 完成判别第 1 步测 dex 层密度。对 APK 里的 dex 统计native方法占比。密度在百分之几十、且有整类全是 native 方法的是 Java2C 形态只有个位数 native 方法的更像 JNI 下沉。第 2 步交叉验证.so符号。数一下.so里导出的Java_*符号数量与 dex 里native方法数对比——项目实测为2:2 和 3:3 的一一对应这是静态链接翻译/下沉的强特征。第 3 步注意弱信号不是结论。JNI_OnLoad、RegisterNatives字符串、libc_shared.so这类命中在普通 JNI 库里无处不在单独出现不能作为加固判据。脚本输出时也会把弱命中单独列为警告块提醒你别把它当结论。⚠️ 一个容易踩的坑如果你grep Java_符号表什么都没搜到不代表没有 native 实现——动态注册 -fvisibilityhidden会把符号全部藏起来。真正有效的检查是该库导出JNI_OnLoad却导出零个Java_*符号这就是动态注册的肯定证据。细节见 java2c-and-jni-sinking.md 的JNI 边界一节。判别之后三条路线怎么走判定为 Java2C→ 别 dump 内存目标产物根本不存在dump 只会让你误以为dump 失败。正确做法以 dex 为索引、以.so为库逐个读翻译出的 C 函数每个都以JNIEnv *env, jobject thiz开头沿着FindClass/GetMethodID/Call*Method这些反向 JNI 调用把原始 Java 逻辑拼回来。判定为抽取壳→ 先 dump 内存用 dex_dump_validate.py 测stub%再走 FART 式主动调用。形态诊断表见 advanced-unpacking.md。判定为 JNI 下沉→ dex 仍然可读定位 Java 调用点后反编译对应的少数 native 函数即可成本最低。新手常见误判速查你看到的现象它不是它其实是整类是nativedump 内存后还看到同样的native声明dump 失败 / 工具坏了代码被永久移出 dex去读.sogrep Java_符号表返回空没有 native 实现动态注册或隐藏可见性库只导出JNI_OnLoad其他都不认识这是个 loader可能是普通的动态注册 JNI 库密度高但每个类都还有 Java 方法Java2C大面积 JNI 下沉或 R8 剥离了方法体延伸阅读判别依据与失败模式全记录java2c-and-jni-sinking.md分类探针脚本支持--apk/--dex/--so/--jsonjava2c_probe.py抽取壳 dump 后的形态诊断与恢复边界advanced-unpacking.md全部实测数据与强度标注observed / inferred / unverifiedevidence-summary.md小结先测密度再看符号最后选路线。2000 倍的密度差异就是那张五形态表里最便宜也最可靠的判据——花一分钟量一下能省下一整天的错误路线。【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考