Können KI-Agenten Ihre App reverse-engineeren?
REA — Reverse Engineer Anything — ist ein quelloffener MCP-Server und ein Kommandozeilenwerkzeug, mit dem ein Coding-Agent professionelle Reverse-Engineering-Software bedienen kann: Richten Sie den Agenten auf eine ausgelieferte App oder Binärdatei, und er untersucht den Code mit echten Dekompilern, schreibt auf, wie ein Feature funktioniert — als Spezifikation —, baut das Feature neu auf und prüft den Nachbau gegen das Original. Im Oktober 2026 wurde es zu einem der am schnellsten wachsenden Projekte auf GitHub, und es verändert die Ökonomie einer alten Tatsache: Alles, was auf dem Rechner eines Nutzers läuft, kann von diesem Nutzer gelesen werden. Dieser Artikel erklärt, was REA tatsächlich ist, den Stack der Werkzeuge, die es steuert, den Arbeitsablauf, der seine Ausgabe vertrauenswürdig macht, und was ein Entwickler, der Software ausliefert, dagegen tun sollte.
Was REA ist
REA (das Repository ist morluto/rea, MIT-lizenziert, von npm als rea-agents installiert) ist kein Dekompiler. Es dekompiliert selbst nichts. Es ist eine Orchestrierungsschicht, die das Model Context Protocol spricht — dieselbe Schnittstelle, mit der sich die Arbeit dieser Website zur Agentenbereitschaft von der Website-Seite her befasst — und Reverse-Engineering-Operationen als Werkzeuge bereitstellt, die ein Coding-Agent wie Claude Code, Codex oder Cursor aufrufen kann: disassembliere diese Binärdatei, dekompiliere diese Funktion, liste die Strings auf, folge den Querverweisen, zeige die Belege. Die Schwerarbeit leisten die darunterliegenden Engines, die der Agent so steuert, wie es ein menschlicher Analyst tun würde, nur dass er es sich leisten kann, erschöpfend zu sein.
Diese Arbeitsteilung ist der Punkt. Die Ausgabe eines Dekompilers ist enorm und größtenteils langweilig; die knappe Fähigkeit im Reverse Engineering war nie, das Werkzeug zu bedienen, sondern zu entscheiden, was als Nächstes anzusehen ist, und zu wissen, wann eine Antwort bewiesen ist. REA verbindet die Engines mit Arbeitsablauf-Anweisungen — in festgelegter Reihenfolge untersuchen, für jede Behauptung Belege festhalten, angeben, was nicht geklärt werden konnte —, sodass die Ausgabe des Agenten kein Haufen Pseudocode ist, sondern eine Reihe von Befunden mit Belegen. Für native Binärdateien steuert es Ghidra, IDA Pro oder Hopper; für Android-Pakete steuert es JADX; für Live-Verhalten kann es HAR- und mitmproxy-Aufzeichnungen lesen. Eine Schnittstelle, viele Engines, und der Agent liefert die Ausdauer.
Der Stack auf einer Karte
Der Analysekern. Ghidra ist der kostenlose Apache-2.0-Dekompiler der NSA und für die meisten die Standard-Engine; IDA Pro ist der kommerzielle Platzhirsch, den viele Profis immer noch bevorzugen. Neu ist keines der beiden Werkzeuge, sondern ihre Brücken: GhidraMCP und ida-pro-mcp stellen eine laufende Ghidra- oder IDA-Sitzung einem Agenten über MCP bereit, sodass der Agent die Disassembly-Datenbank direkt abfragen kann, statt Screenshots zu lesen. REA sitzt eine Ebene über ihnen, wählt Engines aus und reiht die Arbeit aneinander.
Mobil und Apps. jadx dekompiliert Android-APKs zurück zu lesbarem Java; Apktool entpackt die Ressourcen und den Smali-Code einer APK und kann sie neu aufbauen; Frida instrumentiert eine laufende App und hängt sich in Funktionen ein, während sie ausgeführt werden — die dynamische Hälfte, die statische Dekompilierung nicht sehen kann; und ILSpy tut für .NET-Assemblies, was jadx für APKs tut. (Für einen ersten Blick ohne Installation auf die Deklarationen einer APK statt auf ihren Code liest der APK Analyzer dieser Website Manifest, Berechtigungen und Signaturzertifikate in Ihrem Browser.)
Binär und Low-Level. radare2 und sein freundlicherer Fork rizin sind skriptfähige, terminalorientierte Reverse-Engineering-Frameworks; x64dbg ist der Windows-Debugger, zu dem die meisten Analysten greifen; ImHex ist ein Hex-Editor mit einer Mustersprache zur Beschreibung von Dateiformaten; und angr ist eine Engine für symbolische Ausführung, die über jeden Pfad durch eine Funktion nachdenken kann statt nur über einen ihrer Läufe. Dies sind die Werkzeuge für die Fragen, die Dekompiler schlecht beantworten: gepackte Binärdateien, seltsame Dateiformate, „kann diese Eingabe jenen Zweig überhaupt erreichen“.
Netzwerk und Laufzeit. mitmproxy sitzt zwischen einer App und ihren Servern und zeichnet die Unterhaltung auf — bei vielen Apps erklärt der API-Verkehr mehr als der Code, und es ist das Aufzeichnungsformat, das REA nativ liest. dnSpy debuggt und bearbeitet .NET-Anwendungen live, und raddebugger ist Epics moderner grafischer Debugger für Windows. Um all das herum stehen die Karten: Zwei kuratierte Listen, awesome-ai-reverse-engineering (122 Repositories aus der Agenten-Ära, jedes gelesen und bewertet) und die eigene awesome-reverse-engineering des REA-Autors, sind in den Quellen unten verlinkt.
Die Clean-Room-Schleife: spezifizieren, nachbauen, verifizieren
Der Arbeitsablauf, den REA fördert, ist älter als KI: Es ist Clean-Room-Engineering, die Disziplin, mit der einst ein BIOS geklont wurde, ohne es zu kopieren. Der Agent untersucht das Ziel und schreibt SPEC.md — eine Spezifikation dessen, was die Software tut, in einfacher Sprache, mit den Belegen für jedes Verhalten im Anhang. Erst dann beginnt der Nachbau, ausgehend von der Spezifikation statt vom dekompilierten Code, und der Nachbau wird an Akzeptanzkriterien gemessen: gleiche Eingaben, gleiche Ausgaben, gleiche Grenzfälle. Sagt der Richter Nein, geht die Schleife zurück zu den Belegen — nicht zu einer Vermutung — und untersucht erneut.
Deshalb ist das interessante Artefakt die Spezifikation, nicht der Pseudocode. Eine Spezifikation mit Belegen kann von einem zweiten Agenten, einer Testsuite oder einem Menschen geprüft werden; eine rohe Dekompilierung ist nichts davon. Es ist auch der rechtlich bedeutsame Schritt: Ein Nachbau aus einer Verhaltensspezifikation ist ein anderer Akt als das Kopieren einer Implementierung — deshalb besteht die Schleife auf Belegen und Kriterien statt auf Bauchgefühl. Jeder, der Agentenwerkzeuge bewertet — für Reverse Engineering oder sonst etwas —, sollte dieses Muster stehlen: Das Ergebnis ist eine verifizierte Behauptung, keine selbstsichere Antwort.
Was das bedeutet, wenn Sie Software ausliefern
Nichts davon macht clientseitigen Code geheim; das war er nie. Es macht es billig, ihn zu lesen. Ein geübter Analyst mit Ghidra konnte die API-Endpunkte, die Feature-Flags und die Lizenzlogik schon immer aus Ihrer App extrahieren — Werkzeuge der REA-Klasse bedeuten, dass ein Junior mit einem Agenten-Abonnement den ersten Durchgang an einem Nachmittag erledigen kann. Die praktischen Folgen sind die alten, jetzt mit kürzeren Fristen: Ein in eine ausgelieferte Binärdatei eingebettetes Geheimnis — ein API-Schlüssel, ein privater Endpunkt, die eine wahre Rabattregel — ist faktisch veröffentlicht; Obfuskation erhöht die Kosten des Lesens, ist aber eine Verzögerung, keine Barriere; und alles, von dessen Geheimhaltung Ihr Geschäft abhängt, muss auf Ihrem Server leben, hinter Authentifizierung, nicht in der App.
Die Abwehrmaßnahmen sind ebenso unglamourös, und sie funktionieren: Halten Sie Geheimnisse und Preis-/Lizenzentscheidungen serverseitig, vergeben Sie kurzlebige, eng begrenzte Token statt dauerhafter Schlüssel, nutzen Sie Plattform-Attestierung (Play Integrity, App Attest), wo das Risiko es rechtfertigt, und gehen Sie bei der Gestaltung von Missbrauchskontrollen davon aus, dass das Verhalten Ihres Clients vollständig beobachtbar ist. Das ist das Spiegelbild der Lektion dieser Website zur Agentenbereitschaft: Dort ging es darum, dass Agenten die maschinenzugewandte Oberfläche Ihrer Website lesen, ob Sie sie gestaltet haben oder nicht; hier lesen Agenten die Binärdatei Ihrer App auf dieselbe Weise. In beiden Fällen ist der gewinnende Zug, bewusst zu entscheiden, was die maschinenzugewandte Oberfläche sagt.
Legitime Verwendungen — und die Grenzen
Reverse Engineering hat ehrenwerte, etablierte Verwendungen, und REAs eigene Dokumentation nennt dieselbe Liste: die Analyse Ihrer eigenen Software (einschließlich der Kopie, deren Quellcode Sie verloren haben), Sicherheitsforschung und Schwachstellenanalyse, Malware- und Vorfallsuntersuchung, Interoperabilität — Ihr Produkt mit einem anderen zusammenarbeiten zu lassen —, CTF-Wettbewerbe und Ausbildung. In vielen Rechtsordnungen sind einige dieser Verwendungen selbst gegen eine Lizenzklausel geschützt, die sie zu verbieten vorgibt, insbesondere Interoperabilität und gutgläubige Sicherheitsforschung, auch wenn die Einzelheiten variieren und dieser Artikel keine Rechtsberatung ist.
Die Grenzen sind ebenso klar. Eine MIT-Lizenz für die Werkzeuge ist keine Lizenz für das Ziel: Sie erlaubt nicht, das Produkt eines Wettbewerbers aus seiner Binärdatei zu klonen, DRM oder Lizenzdurchsetzung zu besiegen oder das Extrahierte zu verbreiten. Die Clean-Room-Schleife im vorherigen Abschnitt existiert genau dafür, einen Nachbau auf der richtigen Seite dieser Linie zu halten — Verhalten und Belege, keine kopierte Implementierung. Die eigenen Analysewerkzeuge dieser Website verfolgen dieselbe Linie im Kleinen: statisch, lokal, nur lesend, keine Ausführung, keine Umgehung — ein erster Blick, bei dem die schwere und rechtlich heikle Arbeit Werkzeugen und Menschen überlassen bleibt, die dafür Verantwortung übernehmen können.
Probieren Sie es selbst aus
REA benötigt Node.js 22 oder neuer; ein Befehl — npx rea-agents setup — registriert seinen MCP-Server bei den Coding-Agenten, die es findet, und installiert die passenden Arbeitsablauf-Anweisungen, und REAs eigener doctor-Befehl prüft jede Engine (für native Binärdateien muss eine native Engine wie Ghidra installiert sein; JADX deckt APKs ab). Richten Sie es auf Software, die Ihnen gehört, oder auf ein Beispiel, das Sie untersuchen dürfen — ein kleines von Ihnen geschriebenes Hilfsprogramm ist das perfekte erste Ziel — und fragen Sie es, wie ein Feature funktioniert. Lesen Sie die Spezifikation, die es erzeugt, bevor Sie irgendeinen Pseudocode lesen: Die Beleg-Links sind der Ort, an dem die Wahrheit steht.
Wenn Sie die Version des ersten Schritts ohne Installation wollen, ist dafür der Binary File Inspector dieser Website da: Legen Sie eine PE-, ELF- oder Mach-O-Datei auf der Seite ab und lesen Sie ihre Header, Sektionen, Importe und Strings in Ihrem Browser — kein Upload, keine Ausführung, keine Toolchain. Er wird nichts dekompilieren, und er sagt das auch; er ist die Fünf-Minuten-Triage, die Ihnen sagt, ob sich die vollständige REA-Behandlung lohnt einzurichten, und für welche Engine.
Quellen und weiterführende Lektüre
- REA — morluto/rea (GitHub)
- Ghidra — NationalSecurityAgency/ghidra (GitHub)
- GhidraMCP — LaurieWired/GhidraMCP (GitHub)
- ida-pro-mcp — mrexodia/ida-pro-mcp (GitHub)
- jadx — skylot/jadx (GitHub)
- Apktool — iBotPeaches/Apktool (GitHub)
- Frida — frida/frida (GitHub)
- mitmproxy — mitmproxy/mitmproxy (GitHub)
- awesome-ai-reverse-engineering — zhuyansen (GitHub)
- awesome-reverse-engineering — morluto (GitHub)