REA: Reverse Engineering mit KI-Agenten und überprüfbaren Befunden

Was ist REA und wofür brauchst du es?

Beim Reverse Engineering gehst du vom vorhandenen Programm zu seiner Funktionsweise zurück. Du untersuchst etwa eine ausführbare Datei, ein ausgeliefertes JavaScript-Paket oder das Verhalten einer Anwendung. Anders als bei gewöhnlicher Codearbeit steht der ursprüngliche Quelltext nicht unbedingt zur Verfügung.

REA von GitHub-Owner morluto stellt dafür eine Kommandozeile und einen MCP-Server bereit. Das Model Context Protocol macht externe Werkzeuge für einen Agenten aufrufbar. Der Agent kann damit beispielsweise Funktionen untersuchen, Aufrufbeziehungen verfolgen oder Module einer Electron-App erfassen. Laut README des veröffentlichten Tags analysiert REA lokal; die Ergebnisse gehen anschließend an deinen Agenten.

Die sinnvolle Frage lautet deshalb nicht: „Kann die KI diese komplette App kopieren?“ Besser ist: „Welches Modul verarbeitet den Export, welche Schnittstellen benutzt es und welche Befunde stützen diese Erklärung?“ So entsteht ein begrenzter Untersuchungsauftrag mit kontrollierbarem Ergebnis.

Kerndatum	Einordnung und Beleg
Produktklasse	CLI und MCP-Werkzeugschicht, kein eigenes Sprachmodell: README
Paket und Versionsstand	rea-agents in Version 6.4.0; Release vom 11.10.2026
Lizenz	MIT für REA selbst: Lizenztext
Node.js	Unterstützte Laufzeiten laut Paketmetadaten; exakter Bereich im Absatz darunter
Weitere Voraussetzungen	Abhängig von Ziel, Betriebssystem und gewählter Engine: Zielklassen
Kosten	REA-Lizenz ohne Gebühr; Modellbetrieb und externe Engines getrennt kalkulieren

Die exakte Node.js-Anforderung lautet ^22.19.0 || ^24.11.0 || >=26.0.0.

Das ist eine dokumentenbasierte Einordnung, kein eigener Installationstest oder reproduzierter REA-Benchmark.

Wie unterscheiden sich Agent, Skill, MCP und Analyse-Engine?

Diese Begriffe werden schnell vermischt. Bei REA haben sie unterschiedliche Aufgaben:

Bestandteil	Aufgabe	Was er nicht ersetzt
KI-Agent	Plant die Untersuchung, ruft Werkzeuge auf, erklärt Befunde und schreibt bei Bedarf eine Implementierung	Überprüfung seiner Schlussfolgerungen
Skill	Liefert Untersuchungsanweisungen und Referenzen	Laufenden MCP-Server und installierte Engines
REA über MCP oder CLI	Führt Analyseworkflows aus und stellt Ergebnisse strukturiert bereit	Sprachmodell und sichere Ausführungsumgebung
Analyse-Engine oder Parser	Gewinnt technische Informationen aus dem Ziel	Fachliche Interpretation und Tests des Nachbaus

Die REA-Dokumentation beschreibt diese Arbeitsteilung: Der Agent fragt, REA untersucht, der Agent arbeitet mit den zurückgegebenen Befunden weiter. Für tiefe native Binäranalyse kann REA Hopper, Ghidra oder IDA verwenden. Statische JavaScript- und .NET-Inspektion benötigen dagegen keine native Analyse-Engine.

Ein Skill allein schaltet diese Funktionen nicht frei. Die Installationsanleitung trennt ausdrücklich zwischen Anweisungen, MCP-Registrierung und externen Analyseprogrammen.

Welche Aufgaben eignen sich für REA?

Die dokumentierten Zielklassen reichen über klassische Disassembler-Abfragen hinaus. Für den Einstieg sind diese Fälle besonders greifbar:

Ziel	Beispielaufgabe	Voraussetzung oder Grenze
JavaScript/Electron	Imports, Module und IPC-Verbindungen einer eigenen ausgelieferten App nachvollziehen	Lokales App-Verzeichnis oder ASAR; statische Beziehungen sind kein Nachweis tatsächlicher Ausführung
Native Binärdatei	Eine konkrete Berechnung anhand von Pseudocode, Assembly und Referenzen erklären	Passende Engine und unterstütztes Zielformat
.NET-Assembly	Metadaten, CIL-Instruktionen und deklarierte native Abhängigkeiten untersuchen	Statische Inspektion, nicht automatisch wiederhergestellter Originalquelltext
Browser oder Netzwerkaufzeichnung	Seitenstruktur und beobachtete Anfragen eines autorisierten Ablaufs vergleichen	Browserzugang beziehungsweise passende Capture-Datei; begrenzte Beobachtung
Android	Ressourcen eines eigenen APK oder Zustand eines autorisierten Testgeräts untersuchen	Je nach Aufgabe etwa JADX, ADB oder Apktool

Der praktische Vorteil liegt darin, Analyseebenen miteinander zu verbinden. Ein Electron-Modul kann einen IPC-Kanal deklarieren; eine Laufzeitbeobachtung kann später zeigen, ob dein Testablauf diesen Kanal tatsächlich verwendet. Das sind ergänzende Befunde, keine austauschbaren Beweise.

Bei vorhandenem Quellcode kann ein quellcodebezogener Codegraph der passendere Einstieg sein. Der Guide zu codebase-memory-mcp erklärt diesen Ansatz. REA adressiert zusätzlich ausgelieferte Artefakte, native Binärdateien und Beobachtungen zur Laufzeit.

Wie steigst du kontrolliert ein?

Setup eingrenzen und prüfen

Beginne mit einem eigenen kleinen JavaScript- oder Electron-Testartefakt, dessen Aufbau du kennst. Dafür brauchst du keine native Engine. Voraussetzung ist die in den Paketmetadaten festgelegte Node-Laufzeit. Die Installationsdokumentation schließt Node 23, 25 und Prereleases ausdrücklich aus.

Für Codex kannst du zunächst nur den Setup-Plan anzeigen lassen. Die Befehlsformen sind aus der offiziellen Installationsanleitung abgeleitet; die Paketversion ist bewusst festgelegt:

npx rea-agents@6.4.0 setup --client codex --dry-run --json

Prüfe die vorgesehenen Konfigurations- und Skill-Pfade. Erst danach startest du das interaktive Setup in einem normalen Terminal (TTY), ohne Piping, und bestätigst die gewünschten Änderungen:

npx rea-agents@6.4.0 setup --client codex
npx rea-agents@6.4.0 doctor --client codex --json

Starte anschließend deinen Agenten neu. doctor prüft Konfiguration und Voraussetzungen, beweist aber nicht, dass deine bestehende Agentensitzung den Server bereits geladen hat. Maßgeblich sind die tatsächliche Verbindung und Werkzeugverfügbarkeit laut MCP-Vertrag.

Eine begrenzte Frage stellen

Ein selbst formulierter Beispielauftrag für ein autorisiertes Testartefakt:

Untersuche meine eigene Electron-Testapp im angegebenen lokalen Verzeichnis
zunächst ausschließlich statisch. Erfasse Module, Imports und IPC-Beziehungen
rund um die Exportfunktion. Starte die Anwendung nicht. Trenne beobachtete
Fakten, abgeleitete Zusammenhänge und unbekannte Stellen. Nenne zu den
zentralen Befunden die Evidence-IDs und verfügbaren Quellpositionen.

Die Anweisung begrenzt den Auftrag, ist aber keine technische Sandbox. Kontrolliere deshalb zusätzlich die Freigaberegeln deines MCP-Clients.

Für eine direkte CLI-Inspektion dokumentiert der CLI-Guide den folgenden Workflow. Ersetze den Pfad durch dein vorhandenes App-Verzeichnis oder ASAR:

npx rea-agents@6.4.0 analyze-javascript-application /absolute/path/to/app --json

Das ist ein dokumentierter Bedienweg, kein hier ausgeführter Test. Prüfe danach, ob die bekannten Module und Beziehungen deines Testartefakts im Befund auftauchen und welche Teile unaufgelöst bleiben. Rekonstruierten Code testest du separat gegen definierte Ein- und Ausgaben.

Warum sind Evidence-Datensätze wichtiger als überzeugende Antworten?

Ein Sprachmodell kann aus lückenhaftem Pseudocode eine plausible, aber falsche Erklärung bauen. REA versucht, die technische Grundlage solcher Aussagen nachvollziehbar zu halten. Evidenzproduzierende Werkzeuge liefern laut MCP-Ergebnisvertrag kanonische Datensätze mit diesen zentralen Feldern:

Feld	Bedeutung
evidence_id	Identität des zurückgegebenen Evidence-Datensatzes
normalized_result	Strukturiertes Ergebnis der Operation
analysis_profile	Analyseprofil als Objekt oder ausdrücklich null

Befunde können in der Sitzung weiterverwendet und als Bundles exportiert werden. Ein Export ist wichtig, wenn du Ergebnisse über die Verbindung hinaus behalten willst: Sitzungsreferenzen sind nicht automatisch ein dauerhaftes Archiv.

Das macht eine Untersuchung überprüfbarer, garantiert aber keine richtige Schlussfolgerung. Ein Hash bestätigt nicht, dass der Agent eine Assembly-Instruktion korrekt interpretiert hat. Ebenso wenig beweist ein statischer Aufrufpfad, dass er im untersuchten Ablauf ausgeführt wurde.

Praktisch solltest du jede wichtige Aussage auf ihren Ursprung zurückführen können: direkt gelesene Bytes, erkannte Struktur, beobachteter Ablauf oder Interpretation. Unbekannte Stellen gehören ins Ergebnis, nicht unter eine sprachlich glatte Zusammenfassung.

Was zeigt das DX-Ball-Fallbeispiel tatsächlich?

Die Projekt-Showcase-Seite zu DX-Ball 1.07 zeigt eine Untersuchung der Sound-Pan-Berechnung. Der erste Pseudocode lässt den Eingabeparameter nicht erkennen. Weitere REA-Abfragen liefern Assembly, den Aufrufer und gelesene Konstanten. Erst daraus entsteht die rekonstruierte C-Funktion.

Für diese Funktion nennt das Projekt 3.205 Verhaltensvergleiche und 63 übereinstimmende kompilierte Bytes. Die aufgezeichnete Untersuchung verwendet laut Seite REA 4.1.0, nicht den hier beschriebenen aktuellen Paketstand.

Das Beispiel illustriert einen brauchbaren Arbeitsprozess: Widerspruch erkennen, zusätzliche Belege holen, implementieren und gegen das Original prüfen. Es ist jedoch ein projektnahes Fallbeispiel, kein unabhängiger Benchmark allgemeiner REA-Genauigkeit. Die Funktionstests belegen weder vollständige Spielrekonstruktion noch zuverlässiges Klonen beliebiger Anwendungen; hier wurden sie nicht selbst reproduziert.

Was ändert der veröffentlichte Release-Stand?

Die Release-Notes zu 6.4.0 vom 11.10.2026 nennen unter anderem Setup für Pi, Hermes und Qwen Code, einschließlich aktiver Hermes-Profile. Hinzu kommen ADB-Geräteworkflows, Apktool-Ressourcenanalyse und die Anbindung eines vom Nutzer gestarteten JEB-MCP-Servers. Große Analysen erhalten selektive Evidence-Ansichten; JavaScript-Analyse läuft in einem eigenen Prozess mit Heap- und Timeout-Limits.

Ein eigener Prozess mit Ressourcenlimits ist keine Sicherheitssandbox. Außerdem darfst du Repository-main, veröffentlichte npm-Version, Skill und laufenden Server nicht gleichsetzen. Neue Anweisungen aktualisieren keinen bereits gestarteten Server.

Ein konkreter Dokumentationsstolperstein: Die Installationsdatei am veröffentlichten Tag enthält noch einen datierten npm-Prüfstand zu 6.3.0. Die aktuellen Paketmetadaten und Release-Notes belegen dagegen 6.4.0. Historische Abschnitte sind keine aktuelle Verfügbarkeitsgarantie.

Auch Versionswechsel können gespeicherte Befunde betreffen. Die Release-Notes zu 6.3.0 nennen abgewiesene historische Captures ohne benötigte Abrechnungs- oder Identitätsfelder. In 6.4.0 heißt das WebSocket-Ergebnisfeld nun network.websocket_connections statt network.websocket_events. Direkte Ressourcen-APIs verlangen außerdem ArtifactResourceScope; die CLI-/MCP-Eingaben der dort beschriebenen scoped Operations bleiben laut Release unverändert.

Meine Empfehlung: Paketversion und Engine dokumentieren, Befunde vor Updates sichern und Vergleichsworkflows nach Versionswechseln erneut prüfen.

Wie unterscheidet sich REA von GhidraMCP und IDA Pro MCP?

Kriterium	REA	GhidraMCP	IDA Pro MCP
Schwerpunkt	Mehrere Analyseebenen und Provider	Ghidra-Funktionen über Plugin und MCP-Bridge	IDA-bezogene Analyse über MCP
Typische Aufgabe	Artefakte, Modulbeziehungen und Laufzeitbefunde zusammenführen	Dekompilieren, umbenennen, Funktionen und Imports auflisten	IDA-Analysen für einen Agenten verfügbar machen
Voraussetzungen	Zielabhängig; statisches JavaScript ohne native Engine	Ghidra und Python-basierte MCP-Anbindung	IDA Pro und Python; IDA Free nicht unterstützt
Auswahlkriterium	Unterschiedliche Zielklassen und nachvollziehbare Evidence-Verträge	Vorhandener Ghidra-Workflow	Vorhandener IDA-Workflow

Grundlage sind die REA-Dokumentation, das GhidraMCP-README und das IDA-Pro-MCP-README. Letzteres empfiehlt inzwischen ausdrücklich den offiziellen Hex-Rays-MCP-Server; diese Empfehlung ist kein hier durchgeführter Vergleichstest.

REA ist damit breiter angelegt, aber nicht nachweislich genauer. Ohne identische Testziele und Vergleichsmethodik wäre eine Qualitätsrangfolge erfunden.

Welche Einschränkungen und Risiken musst du beachten?

Lokal bedeutet weder abgeschottet noch ausschließlich lokal verarbeitet

Die Security Policy sagt ausdrücklich: Die lokalen Bridges sind keine Sandbox. Nicht vertrauenswürdige Binärdateien werden vom gewählten Provider mit den Rechten des Betriebssystemnutzers verarbeitet. Für riskante Ziele empfehle ich eine getrennte, unprivilegierte Testumgebung statt deines normalen Arbeitskontos.

Bei Process Capture wird das Ziel tatsächlich gestartet. Die Process-Capture-Dokumentation unterscheidet Beobachtungspfade von Zugriffsrechten: Ein gewählter Dateisystem-Scope beschränkt, was REA beobachtet, nicht, was der Prozess lesen oder schreiben darf. Schnappschüsse können außerdem kurzlebige Änderungen übersehen.

Werkzeugergebnisse gehen an deinen Agenten und unterliegen anschließend der Datenpolitik seines Modellproviders. Vertraulichen Code, Tokens und Kundendaten solltest du nicht ohne Freigabe in dessen Kontext geben. REA verlangt laut MCP-Vertrag keine zusätzliche Freigabe je Werkzeugaufruf; entsprechende Kontrollen muss dein Client leisten.

Fehlerberichte brauchen Versionskontext

Issue #1606 berichtet über verlorene MCP-Umgebungsoptionen beim Setup auf der dort genannten Quellrevision. Es wurde als completed geschlossen; die Release-Notes nennen ausdrücklich das Erhalten bestehender MCP-Umgebungen als Fix. Das ist ein dokumentierter Upstream-Fix, kein eigener Regressionstest.

Issue #1608 beschreibt auf einer anderen Quellrevision deklarierte Geheimnisse, die in HTML- oder URL-kodierter Schreibweise in DOM-/Accessibility-Artefakten verbleiben. Der Status ist not_planned. Diese Schließung belegt keine Fehlerbehebung; der Bericht wurde hier nicht auf der veröffentlichten Version reproduziert. Nutze synthetische Zugangsdaten und prüfe Capture-Inhalte vor ihrer Weitergabe.

Die MIT-Lizenz erlaubt nicht jeden Nachbau

§ 69e UrhG erlaubt bestimmte Dekompilierung zur notwendigen Interoperabilität unter konkreten Voraussetzungen. Umfang und spätere Informationsverwendung sind begrenzt; daraus folgt keine pauschale Klon-Erlaubnis.

§ 3 GeschGehG erlaubt unter Bedingungen Beobachten, Untersuchen, Rückbauen oder Testen. Die Regelung ersetzt keine gesonderte urheberrechtliche Prüfung. Beschränke erste Versuche auf eigene Programme oder ausdrücklich autorisierte Ziele. Das ist eine technische Empfehlung, keine Rechtsberatung.

FAQ: Häufig gestellte Fragen zu REA

Brauche ich für REA immer Ghidra?

Nein. Laut README funktioniert statische JavaScript- und .NET-Inspektion ohne native Engine. Tiefe native Analyse benötigt einen passenden Provider wie Ghidra, Hopper oder IDA.

Reicht die Installation des Skills?

Nein. Ein Skill liefert Anweisungen, nicht die MCP-Verbindung oder die Analyse-Engines. Der Unterschied steht in der Installationsanleitung.

Ist REA kostenlos?

REA selbst steht unter MIT. Modellbetrieb und gegebenenfalls kommerzielle Analyse-Engines sind davon getrennt; aktuelle Engine-Preise wurden hier nicht geprüft.

Bleiben alle untersuchten Daten lokal?

Nicht automatisch. REA analysiert lokal, aber dein Agent erhält Werkzeugergebnisse. Für deren Modellverarbeitung gilt laut README die Datenpolitik des Modellproviders.

Kann REA eine komplette App zuverlässig klonen?

Dafür liefern die geprüften Quellen keinen allgemeinen Nachweis. Der DX-Ball-Showcase zeigt nachvollziehbare Funktionsrekonstruktion mit Tests, keine universelle Klon-Garantie.

Fazit

REA lohnt einen kontrollierten Einstieg, wenn du konkrete Funktionen oder Abhängigkeiten autorisierter Software verstehen willst. Nutze es als Werkzeugschicht für überprüfbare Befunde, nicht als Abkürzung zu einem garantiert korrekten App-Nachbau. Beginne statisch, begrenze den Auftrag und prüfe jede Rekonstruktion separat; für vorhandenen Quellcode bietet der Codegraph-Guide zu codebase-memory-mcp die passende Abgrenzung.

Quellen

Primärquellen: Projekt, Releases und Verträge

• REA-Repository und README am veröffentlichten Tag: Produktklasse, Zielklassen und Datenfluss.
• npm-Metadaten für 6.4.0: Version, Node-Anforderung und Lizenz.
• Release 6.4.0 und Release 6.3.0: Erweiterungen, Fixes und Breaking Changes.
• Installation, CLI und MCP-Verträge: dokumentierte Bedienwege, Sitzungsidentität und Evidence.
• Security Policy und Process Capture, historische Vertragsbasis: Rechte und Beobachtungsgrenzen.
• MIT-Lizenz: Rechte an REA selbst.

Projektfallbeispiel und externe Gegenpositionen

• DX-Ball-Showcase: projektnahe Funktionsrekonstruktion und zugehörige Prüfungen, kein unabhängiger allgemeiner Benchmark.
• Issue #1606 und Issue #1608: revisionsgebundene Nutzerberichte; nicht selbst reproduziert.
• GhidraMCP und IDA Pro MCP: Selbstdokumentation der Alternativen, kein Leistungsvergleich.
• Unabhängige allgemeine Genauigkeitsmessungen von REA sind durch diese Quellen nicht belegt.

Recht und Recherchezugang

• § 69e UrhG und § 3 GeschGehG: deutsche Rechtsquellen.
• Öffentlich geteiltes Recherche-Notebook: Quellensammlung und Synthese, kein unabhängiger Test; Google-Anmeldung kann erforderlich sein.

*Quellen geprüft am 11.10.2026. Dokumentenrecherche ohne eigenen REA-Laufzeittest.*