I built a very, very fast Android decompiler called Droid ASC. Literally dozens to hundreds of times faster than JADX, no exaggeration.
It is now installable via pip install droidasc
The tool has been accepted into the Black Hat Europe 2026 Arsenal. See the link below:
MG1937
/
ASC
ASC is a super FAST Android decompiler front-end designed for Agents/Mobile Researchers.
Droid ASC: R8 Compiler Optimization as a DeCompiler Primitive
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…
Here are the benchmark charts. I tested APKs across 4 orders of magnitude. For a ~50MB APK, a global cross reference index search takes 400ms, which is 41 times faster than JADX. For a 300MB APK, it takes only 1.79s, which is 269 times faster than JADX.
I have stopped using jadx mcp entirely. ASC can analyze dozens of APKs in parallel with no problem. Here is an experiment I ran:
using GPT5.6 plus ASC, with almost no human intervention, an automated pipeline ran for two days straight. It analyzed every APK on a Xiaomi device with uid=1000, pulling in nearly 100 APK/JAR/APEX files. In the end it found one Xiaomi HyperOS3 RCE, one Xiaomi system uid arbitrary file write, two vulnerabilities that can execute Xiaomi ROOT commands, and one SELinux restricted vulnerability that can execute Xiaomi ROOT commands. Pretty wild!!
Bottom line: I do not use JADX anymore. Think about it. JADX takes several minutes just to open a single APK, or outright crashes (and modern APKs are often 100+ MB). If I want to analyze 100+ APKs in parallel, am I supposed to spin up 100 JADX MCP instances on my laptop, each one at risk of OOM at any moment? That is absurd.
Here is the core idea:
Treat the APK as a database.
When you get a .db file, do you query it directly with a database tool, or do you export every table row into tens of thousands of JSON files and then grep through them? The former sounds obvious. The latter is exactly how most decompilers today (jadx, garlic, etc.) treat APKs.
An APK, as a compiled artifact, is already highly structured data, yet modern decompilers never exploit this. They spend enormous time and memory rebuilding a bloated code relationship database on top of already structured data. This engineering approach defies common sense. When you can extract arbitrary code relationships from an APK in milliseconds, what value do these preprocessing steps add?
Instead of dragging the decompiler into heavy preprocessing, treat the compiled artifact directly as a database to query. ASC is a stateless, zero preprocessing engine that extracts and searches code on demand, in milliseconds. Concretely, its engineering implementation covers the following:
Bypassing full inflation: Instead of fully unzipping the APK, it probes directly inside the Deflate bitstream, builds dense Huffman lookup tables, and extracts core metadata without touching irrelevant data blocks.
Exploiting R8 compiler behavior: R8's deterministic constant relocation and instruction deduplication leave highly concentrated structures in the physical layout. ASC weaponizes this compiler behavior to achieve extremely fast cross DEX code search.
O(1) instruction location primitive: Maps raw bytecode offsets back to methods in constant time, without building heavy mapping tables.
On demand minimal DEX reassembly: Once a target is hit, it extracts only the specific bytecode and its dependencies, dynamically rebuilding a minimal, self consistent DEX in memory for instant decompilation.
DEX reassembly sounds tedious, but in benchmarks, even reassembling for a 300MB APK takes only 9ms.
Q&A
Q1: What is ASC's advantage over garlic? Why not use garlic or jadx?
The traditional approach to AI decompilation is to get the full source. But jadx is too heavy. A pipeline analyzing a dozen APKs with a dozen jadx mcp instances will just freeze the machine. So people would rather spend ten seconds to several minutes per APK exporting all pseudocode out of the APK, and that is what garlic does.
But this is unnecessary. The APK is already structured data. If you only need to access the pseudocode of one class, just extract all elements of that class into a tiny DEX and hand it to a downstream decompiler. You get both speed and the ability to swap decompilation engines at will, leveraging other engines' superior decompilation mechanisms. DEX reassembly sounds tedious, but in practice, even for a 300MB APK, it takes only 9ms.
Q2: What about code search? Isn't searching easier after exporting?
For anything but a tiny APK, exporting is absurd. The author tried exporting pseudocode from a 300MB+ APK. All those classes and small file fragments land on disk at nearly 1GB, and even deleting them takes a while. Searching for "int xx = yy" in a 1GB pile of files might take a few seconds, or a dozen in extreme cases, because that 1GB is not a contiguous file. It is tens of thousands of fragments scattered around, requiring one IO per file per search.
Flip it around. The original APK is only 300MB, and the whole file is contiguous, so searching code only needs one IO. Searching instructions and raw bytecode directly in a single contiguous file, versus exporting all source and running tens of thousands of IOs to search. Which do you think is faster? And by not exporting source, you can maintain a pipeline. When an APK updates, pull it and immediately access it with ASC. You cannot reasonably do a full export every time you pull an APK. One APK means tens of thousands of files, and a pipeline processing multiple APKs means hundreds of thousands to millions of files. No need.
Top comments (0)