jadx-ai-mcp: ein MCP-Server im JADX-Decompiler

Welche Lücke das Plugin schließt

JADX ist ein Decompiler: Er übersetzt DEX-Bytecode zurück in lesbaren Java-Code und stellt ihn in einer Oberfläche mit Klassenbaum, Suche und Querverweisen dar. Was fehlt, ist eine Schnittstelle, über die ein Sprachmodell denselben Code lesen und durchsuchen kann, ohne dass jemand Dateien exportiert und in einen Chat einfügt. Genau dort setzt jadx-ai-mcp an. Das Repository beschreibt das Projekt als Plugin für JADX, das direkt mit dem Model Context Protocol verbunden ist, um live Unterstützung beim Reverse Engineering mit LLMs wie Claude zu bieten. Die Zielgruppe ist eng umrissen: Mobile-Security-Analysten, Pentester und SAST-Teams, die APKs untersuchen und dabei bereits JADX benutzen. Die Topics des Repositories nennen genau diese Felder: pentesting, reverse-engineering, sast, vapt. Wer nur gelegentlich eine App öffnet, um eine Zeichenkette zu suchen, braucht das nicht. Wer wiederkehrend Klassen, Aufrufketten und Manifest-Einträge durchgeht, spart mit einem Modell, das selbst suchen darf, eine Menge Kopierarbeit.

MCP als Protokollschicht zwischen Modell und Decompiler

Der Mechanismus ist eine Zweiteilung. Im JADX-Prozess läuft ein Plugin, das Zugriff auf die internen Strukturen des Decompilers hat. Daneben existiert ein separater MCP-Server, im Repository als Schwesterprojekt jadx-mcp-server geführt. Das Modell spricht nicht direkt mit JADX, sondern mit dem MCP-Server, der die Anfragen in Plugin-Aufrufe übersetzt und die Antworten zurückliefert. Das erklärt auch die Versionshinweise: Release v6.4.0 trägt den Titel Search Infrastructure Overhauled, die Suchwege wurden also überarbeitet, und v6.3.0 mit dem Titel Remote Host Support hat den Betrieb über einen entfernten Host ergänzt. Beide Änderungen betreffen die Schnittstelle, nicht den Decompiler selbst. Zwei Laufzeitumgebungen sind nötig: Das README nennt Java 11+ für die Plugin-Seite und Python 3.10+ für den Server. Wer diese Trennung nicht aufbauen will, kann das Plugin nicht sinnvoll nutzen.

Installation und Konfiguration

Das README verweist für die Einrichtung auf die Dokumentation unter jadx-ai-mcp.readthedocs.io, statt die Schritte im Repository selbst auszubreiten. Wer das Projekt einschätzt, sollte diesen Verweis ernst nehmen: Die Read the Docs Seite ist die eigentliche Installationsquelle, und ihre Vollständigkeit entscheidet darüber, ob der Aufbau an einem Nachmittag gelingt. Aus dem Repository selbst gehen die Eckdaten hervor: Der Standardzweig heißt jadx-ai, nicht main, was bei einem Klon mit falschem Branch sofort zu Verwirrung führt. Für die Plugin-Seite ist eine JADX-Installation Voraussetzung, in die das Plugin geladen wird. Auf der Serverseite läuft ein Python-Prozess, der über MCP angesprochen wird. Der Remote-Host-Support aus v6.3.0 bedeutet, dass Server und JADX nicht auf derselben Maschine liegen müssen. Das ist für Analysten nützlich, die eine große APK auf einer stärkeren Maschine dekompilieren. Es bedeutet aber auch, dass die Verbindung zwischen beiden Seiten abgesichert werden muss, und dazu macht das vorliegende Material keine Angaben.

Wo der Ansatz an seine Grenzen stößt

Der wichtigste Vorbehalt steht im Repository selbst, wenn auch auskommentiert: Der Hinweis auf einen frühen Entwicklungsstand mit möglichen Bugs, Abstürzen und logischen Fehlern. Ein Kommentar ist keine Zusage, aber er stammt aus dem Projekt und sollte bei der Planung mitgelesen werden. Dazu kommt ein struktureller Punkt. JADX kann mit sehr großen APKs umgehen, weil es Code selektiv lädt und anzeigt. Ein Modell arbeitet anders: Es muss Code in seinen Kontext holen, und dieser Kontext ist begrenzt. Bei einer umfangreichen App mit vielen Bibliotheken ist die relevante Klasse nicht automatisch die, die das Modell zuerst liest. Die Qualität hängt deshalb stark davon ab, wie gut die Suchanfragen formuliert sind, und genau hier liegt die eigentliche Arbeit. Ein weiterer Punkt: Die Ergebnisse sind nicht deterministisch. Zwei Läufe über dieselbe APK können unterschiedliche Funde ergeben. Für einen Audit, dessen Befunde nachvollziehbar sein müssen, ist das ein Problem, das sich nicht durch bessere Prompts auflösen lässt.

Was ein regelbasierter Analyzer anders macht

Die naheliegende Alternative ist ein statischer Analyzer mit festem Regelwerk, etwa MobSF oder Semgrep mit Android-Regeln. Der Unterschied liegt nicht im Ergebnisformat, sondern im Verfahren. Ein regelbasierter Scanner arbeitet eine definierte Menge von Mustern ab: unsichere Konfigurationen, bekannte API-Missbräuche, fehlende Flags im Manifest. Jeder Lauf liefert dieselbe Liste, und jeder Befund lässt sich auf eine Regel zurückführen. Das ist reproduzierbar und in einer Pipeline automatisierbar. jadx-ai-mcp macht das Gegenteil: Es gibt dem Modell Werkzeuge in die Hand und lässt es selbst entscheiden, was es liest. Das findet Zusammenhänge, die keine Regel beschreibt, etwa eine ungewöhnliche Aufrufkette über mehrere Klassen. Es findet aber auch Dinge, die keine sind, und übersieht Dinge, die eine Regel erwischt hätte. Die beiden Ansätze schließen sich nicht aus. Wer mit einem Scanner die bekannten Muster abräumt und danach mit dem Modell in die verbleibenden Klassen schaut, nutzt beide Stärken.

Wartung, Versionen und Lizenz

Die Release-Historie zeigt einen schnellen Rhythmus: v6.3.0 im März 2026, v6.4.0 im Mai, v6.4.1 im August. Der letzte Push liegt auf dem 30. August 2026, das Projekt ist also aktiv. Diese Geschwindigkeit hat eine Kehrseite: Wer das Plugin in eine feste Umgebung einbaut, muss mit häufigen Aktualisierungen rechnen, und ein Sprung von v6.3 auf v6.4 hat laut Versionsnotizen die Suchinfrastruktur umgebaut, was bestehende Abläufe verändern kann. Ein Upgrade ist daher kein Routinevorgang, sondern sollte gegen eine bekannte APK getestet werden. Die Lizenz ist Apache-2.0, also eine permissive Lizenz mit ausdrücklicher Patentgewährung. Für die Weitergabe im Unternehmen ist das unkompliziert, solange die Lizenzhinweise erhalten bleiben. Zu beachten ist, dass das Plugin JADX selbst nutzt, das unter einer anderen Lizenz steht, und dass der MCP-Server ein eigenes Repository mit eigener Lizenz ist. Eine rechtliche Prüfung ersetzt das nicht.

Für wen sich der Aufbau lohnt

Der Aufwand besteht aus zwei Installationen, einer JADX-Instanz mit geladenem Plugin und einem Python-Prozess für den MCP-Server, dazu die Konfiguration der Verbindung. Das rechnet sich, wenn Analysearbeit regelmäßig anfällt und die Ergebnisse in einem Bericht landen, den ein Mensch anschließend prüft. Es rechnet sich nicht, wenn ein einmaliger Blick in eine APK genügt oder wenn ein Scanner in einer CI-Pipeline laufen soll, denn dort zählt Reproduzierbarkeit mehr als Flexibilität. Ein Zwischenweg: das Plugin für die Erkundungsphase nutzen, in der noch unklar ist, wo im Code die relevante Logik sitzt, und die bestätigten Funde danach mit einem festen Werkzeug absichern. Wer diesen Weg geht, sollte die Version des Plugins im Bericht festhalten, weil sich die Suchinfrastruktur zwischen Releases geändert hat.

Redaktionelles Fazit

Sinnvoll ist jadx-ai-mcp für Reverse-Engineering- und SAST-Arbeit an einzelnen APKs, bei der ein Analyst ohnehin mit JADX arbeitet und die Suche sowie das Lesen von Dekompilaten beschleunigen will. Wer große App-Bestände automatisiert scannen oder reproduzierbare Befunde mit festem Regelwerk braucht, ist mit einem regelbasierten Analyzer besser bedient, weil jeder LLM-Lauf anders ausfallen kann. Vor dem ersten Einsatz zu prüfen: ob die installierte JADX-Version zum Plugin-Zweig jadx-ai passt, ob der MCP-Server aus dem Schwesterprojekt jadx-mcp-server erreichbar ist und ob der Zielhost bei Remote-Betrieb tatsächlich abgesichert ist.

Offizielle Quellen

1. Issues
2. License: Apache-2.0
3. README
4. Releases
5. zinja-coder/jadx-ai-mcp on GitHub