ASC README

The project's README from github.com/MG1937/ASC. As one markdown file: README.md.

Droid ASC: R8 Compiler Optimization as a DeCompiler Primitive

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

When decompiling massive Android APKs, the standard procedure is to wait. We wait for tools to eat gigabytes of RAM, fully inflate the artifacts, and spend tens of minutes building heavy global indexes and cross references... All of this is just to guarantee fast code searches later, but here is the contradiction. A compiled artifact is already highly structured, modern decompilers never utilize this, they waste massive amounts of time and memory reconstructing a bloated database of code relationships over already structured data. This engineering approach defies common sense. When I can directly extract any code relationship from the APK in milliseconds, does this preprocessing still hold any value?

Instead of forcing decompilers into heavy preprocessing, we choose to query the compiled artifact directly as a database. We built a stateless, zero-overhead engine that extracts and searches code on demand in milliseconds. In this briefing, we will explore the underlying engineering required to bypass traditional bottlenecks. We will demonstrate how to abandon full inflate by probing directly within the Deflate bitstream, building dense Huffman lookup tables to extract core metadata without touching irrelevant data blocks. Furthermore, we will explain optimization details of the R8 compiler, especially how deterministic constant relocation and instruction deduplication leave behind highly concentrated physical layouts, we weaponize this compiler behavior to execute lightning-fast cross DEX code searches. To map these raw bytecode offsets back to methods, we engineered an O(1) instruction locating primitive, achieving constant-time method resolution without building heavy mapping tables. Finally, upon hitting a target, Droid ASC extracts only the specific bytecodes and its dependencies, dynamically reconstructing a minimal and self consistent DEX entirely in memory for instant decompilation.

We will demonstrate this architecture live against a 352MB commercial APK. Droid ASC executes global cross reference searches in 1.79 seconds and decompiles target classes in 177 milliseconds using only 141MB of RAM. By treating the artifact as a read only database and operating with zero preprocessing, we return the decompiler to its core essence. It is no longer a bloated indexing tool, but a lightning fast, on demand decompilation engine that fundamentally redefines how we analyze compiled code.

Benchmark

Benchmark

https://github.com/user-attachments/assets/4c4a6813-8561-490c-a573-ef113da861b6

Install

# from PyPI
pip install droidasc

# or from source
pip install .

After installation, the droidasc CLI command is available globally:

usage: droidasc [-h] {getclass,listclass,getmanifest,findrefs} ...

ASC tooling entry.

positional arguments:
  {getclass,listclass,getmanifest,findrefs}
    getclass            Locate the target class in APK, extract one DEX in memory, then decompile.
    listclass           List classes defined across all DEX entries in APK.
    getmanifest         Decode AndroidManifest.xml from APK and print it as XML.
    findrefs            Find code references for string/type/method/field across all DEX entries in APK.

options:
  -h, --help            show this help message and exit

examples:
  droidasc app.apk --gui
  droidasc getclass app.apk Lcom/poc/Main; -o Main.java
  droidasc getclass app.apk com.poc.Main --threads 16
  droidasc listclass app.apk -o classes.txt
  droidasc listclass app.apk --prefix com.poc
  droidasc getmanifest app.apk -o AndroidManifest.xml
  droidasc findrefs app.apk string token -o string_refs.txt
  droidasc findrefs app.apk type com.poc.Main
  droidasc findrefs app.apk method onCreate --class com.poc.Main
  droidasc findrefs app.apk method notify --class MainActivity --fuzzy-class -o method_refs.txt
  droidasc findrefs app.apk field apiKey -o field_refs.txt

listclass prints Dalvik class descriptors in APK/DEX definition order, one per line. With -o, output is written to the selected file instead of stdout. --prefix com.poc filters by Lcom/poc; an already normalized prefix such as Lcom/poc is kept unchanged.

You can also use python main.py as before — it delegates to the same entry point.

ASC (MG1937/ASC)

Searching Database…

2.5K ·GitHub
这是什么?Droid ASC 是一个速度极快、轻量级的 Android 反编译工具,专为 AI 智能体和移动端研究人员打造:它不对 APK 预先建立索引,而是按需在毫秒级时间内提取并反编译代码。
和普通的 Android 反编译工具相比,用它有什么好处?传统反编译工具会把 APK 完整解包,还要花上几分钟和几个 GB 的内存去构建全局索引,以便之后能快速搜索。ASC 完全不做预处理:它直接把编译后的产物当作只读数据库来查询。
它是命令行工具吗?怎么让它跑起来?是的,它是一个命令行工具:安装完成后,'droidasc' 命令全局可用。README 里没有给出具体的安装步骤命令,但在仓库目录里运行 'python main.py' 会调用同一个入口。
它的速度是否取决于 APK 是怎么编译的?它的快速跨 DEX 搜索建立在 R8 编译器的行为之上:确定性的常量重定位和指令去重会留下高度集中的物理布局,引擎正是利用了这一点。README 没有讨论以其他方式编译的 APK。
它怎么做到不完全解包就能读取 APK?它放弃了完整解包的做法,直接在 Deflate 压缩比特流里探测,利用稠密的 Huffman 查找表把核心元数据取出来,而不碰无关的数据块。
它是怎么这么快就找到并反编译目标类的?一个 O(1) 的指令定位原语可以在常数时间内把原始字节码偏移量映射回对应方法,不需要构建映射表。随后它只提取所需的字节码及其依赖,完全在内存中重建一个最小化的、自洽的 DEX,从而实现即时反编译。
为什么说它是为智能体设计的,而不只是给人类研究人员用的?它的无状态、零开销设计非常适合自动化流水线:每次查询都在毫秒级返回,不需要漫长预处理在旁边盯着,所以智能体可以按需探测 APK,而不是每做一次完整扫描就等上几分钟。
整个 APK 会被加载到内存里吗?不会。它的设计是只访问需要的部分:元数据直接从压缩流中读取,内存里也只重建目标字节码及其依赖,这就是为什么分析一个 352MB 的 APK 只用了 141MB 内存。
Creator
MG1937
Size
13.9 MB
Stars
2.5K
Age
4mo
Commits · 90 Days