Wie man eine App mit Claude Code per Reverse Engineering analysiert

Reverse Engineering bedeutet, ein fertiges Stück Software zu untersuchen, um zu verstehen, wie es funktioniert, meist ohne den ursprünglichen Quellcode oder irgendwelche Entwurfsdokumente zu haben, die darin eingeflossen sind. Man schaut sich an, was es macht, wie es aufgebaut ist und mit was es kommuniziert, und arbeitet davon ausgehend rückwärts zu einem Modell seines Verhaltens.

Menschen tun das aus Gründen, die meist wenig glamourös und meist legitim sind. Sicherheitsforscher reverse-engineeren Programme, um eine Schwachstelle zu finden, bevor es jemand mit schlechteren Absichten tut. Entwickler reverse-engineeren Dateiformate und Netzwerkprotokolle, damit ein neues Programm mit einem alten zusammenarbeiten kann, das niemand für sie dokumentieren wird. Archivare und Hobbyisten reverse-engineeren alte Software, um sie am Laufen zu halten, wenn die ursprüngliche Hardware und das Unternehmen dahinter beide verschwunden sind. Und manchmal ist der Grund einfach, dass ein Programm, auf das man angewiesen ist, etwas Undokumentiertes tut, und man wissen muss, was, bevor man ihm vertrauen oder es umgehen kann.

Nichts davon ist neu. Sicherheitsforscher und Software-Archivare machen das seit Jahrzehnten mit Disassemblern und Debuggern, lange bevor es überhaupt KI-Agenten gab. Was sich geändert hat, ist die Geschwindigkeit: Ein Agent kann ein Disassembly-Listing oder eine dekompilierte Methode lesen und in Sekunden zusammenfassen, eine Arbeit, die eine erfahrene Person früher Stunden gekostet hätte. Das ist ein echter Fähigkeitsgewinn, und genau deshalb zählt die rechtliche und ethische Grenze später in diesem Leitfaden jetzt mehr, nicht weniger, da der Flaschenhals, der Menschen früher zwischen Neugier und Kopieren ausgebremst hat, größtenteils verschwunden ist.

Der Rest dieses Leitfadens ist konkret: Er geht ein Tool namens REA durch, das einen Agenten wie Claude Code mit dieser Art von Analyse verbindet, sowie die Gewohnheiten, die es sich lohnt, zu haben, bevor man es auf irgendetwas richtet.

Die Unterscheidung, die hier am wichtigsten ist, ist die zwischen dem Studieren der Funktionsweise und dem Kopieren der geschützten Ausdrucksform. Reverse Engineering, um eine Schnittstelle, ein Dateiformat oder ein Stück Verhalten zu lernen, ist rechtlich ein anderer Vorgang, als den Code oder die Assets einer anderen Person in ein eigenes Produkt zu übernehmen.

Die Praxis, die um diese Unterscheidung herum aufgebaut ist, heißt Clean-Room-Design. Eine Person oder eine Sitzung untersucht das Original und schreibt eine einfache Spezifikation dessen, was es macht: seine Schnittstellen, seine Datenformate, sein Verhalten, in eigenen Worten, ohne dass Originalcode in das Dokument kopiert wird. Eine separate Person oder Sitzung, die das Original nie gesehen hat, baut dann eine neue Implementierung ausschließlich aus dieser Spezifikation. Der Punkt ist, dass sich beim Endergebnis zeigen lässt, dass es aus einer schriftlichen Beschreibung stammt, nicht aus dem Originalwerk selbst.

Zwei ältere US-Gerichtsentscheidungen werden zu diesem Punkt oft zitiert, und es lohnt sich, sie zu kennen, obwohl keine von beiden eine allgemeine Erlaubnis ist, irgendetwas zu reverse-engineeren. Sega Enterprises Ltd. v. Accolade, Inc., 1992 vom Ninth Circuit entschieden, betraf ein Unternehmen, das das Sperrsystem einer Spielkonsole reverse-engineerte, damit seine eigenen Spiele auf dieser Konsole laufen konnten. Das Gericht entschied, dass das Zwischenkopieren, das bei diesem Reverse Engineering anfiel, um ungeschützte funktionale Elemente zu erreichen, die nötig waren, damit die Spiele überhaupt auf der Hardware liefen, auf den konkreten Umständen dieses Falls Fair Use war. Sony Computer Entertainment, Inc. v. Connectix Corp., 2000 vom selben Gericht entschieden, kam zu einem ähnlichen Schluss, als ein Unternehmen die Startsoftware einer Konsole reverse-engineerte, um einen Emulator für eine andere Art von Computer zu bauen, und behandelte auch dort das Kopieren auf dem Weg dorthin als Fair Use im Dienst eines unabhängig geschriebenen, interoperablen Produkts.

Behandle beide als historischen Kontext, nicht als Ratschlag für deine Situation. Es sind zwei konkrete Berufungsentscheidungen zu konkreten Umständen, Fair Use wird von Fall zu Fall entschieden, andere Länder ziehen diese Grenzen anders, und spätere Gesetze gegen die Umgehung von Kopierschutz schränken das bei Software mit DRM erheblich ein. Wer auf dieser Art von Arbeit aufbauen will, besonders bei allem, was ausgeliefert oder verkauft werden soll, sollte mit einem echten Anwalt sprechen, bevor er sich darauf verlässt.

REA zieht seine eigene Grenze unabhängig davon, was ein Gericht irgendwann über einen bestimmten Fall entscheiden könnte. Laut der DISCLAIMER.md des Projekts unterstützt REA es nicht und wird nicht dabei helfen, DRM, Lizenzprüfungen, Anti-Cheat-Systeme oder andere technische Schutzmaßnahmen zu umgehen, oder proprietäre Software oder ihren geschützten Code und ihre Assets zu kopieren, und das Projekt sagt unmissverständlich, dass die Analyseausgabe keine Rechte am Originalprogramm verleiht. Die praktische Regel, die daraus folgt: Analysiere nur Software, die dir gehört, die du selbst geschrieben hast oder die du anderweitig untersuchen darfst.

Die Node.js-Version spielt hier eine Rolle. REAs eigene README nennt die Anforderung genau so: Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) oder 26.12.1+, plus npm. Prüfe das gegen die aktuelle README, bevor du installierst, da sich diese Art von Anforderung zwischen Releases ändert.

Der Setup-Befehl ist npx rea-agents setup. Laut README führt er dich durch die Auswahl, bei welchen Agenten REA registriert werden soll, zeigt dir die vorgeschlagenen Änderungen, bevor du sie bestätigst, und behält Backups deiner bestehenden Konfiguration. Starte deinen Agenten anschließend neu, damit er den neuen MCP-Server übernimmt; REAs eigene Anleitung sagt das unmissverständlich.

Für eine dauerhafte Installation über die Kommandozeile statt eines einmaligen npx-Laufs beschreibt die README npm install --global rea-agents, gefolgt von rea --help, um zu sehen, was verfügbar ist. Bei einer globalen Installation bringt dich rea update nach deinem eigenen Zeitplan auf eine neue Version statt automatisch, und ein anschließendes npx rea-agents@latest setup aktualisiert die Agenten-Registrierung entsprechend.

Bevor du REA auf irgendetwas richtest, das dir nicht vollständig gehört, probiere es zuerst an einer winzigen Anwendung aus, die du selbst geschrieben hast. Sobald REA eingerichtet ist, bitte Claude Code, diese kleine App zu öffnen und Funktion für Funktion zu beschreiben, was es sieht, und vergleiche das mit dem, was du bereits weißt, selbst geschrieben zu haben. Diese eine Übung bestätigt, dass die Einrichtung tatsächlich funktioniert hat, und sie gibt dir ein Gefühl dafür, wie sich REAs Belege, eine Datei, eine Funktion, ein Aufruf, in der Praxis lesen, bevor du dich bei irgendetwas Wichtigem darauf verlässt.

Bring die Clean-Room-Idee von vorhin in eine konkrete Form mit zwei getrennten Claude-Code-Sitzungen. Die erste ist eine Spezifikationssitzung: Richte REA auf die Software, die du untersuchen darfst, und bitte den Agenten, eine Spezifikation in einfacher Sprache zu ihren Schnittstellen, ihren Datenformaten und dem Verhalten ihrer wichtigsten Funktionen zu schreiben, vollständig in eigenen Worten, ohne Originalcode oder Pseudocode wörtlich in das Dokument zu kopieren.

Die zweite ist eine Build-Sitzung, frisch gestartet, ohne Erinnerung an die erste. Gib ihr nur die Spezifikationsdatei, nichts anderes: nicht die Original-Binärdatei, nicht das Protokoll der ersten Sitzung, nicht REAs Rohausgabe. Bitte sie, eine neue, unabhängige Implementierung zu bauen, die die Spezifikation erfüllt, und dir zu sagen, wenn etwas in dieser Spezifikation unklar ist, statt still zu raten, was das ursprüngliche Programm gemacht haben muss.

Diese beiden als wirklich getrennte Sitzungen zu behandeln, nicht als zwei Phasen eines einzigen langen Gesprächs, ist der entscheidende Teil. Eine einzige Sitzung, die sowohl das Original studiert als auch den Ersatz geschrieben hat, hat genau die Grenze verwischt, die Clean-Room-Design scharf halten soll, da sich nachträglich nicht zeigen lässt, dass die zweite Hälfte sich nicht auf die erste gestützt hat.

Sei dir klar darüber, was dir das tatsächlich bringt. Ein disziplinierter Zwei-Sitzungs-Workflow ist eine Praxis, die ein späteres Clean-Room-Argument unterstützt, falls jemand jemals fragt, wie etwas gebaut wurde. Er ist für sich allein keine rechtliche Garantie und ersetzt nicht, einen echten Anwalt auf alles schauen zu lassen, was du ausliefern oder verkaufen willst.