Reverse Engineering mit Claude Code: REA für Analyse von Builds einrichten
Manche Antworten stecken nicht im Quellcode, sondern in fertigen Builds wie Electron-Apps, APKs oder nativen Binaries. REA ermöglicht es, mit Claude Code solche Artefakte agentenbasiert zu untersuchen und etwa Änderungen zwischen zwei Builds nachzuvollziehen.
Veröffentlicht am 26. Oktober • Zuerst erschienen auf mahmadmanzoor.com
Manchmal liegt die Antwort nicht in einem Quellrepository. Sie liegt in einem Build: der Electron-App, die letzten Monat ausgeliefert wurde, einer APK auf einem Testtelefon, einer nativen Binärdatei aus einem alten Release ohne Tag. Fragen wie "Wurden die Source Maps mit ausgeliefert?" oder "Was hat sich zwischen diesen beiden Builds geändert?" erfordern, dass jemand das Artefakt selbst öffnet.
REA, kurz für "reverse engineer anything", ist ein MCP-Server und eine CLI, die einem Coding-Agent die Werkzeuge für diese Aufgabe an die Hand geben. Seine README beschreibt es als Reverse Engineering mit Agents, "vom App-Verhalten bis hin zu nativen Binärdateien", und es läuft lokal. Ich habe es in Claude Code als MCP-Server namens rea registriert, zusammen mit seinem Skill reverse-engineer-anything. Dieser Beitrag behandelt das Setup, was das Tool analysieren kann, die Workflows, die ich bei Software einsetze, die mir gehört, sowie die Regeln, die ich mir auferlege.
morluto/rea: REA-Quellcode: MCP-Server und CLI für agentengetriebenes Reverse Engineering. MIT-Lizenz für Code, der von REA stammt.
Alles läuft auf deinem Rechner. Die schweren Analyse-Engines musst du selbst installieren.
REA besteht aus zwei Teilen, und die Skill-Datei stellt ausdrücklich klar, dass das eine nicht das andere impliziert. Der MCP-Server, auf npm als rea-agents veröffentlicht, stellt die Werkzeuge bereit. Der Skill ist ein Satz Anweisungen, der dem Agent beibringt, wann er REA einsetzen soll, welches Werkzeug er zuerst aufrufen soll und wie er Ergebnisse berichtet. Die Installation des Skills registriert nicht den Server, und die Registrierung des Servers installiert keine Analyse-Engines.
Der Skill sagt auch, wann man REA nicht einsetzen soll: Für die gewöhnliche Analyse eines vollständigen Quellrepositorys nutzt man normale Repository-Werkzeuge. Das deckt sich mit meiner Erfahrung. REA ist für ausgelieferte Artefakte und Laufzeitverhalten gedacht, nicht für das Lesen von Code, den man bereits hat.
Nutze nur die offiziellen Quellen. Die README warnt, dass ein ähnlicher Repository-Name oder eine kopierte README einen Download nicht offiziell machen, und nennt drei Quellen: das Repository morluto/rea, rea.tools und das npm-Paket rea-agents. Du benötigst Node.js 22.x (22.23.4 oder neuer), 24.x (24.22.1 oder neuer) oder 26.12.1 und neuer.
Der Probelauf gibt die Pfade aus, die er ändern würde, die Backups und den Skill, den er installieren würde, ohne irgendetwas zu schreiben.
npx -y rea-agents@latest setup --client claude_code --dry-run Enter fullscreen mode Exit fullscreen mode Anwendung Das Setup registriert den MCP-Server und installiert den Skill für den von dir genannten Client. Führe das einfache npx rea-agents setup aus, um Clients interaktiv auszuwählen.
npx rea-agents setup --client claude_code Enter fullscreen mode Exit fullscreen mode Bereitschaft prüfen Doctor meldet Registrierungs- und Skill-Status als JSON. Es kann nicht beweisen, dass der laufende Agent verbunden ist, deshalb starte Claude Code nach dem Setup neu.
npx rea-agents doctor --client claude_code --skill --json Enter fullscreen mode Exit fullscreen mode Oder von Hand registrieren, mit fixierter Version Die Installationsanleitung gibt einen manuellen Befehl mit fixierter Version an. Eine fixierte Version bedeutet, dass ein Upgrade eine Entscheidung ist und keine Überraschung.
claude mcp add --scope local rea -- npx -y rea-agents@6.7.0 mcp Enter fullscreen mode Exit fullscreen mode Meine eigene Registrierung ist die manuelle Form, fixiert auf die von mir installierte Version, mit einer Umgebungsvariablen, die REA auf meine Hopper-Installation verweist. Dein Pfad wird anders sein. Andere Engines verwenden ihre eigenen Variablen, etwa GHIDRA_INSTALL_DIR und JAVA_HOME.
REA: Reverse Engineering für deinen Coding-Agent: Die REA-Homepage: was das Tool macht und der Setup-Befehl in einer Zeile.
Die erste Regel des Skills lautet, nach Ziel zu routen: Man betrachtet, was der Nutzer geliefert hat, und wählt daraus das erste Werkzeug. Diese Übersicht behalte ich im Kopf.
Der erste Aufruf hängt vom Artefakt ab. Alles danach folgt den Beweisen.
Was ich an REA am meisten schätze, ist die Art der Berichterstattung. Jedes Werkzeug liefert einen Evidence-Eintrag mit einer ID, und der Skill weist den Agent an, zu trennen, was beobachtet wurde, was geschlossen wurde und was noch unbekannt ist. Eine dekompilierte Funktion ist eine Beobachtung des Analyseergebnisses, nicht der ursprüngliche Quellcode. Ein statisches Ergebnis beweist niemals, dass Code ausgeführt wurde.
Jede Aussage in der endgültigen Antwort sollte auf eine Evidence-ID verweisen.
Für breite Fragen verlangt der Skill ein Finding-Ledger: jede Schlussfolgerung verknüpft mit ihren Evidence-IDs, dem Beweistyp, der Suchgrenze und dem, was unbekannt bleibt. Auch für die Lücken gibt es Werkzeuge: record_unknown verfolgt eine offene Frage, und Vergleichswerkzeuge wie compare_artifacts, compare_functions und find_changed_behavior behandeln statische Unterschiede als Kandidaten, nicht als Beweis.
Grosse Bündel werden seitenweise aus einer einzigen, im Speicher behaltenen Analyse gelesen.
Das ist der Workflow, den ich am häufigsten nutze. Verweise den Agent auf das gepackte ASAR einer App, die du gebaut hast, und stelle eine enge Frage, etwa ob Source Maps oder ein Debug-Flag in die Produktion gelangt sind. Bei einer grossen App sagt der Skill, dass man Details anfordern soll: zuerst "summary", dann die zurückgegebene parent_evidence_id mit inspect_analysis_view nutzen, um durch Module zu blättern und ein Element nach dem anderen zu lesen, ohne die Analyse erneut auszuführen.
Nutze REA auf /Applications/MyApp.app/Contents/Resources/app.asar. Beginne mit einer Zusammenfassung. Wurden in diesem Build Source Maps oder.env-Dateien ausgeliefert? Liste jeden Befund mit seiner Evidence-ID und sage, was du nicht prüfen konntest. Enter fullscreen mode Exit fullscreen mode Dasselbe funktioniert aus der Shell, wenn ich den vollständigen Datensatz auf der Festplatte haben möchte statt im Kontext des Agents. Diese Befehle stammen aus dem Recovery-Leitfaden des Skills:
Passiv by Design. Du steuerst die App; REA zeichnet auf, was es sehen kann.
# ein separates Profil, Debugging-Port nur auf dem Loopback "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \ --remote-debugging-port = 9222 --user-data-dir = " $HOME /.rea-chrome" Enter fullscreen mode Exit fullscreen mode Nutze es nur, wo du dazu berechtigt bist
Reverse-Engineering-Werkzeuge sind dual-use, und ein Agent macht sie schneller, was die Tragweite erhöht. Die REA-README sagt, das Tool sei für rechtmässige Forschung, Bildung, Interoperabilität, Softwareerhaltung und die Analyse von Software bestimmt, die dir gehört oder die du untersuchen darfst, und dass geknackte Kopien, gestohlene Schlüssel, unbefugtes Weitergeben von Schlüsseln und Lizenzumgehungen nicht autorisiert sind. Ich lege darüber hinaus einige eigene Regeln fest:
Innerhalb dieser Grenzen ist REA das nützlichste Agent-Werkzeug, das ich in diesem Jahr für Fragen zu Builds statt zu Quellcode hinzugefügt habe. Es verwandelt "Ich glaube, die alte Version hat das gemacht" in eine Liste von Aussagen mit Belegen, und das ist die Art von Antwort, mit der ich arbeiten kann.
REA-Installationsanleitung: Setup pro Client, Doctor-Prüfungen, manuelle MCP-Registrierung und Engine-Umgebungsvariablen.
Zuerst veröffentlicht auf meiner Website. Weitere Beiträge und Projekte unter mahmadmanzoor.com.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 26 • Originally published at mahmadmanzoor.com
Sometimes the answer is not in a source repository. It is in a build: the Electron app that went out last month, an APK on a test phone, a native binary from an old release with no tag. Questions like "did the source maps ship?" or "what changed between these two builds?" need someone to open the artifact itself.
REA, short for "reverse engineer anything", is an MCP server and CLI that gives a coding agent the tools for that job. Its README describes it as reverse engineering with agents, "from app behavior down to native binaries", and it runs locally. I have it registered in Claude Code as an MCP server named rea, alongside its skill, reverse-engineer-anything. This post covers the setup, what it can analyse, the workflows I use on software I own, and the rules I keep.
morluto/rea: REA source: MCP server and CLI for agent-driven reverse engineering. MIT licence for REA-authored code.
Everything runs on your machine. The heavy engines are yours to install.
REA comes in two parts, and the skill file is explicit that one does not imply the other. The MCP server, published on npm as rea-agents, provides the tools. The skill is a set of instructions that teaches the agent when to use REA, which tool to call first, and how to report results. Installing the skill does not register the server, and registering the server does not install analysis engines.
The skill also says when not to use REA: for ordinary analysis of a complete source repository, use normal repository tools. That matches my experience. REA is for shipped artifacts and runtime behaviour, not for reading code you already have.
Use the official sources only. The README warns that a similar repository name or a copied README does not make a download official, and lists three: the morluto/rea repository, rea.tools and the rea-agents npm package. You need Node.js 22.x (22.23.4 or later), 24.x (24.22.1 or later) or 26.12.1 and later.
The dry run prints the paths it would change, the backups and the skill it would install, without writing anything.
npx -y rea-agents@latest setup --client claude_code --dry-run Enter fullscreen mode Exit fullscreen mode Apply it Setup registers the MCP server and installs the skill for the client you name. Run the plain npx rea-agents setup to pick clients interactively.
npx rea-agents setup --client claude_code Enter fullscreen mode Exit fullscreen mode Check readiness Doctor reports registration and skill state as JSON. It cannot prove the running agent is connected, so restart Claude Code after setup.
npx rea-agents doctor --client claude_code --skill --json Enter fullscreen mode Exit fullscreen mode Or register it by hand, pinned The installation guide gives a manual command with a pinned version. Pinning means an upgrade is a decision, not a surprise.
claude mcp add --scope local rea -- npx -y rea-agents@6.7.0 mcp Enter fullscreen mode Exit fullscreen mode My own registration is the manual form, pinned to the version I installed, with one environment variable that points REA at my Hopper install. Your path will differ. Other engines use their own variables, such as GHIDRA_INSTALL_DIR and JAVA_HOME.
REA: Reverse Engineering for Your Coding Agent: The REA homepage: what it does and the one-line setup command.
The skill’s first rule is to route by target: look at what the user supplied, and pick the first tool from that. This is the map I keep in my head.
The first call depends on the artifact. Everything after it follows the evidence.
What I like most about REA is how it reports. Every tool returns an Evidence record with an ID, and the skill tells the agent to separate what was observed from what was inferred and what is still unknown. A decompiled function is an observation of analysis output, not original source. A static result never proves that code ran.
Every claim in the final answer should point back at an Evidence ID.
For broad questions the skill asks for a finding ledger: each conclusion linked to its Evidence IDs, the evidence type, the search boundary and what remains unknown. There are tools for the gaps too: record_unknown tracks an open question, and comparison tools like compare_artifacts, compare_functions and find_changed_behavior treat static differences as candidates, not proof.
Large bundles are read in pages from one retained analysis.
This is the workflow I use most. Point the agent at the packaged ASAR of an app you built and ask a narrow question, such as whether source maps or a debug flag made it into production. For a big app, the skill says to request detail: "summary" first, then use the returned parent_evidence_id with inspect_analysis_view to page through modules and read one item at a time, without running the analysis again.
Use REA on /Applications/MyApp.app/Contents/Resources/app.asar. Start with a summary. Did any source maps or.env files ship in this build? List each finding with its Evidence ID and say what you could not check. Enter fullscreen mode Exit fullscreen mode The same works from the shell when I want the full record on disk instead of in the agent’s context. These commands come from the skill’s recovery guide:
Passive by design. You drive the app; REA records what it can see.
# a separate profile, debugging port on loopback only "/Applications/Google Chrome.app/Contents/MacOS/Google Chrome" \ --remote-debugging-port = 9222 --user-data-dir = " $HOME /.rea-chrome" Enter fullscreen mode Exit fullscreen mode Use it only where you are allowed to
Reverse engineering tools are dual-use, and an agent makes them faster, which raises the stakes. The REA README says it is for lawful research, education, interoperability, software preservation and analysis of software you own or are authorised to examine, and that cracked copies, stolen keys, unauthorised key sharing and licence bypasses are not authorised. I keep a few rules of my own on top:
Inside those lines, REA is the most useful agent tool I have added this year for questions about builds rather than source. It turns "I think the old version did this" into a list of claims with evidence, which is the kind of answer I can act on.
REA installation guide: Setup per client, doctor checks, manual MCP registration and engine environment variables.
Originally published on my site. More posts and projects at mahmadmanzoor.com.