REA: Alles zurückentwickeln mit autonomen Agenten, vom App-Verhalten bis zu nativen Binärdateien

Jeder Entwickler kennt die Frustration: Man stößt auf eine bewundernswerte Funktion und hat keine Möglichkeit herauszufinden, wie sie gebaut wurde. Der Quellcode ist geschlossen, die Binärdatei ist von Symbolen befreit, und die Electron-App wird als einzelnes ASAR-Archiv ausgeliefert. Die klassische Antwort war ein Reverse Engineer, der tage- oder wochenlang Zeile für Zeile in einem Disassembler las. REA, kurz für Reverse Engineer Anything, ist ein Open-Source-Projekt auf GitHub, das diesen Ablauf verändern will. Das Versprechen ist schlicht: ein einziger MCP-Server, der Ihrem Agenten Werkzeuge für das Reverse Engineering von nativen Binärdateien, Anwendungen und Laufzeitverhalten gibt. Das Projekt steht unter der MIT-Lizenz, wird als npm-Paket rea-agents verteilt und hat laut README mehr als 60.000 GitHub-Sterne sowie Dokumentation in neunzehn Sprachen. Für ein Werkzeug zwischen Sicherheitsforschung und alltäglicher Softwareentwicklung zeigt diese Aufmerksamkeit, wie real der Bedarf ist.

Die Funktionsweise von REA ist nicht geheimnisvoll. Man führt npx rea-agents setup aus, wählt die verwendeten Agenten, prüft die vorgeschlagenen Änderungen und genehmigt sie. Das Setup registriert den MCP-Server von REA, installiert passende Arbeitsanweisungen und sichert die vorhandene Konfiguration. Das README nennt Claude Code, Codex, Cursor, Gemini CLI und Grok Build und sagt, dass jeder Agent mit Unterstützung für lokale MCP-Server REA nutzen kann. Nach einem Neustart fragt man in normaler Sprache: Verstehe, wie die Suche in einer bestimmten App funktioniert, zeige die Belege und baue eine ähnliche Funktion für mein Projekt. Der Agent ruft REA über MCP auf, um das Ziel zu untersuchen und den relevanten Code zu verfolgen. REA liefert Befunde samt Belegen zurück, also Code, Verweise und die weiterhin offenen Punkte. Der Agent stellt daraufhin Folgefragen, erklärt das Verhalten oder schreibt und testet eine Implementierung. Dieselben Abläufe stehen als Befehle im Terminal bereit, sodass ein Mensch nachvollziehen kann, was der Agent getan hat.

Gewicht verleiht dem Projekt die Breite der unterstützten Ziele. Laut der Tabelle im README liefert REA für native Binärdateien Pseudocode, Assembler, Zeichenketten, Symbole, Aufrufe und Referenzen, gestützt auf Hopper, Ghidra oder IDA. Bei JavaScript- und Electron-Anwendungen stellt es Module, Importe, Source Maps, Routen, IPC und die Beziehungen zu nativen Add-ons wieder her; dieser Teil braucht nur Node.js und keine native Analyse-Engine. Außerdem untersucht es Websites, gespeicherte HAR-Netzwerkmitschnitte, .NET-Assemblies bis hin zu Metadaten und CIL-Anweisungen, Android-APKs und -Geräte, Firmware-Abbilder, EVM-Bytecode, Offline-ELF-Layouts und aufgezeichnete Linux-Abstürze. Ein Modus für Prozessverhalten erfasst Terminalausgabe, Interaktionen, Exit-Status und Beobachtungen am Dateisystem und vergleicht dann mehrere Läufe. In der Praxis kann eine einzige Agentensitzung eine Electron-Funktion vom Renderer bis in den Hauptprozess verfolgen und danach in den Assembler eines nativen Add-ons hinabsteigen. Arbeit, die früher den Wechsel zwischen fünf oder sechs unverbundenen Werkzeugen erforderte, liegt nun in einem Werkzeugkatalog.

Die drei Fallstudien im README zeigen, wie das in der Praxis aussieht. Im Fall DX-Ball beginnt die Untersuchung bei einem Soundaufruf, folgt einer Hilfsfunktion, die eine Position in Stereo-Panning umrechnet, prüft die Anweisungen und macht aus unvollständigem Pseudocode C-Code. Das README gibt an, dass die Rekonstruktion 3.205 Fälle des ursprünglichen x86-Codes besteht und alle 63 Bytes der kompilierten Funktion reproduziert. Im Fall Notion findet der Agent die Zwischenablage-API des Renderers, verfolgt sie über Preload und IPC in den Hauptprozess und untersucht das reichhaltige Zwischenablageformat. Im Fall TH04 liest er die 16-Bit-Anweisungen des originalen PC-98-Spiels, stellt die Winkelberechnungen für feste und gezielte Schüsse wieder her und vergleicht das rekonstruierte C++ mit der Ausgabe des historischen Compilers. Die Schwierigkeit unterscheidet sich, das Muster bleibt gleich: Die Schlussfolgerung stammt nicht aus dem Eindruck des Modells, was der Code wohl tut. Sie stützt sich auf Belege auf Befehlsebene, die ein Mensch nachprüfen kann, und auf Tests, die das Ergebnis bestätigen. Das ist der Grundsatz, den das Projekt am häufigsten wiederholt: Jede Schlussfolgerung trägt ihre Belege und ihre Grenzen.

Aus Branchensicht ist REA ein klares Beispiel für einen Trend, den man beobachten sollte. Spezialwerkzeuge werden in ein Protokoll verpackt, das Agenten aufrufen können. Das Sprachmodell übernimmt Planung und Erklärung, während deterministische Analyse-Engines die Belege sammeln. Das README ist beim Thema Lokalität eindeutig: Die Analyse läuft auf Ihrem Rechner, Ihr Agent erhält die Werkzeugergebnisse, und was der Modellanbieter damit macht, richtet sich nach dessen eigener Datenrichtlinie. Diese Arbeitsteilung senkt das Risiko, dass ein Modell das Verhalten einer Binärdatei errät, und erleichtert einem Sicherheitsteam die Prüfung des gesamten Ablaufs. Dennoch ist Vorsicht geboten. Die Laufzeiterfassung führt das gewählte Ziel mit Ihren Benutzerrechten aus oder interagiert damit; lesen Sie deshalb vorher die zugehörige Anleitung. Das Projekt betont außerdem, dass es für rechtmäßige Forschung im Reverse Engineering gedacht ist, dass Genehmigung und Rechtskonformität in der Verantwortung der Nutzer liegen und dass es keine Kryptowährung und keinen Token ausgegeben hat. Für Entwickler und Sicherheitsteams empfiehlt sich, es einmal an eigener Software zu erproben, zu prüfen, ob die Beweiskette der eigenen Kontrolle standhält, und erst dann zu entscheiden, ob es in den Arbeitsalltag gehört.