KI-Agenten beginnen, Software „auseinanderzunehmen“: Wie weit bringt REA das Reverse Engineering?

17 U.S.C. § 1201 ist eine konkrete US-amerikanische Rechtsvorschrift zu technischen Schutzmaßnahmen – sie ist keine allgemeine Erlaubnis zum Analysieren fremder Software (Gesetzestext). Für Ihre Entscheidung gilt: REA kann einen KI-Agenten dabei unterstützen, sichtbares Verhalten zu beobachten, Analysehinweise zu ordnen und einzelne Funktionen nachzubilden. Daraus folgt aber weder eine stabile Wiederherstellung des Quellcodes noch eine vollständige Rekonstruktion verborgener Serverlogik. Prüfen Sie in dieser Woche zuerst, welche REA-Implementierung gemeint ist, welche Daten sie tatsächlich sieht und ob Sie ihre Ergebnisse unabhängig testen dürfen.

Dieser Artikel richtet sich an Entwickler, die KI-Agenten für Softwareanalyse oder lokale Nachbildungen bewerten.
Er hilft technischen Verantwortlichen, Auswirkungen auf Sicherheit, Kompatibilität und Tests einzuordnen.
Wenn Sie vor allem eine vollständige, verlässliche Wiederherstellung erwarten, erfahren Sie hier, warum dafür eine Demo allein nicht genügt.

Beobachtetes Verhalten ist nicht dasselbe wie Reverse Engineering

REA ist kein eindeutiger Begriff, den Sie ohne Prüfung einer bestimmten Produktdefinition zuordnen sollten. Die hier verfügbaren Quellen verweisen auf das Projekt morluto/rea auf GitHub und dessen offizielle Demonstration. Die Projektbeschreibung und die dort dokumentierte Fähigkeit „reverse-engineer-anything“ geben Hinweise auf den vorgesehenen Ablauf. Sie belegen für sich genommen aber weder eine allgemeine Fähigkeit, beliebige Software zu analysieren, noch eine bestimmte Erfolgsquote. Eine vollständige Ausführung des Kürzels oder die Gleichsetzung mit anderen Projekten wäre ohne passenden Nachweis ebenfalls nicht belastbar.

Für die Bewertung sollten Sie vier Ebenen auseinanderhalten:

Beobachtung: Was zeigt die Oberfläche? Welche Eingabe führt zu welcher sichtbaren Ausgabe? Welche Meldung erscheint bei einem Fehler?
Strukturhinweis: Welche Reihenfolge oder Abhängigkeit legt das beobachtete Verhalten nahe?
Rekonstruktion: Kann eine nachgebildete Funktion bei vergleichbaren Eingaben ein ähnliches Ergebnis liefern?
Vollständige Wiederherstellung: Sind Quellcode, Datenmodell, Geschäftsregeln und serverseitiges Verhalten tatsächlich bekannt?

Ein KI-Agent kann die ersten Ebenen systematisch unterstützen. Eine lokale Nachbildung kann bei einer begrenzten Funktion nützlich sein. Die letzte Ebene folgt daraus nicht. Der Begriff „Software auseinandernehmen“ klingt umfassender, als es die verfügbaren Belege rechtfertigen.

Die REA-Projektbeschreibung und die darin abgelegte Skill-Beschreibung zur Analyse sind deshalb als Beschreibungen des vorgesehenen Vorgehens zu lesen. Eine Anleitung oder Demonstration ist ein Beleg dafür, was gezeigt oder beschrieben wird. Sie ist kein unabhängiger Nachweis, dass das Verfahren in anderen Anwendungen zuverlässig dieselben Ergebnisse erzielt.

Was kann ein KI-Agent mit REA beobachten – und was bleibt Vermutung?

Ein Agent kann Informationen auswerten, die während einer erlaubten Interaktion tatsächlich sichtbar oder zugänglich sind. Dazu können Bildschirmzustände, Eingaben und Ausgaben, Netzwerkhinweise oder Fehlerreaktionen gehören – sofern die jeweilige Implementierung diese Daten erfasst und die Zugriffsrechte vorhanden sind. Welche Quellen REA in einer konkreten Konfiguration nutzt, sollten Sie anhand der Projektunterlagen und einer eigenen Prüfung feststellen, nicht aus dem Namen ableiten.

Ein nachvollziehbares Beobachtungsprotokoll sollte mindestens enthalten:

die geprüfte Anwendung und die verwendete Version;
den Ausgangszustand sowie die eingegebene Aktion;
die sichtbare Antwort und etwaige Fehlermeldungen;
die Bedingungen, unter denen der Ablauf wiederholt wurde;
Hinweise darauf, welche Informationen nicht zugänglich waren.

Wiederholt sich eine sichtbare Reaktion unter denselben Bedingungen, ist das ein belastbarer Hinweis auf das beobachtete Verhalten. Es beweist jedoch nicht, wodurch dieses Verhalten intern entsteht. Eine Schaltfläche kann etwa eine lokale Berechnung auslösen, eine Anfrage an einen Server senden oder beide Schritte kombinieren. Eine äußerlich identische Ausgabe erlaubt nicht, zwischen diesen Möglichkeiten sicher zu unterscheiden.

Auch Schnittstelleninformationen haben Grenzen. Wenn Sie in einer autorisierten Testumgebung nachvollziehbare Anfragen und Antworten sehen, können diese die Analyse stützen. Sie verraten aber nicht automatisch, welche internen Prüfungen, Datenbankregeln oder alternativen Pfade dahinterliegen. Fehlermeldungen liefern ebenfalls Hinweise, können jedoch absichtlich vereinheitlicht, unvollständig oder von Umgebung und Benutzerrechten abhängig sein.

Das gilt besonders für serverseitige Logik. Ein Agent kann aus mehreren beobachteten Abläufen eine plausible Erklärung ableiten. Ohne Zugang zu den entsprechenden Implementierungen, Testdaten oder einer verlässlichen Spezifikation bleibt diese Erklärung eine Schlussfolgerung. Bezeichnen Sie sie in Ihren Unterlagen als Hypothese und nicht als bestätigte Tatsache. Die OWASP Web Security Testing Guide bietet einen Rahmen für strukturierte Sicherheitstests; die Anwendung einer Prüfmethode ersetzt aber nicht den Nachweis über unbekannte interne Abläufe.

Welche REA-Ergebnisse dürfen Sie als belastbar behandeln?

Für Ihre Entscheidung hilft eine klare Trennung zwischen Belegstärke und Nutzen. Eine nachgebildete Funktion kann brauchbar sein, auch wenn die ursprüngliche Implementierung unbekannt bleibt. Umgekehrt kann eine überzeugend formulierte Analyse falsch sein, wenn sie nur auf wenigen Beobachtungen beruht.

Ergebnis	Was der Agent dafür zeigen kann	Was Sie daraus nicht ableiten sollten
Beobachtete Oberfläche	Dokumentierte Zustände, Eingaben und sichtbare Reaktionen	Welche interne Komponente den Zustand erzeugt
Wiederkehrendes Verhalten	Wiederholte Reaktionen unter dokumentierten Bedingungen	Dass alle Versionen, Konten und Umgebungen gleich reagieren
Schnittstellenhinweis	Beobachtete Ein- und Ausgaben in einer autorisierten Umgebung	Vollständige Kenntnis von Serverlogik oder Datenhaltung
Lokale Nachbildung	Vergleichbares Verhalten für ausgewählte Testfälle	Identischen Quellcode oder vollständige Funktionsgleichheit
Erklärung eines internen Ablaufs	Eine aus Indizien abgeleitete Hypothese	Bestätigung ohne unabhängigen Beleg

Die Tabelle ist ein Bewertungsraster, keine behauptete Leistungsbeschreibung von REA. Entscheidend ist, ob jede Aussage auf ein konkretes Protokoll zurückgeführt werden kann. Fehlt diese Verbindung, sollten Sie die Aussage nicht als gesichertes Analyseergebnis weitergeben.

Eine lokale Reproduktion ist außerdem nicht automatisch eine funktionale Gleichheit. Die ursprüngliche Anwendung kann versteckte Zustände, Kontorechte, externe Dienste, zeitabhängige Daten oder besondere Fehlerpfade verwenden. Wenn Sie nur einen erfolgreichen Standardablauf vergleichen, übersehen Sie womöglich genau jene Fälle, die für Kompatibilität oder Sicherheit wichtig sind.

Vom Teilnachbau zur vollständigen Wiederherstellung: Wo liegt die Grenze?

Ein KI-Agent kann eine sichtbare Funktion nachbilden, ohne den ursprünglichen Quellcode zu kennen. Das ist eine wichtige Abgrenzung: Ein Teilnachbau versucht, ausgewählte beobachtbare Ergebnisse nachzustellen. Eine vollständige Wiederherstellung würde dagegen auch nicht sichtbare Komponenten und Regeln erfassen. Dafür reichen Oberflächenbeobachtungen allein nicht aus.

Mehrere praktische Grenzen wirken zusammen:

Lücken in den Beobachtungsdaten: Nicht getestete Eingaben, Zustände und Fehlersituationen bleiben unbewertet.
Komplexe Zustandsübergänge: Eine Anwendung kann ihr Verhalten anhand von Anmeldung, Berechtigungen, vorherigen Aktionen oder externen Daten ändern.
Abhängigkeiten von der Umgebung: Betriebssystem, Netzwerk, Geräteeigenschaften und externe Dienste können Ergebnisse beeinflussen.
Unvollständiger Zugriff: Eine sichtbare Oberfläche zeigt nicht automatisch interne Datenstrukturen oder serverseitige Entscheidungen.
Schwierige Validierung: Ähnliche Antworten bei wenigen Testfällen beweisen keine Übereinstimmung in nicht getesteten Fällen.

Ein KI-Agent kann Informationen ordnen und Nachbildungen erzeugen, doch das Ergebnis muss gegen die Originalanwendung geprüft werden. Die NIST-Publikation SP 800-163 behandelt die Sicherheitsprüfung mobiler Anwendungen. Sie ist ein Beispiel dafür, dass eine belastbare Beurteilung systematische Prüfungen und nachvollziehbare Kriterien braucht – nicht allein eine plausible Beschreibung eines Werkzeugs.

So prüfen Sie REA in fünf Schritten

Bevor Sie eine Aussage über die Leistungsfähigkeit treffen, gehen Sie nachvollziehbar vor:

Projekt und Zweck identifizieren. Halten Sie fest, auf welches konkrete REA-Projekt, welche Dokumentation und welche Implementierung Sie sich beziehen. Übernehmen Sie keine Definition aus einem anderen Projekt, nur weil dasselbe Kürzel verwendet wird.
Berechtigung und Testumfang festlegen. Klären Sie, ob Sie die Software untersuchen dürfen, welche Daten verwendet werden und welche Systeme oder Schnittstellen ausdrücklich außerhalb des Tests liegen.
Beobachtungen dokumentieren. Speichern Sie Eingabe, Ausgangszustand und sichtbare Reaktion. Notieren Sie Einschränkungen wie fehlende Berechtigungen oder nicht erreichbare Dienste.
Hypothesen getrennt notieren. Markieren Sie Vermutungen über interne Abläufe als solche. Verknüpfen Sie sie mit den Beobachtungen, aus denen sie abgeleitet wurden.
Nachbildung unabhängig vergleichen. Verwenden Sie zusätzliche Testfälle, wiederholen Sie relevante Abläufe und lassen Sie kritische Ergebnisse von einer Person prüfen, die nicht bloß die Agentenausgabe übernimmt.

Für sicherheitsrelevante Anwendungen sollten Sie außerdem festlegen, welche Abweichung einen Befund ungültig macht. Eine erfolgreiche Reaktion in einem Einzelfall genügt nicht, wenn ein anderer Zustand andere Rechte, Daten oder Folgen auslöst. Dokumentieren Sie deshalb auch negative Ergebnisse und nicht reproduzierbare Abläufe, statt sie aus dem Bericht zu entfernen.

Genauigkeit und Zulässigkeit getrennt bewerten

Technische Möglichkeit ist keine Nutzungserlaubnis. Ob Analyse, Zugriff oder Nachbildung zulässig sind, hängt unter anderem von konkreter Software, Lizenzbedingungen, Datenzugriff und anwendbarem Recht ab. Aus einer einzelnen Rechtsquelle lässt sich keine pauschale Freigabe für alle Länder und Anwendungen ableiten. Die Übersicht des Cornell Legal Information Institute zum Reverse Engineering bietet eine allgemeine rechtliche Einordnung, ersetzt aber keine Prüfung des konkreten Vorhabens. Auch die erwähnte US-Vorschrift aus 17 U.S.C. § 1201 ist kein universeller Maßstab für Ihre Situation.

Bevor Sie REA in einem echten Analyseprojekt einsetzen, prüfen Sie diese Punkte:

[ ] Ist eindeutig geklärt, welches REA-Projekt und welche konkrete Implementierung gemeint sind?
[ ] Können Sie jede wichtige Aussage auf protokollierte Beobachtungen zurückführen?
[ ] Sind beobachtete Fakten, Schlussfolgerungen und offene Fragen getrennt gekennzeichnet?
[ ] Wurde eine Nachbildung gegen unabhängige Testfälle und die Originalsoftware verglichen?
[ ] Sind Softwarelizenz, Datenrechte, Zugriffsberechtigungen und einschlägige Regeln geprüft?
[ ] Ist dokumentiert, welche Informationen der Agent nicht sehen konnte?

Wenn Sie bei den ersten vier Punkten keine belastbaren Antworten haben, behandeln Sie das Ergebnis als vorläufig. Wenn die Berechtigung ungeklärt ist, beginnen Sie nicht mit einem Zugriff auf fremde Daten oder geschützte Systeme. Hashvps stellt dazu seine Nutzungsbedingungen bereit; sie ersetzen nicht die Prüfung Ihrer konkreten Software und Ihres Vorhabens.

Wann ist eine Mac-Testumgebung sinnvoll?

Eine Mac-Umgebung ist nur dann relevant, wenn Ihr Prüfobjekt macOS voraussetzt oder Sie das Verhalten gezielt auf dieser Plattform vergleichen müssen. Sie macht eine Analyse nicht automatisch vollständiger und ist kein Beleg für REA-Fähigkeiten. Für einen belastbaren Plattformvergleich sollten Sie festhalten, welche Ergebnisse auf macOS entstanden sind und welche auf anderen Systemen; andernfalls vermischen sich Umgebungsunterschiede mit vermeintlichen Softwareeigenschaften.

Wenn Ihre vorhandene Testumgebung die benötigte Plattform nicht abdeckt, vergleichen Sie die realistischen Alternativen: ein vorhandener eigener Mac, eine geeignete externe Testumgebung oder ein gemieteter Mac für einen begrenzten Testzeitraum. Ein Kauf kann sinnvoller sein, wenn Sie dauerhaft auf ein physisches Gerät oder stabile lokale Peripherie angewiesen sind. Eine Mietlösung kann für zeitlich begrenzte Tests interessanter sein als ein zusätzlicher Gerätekauf; prüfen Sie dafür aber erst die konkret verfügbaren Umgebungs- und Zugriffsangaben. Hashvps’ aktuelle Umgebungsinformationen sollten Sie vorab auf die Anforderungen Ihres Tests abgleichen.

Für die Bewertung von REA bleibt die Reihenfolge entscheidend: erst Belege und Wiederholbarkeit prüfen, dann die Reichweite der Schlussfolgerung festlegen und schließlich die Nutzungserlaubnis klären. So können Sie einen nützlichen Teilnachbau anerkennen, ohne ihn mit vollständigem Reverse Engineering gleichzusetzen.