apk-reverse的基准矩阵实录13个公开目标如何推翻4条已记录结论【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverseapk-reverse 是一个面向 Android APK 逆向工程分析的开源 Agent Skill 仓库提供 dex 补丁、重打包签名、脱壳诊断、Dart AOT 分析等完整工具链。它的 tests/benchmark.md 是一张基准矩阵13 行每行一个公开目标回答一个问题——当智能体遇到这类目标时仓库里文档化的路线到底管不管用更关键的是这轮基准测试推翻了仓库自己之前写下的 4 条结论。本文带你完整复盘这 13 个目标各自发生了什么以及负面结果为什么比正面结果更值钱。 基准矩阵是什么每个目标对应一行每个结论必须可复现这张矩阵不是样本合集而是回归基线。它的设计原则只有一条Result列里的每个断言都必须能用Target列指定的公开样本加上指定脚本复现不允许出现应该会发生什么式的总结。矩阵覆盖了 13 个维度与目标行维度目标一句话结果B1等长 dex 补丁 重打包签名MASTGUnCrackable-Level1.apk✅ 路线端到端跑通屏幕行为真实改变B2反调试 自毁竞态UnCrackable-Level3.apk⚠️ 分叉工具链有效补丁拦不住自毁B3脱壳骨架检测自建 11 变体骨架集推翻了stub% 阈值结论B4Dex-VMP 边界ezAndroid.apk撤回了一个 VMP 判定B5Java2C 识别自建 dcc 转换产物 真实 JNI 样本native 密度相差约 2000 倍B6Stalker 追踪UnCrackable-Level1.apk排除机制救不活零事件B7原生证书固定CyReverse Cronet 样本未执行本机无法构建B8无 schema protobuf 解码合成 fixture 官方运行时21/21 字节级往返一致B9分 APK / App Bundle两套真实分体8/9 成员拒签分支与合并分支都真实触发B10内核级 syscall 伪造KernelSU/APatch 模板生成成功但所有内核路径被封死B11JNI 动态注册发现真实系统库RegisterNatives符号搜索结构性失效B12Dart AOT 字符串表格式本地加固 Flutter APK两条既有声称全被证伪B13反插桩分诊MASTGuncrackable3点名了真正开火的检查strstr(frida)每个结论都带三级强度标签——observed有精确命令和输出、inferred从观察事实推理、unverified假设或他人报告这是 docs/tool-verification/README.md 定义的规则。unverified不是机制不成立而是本仓库还没有人为它付过验证的成本。 目标一B1 等长补丁链路——4 个字节改变屏幕行为B1 是整个矩阵里最标准的成功案例也是 G2/G4 两道的完整演练在 5528 字节的classes.dex中把MainActivity.onCreate第一个 root 检查分支的 2 个字节3900 0e00→0000 0000打平用 skills/apk-reverse/scripts/repack.py 完成 STORED 4 字节对齐重打包apksigner 报告 v1v2v3 全部通过root 安装后设备上base.apk的 sha256 与本地构建逐字节一致最终证据是屏幕原始包和无改动对照组都弹出阻塞式Root detected!对话框补丁包进入主界面对话框消失。这条链路的完整实录包括输入框无法驱动、AES 密钥误读等代价高昂的细节见 EXTENSION-benchmark-l1-l3.md。 B1 同时是推翻结论 #4的现场详见下文第四部分。️ 目标二B3 脱壳骨架检测——阈值不存在只有形状这是矩阵里最重要的负面结果。此前 references/advanced-unpacking.md 声称stub%方法体被清空的比例达到百分之几十就意味着脱壳骨架。实测直接推翻了它。用真实应用的 982 KB dex 派生 11 个等长变体跑 skills/apk-reverse/scripts/dex_dump_validate.py清空形状stub%与对照组1.9%能否区分每体裸return-void100.0%✅ 相差 98 个点截断为const/4 return93.2%✅纯 nop 填充、无 return0.0%❌低于对照组throw RuntimeException桩1.9%❌ 与对照组完全无法区分清空 25/50/75% 方法体1.7 / 1.7 / 2.1%❌ 落在采样噪声里三条结论全部为observedstub% 是双峰的——要么≈对照盲要么≈100%可见中间不存在能安放阈值的带状区间部分提取是隐形的——75% 方法体被清空报告值 2.1%与 1.9% 对照只差 0.2 个点打脸它的两种形状恰好是真实壳最爱用的——throw桩是 360/乐固系的经典形状nop 清空是壳在解密前清槽位的写法。这轮还连出三个脚本缺陷其中两个极其危险全 nop 填充的 dex 被归类为真实甚至被排成最可能是原始包第一名——智能体若按这行路由会去补丁一个被清空的骨架第一轮修复后独立评审发现排序仍指向 25% 清空的改过镜像真正的对照反而排第三。最终rank_key改成三级排序才让对照胜出而throwstub形状至今仍排第三——被诚实地记录为边界而非缺陷。完整数据与修复前后输出对比在 EXTENSION-extraction-shell-bench.md。 目标三B4 撤回 VMP 判定——手写操作码表不是检测器矩阵第二个被推翻的结论来自一次自信的错误。中间版本的工作台脚本用手写操作码宽度表解码ezAndroid.apk一个被标记为 Dex-VMP 的 CTF 样本报告 1393/22424 个方法体无法解码6.21% 失同步当时的解读是方法体在、但解不开 → 私有指令 → Dex VMP。官方解码器一句话终结dexdump对该 dex 输出 34,566 行指令22,424 个 code item零结构错误被标失同步的方法逐条能干净解码——脚本的手写表漏了一个合法的 arm64 分支操作码0xed修正后无法解码为 dalvik 的方法体计数是07 个native声明各自匹配导出的Java_*符号。正确判定这是 JNI sinking不是 Dex-VMP——代码从 dex 搬进了 206 KB 的.so而不是被虚拟化。由此写下的规则进入参考文档我的解码器失同步是关于解码器的陈述不是关于目标的陈述任何稀有操作码密度指标必须先在同一文件上对dexdump验证才允许参与判定。这条线也划出了静态分析的结构性边界静态探针能说这不是 dex-VMP不能说这个目标没加固——native 岛里运行时才生效的检查是任何 dex 层工具看不见的。 目标四B6 Stalker 追踪——排除机制救得活进程救不活事件流社区通行说法arm64 上让 Stalker 跟进libc/libart会导致死锁、看门狗SIGABRT和零事件追踪而Stalker.exclude()是解药。B6 用三臂单变量实验实测臂做法结果baseline附加 恢复不跟进✅ 存活control跟进主线程 6 秒excludeModules: [] 进程被杀treatment同样的跟进排除 20 个系统模块✅ 存活但blocks0 blk0 calls0三个裁决无排除的跟进确实杀死目标且 baseline 臂排除了frida 本来就杀它的替代解释排除让进程活了下来——这不是风格偏好是生死线排除没有恢复事件投递——6 秒窗口依然是零事件。所以零事件是独立于负载问题的第二个缺陷Stalker.exclude()不能被宣传成它的解法这与社区把无事件列进排除机制症状清单的说法部分矛盾。实验还顺手拆掉两个会制造假零事件的脚手架陷阱脚本默认autoStarttrue会在配置落地前用默认选项开跟frida 的 spawn 是挂起态不显式resume则线程什么都不跑。详见 EXTENSION-stalker-exclude.md。 其余 9 个目标每个都留下了可路由的边界剩下的行同样各有牙齿挑最有信息量的看B2 自毁竞态补丁在 resume 后 0.04–0.05 秒写入并存活到 detach但 3 处补丁点含终止例程入口与两个分支输入都拦不住 3.22 秒后的SIGABRT更意外的发现是未改动的原始 APK 在这台设备上就报篡改——干净基线根本不存在后续实验只能以它为基线。B5 Java2C真实 JNI 样本 native 密度 0.03–0.04%Java2C 形态 fixture 82.76%相差约 2000 倍而Java_*符号搜索在真实 Java2C 上会静默失败-fvisibilityhidden C 内联的RegisterNatives不产生符号。能用的组合判据是导出JNI_OnLoad且零Java_*。见 EXTENSION-java2c.md。B9 分 APK两套真实分体跑通决策的两个分支——资源分体按设计被拒合并退出前不写任何字节代码/原生分体成功合并签名为整套成员共享一个证书。见 EXTENSION-split-apk.md。B10 内核路线设备内核 4.14.186低于 eBPF 的 5.10 GKI 门槛主机侧三个NOT FOUND就是 KPM 路线建不了的全部理由。文档级修正有牙普通 KernelSU 模块是用户态模块结构上无法改写 syscall 返回值。B12 Dart AOTarm64 打包字符串格式确认而 armv7 的len*2/UTF-16假设被证伪——32 位记录实际是[header u32][byte-count u32le][UTF-8]提取器读 0 条是格式不匹配不是字符串表为空。B13 反插桩分诊三臂实验点名了开火的检查是strstr(frida)探针臂约 300 ms 死亡且无 tombstone、无 crash、无 ANR目标侧/proc/self/maps带 4 个 frida 命名映射而TracerPid0——只查TracerPid的检测器能过查 maps 的过不了。B8 无 schema protobuf对官方运行时 21/21 字节级一致往返真实 81 字节 DataStore 容器改值后重新编码再读回成功两个经典歧义packed 边界、proto3 零值缺省都在真实字节上复现。 被推翻的 4 条结论为什么比 9 个成功更值钱tests/benchmark.md 把改变了本仓库已记录结论的行单列出来而不是埋在证据文件里B3脱壳骨架的stub%从阈值判定改写为实测双峰分布原百分之几十即骨架的说法因无实测支撑被删除B4基于手写操作码表的 VMP 判定被撤回未经官方反汇编器失败计数校验的稀有操作码密度从此不得参与判定B6Stalker.exclude()的定位从零事件解药修正为保活手段零事件被确认为独立缺陷B1*repack.py 没有 apksigner 签名路径*这一结论在基准进行中过期——另一位作者合入了sign_with_apksigner()路线同一命令重跑即产出完整签名且与手工路线 sha256 逐字节一致。这提醒所有人工具不能做 X的发现带有一个过期时间。矩阵的读法很直白Result写实际发生了什么包括失败。一个被记录下来的负面结果比一个被假设的正面结果更有价值——下一个智能体可以绕开它而不必重新支付同样的时间成本。 如何自己复跑这轮基准样本从不入库每行指定公开来源MASTG UnCrackable 系列、r2pay、DexPatcher 资产等下载到被 git 忽略的tools/_work/bench/并记录样本哈希——不同修订版本的两行不可比核心脚本均可直接运行dex_dump_validate.py骨架/原始判定、repack.py重打包 统一签名、vmp_diff_harness.py已知明文差分闭环校验 218/218 操作码映射零伪造、java2c_probe.pyJava2C/JNI sinking 分诊、protobuf_decode_raw.py无 schema 解码环境自检从 skills/apk-reverse/scripts/doctor.py 开始它报告哪些工具在场、哪些脚本可运行、以及环境里有哪些东西正在污染你的测量。总结 apk-reverse 的基准矩阵给出了逆向工程仓库少见的东西对自己结论的公开处刑记录。13 个公开目标跑下来4 条已写入文档的结论被实测推翻、3 个看起来健康的工具缺陷被变体集逼出来、每一个unverified都被如实标注而不是悄悄省略。如果你想在自己的目标上走同样的路先读 SKILL.md 的四道门槛与两次失败规则再用 docs/tool-verification/ 的三级标签要求自己写下的每一个断言——因为已记录不等于已验证而这轮矩阵正是为了把两者分开。【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/10/3 0:01:09 · 阅读 1.2k apk-reverse的基准矩阵实录：13个公开目标如何推翻4条已记录结论
apk-reverse的基准矩阵实录13个公开目标如何推翻4条已记录结论【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverseapk-reverse 是一个面向 Android APK 逆向工程分析的开源 Agent Skill 仓库提供 dex 补丁、重打包签名、脱壳诊断、Dart AOT 分析等完整工具链。它的 tests/benchmark.md 是一张基准矩阵13 行每行一个公开目标回答一个问题——当智能体遇到这类目标时仓库里文档化的路线到底管不管用更关键的是这轮基准测试推翻了仓库自己之前写下的 4 条结论。本文带你完整复盘这 13 个目标各自发生了什么以及负面结果为什么比正面结果更值钱。 基准矩阵是什么每个目标对应一行每个结论必须可复现这张矩阵不是样本合集而是回归基线。它的设计原则只有一条Result列里的每个断言都必须能用Target列指定的公开样本加上指定脚本复现不允许出现应该会发生什么式的总结。矩阵覆盖了 13 个维度与目标行维度目标一句话结果B1等长 dex 补丁 重打包签名MASTGUnCrackable-Level1.apk✅ 路线端到端跑通屏幕行为真实改变B2反调试 自毁竞态UnCrackable-Level3.apk⚠️ 分叉工具链有效补丁拦不住自毁B3脱壳骨架检测自建 11 变体骨架集推翻了stub% 阈值结论B4Dex-VMP 边界ezAndroid.apk撤回了一个 VMP 判定B5Java2C 识别自建 dcc 转换产物 真实 JNI 样本native 密度相差约 2000 倍B6Stalker 追踪UnCrackable-Level1.apk排除机制救不活零事件B7原生证书固定CyReverse Cronet 样本未执行本机无法构建B8无 schema protobuf 解码合成 fixture 官方运行时21/21 字节级往返一致B9分 APK / App Bundle两套真实分体8/9 成员拒签分支与合并分支都真实触发B10内核级 syscall 伪造KernelSU/APatch 模板生成成功但所有内核路径被封死B11JNI 动态注册发现真实系统库RegisterNatives符号搜索结构性失效B12Dart AOT 字符串表格式本地加固 Flutter APK两条既有声称全被证伪B13反插桩分诊MASTGuncrackable3点名了真正开火的检查strstr(frida)每个结论都带三级强度标签——observed有精确命令和输出、inferred从观察事实推理、unverified假设或他人报告这是 docs/tool-verification/README.md 定义的规则。unverified不是机制不成立而是本仓库还没有人为它付过验证的成本。 目标一B1 等长补丁链路——4 个字节改变屏幕行为B1 是整个矩阵里最标准的成功案例也是 G2/G4 两道的完整演练在 5528 字节的classes.dex中把MainActivity.onCreate第一个 root 检查分支的 2 个字节3900 0e00→0000 0000打平用 skills/apk-reverse/scripts/repack.py 完成 STORED 4 字节对齐重打包apksigner 报告 v1v2v3 全部通过root 安装后设备上base.apk的 sha256 与本地构建逐字节一致最终证据是屏幕原始包和无改动对照组都弹出阻塞式Root detected!对话框补丁包进入主界面对话框消失。这条链路的完整实录包括输入框无法驱动、AES 密钥误读等代价高昂的细节见 EXTENSION-benchmark-l1-l3.md。 B1 同时是推翻结论 #4的现场详见下文第四部分。️ 目标二B3 脱壳骨架检测——阈值不存在只有形状这是矩阵里最重要的负面结果。此前 references/advanced-unpacking.md 声称stub%方法体被清空的比例达到百分之几十就意味着脱壳骨架。实测直接推翻了它。用真实应用的 982 KB dex 派生 11 个等长变体跑 skills/apk-reverse/scripts/dex_dump_validate.py清空形状stub%与对照组1.9%能否区分每体裸return-void100.0%✅ 相差 98 个点截断为const/4 return93.2%✅纯 nop 填充、无 return0.0%❌低于对照组throw RuntimeException桩1.9%❌ 与对照组完全无法区分清空 25/50/75% 方法体1.7 / 1.7 / 2.1%❌ 落在采样噪声里三条结论全部为observedstub% 是双峰的——要么≈对照盲要么≈100%可见中间不存在能安放阈值的带状区间部分提取是隐形的——75% 方法体被清空报告值 2.1%与 1.9% 对照只差 0.2 个点打脸它的两种形状恰好是真实壳最爱用的——throw桩是 360/乐固系的经典形状nop 清空是壳在解密前清槽位的写法。这轮还连出三个脚本缺陷其中两个极其危险全 nop 填充的 dex 被归类为真实甚至被排成最可能是原始包第一名——智能体若按这行路由会去补丁一个被清空的骨架第一轮修复后独立评审发现排序仍指向 25% 清空的改过镜像真正的对照反而排第三。最终rank_key改成三级排序才让对照胜出而throwstub形状至今仍排第三——被诚实地记录为边界而非缺陷。完整数据与修复前后输出对比在 EXTENSION-extraction-shell-bench.md。 目标三B4 撤回 VMP 判定——手写操作码表不是检测器矩阵第二个被推翻的结论来自一次自信的错误。中间版本的工作台脚本用手写操作码宽度表解码ezAndroid.apk一个被标记为 Dex-VMP 的 CTF 样本报告 1393/22424 个方法体无法解码6.21% 失同步当时的解读是方法体在、但解不开 → 私有指令 → Dex VMP。官方解码器一句话终结dexdump对该 dex 输出 34,566 行指令22,424 个 code item零结构错误被标失同步的方法逐条能干净解码——脚本的手写表漏了一个合法的 arm64 分支操作码0xed修正后无法解码为 dalvik 的方法体计数是07 个native声明各自匹配导出的Java_*符号。正确判定这是 JNI sinking不是 Dex-VMP——代码从 dex 搬进了 206 KB 的.so而不是被虚拟化。由此写下的规则进入参考文档我的解码器失同步是关于解码器的陈述不是关于目标的陈述任何稀有操作码密度指标必须先在同一文件上对dexdump验证才允许参与判定。这条线也划出了静态分析的结构性边界静态探针能说这不是 dex-VMP不能说这个目标没加固——native 岛里运行时才生效的检查是任何 dex 层工具看不见的。 目标四B6 Stalker 追踪——排除机制救得活进程救不活事件流社区通行说法arm64 上让 Stalker 跟进libc/libart会导致死锁、看门狗SIGABRT和零事件追踪而Stalker.exclude()是解药。B6 用三臂单变量实验实测臂做法结果baseline附加 恢复不跟进✅ 存活control跟进主线程 6 秒excludeModules: [] 进程被杀treatment同样的跟进排除 20 个系统模块✅ 存活但blocks0 blk0 calls0三个裁决无排除的跟进确实杀死目标且 baseline 臂排除了frida 本来就杀它的替代解释排除让进程活了下来——这不是风格偏好是生死线排除没有恢复事件投递——6 秒窗口依然是零事件。所以零事件是独立于负载问题的第二个缺陷Stalker.exclude()不能被宣传成它的解法这与社区把无事件列进排除机制症状清单的说法部分矛盾。实验还顺手拆掉两个会制造假零事件的脚手架陷阱脚本默认autoStarttrue会在配置落地前用默认选项开跟frida 的 spawn 是挂起态不显式resume则线程什么都不跑。详见 EXTENSION-stalker-exclude.md。 其余 9 个目标每个都留下了可路由的边界剩下的行同样各有牙齿挑最有信息量的看B2 自毁竞态补丁在 resume 后 0.04–0.05 秒写入并存活到 detach但 3 处补丁点含终止例程入口与两个分支输入都拦不住 3.22 秒后的SIGABRT更意外的发现是未改动的原始 APK 在这台设备上就报篡改——干净基线根本不存在后续实验只能以它为基线。B5 Java2C真实 JNI 样本 native 密度 0.03–0.04%Java2C 形态 fixture 82.76%相差约 2000 倍而Java_*符号搜索在真实 Java2C 上会静默失败-fvisibilityhidden C 内联的RegisterNatives不产生符号。能用的组合判据是导出JNI_OnLoad且零Java_*。见 EXTENSION-java2c.md。B9 分 APK两套真实分体跑通决策的两个分支——资源分体按设计被拒合并退出前不写任何字节代码/原生分体成功合并签名为整套成员共享一个证书。见 EXTENSION-split-apk.md。B10 内核路线设备内核 4.14.186低于 eBPF 的 5.10 GKI 门槛主机侧三个NOT FOUND就是 KPM 路线建不了的全部理由。文档级修正有牙普通 KernelSU 模块是用户态模块结构上无法改写 syscall 返回值。B12 Dart AOTarm64 打包字符串格式确认而 armv7 的len*2/UTF-16假设被证伪——32 位记录实际是[header u32][byte-count u32le][UTF-8]提取器读 0 条是格式不匹配不是字符串表为空。B13 反插桩分诊三臂实验点名了开火的检查是strstr(frida)探针臂约 300 ms 死亡且无 tombstone、无 crash、无 ANR目标侧/proc/self/maps带 4 个 frida 命名映射而TracerPid0——只查TracerPid的检测器能过查 maps 的过不了。B8 无 schema protobuf对官方运行时 21/21 字节级一致往返真实 81 字节 DataStore 容器改值后重新编码再读回成功两个经典歧义packed 边界、proto3 零值缺省都在真实字节上复现。 被推翻的 4 条结论为什么比 9 个成功更值钱tests/benchmark.md 把改变了本仓库已记录结论的行单列出来而不是埋在证据文件里B3脱壳骨架的stub%从阈值判定改写为实测双峰分布原百分之几十即骨架的说法因无实测支撑被删除B4基于手写操作码表的 VMP 判定被撤回未经官方反汇编器失败计数校验的稀有操作码密度从此不得参与判定B6Stalker.exclude()的定位从零事件解药修正为保活手段零事件被确认为独立缺陷B1*repack.py 没有 apksigner 签名路径*这一结论在基准进行中过期——另一位作者合入了sign_with_apksigner()路线同一命令重跑即产出完整签名且与手工路线 sha256 逐字节一致。这提醒所有人工具不能做 X的发现带有一个过期时间。矩阵的读法很直白Result写实际发生了什么包括失败。一个被记录下来的负面结果比一个被假设的正面结果更有价值——下一个智能体可以绕开它而不必重新支付同样的时间成本。 如何自己复跑这轮基准样本从不入库每行指定公开来源MASTG UnCrackable 系列、r2pay、DexPatcher 资产等下载到被 git 忽略的tools/_work/bench/并记录样本哈希——不同修订版本的两行不可比核心脚本均可直接运行dex_dump_validate.py骨架/原始判定、repack.py重打包 统一签名、vmp_diff_harness.py已知明文差分闭环校验 218/218 操作码映射零伪造、java2c_probe.pyJava2C/JNI sinking 分诊、protobuf_decode_raw.py无 schema 解码环境自检从 skills/apk-reverse/scripts/doctor.py 开始它报告哪些工具在场、哪些脚本可运行、以及环境里有哪些东西正在污染你的测量。总结 apk-reverse 的基准矩阵给出了逆向工程仓库少见的东西对自己结论的公开处刑记录。13 个公开目标跑下来4 条已写入文档的结论被实测推翻、3 个看起来健康的工具缺陷被变体集逼出来、每一个unverified都被如实标注而不是悄悄省略。如果你想在自己的目标上走同样的路先读 SKILL.md 的四道门槛与两次失败规则再用 docs/tool-verification/ 的三级标签要求自己写下的每一个断言——因为已记录不等于已验证而这轮矩阵正是为了把两者分开。【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考