REA (Reverse Engineer Anything): Wie Agenten Apps dekompilieren und neu aufbauen

REA (kurz für Reverse Engineer Anything) ist ein Open-Source-MCP-Server und CLI, der KI-Coding-Agenten echte Reverse-Engineering-Tools bereitstellt. Anstatt zu raten, wie eine Funktion funktioniert, kann Ihr Agent eine Binärdatei dekompilieren, den relevanten Code nachverfolgen und die Belege hinter jeder Schlussfolgerung aufzeigen – und dann eine Version für Ihr eigenes Projekt schreiben und testen. Dieser Leitfaden erklärt, was REA ist, wie es funktioniert, was analysiert werden kann und wie die Einrichtung erfolgt.

Was ist REA?

REA verbindet Ihren KI-Agenten mit Tools zur Untersuchung nativer Binärdateien, JavaScript- und Electron-Apps, .NET-Assemblies und Websites. Es verwendet das Model Context Protocol (MCP), damit ein Agent Analysen über einen lokalen Server anfordern, relevanten Code verfolgen und Ergebnisse mit ihren Belegen und angegebenen Einschränkungen zurückerhalten kann.

Das Kernversprechen: Eine Funktion entdecken, die Ihnen in einer App gefällt, verstehen, wie sie bis auf Binärebene funktioniert, und sie neu aufbauen. Sie bitten Ihren Agenten, eine Funktion mit REA zu untersuchen, und er kann die App ohne ihren Quellcode inspizieren, erklären, wie die Funktion funktioniert, die Belege aufzeigen und eine Version für Ihr Projekt erstellen.

Einige wichtige Fakten:

• Lizenz und Sprache: MIT-lizenziert und in TypeScript geschrieben, als rea-agents auf npm veröffentlicht.
• Standardmäßig lokal: Die Analyse läuft lokal, und die Ergebnisse enthalten die Belege und Einschränkungen hinter jeder Schlussfolgerung.
• Dynamik: Drittanbieter-Berichte beschreiben es als aktives Projekt, das im Oktober 2026 auf Platz 1 der GitHub-Trends stand, und das Repository verzeichnet zum Zeitpunkt der Erstellung über 125.000 Sterne.

Wie REA funktioniert

REA sitzt zwischen Ihrem Agenten und einer Reihe etablierter Analyse-Tools. Es verwendet das Model Context Protocol, damit Agenten Analysen über einen lokalen Server anfordern können. Der Agent bittet REA, ein Ziel zu inspizieren, verfolgt den relevanten Code und erhält strukturierte Ergebnisse zurück.

Der Arbeitsablauf lässt sich auf drei Schritte reduzieren: Dekompilieren, Verstehen, Nachbauen. Sie richten Ihren Agenten auf eine App aus, fragen, wie eine Funktion funktioniert, und REA ermöglicht es ihm, die Binärdatei zu dekompilieren, den Code zwischen Funktionen zu verfolgen und die Belege hinter seiner Erklärung aufzuzeigen.

Unter der Haube leitet REA Anfragen an das richtige Tool weiter. Wenn Sie Ihren Agenten bitten, eine App zu reverse engineeren, leitet der REA MCP die Anfrage an Tools wie Ghidra, Hopper oder IDA zur Dekompilierung weiter und kann auch Dinge wie Chrome DevTools zur Inspektion webbasierter oder Electron-ähnlicher Apps einbinden. Die Bibliothek übernimmt die Übersetzungsschicht, sodass der Agent nicht wissen muss, wie jedes Tool einzeln zu bedienen ist.

Das ist wichtig, weil Reverse Engineering normalerweise bedeutet, mehrere spezialisierte Tools zu jonglieren. Ghidra für die Dekompilierung, Hopper für die Disassemblierung, dynamische Tracer für das Laufzeitverhalten – jedes Tool hat seine eigene CLI, API-Oberfläche und Sitzungsverwaltung, und REA stellt alle über einen einzigen MCP-Server bereit, sodass Agenten koordinieren können, ohne toolspezifischen Zustand zu verwalten.

Dieselben Arbeitsabläufe sind auch über Ihr Terminal verfügbar, sodass Forscher, die Scripting bevorzugen, nicht an einen Agenten gebunden sind.

Was Sie analysieren können

REAs Abdeckung ist breit. Basierend auf der eigenen Fähigkeitstabelle des Projekts können Sie es auf Folgendes richten:

• Native Binärdateien – Pseudocode, Assembly, Strings, Symbole, Aufrufe und Referenzen (über Hopper, Ghidra oder IDA).
• JavaScript / Electron-Apps – Module, Importe, Source Maps, Routen, IPC- und Native-Add-on-Beziehungen, statisch inspiziert ohne Ausführung der App.
• .NET-Assemblies – Metadaten, CIL-Anweisungen und deklarierte native Abhängigkeiten (nur statisch, kein zusätzliches Engine erforderlich).
• Android APKs – Manifest-Deklarationen, Klassen, dekompilierte Methoden und Referenzen (über headless JADX und ein JDK).
• Websites – Seitenstruktur, Skripte, Netzwerkbeobachtungen und Screenshots (über einen Chrome-kompatiblen Browser).
• WASM, EVM-Bytecode, Go-Binärdateien, Firmware, gespeicherte Netzwerkaufzeichnungen und aufgezeichnete Linux-Abstürze – jeweils mit eigenen Anforderungen und Anleitungen.

Eine wichtige Designentscheidung: Statische JavaScript- und .NET-Inspektion liest die Dateien ohne Ausführung, während die Laufzeiterfassung das Ziel tatsächlich ausführt oder damit interagiert und dabei Ihre Berechtigungen verwendet. Native Analyse hängt von einem Provider ab – es steuert Ghidra, IDA Pro oder Hopper für native Binärdateien – sodass unterstützte Formate und Host-Unterstützung je nach installiertem Provider variieren.

Einrichtung

Die Einrichtung erfolgt mit einem einzigen Befehl. Mit einer unterstützten Node.js-Version und installiertem npm führen Sie aus:

npx rea-agents setup

Sie wählen Ihre Agenten, überprüfen die vorgeschlagenen Änderungen und genehmigen sie; das Setup fügt REAs MCP-Server und passende Workflow-Anweisungen hinzu, mit Sicherungskopien der bestehenden Konfiguration, dann starten Sie Ihren Agenten neu.

Das Setup unterstützt die wichtigsten Coding-Agenten. Zu den unterstützten Optionen gehören Claude Code, Cursor, Codex, Gemini CLI und Grok Build; andere Clients, die lokale MCP-Server unterstützen, können die manuelle Registrierung verwenden.

Für tiefgreifende native Arbeit benötigen Sie einen Provider. Native Analyse kann eine vorhandene Hopper-, Ghidra- oder IDA-Installation verwenden, während statische JavaScript-Analyse keine native Engine benötigt – laut Repository kann das Setup optional Hopper nach Ihrer Genehmigung installieren.

Sobald alles eingerichtet ist, fragen Sie in natürlicher Sprache – zum Beispiel: „Verstehe, wie die Suche in der Notizen-App funktioniert, zeig mir die Belege und baue eine ähnliche Funktion für mein Projekt" – und der Agent führt den gesamten Ablauf durch.

Ist die Nutzung legal?

Reverse Engineering bewegt sich in einem differenzierten rechtlichen Bereich, und REA stellt klar, dass es ein Tool für rechtmäßige Nutzung ist. Das Projekt beschreibt es als geeignet für Forschung, Bildung, Interoperabilität, Software-Erhaltung und die Analyse von Software, die Sie besitzen oder zur Untersuchung berechtigt sind. Es wird auch darauf hingewiesen, dass kommerzielle Engines wie IDA Pro, Hopper und JEB unter ihren eigenen Lizenzen legal erworben werden müssen – REA gewährt keine Tool-Lizenz oder Aktivierung. Behandeln Sie diese Bedingungen als erste Anlaufstelle, bevor Sie einen Agenten auf etwas richten, das Ihnen nicht gehört.

Warum das für KI-Workflows wichtig ist

REA ist Teil eines breiteren Musters: Agenten echte Tools und Belege zu geben, anstatt ein Modell aus dem Gedächtnis schlussfolgern zu lassen. Es ist dieselbe Entwicklung, die hinter Agenten-Laufzeiten wie DeepSeek Harness und zweckgebauten Entwickleroberflächen wie Cursor Origin steckt – der Wert liegt im strukturierten Tool-Zugang und der verifizierbaren Ausgabe, nicht nur im Modell.

Das „Belege zeigen"-Design ist der interessante Teil. Ein Agent, der die genaue Funktion, den Byte-Offset oder den IPC-Aufruf hinter einer Aussage zitieren kann, ist weitaus vertrauenswürdiger als einer, der eine Binärdatei aus dem Bauch heraus zusammenfasst.

Setzen Sie das mit Ihrer eigenen KI-Belegschaft um

REA zeigt, was Agenten leisten können, wenn man ihnen echte Tools gibt und verifizierbare Ergebnisse verlangt. Eigent wendet dieselbe Idee auf die alltägliche Arbeit an: eine Open-Source, lokale Multi-Agenten-„Cowork"-Belegschaft, die echte Aufgaben ausführt – Code und Pull Requests überprüfen, recherchieren und mehrstufige Workflows automatisieren – auf Ihrem eigenen Rechner. Wenn Sie Agenten wollen, die mit Tools handeln statt zu raten, laden Sie Eigent herunter und bauen Sie Ihre eigene Belegschaft auf.