抽取壳还是真dumpapk-reverse的trivial-body比例判别法实战【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverse做 APK 逆向分析时一个让新手反复踩坑的场景是dex dump 明明跑成功了解出来的却是空壳——类名全在、方法签名全在方法体却只剩一行return-void。apk-reverse 项目用trivial-body 比例stub%这一指标把真 dump和抽取壳骨架区分开本文带你实战走一遍这套判别方法。核心问题dump 出来的到底是代码还是一副骨架抽取壳extraction shell的工作原理是按需解密方法体在首次被调用前只是一堆占位桩stub只有真正执行到该方法时壳才会在内存中解密并填充真实代码。这意味着任何某一刻的内存 dump 都只能拿到当时恰好被调用过的方法——绝大多数方法体依然是桩。你 dump 得到的是一个骨架skeleton而不是原始 dex。骨架的典型特征特征说明结构完整magic、版本、类表、字符串表全部正常能通过校验类数偏少但文件很大实测一个 8.9 MB 的壳 dex 只定义4 个类——字节是加密载荷不是代码方法体近乎全空5,061 个方法体里真实代码占比极低多数只剩return-void或 nop 填充dump 的四种形态先诊断再选路线拿到 dump 目录后先判断它属于哪种形态再决定下一步做什么。判别表来自 advanced-unpacking.mddump 形态stub%诊断下一步可解析、类多、方法体真实接近基线落壳成功dump 就是原版过滤后进入打补丁流程可解析、类多、方法体多为return-void桩很高抽取壳骨架走 FART 主动调用循环整类都是裸native声明且对应Java_*导出存在n/aJNI 下沉代码跑去了.so去看 java2c-and-jni-sinking.md方法体在、但指令流解不开基线真 Dex VMP先别下结论用官方解码器验证⚠️ 特别提醒方法体解不开不等于 VMP。实测中曾有人用手写的指令宽度表判定出1,393 个方法体无法解码 → VMP结果官方dexdump对同一文件解码出 34,566 条指令、零结构错误——错的是那张手写表漏了一条 arm64 分支指令。结论任何 VMP 判定前先让没自己写的解码器跑一遍。一键运行 trivial-body 比例判别法判断工具就是项目里的 dex_dump_validate.py。trivial-body 比例的定义很朴素在所有有code_item的方法中指令流跳过普通 nop 单元后只剩一条return*的方法占比。没有code_item的方法是 abstract/native 声明这种空是合法的不计入比例。一条命令跑完整个 dump 目录python skills/apk-reverse/scripts/dex_dump_validate.py dump目录 --find Lcom/example/app/脚本会自动完成四件事按 sha256 去重绝不按大小去重、结构校验并拒绝坏镜像magic 错误、file_size不匹配等、统计类数与桩方法体、对候选镜像排序——最可能是原版 dex 的排最前面。实测输出长这样取自基准 B3 的完整记录name size sha256[:12] ver cksum sig class noco code stub% erased% emptied% allstub.dex 982480 c8d7ca8fb163 035 ok ok 647 250 5061 100.0% 0.0% 100.0% ctrl.dex 982480 1b3a97896b40 035 ok ok 647 250 5061 1.9% 0.0% 1.9% nopfilled.dex 982480 de92dcea4eaf 035 ok ok 647 250 5061 0.0% 100.0% 100.0% throwstub.dex 982480 cab8fd51a743 035 ok ok 647 250 5061 1.9% 0.0% 1.9%解读报告stub%、erased%、emptied% 三列各是什么 报告里三个比例列有微妙但关键的差别列统计内容作用stub%只剩一条return*的方法体占比经典抽取壳信号erased%整个方法体全是 nop 的占比捕获清槽型骨架emptied%上面两类之和判定骨架请看这一列为什么要看emptied%而不是stub%因为有一种壳会把方法体清成纯 nop 而不写 return——这种骨架的stub%是0.0%比没动过的原始 dex 还低。在修复缺陷之前它甚至会被排序算法冠以最可能是原版的头衔。emptied%把两类空法体合并就能把它抓出来。关键发现不是阈值而是双峰分布 项目用一份真实应用 dex982 KB、5,061 个方法体 零改动对照组把壳家族会用到的每种清空手法都造了一遍并实测得到这张决定性的校准表完整命令见 EXTENSION-extraction-shell-bench.md壳留下的形态stub%与对照组1.9%能否区分每个方法体都是裸return-void100.0%✅ 相差 98 个点方法体截成const/4 v0,#0; return v093.2%✅nop 填充、连 return 都没有清槽型0.0%❌ 比原版还低new RuntimeException; throw桩360/乐固常见形态1.9%❌ 与对照组完全无法区分只清空 25% / 50% / 75% 的方法体1.7 / 1.7 / 2.1%❌ 差 0.2 个点属于噪声三个直接推论stub% 是双峰的它要么落在应用自身基线附近看不见要么落在 ≈100%看见了中间不存在能放阈值的区间。早期文档里几十个百分点就是骨架的说法没有实测支撑已被删除。部分抽取是隐形的删掉 75% 方法体的 dex 只比对照组高 0.2 个点——单看比例根本发现不了。高 stub% 是决定性证据低 stub% 什么都证明不了——它既可能是真 dex也可能是全 nop 骨架也可能是 throw 桩骨架。排序与它的失败条件别盲目相信第一名脚本最后会给出ranking最可能是原版的候选排序。排序逻辑分三级先剔除emptied% ≥ 50%的镜像再按minimal nop 擦除方法体数量升序这个计数是单调的能区分 25/50/75% 的抽取程度最后按emptied%升序。但有两个实测过的失败条件必须先知道详见 advanced-unpacking.md §The rankings failure conditions部分抽取的镜像会排在重度桩化的前面——低比例区间内比例已经不是信号了1.7% 对 1.9% 只是噪声throw 桩骨架在所有镜像里都隐形它的stub%与未改动对照组一模一样排序帮不上忙只能逐方法体人工检查。️ 实用规则当emptied%停在应用自身基线、又找不到能区分候选的信号时把排序结果当作无信息不要拿第一名当补丁基线。排序的结论是一句有冠军的陈述句错误的冠军比没有冠军更危险。确认是壳之后FART 三步循环找回真实代码判别出骨架后真正的代码不在任何一次 dump 里——它需要被主动唤醒再截获。FART 系工具的思路是三步循环整图 dump 骨架类定义、签名、字符串表都是完整的这就是第 3 步的地址地图主动调用每一个方法反射遍历类列表逐个调用大多会抛异常没关系——关键是壳会在方法进入瞬间解密并安装方法体在每个方法开始执行时把已解密的code_item按method_idx落盘把方法体拼回骨架按骨架给出的偏移覆盖桩方法体修好 dex 头先签名后校验和必须用 jadx/baksmali 解析通过、方法数与骨架一致才算数——拼上了不等于修好了。另外要提前知道Android 12–16 上经典 hook 点art::interpreter::Execute因入口分流、结构偏移、存储限制、壳方对抗、编译策略漂移五个独立原因全部失效dump 工具日志看起来正常、输出目录却空空如也。排查顺序与修复手段在 advanced-unpacking.md 有完整记录。更多延伸资料 本文涉及的判别法与全部实测证据可在仓库中找到原文抽取壳判别与 FART 循环详解advanced-unpacking.md判别脚本去重、校验、比例统计、排序一体dex_dump_validate.py11 变体骨架基准与三处脚本缺陷修复记录EXTENSION-extraction-shell-bench.md首个壳 dex 验收测试7 个 fixture 的实测输出EXTENSION-unpacking.md基准矩阵 B3 行双峰结论的出处benchmark.md整体技能入口与门控流程SKILL.md一句话总结高 stub% 是骨架的铁证低 stub% 只是无法判断判定骨架看 emptied%选基线别迷信排序第一名VMP 结论必须经官方解码器背书。【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考