Skip to content
KitploitKITPLOIT
도구익스플로잇블로그
Log in
제출
도구익스플로잇블로그
제출

해킹, 침투 테스트 및 사이버 보안 도구를 당신의 보안 무기고에!

Kitploit은 해킹, 사이버 보안 및 침투 테스트 도구 디렉토리입니다. 최신 프로젝트 업데이트를 발견하여 취약점을 찾고, 시스템을 분석하고, 테스트를 자동화하고, 보안을 강화하세요.

피드문의개인정보© 2026 Kitploit

도구 디렉토리

카테고리

모든 카테고리 보기
Loading categories
ASC — Fast Android APK decompiler front-end that queries compiled DEX artifacts directly, extracting classes and cross-references in milliseconds without preprocessing. | Kitploit
도구/GitHubGitHub/mg1937/asc
Android SecurityStatic AnalysisCode AnalysisDynamic Code Analysis (DAST)Mobile App PentestingReverse EngineeringMobile SecurityUtilities & FrameworksBinary Analysis
GitHubmg1937/asc

ASC

Fast Android APK decompiler front-end that queries compiled DEX artifacts directly, extracting classes and cross-references in milliseconds without preprocessing.

저장소 보기
2.5k3591654일 전Kitploit 검토 완료

인기

모두 보기 →

커뮤니티에서 가장 많이 사용되는 도구를 찾아보세요.

모든 도구 탐색

도구 컬렉션을 둘러보세요

모든 도구 보기 →
공유
요청한 언어로 콘텐츠를 사용할 수 없습니다. 영어 버전을 표시합니다.

Droid ASC: R8 Compiler Optimization as a DeCompiler Primitive

Rust version: This project has been rewritten 1:1 in Rust as rust_ASC. The Rust version is 10× faster and supports full APK decompilation: with 16 threads, it decompiles a 383 MB APK in just 4 seconds.

If your workflow is written in Python, you can continue integrating with this project; it remains the fastest Python Android decompiler available. If you only need a binary, please use rust_ASC.

ASC and rust_ASC will be maintained in parallel, so users can choose the integration style that best fits their workflow.

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

Raw absolute values, measured with 10 threads across four APK targets of increasing size:

Global string xref search

ToolTelegramX (59MB)WhatsApp (130MB)Grab (228MB)Lark (352MB)
ASC322ms418ms806ms1.597s
JADX20s32s2m14s8m2s

ASC is 62x to 302x faster than JADX for global string xref search.

Single-class decompile

ToolTelegramX (59MB)WhatsApp (130MB)Grab (228MB)Lark (352MB)
ASC157ms141ms165ms303ms
JADX6s15s37s1m32s

ASC is 38x to 304x faster than JADX for single-class decompile.

CLI memory usage

ToolTelegramX (59MB)WhatsApp (130MB)Grab (228MB)Lark (352MB)
ASC36MB36MB58MB141MB
JADX1,016MB2.1GB7.1GB13.2GB

ASC uses 28x to 125x less memory than JADX for CLI operation.

Disk cache usage

ToolTelegramX (59MB)WhatsApp (130MB)Grab (228MB)Lark (352MB)
ASC0MB0MB0MB0MB
JADX119MB30MB127MB322MB

ASC stays fully in memory with zero disk cache, while JADX writes up to 322MB.

Note: JADX runs out of memory on the largest target (Lark) during the global search (~49% searched), while ASC completes every target.

As the benchmark shows, ASC is 62x faster than JADX on ~50MB APKs, and 302x faster on ~300MB APKs, with a tiny memory footprint. Agents can pair with ASC to analyze dozens or even hundreds of APKs at once, even on weak machines. The JADX MCP has a harder time here: JADX alone uses several GB just to preload, which makes switching between hundreds of APKs impractical.

Install

# from PyPI
pip install droidasc

# or from source
pip install .

After installation, the droidasc CLI command is available globally:

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

ASC tooling entry (v0.1.2.post1).

positional arguments:
  {getclass,disassemble,listclass,getmanifest,findrefs}
    getclass            Locate the target class in APK, extract one DEX in
                        memory, then decompile.
    disassemble         Extract a class, rebuild a small DEX, then disassemble
                        it with dadguard.
    listclass           List classes across all DEX entries; use --prefix to
                        filter by package/class prefix.
    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 disassemble app.apk Lcom/poc/Main; -o Main.smali
  droidasc disassemble app.apk com.poc.Main --debug
  droidasc disassemble app.apk com.poc.Main --debuginfo
  droidasc disassemble app.apk com.poc.Main --method 'run(I)V'
  droidasc listclass app.apk
  droidasc listclass app.apk -o classes.txt
  droidasc listclass app.apk --prefix com.poc
  droidasc getmanifest app.apk
  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
  droidasc findrefs app.apk extends java.lang.Object
  droidasc findrefs app.apk extends android.app.Activity -o subclasses.txt
  droidasc findrefs app.apk impl android.os.IInterface -o impls.txt

-V/--version prints the installed package version.

findrefs searches for code references (string/type/method/field) across all DEX entries; -o writes results to the selected file instead of stdout, and --threads N controls the worker pool. extends/impl locate classes that extend a target class or implement a target interface, respectively.

도구 다운로드