REA: MCP-Server für Reverse Engineering mit KI-Agenten

Hintergrund

Reverse Engineering gilt seit jeher als Handwerk mit hoher Einstiegshürde. Wer verstehen will, wie eine einzelne Funktion in einer Anwendung arbeitet, trifft oft gleichzeitig auf native Binärdateien, gebündeltes JavaScript, Electron-Apps, .NET-Assemblies und laufende Websites. Jede dieser Zielarten hat eine eigene Werkzeugkette. Üblicherweise wechseln Forschende zwischen Disassemblern wie Hopper, Ghidra und IDA, notieren Hinweise von Hand und fassen die Ergebnisse anschließend in Text zusammen.

Genau diesen Ablauf will REA ändern. Die Abkürzung steht für Reverse Engineer Anything. Es handelt sich um einen MCP-Server für Reverse Engineering, der speziell für KI-Agenten gebaut wurde. Das Projekt wird von morluto gepflegt, ist in TypeScript geschrieben und wird als npm-Paket rea-agents verteilt. REA will keinen neuen Dekompiler ersetzen. Es setzt auf vorhandene Analyse-Engines auf und gibt Agenten wie Claude Code, Codex, Cursor und Gemini CLI einen einheitlichen Zugang zu ihnen.

Zum Projekt gehören außerdem eine Website, Anleitungen, eine Fallsammlung, ein FAQ und Dokumente zum MCP-Vertrag. Das README liegt in mehr als zehn Sprachen vor. Eine Discord-Community bietet Raum für Fragen und für gezeigte Arbeiten.

Tiefenanalyse

Wie kann ein KI-Agent mit REA eine App ohne Quellcode analysieren? REA stellt native Binärdateien, JavaScript- und Electron-Apps, .NET-Assemblies und Websites über einen gemeinsamen MCP-Einstieg bereit. Der Agent ruft diesen Einstieg auf, und jedes Ergebnis kommt mit Belegen und einem Hinweis auf seine Grenzen zurück. Für native Ziele kann der Server ein installiertes Hopper, Ghidra oder IDA ansteuern. Die statische JavaScript-Analyse braucht dagegen keine native Engine. Drei Entwurfsentscheidungen fallen auf. Erstens dient derselbe Werkzeugsatz dem Agenten und dem Terminal. Entwickler können den Agenten einen ersten Durchlauf machen lassen und das Ergebnis danach selbst auf der Kommandozeile prüfen. Zweitens läuft die Analyse lokal. Drittens begegnet die Regel „Beleg und Grenzen“ einer bekannten Schwäche von Sprachmodellen: überzeugend klingenden, aber unbelegten Erklärungen. Wer das Ergebnis liest, kann den Belegen folgen, statt dem Modell nur zu glauben.

Die Einrichtung ist kurz. Mit installiertem Node.js und npm genügt der Befehl npx rea-agents setup. Danach wählt man die anzubindenden Agenten und prüft die Änderungen, die das Installationsprogramm auflistet. Es sichert vorhandene Konfigurationen, und anschließend startet man den Agenten neu. Laut README werden Claude Code, Codex, Cursor, Gemini CLI und Grok Build unterstützt; für andere Agenten gibt es separate Installationshinweise. Die Installation schreibt zudem passende Workflow-Anweisungen, damit der Agent weiß, in welcher Reihenfolge er die Werkzeuge einsetzt. Die Repository-Themen agent-skills, binary-analysis und decompiler deuten auf diesen Gedanken hin: Werkzeug und Arbeitsmethode werden gemeinsam geliefert. Unter Linux ist ein Detail wichtig. Für Ghidra, JADX, den Start von Firmware-Werkzeugen sowie die statische JavaScript- und Electron-Analyse braucht REA ein procps-kompatibles ps im PATH. Es dient dazu, die Prozesszugehörigkeit zu prüfen. Die Schritte zur Behebung stehen im passenden Abschnitt von docs/installation.md.

Branchenwirkung

Der typische Anwendungsfall ist einfach. In einer Desktop-App fällt eine Funktion auf, die man verstehen möchte. Man bittet den Agenten, sie mit REA zu untersuchen. Der Agent prüft die App ohne Quellcode, erklärt die Funktionsweise, nennt Belege und kann danach helfen, eine passende Umsetzung für das eigene Projekt zu schreiben. Damit rückt Reverse Engineering von der Spezialistenarbeit näher an einen Ablauf, bei dem ein Agent unterstützt.

Für unabhängige Entwickler und kleine Teams sinken damit die Kosten für Wettbewerbsanalysen, die Suche nach Kompatibilitätsproblemen und das Verständnis von Altsoftware. Für Sicherheitsforschende bedeutet die einheitliche MCP-Schnittstelle, dass sich die Stärken verschiedener Engines kombinieren lassen, statt isoliert zu bleiben.

Die Risiken sind real. Wer fremde Software analysiert, berührt Lizenz- und Rechtsfragen und muss Lizenzbedingungen und örtliches Recht selbst prüfen. Erklärungen des Agenten brauchen trotz beigefügter Belege eine menschliche Kontrolle, besonders wenn sie auf dekompiliertem Code beruhen. Die Qualität der nativen Analyse hängt außerdem vom Zustand von Hopper, Ghidra oder IDA ab. Schließlich warnt das README, dass sich solche Werkzeuge leicht nachahmen lassen. REA sollte nur von morluto/rea, rea.tools oder über das npm-Paket bezogen werden, denn ein Repository mit ähnlichem Namen ist kein Beweis für einen offiziellen Download.

Ausblick

Drei Punkte verdienen Aufmerksamkeit. Der erste ist die Abdeckung: Ob REA über die heute unterstützten vier Zielarten hinaus weitere Formate erschließt, bleibt offen. Der zweite ist das gemeinsame Wissen. Die Fallsammlung und der Ansatz mit agent-skills könnten zu einer wiederverwendbaren Methodenbibliothek wachsen, sofern Beitragende weiter erprobte Abläufe ergänzen.

Der dritte Punkt ist die Konvention selbst. REA verlangt, dass jedes Ergebnis Belege und Grenzen nennt. Übernehmen andere Agenten-Werkzeuge diese Gewohnheit, wird die Prüfung maschinell erzeugter Analysen branchenweit einfacher. Tun sie es nicht, bleibt REA ein nützliches, aber einzelnes Beispiel. Der praktische Test ist bescheiden. Man installiert REA mit npx rea-agents setup, richtet es auf eine App, die man bereits kennt, und prüft, ob die genannten Belege standhalten. Dieser Versuch zeigt schnell, wie weit man dem Werkzeug bei einer unbekannten App vertrauen kann. Letztlich entscheidet die Praxis. Wenn die Belege überprüfbar bleiben und die lokale Ausführung zuverlässig läuft, kann REA die Zeit bis zum ersten Verständnis einer fremden Anwendung deutlich verkürzen.