Start › News

Werkzeug · Software

REA: KI-Assistenten zerlegen fremde Software, und was Betriebe daraus lernen

Das Projekt REA führt die GitHub-Trends an. Es lässt KI-Assistenten fertige Programme ohne Quellcode untersuchen und nachbauen. Das hilft bei verwaister Altsoftware und macht zugleich eigene Software leichter durchschaubar.

13. Oktober 2026 · 4 Minuten Lesezeit

Ein Open-Source-Projekt namens REA steht seit Anfang Oktober 2026 an der Spitze der Trendlisten von GitHub. Es gibt Programmierassistenten wie Claude Code, Codex oder Cursor Werkzeuge an die Hand, mit denen sie fertige Software ohne Quellcode untersuchen können. Für Betriebe ist das aus zwei Richtungen interessant: als Hilfe bei verwaister Altsoftware und als Hinweis darauf, wie leicht sich eigene Software inzwischen durchleuchten lässt.

Was das Werkzeug REA tatsächlich macht

REA steht für „Reverse Engineer Anything“ und ist ein Open-Source-Werkzeug unter MIT-Lizenz. Es verbindet KI-Programmierassistenten über die Schnittstelle MCP mit Analyseprogrammen wie Ghidra, Hopper oder IDA. Der Nutzer beschreibt in normaler Sprache, welche Funktion eines Programms er verstehen will. Der Assistent führt die Analyse aus, liefert Befunde mit Belegen und kann anschließend eine eigene Umsetzung schreiben und testen.

Laut der Projektseite auf GitHub untersucht REA neben klassischen Programmen auch Electron-Apps, .NET-Anwendungen, Android-Apps, Firmware, Webseiten und mitgeschnittenen Netzwerkverkehr. Den Originalquellcode erhält der Assistent nicht, sondern unter anderem Pseudocode, Assemblercode und Zeichenketten. Für tiefe Analysen von Maschinencode muss Hopper, Ghidra oder IDA installiert sein. Lizenzen für kommerzielle Programme muss man sich selbst beschaffen.

Als Beleg führen die Entwickler eine Funktion aus dem Spiel DX-Ball von 1996 an. Der nachgebaute Code besteht nach ihren Angaben 3.205 Testfälle gegen das Original und erzeugt alle 63 Bytes der kompilierten Funktion identisch. Am 13. Oktober 2026 zeigte die GitHub-Seite des Projekts rund 202.700 Sterne und 49.500 Forks.

Wo die Grenzen von REA liegen

Die Sterne auf GitHub messen Aufmerksamkeit, keine Verlässlichkeit. Die Entwickler von REA schreiben selbst, dass KI-gestützte Analysen unvollständig oder falsch sein können und wichtige Schlüsse geprüft werden müssen. Die vorgezeigten Beispiele sind überschaubare Einzelfunktionen aus Spielen, einem Taschenrechner und Notion. Ob REA bei gewachsener Branchensoftware mit Datenbank und Schnittstellen ebenso trägt, zeigt sich erst.

Die Analyse läuft laut Projektbeschreibung lokal auf dem eigenen Rechner. Die Ergebnisse gehen jedoch an das KI-Modell und damit an dessen Anbieter, für den seine eigenen Datenregeln gelten. Wer interne Software, die Firmware einer Anlage oder Netzwerkmitschnitte mit REA untersuchen lässt, gibt also Ausschnitte davon nach außen.

Die rechtliche Verantwortung legt REA vollständig auf den Nutzer. Als Zweck nennen die Entwickler rechtmäßige Forschung, Interoperabilität, Erhaltung alter Software und Programme, die man besitzt oder untersuchen darf. Das Umgehen von Lizenzprüfungen und das Kopieren fremden Codes schließen sie ausdrücklich aus. Sie weisen auch darauf hin, dass weder der Besitz einer Datei noch die lokale Ausführung eine Erlaubnis begründet.

Was REA für Altsoftware und eigene Programme in Ihrem Betrieb heißt

Nützlich wird REA dort, wo ein Betrieb von Software abhängt, die niemand mehr pflegt. Ein Beispiel: Eine Galvanik mit 60 Beschäftigten steuert ihre Gestelllinie über ein Programm, dessen Hersteller nicht mehr existiert. Die Badprotokolle landen in einem undokumentierten Dateiformat, das neue Qualitätssystem kann sie nicht lesen. Ein Assistent mit REA könnte herausfinden, wie dieses Format aufgebaut ist.

Damit ist die Arbeit nicht erledigt. Jemand muss den Befund prüfen, eine Importroutine bauen und sie gegen echte Protokolle testen. Ob die Untersuchung überhaupt zulässig ist, hängt vom Lizenzvertrag der alten Software ab und gehört vorher geklärt. Nach meiner Erfahrung scheitern solche Vorhaben selten an der Technik, häufiger daran, dass niemand mehr weiß, welcher Vertrag gilt.

Die andere Seite betrifft Betriebe, die selbst Software ausliefern: eine Bedien-App zur Maschine, ein Kundenportal, Firmware in einem Gerät. Was bisher Spezialisten und viele Stunden Handarbeit erforderte, lässt sich mit REA per Anweisung in Alltagssprache anstoßen. Rechenlogik, die in solcher Software steckt, bleibt rechtlich geschützt, ist technisch aber leichter einzusehen als bisher.

Welche zwei Listen Sie jetzt anlegen sollten

Für die meisten Betriebe reicht vorerst eine kurze Bestandsaufnahme mit zwei Listen. Die erste enthält Programme, deren Hersteller nicht mehr erreichbar ist. Die zweite enthält eigene Software mit Rechenlogik oder Zugangsdaten, die Ihr Haus verlässt. Für beide genügt meist ein Gespräch mit der Person, die Ihre IT betreut.

Bei der ersten Liste lohnt vor jedem Analyseversuch ein Blick in die Lizenzverträge, bei Unklarheit auch eine anwaltliche Einschätzung; ob sich der Aufwand rechnet, hängt vom Einzelfall ab. Bei der zweiten Liste gilt eine alte Regel mit neuer Dringlichkeit: Zugangsdaten gehören nicht in ausgelieferten Code, und Wissen, das geheim bleiben soll, läuft besser auf dem eigenen Server als beim Kunden.

Wer REA selbst ausprobieren möchte, sollte das an einem Programm tun, dessen Rechte geklärt sind. Vorher sollte feststehen, welche Daten an den KI-Anbieter gehen dürfen.