MCP

REA: App-Verhalten und native Binaries mit Agents reversen

REA eignet sich am besten, um Agents das Reverse Engineering von Anwendungsverhalten lokal durchführen zu lassen – von nativen Binaries über JavaScript- und Electron-Apps und .NET-Assemblies bis zu Websites; Voraussetzung ist die passende Node.js-Version samt npm, und man beachte: Statische Inspektion liest nur Dateien, während Runtime Capture das Ziel mit Ihren Benutzerrechten tatsächlich ausführt oder mit ihm interagiert.

Official source · REA

Install

npx rea-agents setup

Für wen es geeignet ist

REA ist für alle gedacht, die Reverse Engineering im Agent benötigen: Entwickler und Betreuer, die das Verhalten einer Anwendung verstehen oder native Binaries, JavaScript- und Electron-Apps, .NET-Assemblies sowie Websites untersuchen wollen; ebenso passend sind Betreuer von Electron-Desktop-Apps oder .NET-Diensten, die verstehen möchten, was ein Drittanbieter-Dependency oder ein historischer Build wirklich tut. Es bindet diese Inspektionswerkzeuge in Ihren Agent ein, dieselben Werkzeuge lassen sich auch direkt im Terminal nutzen, und die Analyse läuft lokal. Der Prüfmaßstab ist einfach: Wenn die Frage lautet „Was macht dieses Programm oder diese Datei wirklich?“ und die Antwort in Binaries, Build-Artefakten oder Laufzeitverhalten steckt, lohnt sich die Installation. Nicht geeignet, wenn das Ziel keine Datei oder Anwendung ist, zu deren Untersuchung Sie berechtigt sind; wenn die Umgebung die geforderte Node.js-Version nicht installieren kann; oder wenn Sie einen reinen Online-Scan-Dienst suchen, der lokale Dateien nie berührt.

Erster Versuch in 3 Minuten

Es gibt genau einen empfohlenen Hauptweg: Mit dem offiziellen Setup-Befehl den MCP-Server von REA registrieren und die passenden Anweisungen installieren, danach den Agent neu starten.

npx rea-agents setup

Voraussetzungen: Node.js 22.x (mindestens 22.19), 24.x (mindestens 24.11) oder 26+ sowie npm sind lokal installiert. Führen Sie den obigen Befehl im Terminal aus; er registriert den MCP-Server und installiert die passenden Nutzungshinweise. Schlägt die Anbindung fehl, prüfen Sie zuerst, ob Ihre Node.js-Version die genannten Anforderungen erfüllt.

Führen Sie nach dem Neustart einen risikoarmen Aufruf durch, um die Anbindung zu bestätigen: Bitten Sie den Agent, eine lokale JavaScript-Datei statisch zu inspizieren. Beschreiben Sie vor der Aktion deren Natur – offiziell ist dokumentiert, dass die statische JavaScript- und .NET-Inspektion nur die bereitgestellten Dateien liest und die Anwendung nicht ausführt; dieser Schritt startet das Zielprogramm also nicht. Beobachtbare Erfolgssignale: Der Setup-Befehl ist abgeschlossen, und der neu gestartete Agent kann Inspektionsergebnisse für die Datei liefern – die REA-Werkzeuge sind damit im Agent verfügbar. Offiziell sind weder die genauen Namen noch die Parameter der einzelnen Werkzeuge aufgelistet; maßgeblich ist, welche Werkzeuge der Agent nach dem Neustart registriert. Neben dem Aufruf über den Agent können Sie dieselben Werkzeuge auch direkt im Terminal nutzen – laut offizieller Dokumentation die sekundäre Verwendung.

Anwendungsfälle

Fall 1: Eine JavaScript-Datei verstehen, ohne sie auszuführen. Szenario: Sie erhalten eine gebündelte oder obfuszierte JS-Datei und wollen wissen, was sie tut, bevor Sie über die Ausführung entscheiden. Vorgehen: Übergeben Sie den Dateipfad an den Agent und lassen Sie ihn mit REAs statischer JavaScript-Inspektion analysieren. Erwartbares Ergebnis: Der Agent liest die Datei und liefert Analysebefunde, ohne diesen Code jemals auszuführen; für .NET-Assemblies gilt dasselbe, auch dort liest die statische Inspektion nur Dateien; statische Befunde und Laufzeitbeobachtungen können sich zudem gegenseitig bestätigen.

Fall 2: Laufzeitverhalten eines Ziels erfassen. Szenario: Die statische Analyse zeigt nichts, und Sie müssen beobachten, wie das Programm tatsächlich läuft. Prüfen Sie vor der Aktion zwingend die Nebenwirkungen: Offiziell wird Runtime Capture mit Ihren Benutzerrechten ausgeführt bzw. interagiert mit dem gewählten Ziel, und jeder Runtime-Guide beschreibt seine eigenen Effekte; erst nach Klärung von Ziel und Wirkung lassen Sie den Agent die Erfassung ausführen. Betrifft das Ziel echte Nutzerdaten oder eine Produktivumgebung, validieren Sie die Schritte zuerst auf einer isolierten Kopie. Erwartbares Ergebnis: Der Agent liefert Informationen zum Laufzeitverhalten des Ziels; was genau verändert wird, regelt der jeweilige Runtime-Guide.

Nutzungsgrenzen

Lesen und Schreiben unterscheiden: Die statische JavaScript- und .NET-Inspektion liest nur Dateien und führt keine Anwendung aus; Runtime Capture ist eine Operation mit realer Wirkung und führt das Ziel unter Ihren Benutzerrechten aus oder interagiert mit ihm. Für ein einheitliches Rückgängigmachen gibt es keine offiziellen Angaben – setzen Sie bei keinem Schritt voraus, dass er umkehrbar ist.

Zum Ort der Analyse: Offiziell analysiert REA Ziele lokal; dies beschreibt nur, wo die Analyse stattfindet, und ist keine Sicherheitsaussage – dieser Leitfaden trifft auch keine eigenständige Aussage über Datenflüsse oder Datenschutzgrenzen. Wo Analyseartefakte lokal liegen und wie man sie bereinigt, ist auf der offiziellen Seite nicht erklärt und bleibt unbelegt.

Nicht offiziell gelistete Informationen, die Sie vor dem Handeln selbst klären sollten: genaue Namen und Parameter der einzelnen Inspektionswerkzeuge, unterstützte Betriebssysteme und Agent-Clients, ob Konto-Zugangsdaten nötig sind sowie die konkreten Punkte jedes Runtime-Guides. Versionsanforderungen können sich mit dem Projekt ändern; vor dem Setup ist die aktuelle Angabe auf der offiziellen Seite maßgeblich.