Von Zahlen zu Wissen: Wie KI das Reverse Engineering demokratisiert – und was REA wirklich kann

Von DerSchneider

Einleitung: Der Kuchen ohne Rezept

Stellen Sie sich vor, Sie stehen vor einer verschlossenen Schachtel. Darin: eine Software, die Ihr Unternehmen seit Jahren am Laufen hält. Sie haben keinen Quellcode, keine Dokumentation, nicht einmal die Namen der Funktionen. Nur die ausführbare Datei – jene endlose Reihe von Zahlen, die ein Prozessor versteht, ein Mensch aber nicht mehr lesen kann.

Genau hier setzt eine Entwicklung an, die im Oktober 2026 die Softwarewelt in Aufruhr versetzte: KI-Agenten, die lernen, aus diesen Zahlen wieder zu verstehen, was ein Programm tut. Das bekannteste Werkzeug heißt REA – Reverse Engineer Anything. Innerhalb von sechs Tagen sprang das Projekt von weniger als 10.000 auf über 100.000 GitHub-Sterne, allein am 11. Oktober kamen über 31.000 hinzu . Die Versprechungen klingen revolutionär: „Jede App klonen, ohne eine Zeile Code zu sehen.“ Doch was steckt wirklich dahinter? Wo liegen die Grenzen? Und welche Möglichkeiten eröffnen sich für Ingenieure, Entwickler und Unternehmen, die verstehen wollen, wie Software wirklich funktioniert?

Dieser Artikel beleuchtet die technischen Grundlagen, die praktischen Anwendungen und die rechtlichen Grauzonen – und er zeigt, wie Sie selbst mit KI-gestütztem Reverse Engineering arbeiten können, ohne die Bodenhaftung zu verlieren.

Die technische Basis: Was beim Kompilieren verloren geht

Um zu verstehen, was KI beim Reverse Engineering leistet, muss man zunächst begreifen, was ein Compiler mit Code macht. Der Quellcode, den ein Entwickler schreibt, ist für Menschen optimiert: sprechende Variablennamen, Kommentare, klare Strukturen. Der Compiler übersetzt diese Absicht in Maschinencode – Befehle, die ein Prozessor ausführen kann. Dabei geht jedoch fast alles verloren, was die Absicht des Entwicklers transportierte: Namen, Kommentare, die logische Gliederung. Übrig bleibt eine Abfolge von Operationen, die zwar exakt dasselbe tut, aber ihre Herkunft verschweigt.

Traditionelles Reverse Engineering – etwa mit Ghidra, dem von der NSA entwickelten und 2019 kostenlos veröffentlichten Werkzeug – übersetzt diese Zahlen wieder in eine lesbare Form, genannt Pseudocode. Doch dieser Pseudocode sieht aus wie ein Rezept, in dem nur „Zutat 1, Zutat 2, Schritt 17″ steht. Ein menschlicher Experte musste bisher Stunden oder Tage investieren, um aus diesen Fragmenten eine kohärente Geschichte zu weben: Welche Funktion berechnet den Preis? Wo wird die Lizenz geprüft? Was passiert beim Klick auf „Exportieren“?

Genau hier setzt REA an. Es ist kein neuer Decompiler, kein Ersatz für Ghidra. REA ist ein Verbindungsstück – ein MCP-Server (Model Context Protocol), der einen KI-Agenten wie Claude Code, Codex oder Cursor mit den bestehenden Analysewerkzeugen verbindet . Der Agent kann Ghidra selbst bedienen, Fragen stellen, Hypothesen aufstellen und am Programm überprüfen. Er benennt Funktionen wieder, dokumentiert Beweise und sagt ausdrücklich, was er noch nicht weiß .

Die entscheidende Nuance: REA ist nicht der Ursprung dieser Fähigkeit. Bereits vor REA existierten MCP-Server für Ghidra, IDA Pro und radare2 – etwa GhidraMCP, IDA Pro MCP und radare2-mcp . REA bündelte diese Idee lediglich in ein benutzerfreundliches Paket und vermarktete sie geschickt. Der Entwickler selbst schreibt in der Readme, das Tool erhebe nicht den Anspruch, „Originalquellcode wiederherzustellen oder eine Anwendung automatisch zu klonen“ .

Was KI hier wirklich leistet – und was nicht

Die entscheidende Verschiebung liegt nicht in der Rechenleistung, sondern in der Automatisierung von Urteilsvermögen. Ein herkömmliches Skript kann eine Binärdatei disassemblieren. Ein KI-Agent kann eine Vermutung darüber anstellen, was eine Funktion tut, diese Vermutung durch gezielte Nachfragen bei Ghidra überprüfen, bei Widersprüchen die Annahme verwerfen und weitersuchen – eine Schleife, die einem menschlichen Experten nachempfunden ist, nur ohne Ermüdungserscheinungen.

In einem vielbeachteten Selbstversuch testete der Entwickler Korben REA mit Claude Code (Opus 5.5) und Ghidra an vier Aufgaben. Die Ergebnisse sind aufschlussreich – und ernüchternd zugleich:

Die letzte Zeile ist entscheidend für die Einordnung. Der Agent fand die Cheat-Codes zwar im Binary, aber seine Logs zeigten, dass er bereits vor der Analyse nach ihnen gesucht hatte – das vortrainierte Modell „kannte“ Wolfenstein 3D. Das ist keine Entdeckung, sondern Wiedererkennung. Für unbekannte, proprietäre Software fällt dieser Vorteil weg .

Noch ernüchternder ist das Kontrollexperiment: Dieselben vier Aufgaben wurden ohne REA durchgeführt, allein mit Claude Code, das Ghidra über selbstgeschriebene Java-Skripte steuerte. Das Ergebnis: Claude löste alle Aufgaben auch ohne REA . Die Schlussfolgerung des Testers: „REA macht nichts besser als ein Claude, dem man sagt, es soll Ghidra installieren und benutzen.“

Das relativiert die Hype-Welle, entkräftet aber nicht den grundsätzlichen Wandel. Denn die eigentliche Leistung liegt nicht in einem einzelnen Tool, sondern in der Senkung der Einstiegshürde. Wer früher Assembly lesen und Decompiler-Ausgaben interpretieren musste, kann heute in natürlicher Sprache fragen: „Warum ergibt 200 + 10% in diesem Taschenrechner 220?“ Und der Agent liefert nicht nur eine Antwort, sondern den Beweis aus dem Binary.

Die Bandbreite der Möglichkeiten: Von DX-Ball bis Firmware

REA ist nicht auf native Binärdateien beschränkt. Die dokumentierten Anwendungsfälle zeigen eine bemerkenswerte Spannbreite:

DX-Ball (altes Computerspiel): Eine Schallpanorama-Berechnung wurde aus dem x86-Code rekonstruiert. Der Nachbau bestand 3.205 Testfälle gegen das Original und reproduzierte nach dem Kompilieren exakt dieselben 63 Bytes Maschinencode . Das ist kein „ähnliches Verhalten“, sondern bitgenaue Übereinstimmung – der starke Beweis, dass die Rekonstruktion das Originalverhalten vollständig erfasst hat.

Notion (Electron-App): Der Zwischenablage-Mechanismus wurde durch Renderer, Preload-Schicht und Main-Prozess verfolgt. Bei Electron-Apps liegt der Code größtenteils als lesbarer JavaScript-Text vor – hier braucht REA nicht einmal Ghidra, der Agent ordnet den Text und folgt den IPC-Grenzen .

Amphetamine (macOS): Die Funktion „Mac wach halten, solange App X läuft“ wurde analysiert und in einem eigenen Swift-Tool nachgebaut. Der Agent erkannte, dass das Original eine System-Power-Assertion setzt und die Liste laufender Apps überwacht .

Firmware und eingebettete Systeme: Die REA-Ziel-Tabelle listet Firmware-Analyse über Binwalk oder Unblob (Linux), Android-APKs über JADX und adb sowie .NET-Assemblies ohne Zusatzwerkzeuge . Für Elektrotechniker und Embedded-Entwickler ist das potenziell der interessanteste Bereich – vorausgesetzt, die rechtlichen und ethischen Grundlagen stimmen.

Die gemeinsame Struktur dieser Erfolge: Es handelt sich um klar abgegrenzte, überprüfbare Verhaltensweisen. Ein einzelner Datenpfad, eine Berechnung, ein Mechanismus. „Baue die ganze App nach“ ist eine Demo, kein Arbeitsablauf.

Die Grenzen: Was KI nicht kann (und nicht dürfen sollte)

Technische Grenzen. REA holt nicht den Quellcode zurück. Es gibt keine magische Rückübersetzung, die Variablennamen wie rechnung_erstellen oder Kommentare wie „// Achtung: Rundungsfehler bei negativen Beträgen“ wiederherstellt. Diese Informationen sind beim Kompilieren unwiederbringlich verloren. Was REA liefert, ist eine eigene Rekonstruktion mit demselben Verhalten, verifiziert durch Tests – nicht durch Identität des Codes.

Zudem gibt es Grenzen bei der Zielplattform. Im Amphetamine-Test verweigerte REA die Analyse eines Universal-Binaries (Intel + ARM); der Agent musste den ARM-Teil selbst extrahieren . Bei großen Binärdateien können Startzeitüberschreitungen auftreten. Und bei hochsicheren geschützten Samples – etwa mit VMProtect virtualisiertem Code – stößt die statische Analyse grundsätzlich an ihre Grenzen. REA verfügt über keine dynamischen Debugging-Fähigkeiten und kann serverseitige Logik nicht analysieren.

Die entscheidende Einschränkung: Das Modellwissen. Der Wolfenstein-Test zeigt das Kernproblem: Wenn das KI-Modell die zu analysierende Software bereits aus seinem Training kennt, sind die Ergebnisse mit Vorsicht zu genießen. Der Agent „findet“ dann, was er bereits weiß. Für unbekannte, proprietäre oder gar obfuskierte Software fällt dieser Vorteil weg – und die eigentliche Herausforderung beginnt.

Die rechtliche Lage: Enger als der Hype vermuten lässt

§ 69e UrhG: Die Interoperabilitäts-Ausnahme und ihre Grenzen

In Deutschland schützt das Urheberrecht den Code eines Computerprogramms, nicht die Idee dahinter. Doch der Zugang zur Idee ist durch den Code versperrt – und genau hier greift § 69e UrhG. Der Gesetzestext ist präzise und restriktiv:

Die Zustimmung des Rechtsinhabers ist nicht erforderlich, wenn die Dekompilierung unerlässlich ist, um die erforderlichen Informationen zur Herstellung der Interoperabilität eines unabhängig geschaffenen Computerprogramms mit anderen Programmen zu erhalten – sofern drei Bedingungen erfüllt sind:

1. Die Handlungen werden von einem Lizenznehmer oder einer zur Nutzung berechtigten Person vorgenommen;
2. Die Informationen sind noch nicht ohne weiteres zugänglich;
3. Die Handlungen beschränken sich auf die Teile des Programms, die zur Interoperabilität notwendig sind .

Absatz 2 zieht die entscheidende Grenze: Die gewonnenen Informationen dürfen nicht verwendet werden für „die Entwicklung, Herstellung oder Vermarktung eines Programms mit im Wesentlichen ähnlicher Ausdrucksform“ oder für „irgendwelche anderen das Urheberrecht verletzenden Handlungen“ .

Das bedeutet konkret: Wer eine fremde Software analysiert, um eine eigene Version mit demselben Verhalten zu bauen, bewegt sich außerhalb des gesetzlichen Erlaubnistatbestands. Die Interoperabilitäts-Ausnahme erlaubt es, ein Programm mit einem anderen zusammenarbeiten zu lassen – nicht, es nachzubauen.

Vertragsrecht: Der oft übersehene Fallstrick

Doch das Urheberrecht ist nur die eine Seite. In der Praxis ist der erste Anknüpfungspunkt oft der Vertrag mit dem Softwareanbieter. Softwarelizenzen und SaaS-Vereinbarungen verbieten häufig ausdrücklich Reverse Engineering, Dekompilierung, die Entwicklung konkurrierender Produkte oder die Umgehung technischer Schutzmaßnahmen. Eine Handlung, die urheberrechtlich zulässig sein mag, kann dennoch eine Vertragsverletzung darstellen .

Besonders riskant: Viele Verträge enthalten Gewährleistungen und Freistellungsklauseln, die bei Verstößen greifen – und diese Verstöße sind häufig von Haftungsobergrenzen ausgenommen. Ein Reverse-Engineering-Versuch, der operativ unbedeutend erscheint, kann das Unternehmen einer unbegrenzten Haftung aussetzen .

Die Reaktion der Rechteinhaber: Von DMCA bis Memory-Sperre

Die rechtliche Theorie ist das eine – die Praxis zeigt, wie ernst die Industrie die Sache nimmt. Im Oktober 2026 ließen Rockstar, Activision und Bethesda Browser-Versionen ihrer Spiele, die mit KI-Unterstützung erstellt worden waren, per DMCA-Aufforderung entfernen. Betroffen waren unter anderem eine Browser-Adaption von Fallout („Fallout: New York“) und Berichte über GTA V, das auf einem iPhone lief .

Bemerkenswert ist die Risikoverteilung: Die rechtlichen Schritte trafen nicht die Tool-Entwickler, sondern die Endnutzer, die die Ergebnisse öffentlich zugänglich machten. REA und vergleichbare Tools sind durch Open-Source-Lizenzen und Haftungsausschlüsse abgesichert; die Verantwortung für die rechtmäßige Verwendung liegt beim Anwender .

Noch drastischer reagierte Riot Games: Ab dem 6. Oktober 2026 blockierte das Unternehmen den Speicherzugriff für alle unbekannten Drittanwendungen bei League of Legends, Teamfight Tactics und VALORANT. Die offizielle Begründung: „Fortschritte im KI-assistierten Reverse Engineering haben die Reihen potenzieller Hacker in einem untragbaren Tempo wachsen lassen“ . Riot geht es nicht um Urheberrecht, sondern um Cheat-Erkennung – aber die Maßnahme zeigt, wie tief die Angst vor KI-gestützter Analyse in der Industrie sitzt.

Die Grauzone: Was ist erlaubt?

Für Unternehmen und Entwickler ergibt sich eine klare Faustregel: Die Analyse der eigenen, selbst entwickelten Software – etwa um verlorenes Wissen zu rekonstruieren oder eine Modernisierung vorzubereiten – ist der sichere Hafen. Die Analyse von Software, für deren Untersuchung eine ausdrückliche Erlaubnis vorliegt, ist ebenfalls unproblematisch. Alles andere bewegt sich in einer Grauzone, die im Zweifel vor Gericht geklärt werden müsste – mit ungewissem Ausgang und erheblichem Kostenrisiko.

Das REA-Projekt selbst formuliert es in seiner Haftungsausschlusserklärung unmissverständlich: Das Werkzeug ist für rechtmäßige Forschung, Bildung, Interoperabilität, Software-Erhaltung und die Analyse von Software, die Ihnen gehört oder zu deren Untersuchung Sie berechtigt sind .

Praktische Anwendung: Wie man mit REA arbeitet

Die Installation

REA wird über npm distribuiert und setzt Node.js (Version 22.19 oder höher; Version 23 und 25 werden nicht unterstützt) voraus. Der Setup-Befehl npx rea-agents setup registriert den MCP-Server bei einem unterstützten KI-Assistenten und installiert die zugehörigen Anweisungen. Unterstützt werden Claude Code, Claude Desktop, Codex, Cursor, Gemini CLI, Windsurf und weitere. Der Assistent muss anschließend neu gestartet werden .

Für die Analyse nativer Binärdateien wird zusätzlich Ghidra 12.1 mit JDK 21 oder neuer, Hopper (kommerziell) oder IDA benötigt; JavaScript-, .NET- und Website-Analysen funktionieren ohne zusätzliche Engine. Ghidra unter Windows ist laut Dokumentation als „experimentell“ eingestuft .

Prompt-Beispiele für die Praxis

Die Qualität der Ergebnisse steht und fällt mit der Präzision der Frage. Vage Prompts führen zu vagen Zusammenfassungen. Die folgenden Beispiele orientieren sich an dokumentierten erfolgreichen Anwendungsfällen und der offiziellen Prompt-Bibliothek.

Beispiel 1: Eine konkrete Funktion verstehen (Electron/JavaScript)

text

Nutze REA, um die App unter /pfad/zur/app.asar zu analysieren.
Finde heraus, was passiert, wenn der Nutzer auf „Notizen exportieren" klickt:
Welche Nachricht wird gesendet, welcher Prozess verarbeitet sie,
wohin wird die Datei geschrieben und welche Felder enthält sie?
Zitiere für jeden Schritt die Datei und Zeile.

Dieser Prompt folgt dem Muster „Auslöser → Pfad → Beweis“. Er zwingt den Agenten, die Kette vom UI-Ereignis bis zum Dateisystem nachzuvollziehen und für jede Behauptung eine Quelle im Code zu nennen.

Beispiel 2: Eine Berechnung aus nativem Code rekonstruieren

text

Nutze REA mit Ghidra, um die Funktion zu finden, die in diesem Binary
den Prozentwert berechnet. Warum ergibt 200 + 10% den Wert 220?
Zeige den Pseudocode und die relevanten Assembly-Instruktionen.
Baue dann eine kleine, eigenständige Implementierung, die dasselbe tut,
und teste sie mit den Werten 100+5%, 50-10% und 200+10%.

Der letzte Satz ist entscheidend: Die Aufforderung, eine eigene Implementierung zu bauen und zu testen, stellt sicher, dass der Agent Verhalten beschreibt und rekonstruiert, nicht Code kopiert. Die Tests liefern den Beweis, dass die Rekonstruktion funktioniert.

Beispiel 3: Eine Firmware analysieren (für Elektrotechniker)

text

Nutze REA, um dieses Firmware-Image zu analysieren.
Identifiziere das Container-Format, extrahiere Partitionen und Dateisysteme,
ordne jede Region einer Architektur und Ladeadresse zu und lokalisiere
Kernel sowie RootFS. Liste Boot-Einträge, Init-Skripte und Dienste auf.
Zeige für jede Aussage den Offset und die Evidenz. Beginne mit statischer
Analyse; führe nichts aus und flashe nichts.

Dieser Prompt betont die statische Analyse und das explizite Verbot der Ausführung – ein wichtiger Sicherheitsanker bei unbekannter Firmware.

Beispiel 4: Die „sichere Nachbau“-Formel

text

Basierend auf deinen bisherigen Erkenntnissen über die Funktionsweise
dieser Software: Baue eine minimale, eigenständige Implementierung
derselben Kernlogik. Verwende keinen Code aus dem Original, keine
Strings, keine Assets. Der Code muss vollständig originär sein.
Beschreibe zuerst die Spezifikation, die du implementieren wirst,
dann den Code, dann die Tests, die zeigen, dass das Verhalten übereinstimmt.

Dieses Muster – erst Spezifikation, dann eigener Code, dann Verifikation – ist die dokumentierte Vorgehensweise für rechtlich einwandfreie Rekonstruktion. Der Ansatz entspricht dem „Clean Room“-Verfahren, das Compaq in den 1980er Jahren nutzte, um das IBM PC BIOS nachzubauen, ohne urheberrechtlich geschützten Code zu kopieren .

Der breitere Kontext: Was bedeutet das für Software und Gesellschaft?

Die Hype-Welle um REA ist Teil eines größeren Musters. Im Oktober 2026 überschwemmten Projekte die GitHub-Trending-Listen, die versprachen, proprietäre Software durch KI zu „befreien“. Ein Entwickler baute mit Claude eine funktionsfähige Alternative zur Adobe Creative Suite in Rust; ein anderer ließ GTA V auf einem iPhone laufen . Die Motivation war oft Frust über Abonnement-Modelle und geschlossene Ökosysteme.

Doch die langfristige Wirkung könnte anders aussehen als die kurzfristige Empörung. Client-seitiger Code war nie ein starker Schutz. Wer eine Desktop-App besitzt, kann sie analysieren – mit oder ohne KI. Die eigentlichen Wettbewerbsvorteile liegen woanders: in Daten, Nutzern, Cloud-Infrastruktur, Server-Logik, schneller Lieferung und Geschmack. Wenn KI die Analyse demokratisiert, verschiebt sich der Wert noch stärker von „geheimem Code“ zu „exzellenter Ausführung und Service“.

Gleichzeitig entsteht ein neues Risiko: Die Hürde für Missbrauch sinkt. Riot Games nennt in seiner Ankündigung explizit die Zunahme von Cheats und Bot-Farmen als Grund für die Speichersperre . Die Schutzmechanismen sind technisch schwach und rechtlich nachgelagert. Die einzige wirksame Barriere ist die ethische und rechtliche Rahmung, die das REA-Projekt selbst in seinen Lizenzbedingungen zieht – und die Bereitschaft der Nutzer, sich daran zu halten.

Für Ingenieure und Techniker bietet die Entwicklung jedoch eine positive Perspektive: Verstehen wird billiger. Ein Elektrotechniker, der die Firmware eines alten Industriegeräts analysieren muss, für das der Hersteller keinen Support mehr bietet, kann mit REA und einem KI-Agenten in Stunden erreichen, was früher Wochen der Handarbeit erforderte. Ein Entwickler, der verstehen will, wie eine Bibliothek intern funktioniert, kann den Agenten gezielt fragen, statt Stack-Traces zu raten. Das Werkzeug senkt die Kosten der Neugier – und Neugier ist die Grundlage technischen Fortschritts.

Fazit: Ein Werkzeug zum Verstehen, kein Freifahrtschein zum Kopieren

REA ist weder die Revolution, als die es gehypt wird, noch ein bloßer Hype. Es ist ein Beschleuniger für eine Entwicklung, die längst im Gange war: Die KI übernimmt die mühsame, mechanische Arbeit des Reverse Engineering – das Lesen von Pseudocode, das Verfolgen von Aufrufketten, das Testen von Hypothesen – und macht sie für Menschen ohne jahrelange Assembly-Erfahrung zugänglich.

Die technischen Beweise sind beeindruckend: 3.205 bestandene Testfälle und bitgenaue Rekonstruktion im DX-Ball-Fall zeigen, dass die Methode funktioniert, wenn das Ziel klar abgegrenzt und überprüfbar ist. Die Kontrollexperimente zeigen aber auch: Ein fähiger KI-Agent mit Ghidra kann dasselbe erreichen, wenn man ihn geschickt anleitet. REA ist eine Bequemlichkeitsschicht, kein neues Betriebssystem für Reverse Engineering.

Die rechtliche Lage in Deutschland ist eindeutig restriktiv: § 69e UrhG erlaubt Dekompilierung nur für Interoperabilität, unter engen Voraussetzungen, und verbietet ausdrücklich die Verwendung der Ergebnisse für den Nachbau ähnlicher Programme. Vertragsrechtliche Verbote kommen hinzu und können bei Verstößen zu unbegrenzter Haftung führen. Wer REA einsetzt, sollte mit der eigenen Software beginnen – oder mit Software, für deren Untersuchung eine ausdrückliche Erlaubnis vorliegt.

Und vielleicht ist das die wichtigste Erkenntnis: Die Demokratisierung des Verstehens ist ein Gewinn. Die Demokratisierung des Kopierens wäre ein Verlust. Die Grenze verläuft nicht im Code, sondern in der Absicht.

Quellen

1. Yahoo Tech: „From GTA V on iPhone to Free Photoshop: This AI Tool Is Upending Software“ (11. Oktober 2026)
2. Korben: „REA – I tested AI agent reverse engineering“ (13. Oktober 2026)
3. ENS Africa: „Reverse Engineer Anything: the legal risks and opportunities of AI-assisted reverse engineering“ (19. Oktober 2026)
4. § 69e UrhG – Dekompilierung, konsolidierte Fassung (Buzer.de) und Wolters Kluwer Online
5. Toutiao: „AI逆向工具6天暴涨10万星，扛雷的却是个人开发者？“ (12. Oktober 2026)
6. Riot Games Support: „Game Memory Access Removed for Third Party Apps“ (30. September 2026)
7. GitHub – plurigrid/asi: Reverse Engineering Skill (MCP-Server-Übersicht) (Dezember 2025)
8. Apidog: „What Is REA (Reverse Engineer Anything)? The MCP Server That Hit 115K GitHub Stars in a Week“ (11. Oktober 2026)
9. Korben (deutsch): „REA: Ich habe Reverse Engineering per KI-Agent getestet“ (13. Oktober 2026)
10. Yahoo Gaming: „Activision and Bethesda are going after vibe coders, sending cease-and-desist notes for AI recreations“ (2. Oktober 2026)