本文介绍一个面向 AI Agent/移动安全研究者 的安卓反编译器ASC，目前它中稿了BlackHat EU 2026 Arsenal，可通过
pip install droidasc安装使用。目前DroidASC的rust实现已经编写完毕，可见仓库MG1937/rust_ASC，rust实现为python ASC的一比一复刻，采用AI与人工混合开发，项目结构，所有核心细节与python ASC保持一致，性能提升为python ASC的10倍左右，支持全量反编译，实测在16线程下全量反编译QQ（383mb）仅耗时4秒，8线程则为7秒。
后Agent时代，AI分析取代了大部分工程化的静态分析理论，并以惊人的速度统治了代码分析领域，但现有的反编译引擎仍然面向人类，从产物中构建达数GB的CFG, AST, Xrefs…，但Agent需要的仅仅是代码（Agent only wantS Code），我们采用了极端的懒加载策略并利用R8编译器的优化原语，编写了Agent友好的极速反编译引擎。
目前的性能测试中，ASC 在 300MB 量级的 APK 中进行全局交叉索引搜索仅用 1.79 秒， 50MB 量级 APK 仅耗时 493 毫秒。详细可见github链接中的测试视频
参考： https://github.com/MG1937/ASC
https://blackhat.com/europe/arsenal/schedule/index.html#droid-asc-r8-compiler-optimization-as-a-decompiler-primitive-54834
ASC 目前由 Python 编写，方便二次定制与修改，可通过pip安装：pip install droidasc
benchmark:
GUI截图:
将APK作为数据库查询
当你获得一个.db文件，你是直接使用数据库工具查询.db文件内的数据，还是将 db 文件内所有表的结果逐条导出并落地为数万个 json 文件，再用 grep 命令去查询？前者听起来理所当然，后者却正是当下绝大多数反编译器（jadx、garlic 等）对待 APK 的方式。
Apk作为编译后的产物本身就是高度结构化的数据，现代反编译器却从不利用这一点。它们耗费大量时间与内存，在已经结构化的数据之上重建一个臃肿的代码关系数据库。这种工程思路违背常识：当可以直接从 APK 中毫秒级提取任意代码关系时，这些预处理还有何价值？
与其把反编译器拖入沉重的预处理，不如把编译产物直接当作数据库来查询。ASC 是一个无状态、零预处理的引擎，按需提取与搜索代码，毫秒级完成。具体来说，它的工程实现包含以下几个层面：
- 绕过完整膨胀：不完整解压 APK，而是直接在 Deflate 比特流内部探测，构建密集的 Huffman 查找表，在不触碰无关数据块的前提下提取核心元数据。
- 利用 R8 编译器行为：R8 编译器的确定性常量重定位与指令去重，会在物理布局上留下高度集中的结构。ASC 武器化这一编译器行为，实现极速的跨 DEX 代码搜索。
- O(1) 指令定位原语：将原始字节码偏移映射回方法，无需构建沉重的映射表，即可实现常数时间的方法解析。
- 按需重组极小 DEX：命中目标后，只提取特定字节码及其依赖，在内存中动态重建一个最小且自洽的 DEX，用于即时反编译。
重组 dex 看似很麻烦，实际上 benchmark 测下来，即使是给 300MB 的 APK 进行重组，也只要 9ms。
常见问题
Q1：ASC 相比 garlic 的优势是什么？为什么不用 garlic 或者 jadx？
传统做法让 AI 反编译，是希望拿到全量源码。但 jadx 太重，一条流水线分析十几个 APK、开十几个 jadx mcp，机器直接卡死。于是大家宁愿每个 APK 花十几秒甚至几分钟，把伪代码从 APK 内全部导出，garlic 就是这么做的。
但这其实没有必要。APK 本身已经是结构化的数据，如果只需要访问某个 class 的伪代码，就把这个 class 的所有元素抽出来组成一个极小的 dex，再交给下游反编译器即可。既兼顾速度，又能随时切换反编译引擎，把其它引擎优秀的反编译机制为我所用。重组 dex 看似麻烦，实测即使对 300MB 的 APK 做重组，也只要 9ms。
Q2：搜索代码呢？导出之后搜索不是更方便？
一个 APK 只要稍大，导出就非常夸张。作者试过导出 300MB 以上大型 APK 的伪代码，各种 class、小文件碎片直接落盘接近 1GB，甚至连删除都要耗费不少时间。在 1GB 的文件堆里搜索int xx = yy，可能要几秒，夸张点十几秒，因为这 1GB 不是连续文件，而是好几万个碎片分散存放，搜一次每个文件 IO 一次。
反过来想，原本一个 APK 就 300MB，而且整个文件是连续的，搜代码只要 IO 一次。直接在连续的单文件里搜指令、搜纯字节码，和导出全量源码后跑几万次 IO 去搜索，试想哪个更快？在实际测试中，针对300MB Apk的全局交叉索引搜索速度是 JADX 的269倍，针对 50MB Apk 的全局交叉索引搜索速度则是 JADX 的41倍。而且不导出源码，还可以维护流水线：APK 更新了，拉下来马上就能用 ASC 访问。总不能每拉一个 APK 就全量导出一次，1 个 APK 就是几万个文件，流水线处理多个 APK 就是几十万甚至上百万个文件，没必要。
Q3：说了这么多，到底有什么用？
作者用 ASC 产出了数个安卓系统漏洞，并靠这些漏洞中稿 BlackHat ASIA 2026 和 ACM CCS 2026。开发测试期间，作者使用 ASC 成功挖掘了荣耀 RCE 以及小米 RCE 漏洞。目前作者靠 ASC 赚取了 35 万人民币的漏洞赏金。并且，BlackHat reviewer 对工具的评价是：
“Your tool is very very highly rated!”
参考链接：
https://blackhat.com/asia-26/briefings/schedule/#vsyncbreaker-subverting-screen-trust-via-state-disruption-and-one-way-flooding-50006
