REA Untersucht: Wie AI-gestützte Reverse Engineering funktioniert

Was ist REA – und warum wird es beachtet?

Sie können eine Anwendung täglich nutzen, ohne zu wissen, wie ihre Funktionen im Hintergrund funktionieren. REA gibt AI-Assistenten die Möglichkeit, dieses Verhalten zu untersuchen – selbst wenn der ursprüngliche Quellcode nicht verfügbar ist.

REA (Reverse Engineer Anything) ist das Open-Source-Projekt unter morluto/rea, das AI-Agenten mit Software-Analyse-Workflows verbindet. Es stellt Analysevorgänge über eine Befehlszeilenschnittstelle – eingegebene Terminalbefehle – und einen Tool-Server für kompatible AI-Anwendungen bereit. Ein Agent ist eine AI-Anwendung, die Tools über mehrere Schritte hinweg nutzen kann. REA bietet Zugriff auf Analyse-Tools, nicht auf das zugrunde liegende AI-Modell.

Die Unterscheidung ist wichtig: Eine fertige Anwendung zu untersuchen, eine ähnliche Implementierung zu schreiben und ihren ursprünglichen Quellcode wiederherzustellen sind unterschiedliche Leistungen. Die Nützlichkeit von REA hängt von den gesammelten Beweisen, den angewendeten Überprüfungen und den verbleibenden Verantwortungen ab. „Anything” ist der Name des Projekts, keine Garantie, dass jedes Produkt originalgetreu nachgebildet werden kann.

Reverse Engineering: Lernen vom fertigen Programm

Reverse Engineering bedeutet, zu lernen, wie etwas funktioniert, indem man das fertige Ergebnis untersucht. Stellen Sie sich eine Maschine ohne ihre ursprünglichen Konstruktionszeichnungen vor: Das Inspizieren ihrer Teile und ihres Verhaltens kann eine neue Konstruktion unterstützen, gibt Ihnen aber nicht die ursprünglichen Zeichnungen des Designers. Ebenso ermöglicht das Verständnis des Verhaltens von Software nicht, den Quellcode wiederherzustellen, den die Entwickler geschrieben haben.

Für eine native ausführbare Datei, die prozessorfertige Form eines Programms, übersetzt ein Compiler Quellcode in Maschinenbefehl. Dies sind Operationen, die der Prozessor versteht. Die Kompilierung kann das Programm auch optimieren, indem sie Arbeiten neu anordnet oder kombiniert, während das beabsichtigte Verhalten erhalten bleibt. Das Ergebnis ist ausführbare Software, keine komprimierte Kopie des Quellprojekts.

Disassembly präsentiert Maschinenbefehle als lesbare Assembly. Dekompilierung geht weiter und leitet höherwertige, quellähnliche Logik namens Pseudocode ab. Tools wie Ghidra bieten beide Ansichten:

1) Forward production path:
Original source
       ↓
Compile / optimize
       ↓
Native executable

2) Separate analysis path:
Native executable
       ↓
Disassembly / decompilation
       ↓
Assembly / inferred pseudocode
  Original names, comments and structure may be missing
       ↓
Behavior to verify

Native-Code-Fall: Die Kompilierung erzeugt die ausführbare Datei; die Analyse leitet eine lesbare Ansicht und ein Verhalten ab, um es zu überprüfen. Es gibt keinen garantierten umgekehrten Weg zu den ursprünglichen Quelldateien.

Der Informationsverlust ist ungleichmäßig. Kommentare und viele Namen können verschwinden, während Textzeichenfolgen, einige Namen und beschreibende Metadaten erhalten bleiben. Die Optimierung kann vertraute Quellstrukturen schwer erkennbar machen. Verschiedene Quellimplementierungen können auch ähnliches Maschinenverhalten erzeugen, daher muss eine plausible Rekonstruktion nicht dem ursprünglichen Ausdruck des Programmierers entsprechen.

Nicht jede Anwendung ist nativer Maschinencode. Gepacktes JavaScript kann lesbaren Quellcode oder minimierten Code enthalten, der für die Verteilung gekürzt ist. Das Lesen von quellähnlichem Material, das bereits in einem Paket vorhanden ist, unterscheidet sich vom Ableiten von Pseudocode aus Maschinenbefehlen. Was übrig bleibt, bestimmt, welche Fragen die Analyse beantworten kann.

Wie REA eine Frage in eine Evidence Loop verwandelt

Die DX-Ball Untersuchung des Projekts begann mit einer praktischen Frage: Wie bestimmt die horizontale Bildschirmposition eines Steins die Sound-Panoramierung, das Gleichgewicht zwischen linkem und rechtem Audio? Die erste Decompiler-Ansicht zeigte einen Aufruf, der eine Zahl konvertierte, ließ aber die Eingabe und die dahinter stehende Berechnung aus. Es reichte nicht aus, um die Position des Sounds zu erklären.

Die Instruction-Ansicht offenbarte die fehlende Eingabe und Arithmetik. Die Überprüfung der Funktion, die sie aufgerufen hatte, zeigte, dass die Eingabe die Bildschirmkoordinate des Steins war. Das Lesen der gespeicherten Werte lieferte die festen Zahlen der Berechnung und die Einstellung, die die Panoramierung skalierte.

Das Ergebnis war eine konkrete Regel: Bei der üblichen Skalierung wird die Bildschirmmitte auf zentrierte Panoramierung abgebildet, während Positionen auf beiden Seiten das Gleichgewicht nach links oder rechts verschieben. Das Rekonstruktionsprojekt konnte diese Regel dann in C schreiben und mit der ursprünglichen Funktion vergleichen.

Vier Rollen machen diese Untersuchung möglich.

• Sie legen die autorisierte Frage fest.
• Der Agent wählt Folgefragen und interpretiert Ergebnisse.
• REA bietet Werkzeugzugriff und gibt Evidence zurück.
• Eine Analyse-Engine oder ein Parser inspiziert das Zielartefakt – die Datei oder das Paket, das untersucht wird.

Native Engines umfassen Ghidra, Hopper und IDA.

Die Verbindung nutzt Model Context Protocol (MCP), einen Standard für AI-Anwendungen, um auf externe Tools und Systeme zuzugreifen. REA’s MCP Server ist die Software, die diese Operationen bereitstellt, nicht eine Maschine, die Sie mieten müssen. Ein Skill liefert Untersuchungsanweisungen für den Agent; der Server bietet Zugriff auf die Operationen selbst. Der Kernaustauch sieht so aus:

Your feature question
         ↓
Agent
         ↕ MCP
REA tool server
         ↕
Analysis engine / parser
         ↕
Target software

Anfragen reisen zum Ziel; Evidence kehrt zum Agent zurück, der damit die nächste Frage wählt. Der Austausch wiederholt sich, während die Untersuchung voranschreitet.

Der Agent koordiniert diese Folgefragen und verbindet den zurückgegebenen Code und die Referenzen zu einer Erklärung. Evidence-Datensätze identifizieren die Datei- und Code-Positionen und trennen Beobachtungen von Schlussfolgerungen und ungelösten Erkenntnissen. Ein Reviewer kann daher die Erklärung auf ihr unterstützendes Material zurückführen. Der Agent kann auch Kandidaten-Code und Tests als separaten Schritt vom Feststellen dessen, was das Original tut, entwerfen.

Für jedes Ziel unterscheiden Sie statische Inspektion, die Artefakte liest, ohne das Programm auszuführen, von Laufzeitbeobachtung oder Interaktion, die es während der Ausführung untersucht. Wo diese Inspektion stattfindet, ist auch getrennt davon, wo das Modell seine Erkenntnisse verarbeitet. Wenn der Agent ein gehostetes Modell verwendet, können zurückgegebene Ergebnisse die Analysemaschine verlassen.

Welche Arten von Software kann REA inspizieren?

Die Sichtbarkeit hängt vom Ziel ab. Electron verpackt Desktop-Software mit Web-Technologien, während .NET und Android unterschiedliche Anwendungsfamilien mit verschiedenen Analysepfaden darstellen. Jede offenbart unterschiedliche Informationen, wie die Tabelle zeigt:

REA dokumentiert eine breitere Artefaktabdeckung über diese Kategorien hinaus. Überprüfen Sie die offizielle Zielübersicht und aktuelle Dokumentation: Die Anforderungen variieren je nach Engine, Host-Plattform, Ziel und Version. Diese beschreiben verfügbare Inspektions-Workflows, keine verifizierten Rekonstruktionen jedes Ziels.

Eine überzeugende Demo ist keine verifizierte Rekonstruktion

Öffentliche Demonstrationen vermitteln ein konkreteres Bild davon, was REA leisten kann. Bei einer online geteilten Rechner-Rekonstruktion erzeugte AI-gestützte Analyse eine Python-Version von GNOME Calculator. Neben sichtbaren Rekonstruktionen wie dieser vergleichen engere Projekte einen neu erstellten Rechner direkt mit dem Original.

Öffentliche Demonstration — aus zweiter Hand berichtet
Die Rekonstruktion ähnelte GNOME Calculator und stimmte mit einem grundlegenden Rechenergebnis überein. Gemeldete Größenänderungsprobleme offenbarten einen sichtbaren Unterschied, den eine erfolgreiche Rechnerprüfung nicht erfassen würde.

Von Projekten gemeldete Funktionsrekonstruktion
Das DX-Ball Showcase berichtet von 3.205 Vergleichsfällen mit Original-x86 für eine Position-zu-Sound-Pan-Funktion sowie übereinstimmenden kompilierten Bytes mit einem historischen Compiler.

Der Rechner demonstriert eine sichtbare Rekonstruktion; DX-Ball dokumentiert Prüfungen einer spezifischen Berechnung. Jedes Ergebnis beantwortet eine andere Frage.

Bei DX-Ball umfassten die Vergleiche Bildschirmpositionen und mehrere Panning-Stärken. Sie überprüften die Rückgabewerte der C-Funktion gegen die aus der Ausführung der ursprünglichen Anweisungen. Das Kompilieren dieses C mit einem historischen Compiler reproduzierte auch die Bytes der Funktion. Dies sind zwei unterschiedliche Prüfungen: Übereinstimmung bei getesteten Ausgaben und Übereinstimmung bei der kompilierten Funktion, ohne dass der ursprüngliche Quelltext des Programmierers erforderlich ist.

GNOME Calculator hat auch erweiterte, finanzielle und Programmierfunktionen. Der einfache Rechnervergleich lässt diese Funktionen unbewertet, anstatt zu zeigen, ob sie in der Rekonstruktion funktionieren oder nicht. Der Quellcode ist öffentlich, daher kann eine Quellcodeüberprüfung der direktere Ausgangspunkt sein, wenn sie Ihre Wartungsfrage beantwortet. Der sinnvolle Fortschritt verläuft von visueller Ähnlichkeit zu ausgewählten Verhaltensüberprüfungen, dann zu systematischen Vergleichen für das Verhalten, das Sie benötigen.

Wo das “Alles”-Versprechen an seine Grenzen stößt

Fehlender Quellkontext kann eine Komponente schwer interpretierbar machen. Optimierung kann ihre Logik verschleiern, während Obfuskation Code absichtlich schwerer verständlich macht. Externe Abhängigkeiten schaffen eine weitere Lücke: Einige Ausführungspfade benötigen Eingaben, Services oder Bedingungen, die während der Untersuchung nicht verfügbar sind. Selbst sorgfältige Analyse kann Grenzfälle ungelöst lassen, wenn eine Funktion auf Verhalten außerhalb der inspektierten Komponente angewiesen ist.

Ein unabhängiges Gegengewicht kommt von Ishank Choudharys Bericht vom 14. Oktober 2026, der REA 6.4.0 behandelt. Er fand nützliche Electron-Anwendungsstruktur, verpasste aber Preload-Verbindungen: den Bridge-Code, der eine Electron-Seite mit Desktop-seitigen Funktionen verbindet. Er testete statische Tools ohne Agent oder native Analyse-Engines; die Erkenntnisse betreffen diese Version und diesen Workflow, nicht jede aktuelle Version.

Der Bericht beschrieb auch Beziehungen, die aus der Anwendungszusammenfassung aufgrund von Ergebnis-Budgets weggelassen wurden – Grenzen für beibehaltene Ausgaben. Einige Fakten blieben auf Dateiebene, ohne dass ihre Verbindungen in der Zusammenfassung erschienen. Ein abgeschlossener Scan ohne Treffer bedeutete daher, dass die beibehaltene Analyse die Beziehung nicht gefunden hatte, nicht dass die Funktion fehlte. Seine Abdeckungsgrenzen erklärten den Fehler.

Der Aufwand beginnt mit der Einrichtung der Analyse-Engine und der Bereitstellung der erforderlichen Rechenleistung und des Speichers. Die Modellnutzung bringt ihre eigenen Überlegungen mit sich: Der Kontext bestimmt, wie viel Material es auf einmal berücksichtigen kann, während Tokens die Texteinheiten sind, die es verarbeitet. Wiederholte Abfragen erhöhen den Aufwand, gefolgt von Tests und manuellen Reparaturen nach der ersten Ausgabe. Tatsächliche Rechnungen, Hardwareanforderungen und Abschlusszeiten hängen vom Ziel und der Frage ab. Um REAs eigenen Beitrag zu Geschwindigkeit oder Qualität zu messen, wäre ein kontrollierter Vergleich erforderlich.

Nützliche Anwendungen über das bloße Kopieren einer App hinaus

Für Entwickler, Self-Hoster und Migrationsteams liegt der Wert oft darin, eine spezifische Wartungs- oder Kompatibilitätsfrage zu beantworten. Die folgenden Szenarien sind illustrativ und keine getesteten Bereitstellungen oder Ergebnisse dieses Herausgebers.

🛠️ Entwickler / Betreuer

Ein Betreuer, der zwei autorisierte Versionen eines Legacy-Dienstprogramms vergleicht, könnte fragen, warum sich ein Importergebnis geändert hat. REA könnte dabei helfen, die Parsing-Logik zu lokalisieren und Regressionsprüfungen zu leiten. Falls der vollständige Quellcode diese Frage bereits beantwortet, beginnen Sie dort; andernfalls validieren Sie die abgeleitete Ursache gegen das geänderte Verhalten.

🏠 Self-Hoster

Ein Self-Hoster, der mit einem alten lokalen Dateiformat arbeitet, könnte REA nutzen, um dessen Felder zu verstehen. Diese Erkenntnisse könnten dabei helfen, eine unabhängig implementierte Kompatibilitätsbrücke zu definieren. Ein rechtmäßiger Drop-in-Ersatz für die proprietäre Abhängigkeit würde dennoch Tests undokumentierter Fälle und eine Überprüfung der geltenden Rechte erfordern.

💼 Geschäfts- / Migrationsteam

Ein Migrationsteam muss möglicherweise wissen, ob ein erforderliches Exportverhalten unterstützt werden kann, bevor eine Implementierung in Auftrag gegeben wird. REA könnte dabei helfen, technische Machbarkeit zu etablieren und zu klären, was gebaut werden muss. Diese Erkenntnis kann eine Investitionsentscheidung informieren, während Lieferschätzungen, Supportverpflichtungen und vollständige Kompatibilität weitere Bewertungen erfordern.

Bildung und autorisierte Sicherheitsforschung können denselben Ansatz verwenden. Bevor Sie von einer Erklärung zu weiteren Maßnahmen übergehen, definieren Sie, was inspiziert, ausgeführt oder geteilt werden darf. Dieser Umfang bestimmt die Untersuchung, auch wenn die technische Frage unkompliziert erscheint.

Technischer Zugriff regelt keine Autorisierung, Datenschutz oder Vertrauen

Die Berechtigung zur Überprüfung einer Datei kann sich von der Berechtigung zum Ausführen, Beobachten des Datenverkehrs, Veröffentlichung von Ergebnissen oder Wiederverwendung geschützten Materials unterscheiden. Rechte hängen von geltenden Gesetzen und Verträgen ab: bedingte Interoperabilitätsrechte, einschließlich solcher in den USA, sind keine weltweiten Regeln, und der Besitz einer Kopie berechtigt nicht zu jeder Operation.

REAs MIT-Lizenz deckt von REA verfassten Code ab, nicht Zielanwendungen, geschützte Vermögenswerte oder automatisch generierte Ausgaben. Kommerzielle Analyse-Engines benötigen ihre eigenen Lizenzen. Der Haftungsausschluss für verantwortungsvolle Nutzung definiert beabsichtigte Verwendungen und Grenzen der Community-Unterstützung, ohne MIT zu ändern; wiederhergestellter Quellcode wird nicht automatisch zu Open Source oder ist redistributierbar.

⚠️ Warnung: Datenschutz- und Ausführungsrisiken

Die lokale Analyse kann Ergebnisse – einschließlich Code, Anmeldedaten oder persönlicher Daten – an den Modellprovider des Agenten senden. Überprüfen Sie ausgehende Daten und Provider-Bedingungen, bevor Sie vertrauliche Ziele analysieren. REA ist keine Sandbox: statisches Parsing kann Tool-Schwachstellen offenlegen, während das Ausführen oder Interagieren mit Zielen Dateien ändern oder Konten und Dienste beeinflussen kann. Überprüfen Sie die tatsächlichen Operationen und Eindämmung, nicht nur wo Tools ausgeführt werden.

Verwenden Sie offizielle Paket- und Update-Quellen, überprüfen Sie aber auch Abhängigkeiten, generierte Ausgaben, Wartungseigentümerschaft und wie Fixes ankommen. Wenden Sie die gleiche Sorgfalt auf Vendor-Software, Open-Source-Projekte und KI-generierte Alternativen an: offizielle Herkunft, Preis, Quellverfügbarkeit oder Erstellung aus Quellen können eine klare Herkunft und Überprüfungshistorie nicht ersetzen.

Was REA für Softwareeigentum und die Cloud bedeutet

Software einmal zu rekonstruieren finanziert ihre Zukunft nicht. Jemand muss Sicherheitslücken patchen und die Kompatibilität bewahren. Die Unterstützung von Benutzern und die Produktentwicklung erfordern ebenfalls fortlaufende Arbeit. Zugänglichere Untersuchungen können Facharbeiten ergänzen; diese Beispiele zeigen nicht, dass Entwickler oder bezahlte Software obsolet werden. Zuverlässige Updates und verantwortungsvolle Unterstützung bleiben Gründe, sich für ein Produkt zu entscheiden, auch wenn seine Implementierung leichter zu verstehen wird.

Anbieter könnten reagieren, indem sie mehr Funktionalität in Remote-only-Lieferung verschieben, aber die Evidenz hier etabliert keinen REA-getriebenen Trend. Der technische Unterschied ist Client versus Server: Ein Browser empfängt Schnittstellencode und Antworten, während die serverseitige Implementierung normalerweise beim Betreiber bleibt.

Browser / client: delivered UI and scripts
Inspectable to the extent delivered / authorized
                   ↕
           Requests / responses
                   ↕
Server: application logic and database
Behavior observed ≠ exact private source revealed

Eine Sichtbarkeitsbegrenzung, keine vollständige Sicherheitsbegrenzung: Browser-Ressourcen und Antworten können untersucht werden; Backend-Code bleibt normalerweise remote. Offengelegte Daten und andere Sicherheitsprobleme bleiben möglich.

Diese API-Antworten – Daten, die mit dem Service ausgetauscht werden – können genug über das Verhalten einer Funktion offenbaren, um eine neue Implementierung zu informieren. Diese Route beruht auf beobachtbaren Ein- und Ausgaben statt auf Zugriff auf den Backend-Code. Das Fernhalten des Codes eliminiert auch nicht Bugs, offengelegte Daten oder die Möglichkeit autorisierter Untersuchung.

Mit SaaS, Software as a Service, betreibt ein Anbieter die Anwendung.

• Das Selbst-Hosting einer autorisierten Anwendung gibt dir mehr Kontrolle über die Bereitstellung. Du übernimmst dann die Verantwortung für Patching und Zugriffsverwaltung.
• Backups, Überwachung und Wiederherstellung werden auch Teil der Aufrechterhaltung dieser Anwendung.

Ein AlexHost Ubuntu VPS ist eine Infrastruktur-Option für eine überprüfte Anwendung oder Kompatibilitätsbrücke. Vollständiger Root-Zugriff gibt dir Kontrolle über das Gast-Betriebssystem. Es sichert die Anwendung nicht automatisch oder macht externe Modellverarbeitung privat.

Die Erkenntnis: einfachere Untersuchung, keine automatische Wiederherstellung

Ein erkennbares Rechner-Fenster kann ein vielversprechendes erstes Ergebnis sein. Die nächsten Fragen sind, ob das benötigte Verhalten überprüft wurde und wer es warten wird. REA hilft bei der Untersuchung dieses Verhaltens; Implementierung, Verifikation und zuverlässiger Betrieb bleiben separate Arbeiten.

Für tiefere Lektüre beginnen Sie mit dem offiziellen REA-Projekt und seinem DX-Ball-Showcase. Konzentrieren Sie sich auf eine kleine, autorisierte Frage und die Evidenz hinter der Antwort. Das ist ein nützlicherer Ausgangspunkt als die Frage, ob AI ein ganzes Produkt kopieren kann.