Reverse Engineer Anything (REA): Einrichtung und Praxis

Veröffentlicht

17. Oktober 2026

Autor

Faizan Nadeem

Was ist Reverse Engineer Anything?

REA ist eine Analyseschicht, die einem Agenten konkrete Möglichkeiten zur Untersuchung von Software gibt. Der Agent formuliert eine Frage, REA führt die passende Untersuchung durch und der Agent interpretiert die zurückgegebenen Ergebnisse. Bei nativem Code kann ein installierter Decompiler zum Einsatz kommen; bei einer Electron-Anwendung kann die Untersuchung mit dem ausgelieferten JavaScript beginnen. Das Projekt unterstützt außerdem Abläufe über das Terminal. REA-Überblick

Diese Aufgabenteilung ist für die Bewertung der Ergebnisse entscheidend. Das Modell formuliert die Erklärung, während die zugrunde liegenden Werkzeuge die Beobachtungen liefern. Auch eine flüssig geschriebene Antwort braucht nachvollziehbare Fundstellen und eine klare Aussage darüber, was tatsächlich untersucht wurde.

Wenn dir das Protokoll noch nicht vertraut ist, erklärt mein Leitfaden zum Bau eines MCP-Servers mit Python, wie ein Agent die Werkzeuge eines Servers aufruft. REA ist ein konkreter Anwendungsfall dieser Architektur.

Was kann REA analysieren?

Wähle den Analyseweg anhand des Artefakts, das dir vorliegt. Die Dateiendung allein verrät nicht, welche Implementierungsdetails sich rekonstruieren lassen.

Ziel	Nützliche Ergebnisse	Wichtigste Voraussetzung oder Grenze
Native ausführbare Datei oder Bibliothek	Assemblercode, Pseudocode, Zeichenketten, Funktionen, Referenzen	Ein geeignetes Analysewerkzeug für nativen Code, etwa Ghidra, Hopper oder IDA
JavaScript- oder Electron-Paket	Module, Imports, Routen, IPC-Beziehungen	Die statische Analyse kann ohne nativen Decompiler auskommen
Verwaltete .NET-Assembly	Metadaten, CIL-Anweisungen, P/Invoke-Deklarationen	Die statische Untersuchung führt die Assembly nicht aus
Browserseite	DOM, Informationen zu Skripten, zeitlich und sachlich begrenzte Netzwerkbeobachtungen	Ein eigener Browser aus der Chrome-Familie, der über CDP erreichbar ist
Android-APK	Manifest, Klassen, dekompilierte Methoden, Referenzen	Die dokumentierten Voraussetzungen für JADX und das JDK

Diese Analysewege decken unterschiedliche Bereiche ab. Der Leitfaden zur Untersuchung nativen Codes, der Leitfaden für JavaScript-Workflows, die Referenz für verwalteten Code, die Browserreferenz und der Android-Leitfaden beschreiben die jeweiligen Grenzen.

Die Untersuchung von .NET-Metadaten und CIL bedeutet beispielsweise nicht, dass sich eine ausführbare NativeAOT-Datei wie eine gewöhnliche verwaltete Assembly behandeln lässt. Ebenso kann die Beobachtung von Browseranfragen das für den Client sichtbare Verhalten aufzeigen, aber keine Implementierungsdetails des Servers offenlegen, die nicht mit ausgeliefert wurden.

So installierst du REA für einen Coding-Agenten

Beginne mit Node.js und npm. Die Veröffentlichung vom 14. Oktober und die für diesen Artikel geprüften Paketmetadaten nennen REA 6.5.0 sowie die unterstützten Node-Versionen ab 22.19 innerhalb von 22.x, ab 24.11 innerhalb von 24.x oder ab 26. Prüfe bei der Installation die veröffentlichten Paketmetadaten, da sich die neueste Version ändern kann.

Für eine reproduzierbare Einrichtung mit Codex lässt du dir zunächst die geplanten Änderungen anzeigen:

npx -y rea-agents@6.5.0 setup --client codex --dry-run --json

Starte danach die interaktive Einrichtung:

npx -y rea-agents@6.5.0 setup --client codex

Prüfe die vorgeschlagene Konfiguration und die Zielverzeichnisse für Skills, genehmige die gewünschten Änderungen und starte den Agenten neu. Die Option -y bestätigt die npm-Abfrage zum Herunterladen des Pakets; sie ersetzt nicht die Zustimmung zu den Konfigurationsänderungen von REA. Die Installationsanleitung erklärt Sicherungskopien und unterstützte Clients.

Wenn du nur den Skill installierst, erhält der Agent Anweisungen. Dadurch wird weder der MCP-Server registriert noch werden Analysewerkzeuge verfügbar. Fehlen Werkzeuge, prüfe die Registrierung:

npx -y rea-agents@6.5.0 doctor --client codex --json

Eine fehlerfreie Registrierung beweist noch nicht, dass sich die aktuelle Agentensitzung erfolgreich verbunden hat. Starte sie neu oder stelle die Verbindung erneut her und prüfe anschließend, ob die REA-Werkzeuge verfügbar sind. Der MCP-Vertrag unterscheidet zwischen Registrierungsprüfungen und der Identität des tatsächlich verbundenen Servers.

Die Wahl eines Analysewerkzeugs für nativen Code ist eine separate Entscheidung. Das Setup kann mit deiner Zustimmung bei der Installation von Hopper helfen; andere Werkzeuge haben eigene Voraussetzungen. Auch die Unterstützung des Hostsystems hängt vom jeweiligen Vorgang ab. Unter Linux benötigt der dokumentierte JavaScript-/Electron-Analyseweg ein procps-kompatibles ps, um die Prozesszugehörigkeit zu prüfen. Richte dich nach der Installationsmatrix für deinen gewählten Analyseweg. Insbesondere ist die dokumentierte Ghidra-Integration für Windows x64 experimentell und auf Lesezugriffe beschränkt; das Hopper-Setup richtet sich an unterstützte macOS- und Linux-Umgebungen. Gehe nicht davon aus, dass native Analyseabläufe auf allen Betriebssystemen gleich funktionieren. Grenzen der Ghidra-Integration unter Windows

Du kannst die CLI auch ohne Registrierung eines Agenten nutzen. Speichere vollständige JSON-Ergebnisse, wenn spätere Befehle darauf angewiesen sind: Jeder CLI-Aufruf läuft als eigener Prozess, während MCP innerhalb einer Verbindung Belege für Folgefragen vorhalten kann. Eine Belegkennung aus einer anderen Verbindung ist kein übertragbares Ergebnis. Leitfaden zu CLI und Evidence

Ein praktischer Ablauf für Untersuchungen mit REA

Ich würde mit einem beobachtbaren Verhalten und einem klaren Endpunkt beginnen. „Erkläre, wie diese Anwendung ein Dokument exportiert“ lässt sich leichter überprüfen als eine offene Aufforderung, alles zu rekonstruieren.

1. Lege das Artefakt und die Frage fest

Halte die Anwendungsversion, das genaue Paket oder die ausführbare Datei und die zu untersuchende Funktion fest. Trenne Ergebnisse aus unterschiedlichen Builds voneinander. Notiere, was als hilfreiche Antwort gelten würde: etwa das Serialisierungsformat, der Handler für ein Ereignis oder die Funktion, die einen Wert umwandelt.

Für ein bereits ausgewähltes Electron-Paket, zu dessen Untersuchung du berechtigt bist, könnte ein beispielhafter Auftrag an den Agenten so lauten:

Untersuche mit REA die Zwischenablagefunktion im ausgewählten lokalen Paket. Verfolge die bereitgestellte API über Preload und IPC bis zum Handler im Hauptprozess. Belege deine Aussagen mit Codepositionen, unterscheide Beobachtungen von Schlussfolgerungen und liste ungeklärte Schritte auf. Erstelle zuerst eine Erklärung, bevor du eine Implementierung vorschlägst.

Dies ist ein Beispiel für einen Arbeitsablauf, kein Bericht über eine hier durchgeführte Untersuchung.

2. Verfolge eine Funktion anhand der verfügbaren Belege

Bei JavaScript-Anwendungen kann REA Beziehungen ausgehend von einem Modul, einer API, einer Zeichenkette oder einem IPC-Kanal verfolgen. Folge diesen Beziehungen und untersuche den betreffenden Code. Ein passender Name ist ein nützlicher Ausgangspunkt, aber kein ausreichender Nachweis für ein bestimmtes Verhalten. Die Dokumentation zu JavaScript-Workflows beschreibt, wie solche Nachverfolgungen statische Beobachtungen, Schlussfolgerungen und offene Fragen festhalten.

Die Fallstudie zur Zwischenablage von Notion veranschaulicht diesen Ansatz. Sie verfolgt eine für die Seite zugängliche Zwischenablage-API über Preload-Wrapper und einen IPC-Kanal bis zu einer Schreibfunktion für die Zwischenablage im Hauptprozess, die den Absender prüft. Das veröffentlichte Beispiel untersucht Notion Desktop 7.6.1 mit REA 4.1.0 und unterscheidet zwischen dem Lesen des Pakets und gespeicherten Modultests. Es handelt sich um eine Demonstration des Projekts, nicht um ein von mir reproduziertes Ergebnis.

3. Trenne Beobachtungen, Schlussfolgerungen und offene Fragen

Während einer Untersuchung würde ich eine kurze Ergebnistabelle führen:

Ergebniskategorie	Beispielhafte Aussage	Nächster Schritt
Beobachtung	Für einen bestimmten IPC-Kanal ist ein Handler registriert	Die genaue Codeposition festhalten
Schlussfolgerung	Der Handler scheint den Kopierbefehl zu bedienen	Den Aufrufer und die Weitergabe der Argumente prüfen
Offene Frage	Ein dynamisch ausgewählter Handler wurde nicht aufgelöst	Die fehlenden Belege ausdrücklich benennen

Die Ergebnisverträge von REA bewahren die Identität der Belege und Informationen darüber, welcher Bereich untersucht wurde. Ein leeres Ergebnis bei unvollständiger Abdeckung kann nicht belegen, dass ein Verhalten fehlt. Diese Unterscheidung ist besonders beim Vergleich von Versionen wichtig. Evidence-Verträge

4. Prüfe das Verhalten, bevor du dich auf eine Rekonstruktion verlässt

Ein statisch nachvollzogener Pfad belegt Zusammenhänge im untersuchten Code. Um eine Aussage darüber zu treffen, was während einer Interaktion passiert, brauchst du geeignete Laufzeitbelege für genau diese Interaktion.

Die Browserbeobachtung kann begrenzte Belege von einer bestehenden Seite sammeln, darunter Metadaten zu Skripten und zum Netzwerkverkehr. Die passive Beobachtung beschränkt sich auf die ausgewählte Seite und das Beobachtungsfenster. Eine Aufzeichnung sollte daher nicht als vollständige Historie der Anwendung dargestellt werden. Leitfaden zur Browserbeobachtung

Für eine Rekonstruktion würde ich jedes belegte Verhalten in eine Abnahmeprüfung übersetzen: die erwartete Ausgabe für eine bekannte Eingabe, den Umgang mit fehlerhaften Eingaben und wichtige Randfälle. Prüfe die Implementierung anhand dieser Kriterien. Das ist eine technische Empfehlung, keine Behauptung, dass REA eine vollständig nachgebaute Anwendung automatisch überprüft.

Grenzen, die in echten Projekten relevant sind

Dekompilierter Code ist eine Interpretation des ausgelieferten Artefakts. Native Analysewerkzeuge können Anweisungen und Pseudocode sichtbar machen, stellen damit aber weder die ursprünglichen Kommentare noch die Projektstruktur oder die Entwicklungsgeschichte wieder her. Untersuche die relevanten Funktionen und berücksichtige die Grenzen des jeweiligen Werkzeugs bei deinen Schlussfolgerungen. Native Analyse

Welche Werkzeuge verfügbar sind, hängt von der installierten Version und der Umgebung ab. Der Repository-Branch main kann Änderungen beschreiben, die noch nicht in einem veröffentlichten Paket enthalten sind. Nutze die Werkzeugschemata und Verfügbarkeitsinformationen des installierten Servers. Eine festgelegte Paketversion verbessert die Reproduzierbarkeit; sie garantiert nicht, dass jedes Beispiel aus der aktuellen Dokumentation unverändert anwendbar ist.

Lokale Analyse bedeutet nicht, dass jedes Ergebnis auf deinem Rechner bleibt. Laut REA läuft die Analyse des Zielartefakts lokal, während der Agent die Werkzeugergebnisse erhält. Der Umgang deines Modellanbieters mit Daten bleibt deshalb relevant. Projekt-FAQ

Der Untersuchungsumfang bestimmt den Aufwand. Ich würde davon ausgehen, dass wiederholte, breit angelegte Untersuchungen mehr Zeit und Agentenkontext verbrauchen als gezielte Folgefragen. Bewahre nützliche Ergebnisse auf und verfolge die Lücken, die für deine Frage entscheidend sind. Wenn du die Agentenschleife selbst entwickelst, behandelt LangChain im Vergleich zu LangGraph die Entscheidungen zum Kontrollfluss hinter Verzweigungen und dauerhaft gespeichertem Zustand.

Wann ich REA einsetzen würde

REA ist hilfreich, wenn die Antwort vom ausgelieferten Verhalten oder von einem Artefakt abhängt, dessen ursprünglicher Quellcode nicht verfügbar ist: etwa bei der Untersuchung von Kompatibilität, beim Verständnis einer älteren Komponente oder bei der Erklärung einer Änderung zwischen Builds. Liegt ein vollständiges Quellcode-Repository vor, würde ich in der Regel zuerst den Code lesen und seine Tests ausführen.

Der von REA selbst entwickelte Code steht unter der MIT-Lizenz; für kommerzielle Analysewerkzeuge gelten weiterhin deren eigene Lizenzanforderungen. Das Projekt nennt autorisierte Forschung, Interoperabilität und den Erhalt von Software als vorgesehene Einsatzbereiche. Projektlizenz und Hinweise

Wähle für deine erste Untersuchung eine kleine Funktion, bestimme das genaue Artefakt und verlange eine Erklärung mit nachvollziehbaren Belegen. Erfolg bedeutet einen Ablauf, den du selbst prüfen kannst, und eine Schlussfolgerung, deren Grenzen du verstehst. Das ist eine hilfreiche Grundlage für die Implementierung, auch wenn einzelne Fragen offenbleiben.

Quellen