REA (Reverse Engineer Anything): Reverse-Engineering-Skills in Claude Code / Codex installieren und nutzen
REA ist morluto/rea auf GitHub: ein MIT-lizenzierter MCP-Server, eine CLI und eine reverse-engineer-anything-Agenten-Skill, mit denen Claude Code, Codex, Cursor und andere Clients Binaries, Electron-Apps, .NET-Assemblies, APKs und Websites untersuchen können — lokal und mit Evidence. Hier folgen die geprüfte Installation, die ersten Befehle und die Stelle, an der die rechtliche Grenze tatsächlich verläuft.
REA auf einen Blick
- Ein Projekt, drei Teile: Das npm-Paket `rea-agents` liefert die CLI `rea`, einen lokalen MCP-Server und die Skill `reverse-engineer-anything`, die dem Agenten sagt, welches Werkzeug zu welchem Ziel passt.
- Die Installation ist ein einziger geprüfter Befehl: `npx rea-agents setup` listet die genauen Konfigurationspfade, Backups und Skill-Ziele auf und wartet dann auf deine Zustimmung. Vorher wird nichts geschrieben.
- Claude Code, Codex und Cursor haben jeweils auch einen nativen Weg — zwei `/plugin`-Eingaben, zwei `codex plugin`-Befehle oder ein Plugin aus dem Cursor-Marketplace — und setup kann 28 Clients direkt konfigurieren.
- REA ist keine Sandbox und entscheidet nicht, was legal ist: Es läuft mit deinen Benutzerrechten auf Zielen, für deren Analyse du autorisiert sein musst, und der Disclaimer des Projekts listet auf, wobei es die Hilfe verweigert.
morluto/rea — README
Quelle: github.comchecked 2026-11-13
docs/getting-started/installation.md
Quelle: github.comchecked 2026-11-13
.agents/skills/reverse-engineer-anything/SKILL.md
Quelle: github.comchecked 2026-11-13
docs/getting-started/cli.md
Quelle: github.comchecked 2026-11-13
rea-agents — npm registry
Quelle: registry.npmjs.orgchecked 2026-11-13
DISCLAIMER.md + SECURITY.md
Quelle: github.comchecked 2026-11-13
dsh-rea — DeepSeek Harness directory
Quelle: deepseekharnessplugins.comchecked 2026-11-13
dsh-reverse-skill — DeepSeek Harness directory
Quelle: deepseekharnessplugins.comchecked 2026-11-13
Jeder Befehl, jede Client-ID, jede Version und jede Zahl auf dieser Seite wurde am 2026-11-13 aus den oben genannten Quellen gelesen: dem README des Repositorys, docs/getting-started/installation.md, der mitgelieferten SKILL.md, docs/getting-started/cli.md, DISCLAIMER.md und SECURITY.md sowie der npm-Registry. Die Repository-Daten stammen von der GitHub API vom selben Tag: 455,720 Stars, 111,916 Forks, erstellt am 2026-04-14; die neueste npm-Version `rea-agents` 6.9.0, veröffentlicht am 2026-11-12. Star-Zahlen ändern sich täglich, behandle sie also als datierten Schnappschuss. Diese Seite nennt überhaupt keine Leistungszahlen: In der geprüften README und Doku stehen keine Benchmark-Ergebnisse.
Was REA tatsächlich ist
REA steht für Reverse Engineer Anything. Es ist ein Open-Source-Projekt eines Drittanbieters von morluto, MIT-lizenziert, unter github.com/morluto/rea, mit der Website rea.tools. Es ist kein Produkt von Anthropic, OpenAI oder Cursor und kein Decompiler: Es ist die Schicht, die einen Coding-Agenten Decompiler und statische Parser steuern lässt und dann erklärt, was er gefunden hat.
Verteilt wird das npm-Paket `rea-agents`. Es stellt den Befehl `rea`, einen lokalen MCP-Server und die Skill `reverse-engineer-anything` bereit — ein Workflow-Dokument, das den Agenten anweist, das Ziel zuerst einzuordnen (ASAR/Electron, Archiv, APK, .NET, Firmware, native Binary, Browserseite, Capture) und jede Schlussfolgerung an Evidence zu binden. Die Analyse läuft auf deiner Maschine; der Agent erhält die Werkzeugergebnisse, und sein Modellanbieter wendet seine eigene Datenrichtlinie an.
Tiefe native Analyse heißt: Engine selbst mitbringen — Hopper, Ghidra, IDA oder Kuna. Setup kann Hopper nach einer separaten Zustimmung installieren und nutzt ein vorhandenes Ghidra, IDA oder Kuna weiter. Statische JavaScript/Electron- und .NET-Prüfung braucht überhaupt keine native Engine — deshalb ist ein erster Test an einer Electron-App der günstigste Weg herauszufinden, ob REA seinen Platz in deinem Workflow verdient.
- npm-Release
- rea-agents 6.9.0
- Lizenz
- MIT
- GitHub-Stars
- 455,720
- Repository erstellt
- 2026-04-14
Was es sich ansehen kann
Die Ziel-Tabelle im README hat 39 Zeilen; hier steht der Teil, der entscheidet, ob du es installierst. Die letzte Spalte nennt die Anforderung, die die Doku tatsächlich angibt — die meisten Zeilen brauchen nichts außer Node.js.
| Ziel | Was du zurückbekommst | Benötigt |
|---|---|---|
JavaScript / Electron | Module, Imports, source maps, Routen, IPC-Grenzen und native Add-ons — statisch, ohne die App auszuführen. | Node.js + npm (unter Linux ein `ps` aus procps) |
Native binaries | Pseudocode, Assembly, Strings, Symbole, Aufrufe und Querverweise. | Hopper, Ghidra, IDA oder Kuna |
.NET assemblies | Metadaten, CIL-Anweisungen, deklarierte native Abhängigkeiten, Build-Vergleiche. | Nichts weiter (nur statisch) |
Android APK | Manifest-Deklarationen, Klassen, dekompilierte Methoden und Referenzen; Fakten zu APK-Signaturen. | Headless-JADX + ein vollständiges JDK (für Signaturen ist nichts nötig) |
Websites / captures | Seitenstruktur, Skripte, Netzwerkbeobachtungen, angeforderte Screenshots; HAR- und SAZ-Captures. | Ein Browser aus der Chrome-Familie (Captures: HAR oder SAZ) |
Go / Rust / PE / WASM | Go-Build-Informationen, Rust-Crates aus cargo-auditable, PE-Imports und -Zertifikate, ELF-Notes, WASM, Hardening-Flags. | Nichts weiter (nur statisch) |
Archives / firmware | Mitgliederliste und Entpacken für ZIP/APK/IPA/MSIX/DMG, Godot PCK, UnityFS, wxapkg; Firmware-Regionen. | Binwalk oder Unblob unter Linux, für Firmware |
GGUF / safetensors | GGUF- und safetensors-Metadaten, Tensor-Deklarationen, optionaler Hash über die ganze Datei. | Nichts weiter (nur statisch) |
Release exposure | Ein Release-Exposure-Bericht mit stabilen Check-IDs, Status und Behebung: ausgelieferte source maps, Electron-fuses, Marker für Zugangsdaten. | Nichts weiter (nur statisch) |
Zwei Grenzen lohnt es, zweimal zu lesen. Statische Prüfung parst Dateien und führt das Ziel nicht aus; Laufzeit-Capture, Browserszenarien und Geräte-Workflows führen es dagegen aus oder interagieren damit, unter deinen Benutzerrechten. Und jedes Ergebnis trägt seine eigenen Einschränkungen und Unbekannten — die Doku sagt klar, dass ein sauberer Release-Exposure-Bericht nicht bedeutet, dass eine Anwendung sicher ist.
Installation: ein geprüfter Befehl, dann Routen pro Client
Setup ist standardmäßig interaktiv: Es listet die unterstützten Clients auf, zeigt die genauen Dateien, die es anfasst, samt Backups, und fragt vor dem Schreiben. Die npm-Download-Zustimmung und REAs eigene Zustimmung sind getrennte Abfragen — npm zu bestätigen heißt nicht, die Konfigurationsänderungen zu bestätigen.
1. Das geführte Setup — funktioniert für jeden unterstützten Client
Führe es mit Node.js und npm im PATH aus. Wähle Clients (bestehende REA-Registrierungen sind vorausgewählt, neu erkannte nicht), lies den Plan, stimme zu. Starte danach die in der Abschlussmeldung genannten Agenten vollständig neu: Ein laufender Client kann seine eigene Registrierung überschreiben. Für Skripte `--client <id>` ergänzen und mit `--dry-run --json` beginnen, um einen rein lesenden Plan zu bekommen.
Befehle
npx rea-agents setupnpx rea-agents setup --client claude_code --dry-run --json2. Claude Code: zwei /plugin-Eingaben, kein Setup-Lauf
REAs npm-Paket ist zugleich ein Claude-Code-Plugin. Füge das Repository als Marketplace hinzu und installiere dann `rea@rea`. Ein Plugin führt `rea setup` nicht aus, deshalb kommt die Provider-Konfiguration (Ghidra/IDA-Pfade) weiterhin aus den Abschnitten unten, und `rea doctor` meldet das Plugin als `missing` — prüfe es stattdessen mit `/plugin` und `/mcp`. Nutze für einen gegebenen Client entweder das Plugin oder eine Setup-Registrierung, nie beides, sonst starten zwei `rea`-Server.
Befehle
/plugin marketplace add morluto/rea/plugin install rea@rea3. Codex: dasselbe Plugin, zwei codex-Befehle
Dasselbe npm-Paket enthält ein `.codex-plugin`-Manifest. Füge den Marketplace hinzu und installiere dann `rea@rea`. Der Client braucht ein eigenständiges `node` im PATH. Wie bei Claude Code ist eine Plugin-Installation für `rea doctor` unsichtbar; prüfe sie mit `codex plugin list`.
Befehle
codex plugin marketplace add morluto/reacodex plugin add rea@rea4. Cursor: Setup-Registrierung oder das Marketplace-Plugin
`rea setup --client cursor` schreibt `~/.cursor/mcp.json` plus die von Setup verwaltete Skill. Cursors Marketplace listet das Repository außerdem als Plugin, das sowohl die Skill als auch einen `rea`-MCP-Server bündelt, der auf eine veröffentlichte Version festgelegt ist; dieser Weg ist ein Git-Checkout und legt `rea` nicht in den PATH. Nimm einen der beiden Wege, nicht beide.
Befehle
npx rea-agents setup --client cursor5. Nur die Skill — Anweisungen ohne Werkzeuge
Wenn du nur die Anweisungen willst, etwa um sie mit einem selbst registrierten MCP-Server zu kombinieren, installiere die Skill von skills.sh. Damit bekommt der Agent die Routing-Regeln und mitgelieferte Referenzen, aber es werden keine Werkzeuge registriert; REA-Aufrufe fehlen also, bis ein MCP-Server existiert.
Befehle
npx skills add morluto/rea --skill reverse-engineer-anything6. Prüfen, bevor du vertraust
`rea doctor` ist rein lesend. Prüfe einen Client, die installierte Skill und eine Engine getrennt: Ein Provider-Fehler blockiert keine zielunabhängigen Werkzeuge, und eine Client-Prüfung verifiziert die Registrierung, nicht eine erfolgreiche Untersuchung. Doctor liest Dateien und Voraussetzungen; es sieht die laufende Sitzung nicht, ein registrierter Server braucht also weiterhin einen Neustart oder ein Reconnect.
Befehle
rea doctor --client claude_code --jsonrea doctor --skill --jsonrea doctor --provider ghidra --jsonVoraussetzungen, wie dokumentiert
- 1Node.js 22.x (>= 22.23.4), 24.x (>= 24.22.1) oder 26.12.1+, plus das dazu passende npm. Node 23, 25, frühere 26.x-Releases und Prereleases werden nicht unterstützt.
- 2Ein Client, der lokale MCP-Server unterstützt. Setup kennt 28 Client-IDs, darunter claude_code, claude_desktop, codex, cursor, gemini_cli, windsurf, opencode, copilot_cli, antigravity, kimi, dsh und pi.
- 3Eine native Engine nur für native Arbeit. Statische JavaScript/Electron- und .NET-Analyse braucht nichts weiter; Android braucht Headless-JADX und ein JDK; Firmware braucht Binwalk oder Unblob unter Linux.
- 4Führe den Paketbezug aus einem vertrauenswürdigen Verzeichnis außerhalb des Zielprojekts aus und übergib Analysebefehlen absolute Pfade — ein Paket-Runner kann projektlokale Pakete auswählen, und REA kann nicht prüfen, was vor seinem Entrypoint passiert ist.
Eine erste Sitzung, die etwas beweist
Der günstigste ehrliche Test ist eine Funktion, die du schon verstehst, in einer App, die dir gehört, an einem Ziel ohne native Engine im Weg. Verlange die Evidence, nicht nur die Antwort: Der Sinn von REA ist, dass der Agent den Codepfad zeigen muss, den er behauptet.
Frag den Agenten
Das Beispiel aus dem README, wörtlich. Ersetze Notes durch dein Ziel und die Funktion durch etwas, das du von Hand verifizieren kannst. Erwarte, dass der Agent REA-Werkzeuge aufruft, die Evidence liest und die Teile benennt, die er nicht belegen konnte — antwortet er ohne Evidence, fehlen wahrscheinlich die MCP-Verbindung oder die Skill.
Prompt
Understand how search works in the Notes app, show me the evidence,and build a similar feature for my project.Oder treib die CLI selbst
Jeder MCP-Workflow hat ein CLI-Gegenstück, und das ist der schnellste Weg zu prüfen, ob eine Behauptung über REA stimmt. Der erste Befehl liefert einen Evidence-Datensatz für ein entpacktes Electron-Verzeichnis oder ein ASAR, ohne jede Engine; der zweite auditiert ein ausgeliefertes Artefakt und endet mit Exit-Code 3, wenn eine aufgedeckte Prüfung den von dir angegebenen Schweregrad erreicht.
Befehle
npx -y rea-agents@latest analyze-javascript-application /absolute/path/to/app --jsonrea audit-release-exposure ./dist/MyApp.app --fail_on high --jsonWarum die Ausgabe so groß ist — und was man dagegen tun kann
Echte Anwendungs-Evidence kann Hunderte Megabyte erreichen. Die dokumentierte Antwort ist, sie zu speichern und eine Sicht zu projizieren: `rea analyze-javascript-application … > app-evidence.json`, dann `rea inspect-analysis-view` mit einer Zusammenfassung oder einer Seite voller Module. Über MCP steuern `REA_MCP_MAX_RESPONSE_BYTES`, `REA_MCP_INPUT_SCHEMA_PROFILE=full` und `REA_MCP_OUTPUT_SCHEMA_PROFILE=compact`, wie viel davon das Modell sieht.
Aktualisieren und entfernen
`rea update` aktualisiert die globale npm- oder Bun-Installation, der die laufende CLI gehört; ein `npx`-Setup wird aufgefrischt, indem du `npx rea-agents@latest setup` erneut ausführst. `rea uninstall` entfernt nur REA-eigene Registrierungen und Skill-Dateien, `--purge-data` verwirft zusätzlich Cache und State, und keines von beiden fasst Hopper, Node.js, Evidence-Dateien oder fremde Skills an.
Befehle
rea updatenpx rea-agents@latest setuprea uninstallrea uninstall --purge-dataREA vs. Handarbeit vs. ein reines Instruktions-Skill-Paket
Der ehrliche Vergleich ist nicht REA gegen einen menschlichen Reverse Engineer. Er ist REA gegen denselben Agenten mit einer Shell und ohne Werkzeuge, und gegen Skill-Pakete, die Anweisungen, aber keinen Server mitbringen.
| Aspekt | Agent + Shell, ohne REA | Agent + REA |
|---|---|---|
| Werkzeug-Verdrahtung | Du fügst Befehle und Pfade in den Chat ein und das Modell rät, welches Decompiler-Flag zu nehmen ist. | Die Skill ordnet das Ziel einem Werkzeug mit Schema zu; der Server validiert Argumente und gibt strukturierte Evidence zurück. |
| Evidence | Was auch immer der Agent zitiert, ohne Aufzeichnung, aus welcher Datei oder welchem Offset es stammt. | Befunde tragen ihre Evidence und ihre Grenzen mit sich, und Unbekanntes bleibt aufgelistet, statt glattgebügelt zu werden. |
| Große Ausgabe | Ein 300 MB großer Dump sprengt entweder das Kontextfenster oder wird von `head` abgeschnitten. | Evidence wird gespeichert und projiziert — Zusammenfassung, Modulseite oder ein einzelnes Modul — bevor sie das Modell erreicht. |
| Reine Instruktions-Pakete | Ein Reverse-Engineering-Skill-Paket lehrt die Methode, registriert aber keine Werkzeuge, also ruft der Agent weiter die Shell auf. | REA liefert beide Hälften: die Skill und den MCP-Server/die CLI, die sie beschreibt. Skill-only-Installationen werden unterstützt, lassen aber die Werkzeuge fehlen. |
Rechtliche und sicherheitsbezogene Grenzen — vom Projekt, nicht hier erfunden
REAs eigene DISCLAIMER.md und SECURITY.md ziehen die Linie, und sie ist strenger, als es die Werbung rund um solche Werkzeuge üblicherweise ist. Die Kurzfassung: Software analysieren zu können heißt nicht, sie analysieren zu dürfen.
- Vorgesehene Verwendungen: Sicherheitsforschung, Malware- und Incident-Analyse, Schwachstellenforschung und koordinierte Offenlegung, CTFs und Ausbildung, Interoperabilität, Software-Erhaltung sowie die Prüfung von Software, die dir gehört oder die zu prüfen du autorisiert bist.
- Ausdrücklich nicht unterstützt: die Umgehung von DRM, Lizenzprüfungen, Anti-Cheat oder anderen technischen Schutzmaßnahmen; Spiel-Cheats oder Manipulation von Online-Diensten; das Umgehen von Authentifizierung oder Zugriffskontrollen, die zu testen du nicht autorisiert bist; das Kopieren proprietären Codes und proprietärer Assets; das Umgehen von Richtlinien der Modellanbieter.
- Die Autorisierung musst du selbst herstellen. Die öffentliche Verfügbarkeit einer Binary, der Besitz einer Datei oder der Zugang zu einem Debugging-Endpunkt erteilt für sich genommen keine Erlaubnis, und Reverse Engineering kann in deiner Jurisdiktion durch Gesetze oder durch die Lizenz der Software eingeschränkt sein.
- Kommerzielle Werkzeuge bleiben kommerziell: IDA Pro/Hex-Rays, Hopper und JEB müssen legal beschafft und lizenziert werden. REA stellt keinen Key, keine Lizenz und keine Aktivierung bereit, und gecrackte Kopien oder geteilte Keys sind nicht autorisiert.
Zwei weitere praktische Punkte aus SECURITY.md: REA ist keine Sandbox — CLI und MCP laufen mit den Rechten deines Accounts — und Zieldateien, Captures und Webseiten sind nicht vertrauenswürdige Daten, eine in eine Binary eingebettete Anweisung ist also keine Anweisung von dir. Nutze eine Wegwerf-VM oder einen Container für alles, was du nicht selbst gebaut hast, und richte Laufzeit-Workflows nie auf Systeme, die dir nicht gehören.
Vor der Installation: fünf ehrliche Einschränkungen
Nichts davon ist ein Grund, REA auszulassen; alles davon ist ein Grund, es zuerst an einem einzigen Ziel auszuprobieren.
- 1Es ist ein schnelllebiges Drittprojekt: npm ging innerhalb von drei Wochen von 6.8.0 auf 6.9.0, und die Doku warnt, dass eine von `main` installierte Skill Fähigkeiten beschreiben kann, die ein älteres npm-Release nicht hat. Vertraue der Werkzeugliste des verbundenen Servers, nicht dem Skill-Text.
- 2Die Client-Abdeckung ist breit, aber ungleich: Manche Client-IDs brauchen ein neueres rea-agents (droid, dsh, kimi, qoder, trae, workbuddy und zcode ab 6.5.0; freebuff ab 6.8.0), und `lm_studio` braucht ein Release nach 6.8.0.
- 3Setup schreibt in deine Agenten-Konfiguration und in Skill-Verzeichnisse. Es legt `.rea.backup`-Snapshots an und weigert sich, Dateien zu überschreiben, die es nicht verifizieren kann, aber es kann sich nicht mit einem anderen Schreiber abstimmen, der dieselbe Datei bearbeitet — beende den Client vorher, wie die Doku es verlangt.
- 4Die Engine-Einrichtung ist der Teil, der beißt. Hopper ist kommerziell mit eingeschränkter Demo, der automatische Installer deckt nur macOS und x86_64-Linux ab, und für andere Architekturen ist dokumentiert, Ghidra zu verwenden. Ohne Engine kann das Gesamt-`healthy` von doctor false sein; laut Doku ist das normal, solange der gewählte Workflow läuft, und es blockiert nur nativen Pseudocode.
- 5Kontext und Privatsphäre: Der Agent sieht die Evidence, also sieht dein Modellanbieter sie auch. Die Analyse ist lokal, die Ergebnisse sind es nicht — halte sensible Ziele auf einem lokalen Modell oder ganz aus dem Kreislauf heraus.
DeepSeek Harness und die benachbarten Skill-Pakete
REAs README erwähnt DeepSeek Harness nicht, aber das Paket kann sich dort registrieren: `dsh` ist eine der Client-IDs von Setup, und das DSH-Verzeichnis listet sowohl das REA-Projekt selbst als auch Community-Adapter. zhaofeng130/dsh-rea ist ein inoffizieller Adapter, der die Skill `reverse-engineer-anything` plus die Werkzeuge `rea` und `rea_doctor` registriert und REA ausdrücklich nicht mitliefert. dhicoc/dsh-reverse-skill ist noch etwas anderes: ein Port des reverse-skill-Pakets (87 SKILL.md-Dateien für Reverse Engineering, autorisiertes Pentesting und CTF) ohne REA-Abhängigkeit. Beide sind nicht mit morluto/rea verbunden — lies sie, bevor du sie installierst.