Ein Agent kann fremde Software heute untersuchen und erklären, was sie tut – vorausgesetzt, er bekommt Werkzeuge und muss zu jedem Befund die Fundstelle nennen. Genau das ist REA („Reverse Engineer Anything“): ein offenes Projekt, das einen Analyse-Server für Agenten und ein Kommandozeilen-Werkzeug in einem Paket liefert. Die Analyse läuft lokal, jeder Befund kommt mit Beleg und ausgewiesener Lücke, und tiefe Analyse nativer Programme braucht weiterhin eine eigene Engine. Rund 186.500 Sterne und rund 45.250 Forks bei GitHub, MIT-Lizenz, 349 offene Issues und 266 offene Pull Requests – Stand 13.10.2026, live gemessen. Bemerkenswert ist aber nicht die Reichweite, sondern die Eigenschaft, die vorher fehlte: Der Agent rät nicht mehr, er zitiert – und er sagt, was er nicht weiß.

Der folgende Text ordnet in dieser Reihenfolge ein: was REA ist, wie der Ablauf aussieht, was sich damit auswerten lässt, was das Projekt an belastbaren Zahlen hergibt, wohin die Ergebnisse tatsächlich wandern, wo der rechtliche Rahmen liegt und für welche Betriebe in Nordrhein-Westfalen sich ein Blick darauf lohnt. Alle Kennzahlen sind am 13.10.2026 gemessen; wo eine Aussage nicht belegbar ist, steht das ausdrücklich dort.

Warum ein Agent ohne Werkzeug teuer wird

Wenn ein Sprachmodell erklärt, wie ein fremdes Programm funktioniert, klingt die Antwort immer plausibel. Bei Code, den es millionenfach im Training gesehen hat, trifft sie häufig. Bei einer kompilierten Anwendung, die es nie gesehen hat, füllt es die Lücken mit Wahrscheinlichkeit – mit der Selbstsicherheit eines Systems, das nicht sagen kann, was es nicht weiß.

Für einen Betrieb ist dieser Fehler nicht peinlich, sondern teuer. Eine Schnittstelle, die auf einer erfundenen Annahme gebaut wird, kostet Wochen. Eine Migrationsplanung für ein Altsystem, dessen Verhalten falsch eingeschätzt wurde, kostet mehr. Und eine Kaufentscheidung, die auf einer Vermutung über die Datenwege einer Software beruht, kostet im schlechtesten Fall das Projekt.

REA löst das nicht mit einem besseren Modell, sondern mit einer anderen Rollenverteilung: Der Agent bekommt Werkzeuge, mit denen er das Ziel selbst untersucht. Seine Antwort muss sich an Befunden messen lassen.

Was REA ist

REA steht für „Reverse Engineer Anything“. Die Beschreibung im Projekt lautet wörtlich: „Reverse engineer anything with agents, from app behavior down to native binaries“ – also alles mit Agenten zurückentwickeln, vom Verhalten einer Anwendung bis hinunter in native Programme.

Es handelt sich um ein offenes Projekt unter der MIT-Lizenz, erreichbar über https://github.com/morluto/rea und die Projektseite https://rea.tools. In einem einzigen npm-Paket stecken zwei Dinge: ein Kommandozeilen-Werkzeug und ein Analyse-Server nach dem offenen Protokoll MCP. Damit kann jeder Agent arbeiten, der lokale MCP-Server unterstützt. Voraussetzung ist Node.js ab Version 22.19 plus npm.

Der Einstieg ist ein Befehl – npx rea-agents setup. Er registriert den Server beim gewählten Agenten und installiert passende Arbeitsanweisungen. Bevor etwas geschrieben wird, zeigt das Setup den geplanten Änderungsplan, sichert bestehende Konfigurationen und fragt vor jeder Änderung nach. Danach wird der Agent neu gestartet. Wer die Kommandozeile ohne Agent nutzen will, installiert das Werkzeug dauerhaft und arbeitet mit denselben Arbeitsschritten.

Frage, lokale Analyse, Evidenz – so läuft es ab

Der Ablauf hat drei Schritte, und der dritte ist der entscheidende.

Der Agent stellt eine Frage zu einem Ziel, das auf dem eigenen Rechner liegt: eine Programmdatei, eine Anwendung, eine Website, eine aufgezeichnete Netzwerksitzung. REA untersucht das Ziel mit seinen Analyse-Werkzeugen und verfolgt den Code über die Grenzen einzelner Dateien hinweg. Zurück kommt der vollständige Datensatz: Quellorte, Abdeckung, Vertrauensgrad und – ausdrücklich – die Grenzen der jeweiligen Aussage. Der Agent nutzt diese Befunde für die Erklärung, für Rückfragen oder für eine eigene Implementierung, die er anschließend testet. Die Kommandozeile nutzt dieselben Arbeitsschritte und dieselben Zusagen, nur ohne Agent dazwischen.

Der Grundsatz, der dieses Vorgehen von „ein Modell liest mal eine Datei“ unterscheidet, steht wörtlich in der Projekt-Dokumentation: Fehlende Abdeckung ist unbekannt, nicht abwesend. Wenn ein Werkzeug nichts findet, heißt das nicht, dass nichts da ist. Deshalb bleiben beobachtete, abgeleitete und vermutete Beziehungen getrennt, ungelöste Pfade bleiben sichtbar, und ein leeres Aufrufergebnis ist kein Beweis, dass eine Funktion nichts aufruft. Wird eine Suche abgeschnitten, steht das als Vermerk im Ergebnis. Selbst Fehlerfälle kommen mit vollständiger Diagnose: Fehlercode, betroffenes Ziel, Teilergebnisse und Abhilfe.

Für die Praxis ist das der ganze Punkt. Ein Befund, der seine Herkunft mitliefert, lässt sich prüfen. Eine glatte Behauptung nicht.

Was sich damit auswerten lässt

Das Projekt dokumentiert eine breite Zielliste. Die folgende Übersicht nennt den Kern, jeweils mit dem, was zurückkommt, und der Voraussetzung.

Zwei Dinge trennt die Dokumentation sauber. Die statische Prüfung von JavaScript und .NET liest die vorliegenden Dateien, ohne die Anwendung zu starten. Wer dagegen das Laufzeitverhalten erfasst, startet oder bedient das Ziel mit den Rechten des angemeldeten Nutzers.

Für Windows-Arbeitsplätze gehört eine Einschränkung dazu, denn sie betrifft die meisten Büros: Die tiefe Analyse nativer Programme gilt unter Windows laut Projekt als experimentell, auch wenn ein passendes Bauteil für Windows mitgeliefert wird. Hopper ist ein macOS-Werkzeug. Prozessaufzeichnung und Firmware-Analyse setzen Linux oder macOS voraus. Wer auf Windows arbeitet, bleibt bei der statischen Prüfung von JavaScript, .NET und Paketen sowie bei allem, was Ghidra oder IDA unter Windows trägt – und braucht für die übrigen Ziele eine zweite Umgebung.

Der Unterschied zum klassischen Reverse Engineering

Klassisch setzt sich ein Mensch vor ein Werkzeug wie Hopper, IDA oder Ghidra, liest Assembly, benennt Funktionen um und zieht seine Schlüsse selbst. Analyst und Werkzeugführer sind dieselbe Person, und die Qualität des Ergebnisses hängt an ihrer Erfahrung.

REA setzt einen Fragesteller davor. Der Agent formuliert die Frage, das Werkzeug antwortet strukturiert und mit Fundstellen, und die Antwort kommt in einer Form zurück, die sich prüfen lässt. Die Analysewerkzeuge bleiben dabei dieselben – neu ist die Bedienung und die Dokumentation der Fundstellen.

Zwei Dinge ändern sich nicht. Erstens: Für tiefe native Analyse braucht es weiterhin Hopper, Ghidra oder IDA. REA ersetzt sie nicht. Ohne eine solche Engine bleibt die statische Prüfung von JavaScript, Electron und .NET – ein Decompiler ist dann nicht dabei. Zweitens: Ob eine Schlussfolgerung trägt, entscheidet weiterhin ein Mensch. Die Evidenz sagt, was gefunden wurde, nicht was es bedeutet.

Was das Projekt an belastbaren Zahlen hergibt

Alle folgenden Werte wurden am 13.10.2026 live gemessen – über die Programmierschnittstelle von GitHub, gegengeprüft über die Projektseite und einen unabhängigen Spiegel. Drei Quellen, gleiche Größenordnung.

Zwischen den Messungen liegen 73 Sekunden, und in dieser Zeit sind rund 55 Sterne dazugekommen. Deshalb steht in Außendarstellungen eine gerundete Angabe mit Datum: rund 186.500 Sterne und rund 45.250 Forks, Stand 13.10.2026. Eine exakte Zahl wäre Minuten später schon falsch.

Aussagekräftiger als die Sterne sind zwei andere Werte. Das Paket wurde in der Woche vom 05. bis 11.10.2026 insgesamt 132.518 Mal geladen, im ganzen Monat 134.114 Mal – der Schub ist also frisch und nicht über Monate gewachsen. Und die Veröffentlichungen kommen in kurzen Abständen: 31 Versionen seit dem 12.07.2026, die zum Messzeitpunkt jüngste trägt die Nummer 6.4.0 vom 11.10.2026 und ist damit zwei Tage alt. Wer dieses Werkzeug einsetzt, plant Updates ein. Das ist eine Aussage über die Reife, die man in Sternen nicht sieht.

Das Projekt dokumentiert außerdem drei ausgearbeitete Beispielfälle. In einem davon wird eine Schallberechnung aus einem bekannten Geschicklichkeitsspiel rekonstruiert; die Rekonstruktion besteht 3.205 Original-Fälle der x86-Architektur und erzeugt alle 63 kompilierten Bytes der Funktion wieder. Zwei weitere Fälle verfolgen die Zwischenablage-Brücke einer Notiz-Anwendung durch ihre Prozessgrenzen und rekonstruieren eine Geschossberechnung aus einem DOS-Spiel anhand der 16-Bit-Instruktionen. Solche Beispiele sind Einzelfälle, keine Messreihe – sie zeigen aber, welche Tiefe möglich ist.

Ein Hinweis zur Einordnung: Sterne sind ein Aufmerksamkeitssignal, kein Qualitätsurteil. Warum genau die Zahlen in dieser Geschwindigkeit gewachsen sind, ist nicht belegt, und wir behaupten es nicht.

Wohin die Ergebnisse tatsächlich wandern

Hier wird in Projektdarstellungen gern unscharf argumentiert, deshalb genau: Die Analyse läuft lokal. REA überträgt nichts von sich aus an Dritte, es gibt keinen Dienst, der die untersuchten Dateien einsammelt.

Der Agent erhält jedoch die Werkzeugergebnisse, und der Anbieter des verwendeten Modells hat seine eigene Datenrichtlinie. Wer ein Cloud-Modell einsetzt, schickt die Analyseergebnisse damit in die Cloud – so steht es auch in der Projekt-Dokumentation selbst. Wer erreichen will, dass nichts das Haus verlässt, braucht ein lokal betriebenes Modell. Die Analyse zu lokalisieren ist die eine Hälfte; die Datenpolitik des Modellanbieters ist die andere, und sie wird vor dem Einsatz geklärt, nicht danach.

Ein zweiter Punkt gehört dazu: Läuft das Werkzeug mit den Rechten des angemeldeten Nutzers, dann gilt das auch für die untersuchte Anwendung. Ein nicht vertrauenswürdiges Programm wird mit genau diesen Rechten ausgeführt. Eine abgeschottete Umgebung ist laut Projekt nicht Teil des Konzepts. Wer Software prüft, deren Herkunft unklar ist, richtet dafür einen getrennten Rechner ein.

Rechtlich: prüfen ja, aber nicht ohne Berechtigung

Hier versprechen wir am wenigsten und werden am deutlichsten. Eine rechtliche Bewertung ist keine Rechtsberatung, sie ist eine Orientierung.

Analysieren dürfen Sie Software, die Ihnen gehört oder für deren Prüfung Sie beauftragt oder autorisiert sind. Diese Grenze ist keine Formalie, sie entscheidet über den gesamten Einsatz. Das Urheberrecht gibt dem Rechteinhaber das Recht, das Programm zu vervielfältigen und umzuarbeiten. Erlaubt ist ohne Zustimmung, was für die bestimmungsgemäße Nutzung durch einen dazu Berechtigten erforderlich ist – und auch das nur, solange keine besonderen vertraglichen Bestimmungen entgegenstehen. Nutzungsbedingungen können eine Analyse also wirksam ausschließen. Wer zur Verwendung berechtigt ist, darf das Funktionieren eines Programms beobachten, untersuchen und testen, um die zugrunde liegenden Ideen zu ermitteln. Eine Dekompilierung ohne Zustimmung ist dagegen nur in einem eng umrissenen Fall zulässig: zur Herstellung der Interoperabilität eines unabhängig geschaffenen Programms, und die dabei gewonnenen Informationen dürfen nicht dafür verwendet werden, ein Programm mit im Wesentlichen gleicher Ausdrucksform zu entwickeln. Genau dort liegt das Risiko bei der Frage „wie baut man das nach“ – nicht in der Analyse selbst.

Auf der anderen Seite stehen zwei Strafnormen. Das Ausspähen besonders gesicherter Daten durch Überwinden der Zugangssicherung ist strafbar, und bereits die Vorbereitung einer solchen Tat kann es sein. Wer also fremde Software ohne Auftrag und ohne Berechtigung zerlegt, ist nicht neugierig, sondern möglicherweise schon dort, wo diese Normen greifen.

Das Projekt selbst zieht eine klare Linie: Erlaubt sind rechtmäßige Analyse, Sicherheitsforschung, Malware- und Vorfallanalyse, Schwachstellenforschung mit koordinierter Offenlegung, Interoperabilität, Software-Erhaltung sowie Prüfung von Software, die man besitzt oder zu prüfen berechtigt ist. Ausdrücklich nicht unterstützt werden die Umgehung von Kopierschutz, Lizenzprüfungen, Anti-Cheat oder anderen technischen Schutzmaßnahmen, Spiele-Manipulation, das Umgehen von Authentifizierung und Zugangskontrollen sowie das Kopieren proprietärer Software. Der Nutzer ist für die erforderliche Autorisierung und für die Einhaltung von Gesetzen, Lizenzvereinbarungen und Nutzungsbedingungen selbst verantwortlich.

Zum EU AI Act gilt eine nüchterne Feststellung. Für REA selbst liegt keine belegte Aussage vor. Belegbar ist, dass es sich um ein Entwicklerwerkzeug handelt, das von einem KI-System aufgerufen wird. Pflichten aus der KI-Verordnung treffen die Anbieter und Betreiber der eingesetzten KI-Systeme – nicht dieses Werkzeug. Eine Einordnung als Hochrisiko-System ist nicht belegt, und wir behaupten sie nicht. Praktisch heißt das: Wer den Agenten mit einem Cloud-Modell betreibt, klärt dessen Datenpolitik, und falls in analysierten Aufzeichnungen, Datenbanken oder Bildschirmaufnahmen personenbezogene Daten landen, gelten die allgemeinen datenschutzrechtlichen Regeln. Ein Werkzeug macht einen Zweck nicht rechtmäßig; das bleibt eine eigene Bewertung.

Wo es für Betriebe in Nordrhein-Westfalen andockt

Ein Handwerksbetrieb wird dieses Werkzeug nicht morgen in der Werkstatt bedienen. Es ist ein Werkzeug für Entwickler und für alle, die fremde Software wirklich verstehen müssen – und genau dort liegen die realistischen Ansatzpunkte in kleinen und mittleren Betrieben.

Der häufigste Fall ist die Auslaufsoftware. Ein Programm tut seit Jahren seinen Dienst, der Hersteller ist verschwunden, und niemand kann sagen, was die Anwendung im Hintergrund wirklich macht: welche Daten wohin gehen, welche Schnittstellen existieren, was beim Umstieg verloren geht. Vor einer Migration oder einer neuen Anbindung ist Verstehen keine akademische Übung, sondern die Grundlage jeder Planung.

Der zweite Fall ist die Prüfung vor einer Übernahme. In Software steckt heute oft mehr als in der Halle. Welche Telemetrie läuft, wohin verbindet sich das Programm, wie werden Daten abgelegt, welche Bausteine sind fremd lizenziert? Wer eine Bewertung abgibt, muss in die Software hineinschauen können – mit Befunden, die man einem Käufer oder einer Bank vorlegen kann. Das ist genau die Arbeit, die wir in Wertgutachten für Unternehmen leisten, und dieses Werkzeug macht den technischen Teil davon belastbarer.

Der dritte Fall betrifft das eigene Produkt. Wer eine Software abgibt oder betreibt, sollte wissen, was ein Agent darin nachvollziehen kann – und was davon in einer Dokumentation stehen müsste. Diese Frage stellt sich spätestens dann, wenn ein Kunde oder ein Betriebsprüfer sie stellt.

Und der vierte Fall ist der enge, gesetzlich ausdrücklich vorgesehene: Interoperabilität. Wenn ein System mit einem anderen sprechen muss und die Schnittstelle nicht dokumentiert ist, ist die Analyse unter den genannten Voraussetzungen der vorgesehene Weg.

Was REA dabei nicht ist, sagen wir genauso klar: Es ist kein Compliance-Werkzeug. Es erzeugt keinen Nachweis und kein Gutachten, es dokumentiert Analyseergebnisse. Der Nachweis bleibt Handarbeit. Und ohne jemanden, der die Umgebung einrichtet, die Engine pflegt und die Fundstellen bewertet, bleibt das Werkzeug liegen. Der erste Schritt ist deshalb keine Installation, sondern eine Frage, deren Antwort sich lohnt – und die Klärung, wer die Berechtigung dafür hat.

Was wir nicht behaupten

Zu jedem Befund gehört bei uns die Angabe, wie belastbar er ist. Für diesen Text heißt das:

• Der Grund für das schnelle Wachstum der Sternezahl und der Zugriffszahlen ist nicht belegt. Wir erklären es nicht zur Entwicklung und nennen keine Ursache.
• Die tiefe Analyse nativer Programme unter Windows ist laut Projekt experimentell. Praxisbeispiele dazu haben wir nicht geprüft und nennen keine.
• Zum EU AI Act gibt es keine belegte Aussage über REA selbst. Wer anderes liest, liest an der Quelle vorbei.
• Einen Datenschutzbezug dokumentiert das Projekt nicht. Er entsteht erst dort, wo personenbezogene Daten in den Analyseergebnissen landen.
• Zum Anbieter hinter dem Projekt ist nur der Nutzername belegt. Aussagen über Träger, Firma oder Kommerzialisierung lassen sich daraus nicht ableiten.
• Versionsnummern und Zahlen sind Momentaufnahmen. Wir nennen sie mit Datum, und wir erneuern sie, bevor sie in einer Veröffentlichung stehen.
• Die rechtliche Einordnung bleibt eine Orientierung und ersetzt keine Rechtsberatung.

Wenn Sie eine Anwendung im Haus haben, die seit Jahren niemand mehr versteht, oder wenn vor einer Übernahme zu klären ist, was in der Software eines Kaufobjekts steckt: Schreiben Sie uns zwei Sätze zu Ihrer Frage. Sie bekommen eine ehrliche Einschätzung – ob eine Analyse trägt, ob zuerst eine Berechtigung zu klären ist, und ob die Antwort vielleicht schon in der vorhandenen Dokumentation steht.

Quellen

Alle Kennzahlen zum Projekt wurden am 13.10.2026 live gemessen; die Messwerte sind im Text als solche gekennzeichnet. Rechtsnormen wurden am 13.10.2026 im amtlichen Text geprüft.

1. Projekt-Repository (Beschreibung, Funktionsumfang, Zielliste, Showcases, Lizenz, Voraussetzungen): https://github.com/morluto/rea
2. Projektseite mit Anleitungen und Fallstudien (Selbstbeschreibung, Antworten zum Datenfluss): https://rea.tools
3. Messung der Kennzahlen am 13.10.2026 über die GitHub-Schnittstelle (api.github.com/repos/morluto/rea, Suchschnittstelle für Issues und Pull Requests), mit Gegenproben über die live geladene Projektseite (stargazerCount) und den unabhängigen Spiegel https://ungh.cc/repos/morluto/rea
4. npm-Paket rea-agents: Versionen, Veröffentlichungsdaten und Downloadstatistik über https://registry.npmjs.org/rea-agents und https://api.npmjs.org/downloads
5. Nutzungsgrenzen des Projekts (DISCLAIMER.md im Repository): erlaubte Zwecke, ausdrücklich ausgeschlossene Anwendungen, Verantwortung des Nutzers
6. Sicherheitsmodell des Projekts (SECURITY.md im Repository): Ausführung mit Nutzerrechten, kein Sandbox-Betrieb
7. Setup, Kommandozeile, Evidenz- und Werkzeugverträge: docs/installation.md, docs/cli.md, docs/mcp-contracts.md, docs/tool-design.md im Repository (Stand Hauptzweig, abgerufen 13.10.2026)
8. § 69c UrhG (Rechte des Rechtsinhabers): https://www.gesetze-im-internet.de/urhg/__69c.html
9. § 69d UrhG (bestimmungsgemäße Benutzung, Beobachten und Testen): https://www.gesetze-im-internet.de/urhg/__69d.html
10. § 69e UrhG (Dekompilierung, Interoperabilität): https://www.gesetze-im-internet.de/urhg/__69e.html
11. § 202a StGB (Ausspähen von Daten): https://www.gesetze-im-internet.de/stgb/__202a.html
12. § 202c StGB (Vorbereiten des Ausspähens von Daten): https://www.gesetze-im-internet.de/stgb/__202c.html

Autor: Team REN-AI-SSANCE – mit KI-Unterstützung erstellt, von Menschen geprüft und freigegeben.