ddc — DEX → Java-Decompiler in Rust

ddc dekompiliert Android-DEX-Bytecode zurück in lesbares Java — in realistischer App-Größenordnung, abfragbar wie eine Datenbank und javac-verifiziert: Jede der 909.689 Dateien, die es über sieben reale APKs hinweg erzeugt, lässt sich fehlerfrei parsen.

Highlights

Schnell — ein 226 MB / 20-Dex-APK (weibo, 98k Klassen) wird vollständig in ~13s bei hoher Qualität dekompiliert, eine 62 MB große App (Telegram) in ~4,5s; pathologische Klassen laufen auf deadline-begrenzten überwachten Threads, statt den Lauf zum Hängen zu bringen.
Kompiliert — die vollständige Ausgabe aller sieben Benchmark-APKs (reqable, Telegram, WhatsApp, weibo, weixin, qq, lark — 0,91 Mio. Dateien) besteht javac mit null Syntaxfehlern; jede Klasse eines Namenspaars mit abweichender Groß-/Kleinschreibung (X/Cua vs. X/cua) bleibt als eigene Datei erhalten, statt dass die letzte sie stillschweigend überschreibt.
Progressive Dekompilierung — 15 Abfrage-Unterbefehle (Strings, Querverweise, Hierarchien, Manifest, Ressourcen, Dekompilate pro Methode) antworten in Millisekunden: zuerst Metadaten abfragen, bei Bedarf dekompilieren, den vollständigen Lauf ganz überspringen.
DEX 035–041, vollständig — Multi-Dex-APKs, XAPK/APKS/APKM- Container, invoke-custom; Lambdas und String-Konkatenationen werden wieder zu echtem Java zusammengeführt ((a) -> …, Cls::name, a + b).
Lesbare Ausgabe — lokale Namen im jadx-Stil (str, getName() → name, Kotlin-Intrinsics-Parameterstrings) statt v12; IntDef-Literale werden sofort als ihre Konstanten ausgegeben (setVisibility(8) → View.GONE; eine eingebaute android-37-Domänen- Tabelle, --symbols überschreibt); Kotlin-Null-Check-Rauschen wird entfernt und synthetische access$NNN-Brücken werden an ihren Aufrufstellen eingebettet.
Reproduzierbare Ausgabe — keine Zeitstempel; zwei Läufe ergeben einen sauberen Diff.
Menschengerechte Ausgabe, standardmäßig (cure): jede Datei durchläuft einen semantikerhaltenden Quelltext-Durchlauf, der Register-Kopierketten einbettet, if/else-Zuweisungen zu Ternären zusammenfaltet, for-each wiederherstellt, tote Stores und Compiler- Artefakte entfernt — −15 % Ausgabezeilen auf realen Korpora bei identischen javac-Gate-Ergebnissen. Der Durchlauf ist exakt, kostet also Zeit: weibo (110k Dateien) braucht 21 s optimiert vs. 10 s mit --fast (Vereinfachung überspringen, Formatierung beibehalten).
HTTP REST + MCP, eingebaut (xyz-rust): ddc serve stellt jede Abfrage als REST-Route bereit (GET mit Query- Parametern oder POST mit einem JSON-Body) plus GET /openapi.json und einen streamable MCP-Endpunkt unter /mcp — richte einen MCP-Client auf http://addr/mcp; ddc http ist nur REST (kein /mcp); ddc mcp stdio|http führt dieselben Befehle als MCP-Tools mit Eingabe- und Ausgabeschemata aus. Abfragebefehle akzeptieren --format auto|text|table|markdown|md|json|jsonl (auto: Tabelle auf einem Terminal, die stabile Textform bei Pipe-Weiterleitung).
Zweisprachige CLI — Meldungen werden automatisch lokalisiert (DDC_LANG=zh|en erzwingt; englischer Fallback).
Basiert auf jdc-core, dem maschinenneutralen Kern, der mit jcdc geteilt wird.

Installation

macOS (Homebrew):

brew install ejfkdev/tap/ddc

Windows (Scoop) — fügen Sie den Bucket einmal hinzu und installieren Sie dann nach Namen (Scoop löst keine bloße user/repo/app-Form auf — 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 (jede Plattform – ruft die vorgebaute Release-Binärdatei ab, anstatt zu kompilieren):

cargo binstall ddc-cli

Binärdateien: Jedes Release liefert rohe Binärdateien (keine Archive) für linux-amd64, linux-arm64, windows-amd64, windows-arm64, macos-amd64 und macos-arm64 — Nicht-macOS-Builds sind UPX-komprimiert.

Aus dem Quellcode (Rust stable):

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

Verwendung

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

Vollständige Optionen und Beispiele: ddc --help (Unterbefehl-Menü nach Workflow gruppiert). Die vollständige Referenz — die Semantik jeder Option, das Ausgabeformat und Verhalten jedes Unterbefehls — befindet sich in docs/cli.md (中文).

Performance

Sieben reale APKs, Release-Build, gemessen nach einer Abkühlphase (Apple Silicon, 6P+12E). Das 39-APK-Validierungskorpus (4,08 Mio. dekompilierte Dateien, Wandzeit pro APK / Spitzen-RSS / javac-Parse-Gate) ist in docs/validation.md (中文) zu finden.

Vollständige Dekompilierung — 7 reale APKs

APK	Größe	Vollständige Dekompilierung	Spitzen-RSS
reqable	34 MB	0,57s	162 MB
Telegram	62 MB	4,50s	786 MB
WhatsApp	139 MB	13,6s (99.483 Dateien — alle Klassenpaare mit Groß-/Kleinschreibungsvarianten erhalten)	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

Abfrage-Unterbefehle auf denselben APKs (Zellen: Zeit / Spitzen-RSS; strings -f <package> --with-locations, findrefs auf dem Paket-String und der Methode onCreate, hierarchy/disasm/getclass auf der Launcher-Klasse jeder App):

Abfrage-Unterbefehle — 13 Befehle × 7 APKs

ddc

Beliebteste

ddc — DEX → Java-Decompiler in Rust

Highlights

Installation

Verwendung

Performance