【开源】Droid ASC：面向 AI Agent 时代的极速 Android 反编译引擎

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

• 我的帖子已经打上 开源推广 标签：是


• 我的开源项目完整开源，无未开源部分：是


• 我的开源项目已链接认可 LINUX DO 社区：是


• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出：是


• 以上选择我承诺是永久有效的，接受社区和佬友监督：是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

后Agent时代，AI分析取代了大部分工程化的静态分析理论，并以惊人的速度统治了代码分析领域，但现有的反编译引擎仍然面向人类，从产物中构建达数GB的CFG, AST, Xrefs…，但Agent需要的仅仅是代码（Agent only wantS Code），我们采用了极端的懒加载策略并利用R8编译器的优化原语，编写了Agent友好的极速反编译引擎。

大佬们，我自己写了一个面向AI Agent的安卓反编译器ASC，目前中稿了BlackHat EU 2026，与garlic，jadx这类反编译器不同，它不强调导出伪代码，而是直接把APK本身当成源码访问，我自己测试了4个apk量级：50mb，100mb，200mb以及300mb，其中50mb的量级中ASC全局搜索交叉引用相比于jadx提速41倍（耗时493ms），300mb量级则相比jadx提速269倍（耗时1.79s），具体可见github链接中的视频。

参考： GitHub - MG1937/ASC: ASC is a super FAST Android decompiler front-end designed for Agents/Mobile Researchers. · GitHub

https://blackhat.com/europe/arsenal/schedule/index.html#droid-asc-r8-compiler-optimization-as-a-decompiler-primitive-54834

目前ASC可通过pip安装：pip install droidasc

下图为项目的benchmark，由AI编写代码并生成的截图：

大佬们见笑了，咱们大概是这么个逻辑：

Q：你和garlic的优势是啥，我为啥不用garlic或者jadx？

A. 原本咱们让ai反编译是希望给到全量的源码，jadx又太重，一个流水线分析十几个apk开十几个jadx mcp那电脑得卡爆炸了，所以咱们宁愿每个apk耗时个十几秒或者几分钟把伪代码从apk内全部导出（garlic就是这么做的），但实际上似乎没有必要，其一是apk本身已经是一个结构化的数据了，我既然只想访问某个class的伪代码，那我就把这个class的所有元素从apk内抽出（字节码，field，method，注解信息…）组成一个极小的dex，然后再给下游反编译器不就得了嘛，这样既兼顾了速度，又可以随时切换反编译引擎将其它引擎的优秀的反编译机制为我所用，重组dex看似很麻烦，实际上我benchmark测试了下即使是给300mb的apk进行重组，也只要9ms。

Q：搜索代码呢？我导出了搜索不是更方便嘛？

A：完全没问题，但问题是一个apk只要大一点，比如我试过导出DY的伪代码，各种class，小文件碎片直接落盘了有快1个gb，太夸张了删除都不好删除，你在1gb里的文件堆里搜索“xx = xx”可能都要几秒，夸张点都要十几秒，因为这1gb他不是连续的文件阿，是好几万个文件分散着放的，搜一次每个文件io一次这个也太抽象了，而且你反过来想，原本一个抖音apk就300mb，而且apk整个文件还是连续的，我搜代码只要io一次，你想想看，我直接在连续的单个文件里面搜指令，搜纯字节码快，还是你导出全量源码跑去几万次io去搜索快？而且我不需要导出源码，还可以维护一个流水线，比如apk更新了，那我直接给apk拉下来马上就能用ASC访问了，总不能拉一个apk我就全量导出一个吧，1个apk就有几万个文件，假如你要流水线处理好几个apk，几十万甚至百万个文件，，没必要吧。。。

Q：所以你说了这么多，到底有啥用呢？？

A：我用ASC产出了数个安卓系统漏洞，并靠这些漏洞中稿BlackHat ASIA 2026和ACM CCS 2026，对了，我上周用ASC挖了一个荣耀RCE，这周用ASC又挖了一个小米RCE，目前我靠ASC赚了35w人民币，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