ddc — decompilatore DEX → Java in Rust

ddc decompila il bytecode Android DEX di nuovo in Java leggibile — alla scala di app reali, interrogabile come un database e verificato con javac: ognuno dei 909.689 file che emette su sette APK reali viene analizzato senza errori.

Punti salienti

Veloce — un APK da 226 MB / 20 dex (weibo, 98k classi) viene decompilato completamente in ~13s con alta qualità, un'app da 62 MB (Telegram) in ~4.5s; le classi patologiche vengono eseguite su thread monitorati con scadenza invece di bloccare l'esecuzione.
Compila — l'intero output di tutti e sette gli APK di benchmark (reqable, Telegram, WhatsApp, weibo, weixin, qq, lark — 0.91M file) supera javac con zero errori di sintassi; ogni classe di una coppia di nomi con varianti di maiuscole (X/Cua vs X/cua) viene preservata come file a sé stante invece che l'ultima sovrascriva silenziosamente.
Decompilazione progressiva — 15 sottocomandi di query (stringhe, riferimenti incrociati, gerarchie, manifest, risorse, decompilazioni per metodo) rispondono in millisecondi: prima interroga i metadati, decompila su richiesta, salta del tutto l'esecuzione completa.
DEX 035–041, completo — APK multi-dex, container XAPK/APKS/APKM, invoke-custom; lambda e concatenazioni di stringhe vengono ricondotte a Java reale ((a) -> …, Cls::name, a + b).
Output leggibile — nomi locali in stile jadx (str, getName() → name, stringhe dei parametri Intrinsics di Kotlin) invece di v12; i letterali IntDef vengono resi come le loro costanti fin da subito (setVisibility(8) → View.GONE; una tabella di dominio android-37 integrata, --symbols la sovrascrive); il rumore dei controlli null di Kotlin viene eliminato e i bridge sintetici access$NNN vengono inlinati nei loro punti di chiamata.
Output riproducibile — nessun timestamp; due esecuzioni producono un diff pulito.
Output dall'aspetto umano, per impostazione predefinita (cure): ogni file passa attraverso un passaggio a livello di sorgente che preserva la semantica che inlina le catene di copia dei registri, trasforma le assegnazioni if/else in ternari, recupera i for-each, elimina gli store morti e gli artefatti del compilatore — −15% di righe di output su corpora reali con identici risultati del gate javac. Il passaggio è esatto, quindi costa tempo: weibo (110k file) impiega 21 s ottimizzato contro 10 s con --fast (salta la semplificazione, mantiene la formattazione).
HTTP REST + MCP, integrati (xyz-rust): ddc serve espone ogni query come rotta REST (GET con parametri di query o POST con un corpo JSON) più GET /openapi.json e un endpoint MCP streamable su /mcp — punta un client MCP su http://addr/mcp; ddc http è solo REST (senza /mcp); ddc mcp stdio|http esegue gli stessi comandi come strumenti MCP con schemi di input e output. I comandi di query accettano --format auto|text|table|markdown|md|json|jsonl (auto: tabella su un terminale, la forma testuale stabile quando in pipe).
CLI bilingue — i messaggi si localizzano automaticamente (DDC_LANG=zh|en forza; fallback all'inglese).
Basato su jdc-core, il core neutro rispetto alla macchina condiviso con jcdc.

Installazione

macOS (Homebrew):

brew install ejfkdev/tap/ddc

Windows (Scoop) — aggiungi il bucket una volta, poi installa per nome (scoop non risolve una forma nuda user/repo/app — issue #3):

scoop bucket add ejfkdev https://github.com/ejfkdev/scoop-bucket
scoop install ddc

# or install straight from the manifest URL, no bucket needed:
scoop install https://raw.githubusercontent.com/ejfkdev/scoop-bucket/main/bucket/ddc.json

cargo-binstall (qualsiasi piattaforma — scarica il binario precompilato della release invece di compilare):

cargo binstall ddc-cli

Binari: ogni release fornisce binari non compressi (senza archivi) per linux-amd64, linux-arm64, windows-amd64, windows-arm64, macos-amd64 e macos-arm64 — le build non-macOS sono compresse con UPX.

Dai sorgenti (Rust stable):

git clone https://github.com/ejfkdev/ddc && cd ddc
cargo build --release

Utilizzo

ddc app.apk                          # full decompile → app-out/
ddc app.apk -c com.example.Foo       # one class to stdout
ddc app.apk -o - | less              # everything to stdout

ddc info app.apk                      # app context (label via arsc, package,
                                      # version, md5) + per-dex counts
ddc mainactivity app.apk             # entry point: package + launcher
ddc findrefs app.apk string token    # every const-string "token" site
ddc getmethod app.apk Foo.toString   # one method, all overloads
ddc pkg app.apk --app -o own/        # the app's own code only

Opzioni ed esempi completi: ddc --help (menu dei sottocomandi raggruppato per flusso di lavoro). Il riferimento completo — la semantica di ogni opzione, il formato di output e il comportamento di ogni sottocomando — si trova in docs/cli.md (中文).

Prestazioni

Sette APK reali, build di release, misurati dopo un raffreddamento (Apple Silicon, 6P+12E). Il corpus di validazione di 39 APK (4,08M file decompilati, tempo reale per APK / RSS di picco / controllo di parsing javac) è in docs/validation.md (中文).

Decompilazione completa — 7 APK reali

APK	Dimensione	Decompilazione completa	RSS di picco
reqable	34 MB	0,57s	162 MB
Telegram	62 MB	4,50s	786 MB
WhatsApp	139 MB	13,6s (99.483 file — tutte le coppie di classi con varianti di maiuscole preservate)	944 MB
weibo	226 MB	13,5s	1173 MB
weixin	268 MB	32,7s	1401 MB
lark	398 MB	16,1s	2226 MB
qq	374 MB	37,1s	2268 MB

Sottocomandi di query sugli stessi APK (celle: tempo / RSS di picco; strings -f <package> --with-locations, findrefs sulla stringa del package e sul metodo onCreate, hierarchy/disasm/getclass sulla classe launcher di ciascuna app):

Sottocomandi di query — 13 comandi × 7 APK

ddc

Più Popolari

ddc — decompilatore DEX → Java in Rust

Punti salienti

Installazione

Utilizzo

Prestazioni