RHEXA
Retargetable Headless Executable Analyzer
Reverse Engineering für KI-Agenten: Ein Agent stellt eine konkrete Frage an ein Programm, RHEXA beantwortet sie über mehrere Analyseverfahren hinweg und legt jeden Befund mit Belegen offen. Die statische Tiefenanalyse übernimmt die Rhexa Engine, eine eigenständig weiterentwickelte, rein headless Ableitung von Ghidra, die fest in RHEXA integriert ist.
Überblick
RHEXA ist ein Produkt aus zwei Technologie-Stacks in einem Repository. Die Agentenschicht spricht mit KI-Agenten, die Engine analysiert Maschinencode. Beide sind über einen versionierten Vertrag verbunden und lassen sich unabhängig bauen, testen und ausliefern.
Ein Analysewerkzeug
Für statische Binäranalyse gibt es genau einen Tiefenanalysator, die Rhexa Engine. Hopper, IDA, JEB, Cutter, Rizin und objdump werden schrittweise ersetzt, sobald die Engine die jeweils genutzte Fähigkeit nachweislich abdeckt.
Belege statt Behauptungen
Jede Antwort trägt Artefaktidentität, Engine- und Vertragsversion, Parameter und Fundstelle. Beobachtung, Ableitung, Hypothese und offene Frage bleiben getrennt; fehlende Abdeckung wird offen ausgewiesen.
Headless und eigenständig
Die Engine braucht keine Oberfläche. Sie wird im Repository gebaut, getestet und ausgeliefert und folgt Ghidra nicht per Merge; Sicherheitskorrekturen werden einzeln und nachvollziehbar übernommen.
Ausgangslage
RHEXA beginnt nicht bei null. Es führt zwei ausgereifte Open-Source-Projekte zusammen, deren Stärken sich ergänzen, die aber jeweils für einen anderen Zweck gebaut wurden.
REA – die Agentenschicht
„Reverse Engineer Anything“ ist ein MCP-Server mit Kommandozeile, über den
KI-Agenten native Programme, Web- und Electron-Anwendungen, .NET, Android,
Firmware, WebAssembly und mehr untersuchen. Übernommen bei Commit
efbc486.
- 207 Werkzeuge im MCP-Katalog, rund 300.000 Zeilen Produktions- und 186.000 Zeilen Testcode
- Mehrere Tiefenanalysatoren nebeneinander: Ghidra, Hopper und IDA, dazu objdump, Rizin, Cutter und JEB
- Ghidra musste separat installiert werden; die Brücke wurde bei jedem Start als Skript mit dem Java-Compiler übersetzt
- Kein reproduzierbarer Nachweis, ob eine Änderung Analysen wirklich besser macht
- Die Linux-Prüfläufe gegen echtes Ghidra liefen nicht in der CI und hatten unbemerkt veraltete Erwartungen
Ghidra – die Analyse-Engine
Das Software-Reverse-Engineering-Framework mit einem der besten frei verfügbaren Decompiler, Prozessormodellen für dutzende Architekturen und umfangreichen Analysemodulen. Übernommen als unveränderter Quellstand ohne Git-Historie.
- Rund 2,28 Mio. Zeilen Java in 12.837 Dateien, dazu nativer C++-Code für Decompiler und Sleigh
- Als Desktop-Werkzeug gebaut: rund 830.000 Zeilen Swing-Oberfläche mit 240 Plugins
- Mehrbenutzer-Server, Debugger, Versionsverwaltung, Grafik- und Diff-Ansichten, die für automatisierte Analyse nicht gebraucht werden
- Java 21 als Mindestversion, Build auf Gradle 8.5 ausgelegt
- 153 bekannte Schwachstellen-Funde in mitgelieferten Fremdbibliotheken, vor allem im Server-Teil
Warum eine eigene Ableitung?
Ein KI-Agent braucht keine Fenster, sondern schnelle, belegte Antworten. Headless nutzt RHEXA nur rund 19 % der Engine-Klassen. Der Rest kostet Startzeit, vergrößert die Angriffsfläche und erschwert die Weiterentwicklung. Mit einer eigenen, schlanken Engine im selben Repository lassen sich Analyse und Agentenschicht gemeinsam verbessern, gemeinsam testen und als ein Produkt ausliefern.
RHEXA ist ein unabhängiges Projekt. Es steht in keiner Verbindung zu den Autoren von REA oder zur National Security Agency und wird von ihnen weder unterstützt noch empfohlen. Der eigene Name ist notwendig, weil die Apache-Lizenz keine Rechte am Namen „Ghidra“ einräumt und „REA“ zum Original gehört.
Arbeitsweise
So beantwortet RHEXA eine Frage wie „Welche Funktion prüft den Lizenzschlüssel, und mit welcher Konstante?“
Frage stellen
Der Agent formuliert eine konkrete Analysefrage und öffnet das Zielprogramm über
open_binary. RHEXA bestimmt Format, Architektur und passenden
Analysepfad.
Analysieren
Die Rhexa Engine importiert das Programm headless, erkennt Funktionen, Referenzen und Datentypen und dekompiliert bei Bedarf. Die Zieldatei selbst wird nie verändert.
Gezielt nachsehen
Statt ganze Inventare zu laden, ruft der Agent nur die Werkzeuge auf, die er braucht: Zeichenketten, Prozeduren, Pseudocode, Speicherinhalte. Schemas werden erst bei Bedarf geladen.
Belegt antworten
Jedes Ergebnis landet mit Herkunft im Evidence-Ledger. Die Antwort nennt Adresse, Konstante und Fundstelle; Unbekanntes wird als unbekannt markiert.
Laufzeit ergänzen
Wo statische Analyse nicht reicht, beobachtet RHEXA Prozesse, Browser oder Frida-Sitzungen und verknüpft die Laufzeitbelege mit dem statischen Modell.
Messen
Ein reproduzierbarer Benchmark prüft jede Änderung auf Qualität, Token, Kosten, CPU und Speicher. Eine Verbesserung, die Belege verliert, zählt nicht.
Was bereits besser ist
Jede Änderung ist ein eigener, nachvollziehbarer Commit mit Begründung und Prüfung.
| Bereich | Vorher | Jetzt |
|---|---|---|
| Testabdeckung der Agentenschicht | 90,8 % Zeilen / 82,0 % Branches | 97,1 % / 91,3 % |
| Abhängigkeiten | teils veraltet | alle npm-Pakete und CI-Aktionen auf aktuellem stabilem Stand |
| Schwachstellen-Prüfung | keine Baseline | npm: 690 Pakete, 0 Funde · Engine: regelmäßiger OWASP-Scan |
| Schwachstellen-Funde der Engine-Distribution | 153 (17 kritisch) | 12 (0 kritisch) |
| Java und Build | Java 21, Gradle 8.5+, über 2.000 Gradle-Warnungen | Java 25 (LTS), Gradle 9.8.1 mit geprüfter Prüfsumme, Altlasten bereinigt |
| Engine-Umfang | vollständige Desktop-Anwendung mit Server und Debugger | Server, 28 Module und rund 1.450 GUI-Quelldateien entfernt; GUI-Ausbau läuft |
| Nachweis von Verbesserungen | keiner | Aufgaben-Benchmark mit Baseline, Vergleich mit Toleranz |
| Fehlgriffe des Agenten vor dem Öffnen eines Ziels | 7 pro Benchmark-Lauf | 0, Token-Median −11 % |
| Prüfläufe gegen die Engine | nicht in CI, teils mit veralteten Erwartungen | 13 von 19 grün gegen den Eigenbau, eigene Engine-CI |
Änderungen gegenüber REA
- Tests deutlich ausgebaut Abdeckung um 6 bzw. 9 Prozentpunkte erhöht, Schwellen angehoben.
- Alle Abhängigkeiten aktuell npm-Pakete und GitHub Actions auf den neuesten stabilen Stand, Node.js-Mindestversion angehoben.
- Schwachstellen-Scan npm audit und OSV-Scanner mit befristeter Ausnahmeliste.
- Fehler im Sitzungslebenszyklus behoben Ein erneutes Öffnen desselben Ziels startete die Engine vorzeitig und konnte eine geänderte Quelldatei übersehen. Der Fehler besteht im Original.
- Reproduzierbarer Aufgaben-Benchmark Fünf Analyseaufgaben mit Antwortschlüssel, isolierter Agent, Messung von Qualität, Token, Kosten, CPU und Speicher.
- Bessere Agentenführung Ein Hinweis in den Server-Anweisungen beseitigte alle Aufrufe vor dem Öffnen eines Ziels.
- Prüfskripte korrigiert Drei veraltete Erwartungen in den Ghidra-Prüfläufen (MIPS-Attribute, Ablehnung beschnittener ELF-Dateien, CET-Sprungbefehle), die ebenfalls im Original stecken.
Änderungen gegenüber Ghidra 12.1.4
- Ghidra-Server entfernt Mehrbenutzer-Server samt Dienstwrapper und veralteter Netzwerkbibliothek ausgebaut.
- Moderne Toolchain Java 25 als Mindestversion und Bytecode-Ziel, Gradle 9.8.1, Gradle-10-Altlasten in 32 Build-Skripten bereinigt.
- GUI-Ausbau, Welle 1 28 Module ohne Bedeutung für die Headless-Analyse entfernt, darunter der Debugger-Komplex, Diff- und Graph-Ansichten; verifiziert mit Prüfläufen, Unit- und Integrationstests.
- Eigene Engine-CI Build, Unit-Tests, Abdeckung und Schwachstellen-Scan laufen getrennt von der Agentenschicht.
- Sicherheitsnetz für den Umbau 128 headless Integrationstest-Klassen mit 1.832 Tests, dazu über 8.000 Unit-Tests, die Prüfläufe der Agentenschicht und der Benchmark.
Messwerte
| Messung | Ergebnis |
|---|---|
| Aufgaben-Benchmark (Baseline) | 30 von 30 Läufen erfolgreich, keine falsche Behauptung |
| Aufgaben-Benchmark nach dem GUI-Ausbau | 30 von 30 Läufen erfolgreich, keine falsche Behauptung, Kosten wie Baseline (10,68 statt 10,59 USD) |
| Aufgaben-Benchmark mit kompakter Ergebnislieferung (Paket B) | 30 von 30 Läufen erfolgreich, keine falsche Behauptung; Tool-Antworten −30 %, 4,12 statt 4,87 Mio. Token (−15,5 %), 10,46 statt 10,68 USD |
| Prüfläufe der Agentenschicht gegen die Engine | 13 von 19 bestanden, keiner scheitert an der Engine; 6 brauchen macOS, Windows oder neuere Compiler |
| Engine-Unit-Tests (ohne Oberfläche) | 7.001 Fälle, 0 Fehlschläge |
| Headless Integrationstests | 429 Tests, 0 Fehlschläge |
Startzeit analyzeHeadless (kleine ELF, ohne Analyse, Median) | Ghidra 12.1.4: 4,81 s · RHEXA-Engine: 4,12 s (−14 %) |
| Headless geladene Engine-Klassen | 3.878 von 19.996 |
Roadmap
Zwei Spuren laufen parallel: die Agentenschicht (TypeScript) und die Engine (Java/C++). Zwischen den Phasen liegen Gates. Ein Gate gilt nur als bestanden, wenn der Benchmark keine Belege verliert und nicht mehr Token braucht. Zeiträume sind Planungsrahmen für einen bewusst engen ersten Umfang, keine Zusagen.
Phasen im Überblick
- Eigenbau auf Java 25 und Gradle 9.8.1, Tests und Abdeckungs-Baseline
- Schwachstellen-Baselines beider Stacks, Ghidra-Server entfernt
- Aufgaben-Benchmark mit Baseline, Engine-CI, Fehler im Sitzungslebenszyklus behoben
- ✓ Vorab: Ghidra-Server entfernt (Schwachstellen-Funde 153 → 12)
- ✓ Welle 1: 28 Module ohne Headless-Bedeutung entfernt (Debugger, Emulation, ByteViewer, Diff- und Graph-Ansichten)
- ✓ Welle 2: rund 1.450 unerreichbare Quelldateien und über 200 GUI-Tests entfernt
- ✓ Welle 3: 69 oberflächenfreie Klassen aus den Fenster-Modulen in das GUI-freie Basismodul verschoben
- ✓ Welle 4: Einfallstore entkoppelt: Optionen und Hilfe-Verweise, Farben und Icons, Task-Ausführung, Rückfragen, Skript-Dialoge
- ✓ Welle 5: Kanten vom Headless-Kern in die Oberfläche gekappt, Fenster-, Hilfe- und Theme-Framework samt Werkzeugschicht gelöscht; die Engine ist rein headless und startet 14 % schneller
- Umbenennung in RHEXA einschließlich Branding der Engine (erledigt)
- Brücke zur Engine als echtes, getestetes Engine-Modul (erledigt)
- Ein gemeinsamer, versionierter Vertrag, geprüft von beiden Stacks (erledigt)
- Sparsamere, aufgabenbezogene Ergebnislieferung (erledigt: Tool-Antworten −30 %)
rhexa engine installmit geprüften Release-Archiven je Plattform- Startzeit weiter verkürzen (Klassenarchiv, schlankere Analyseprofile)
- Erste Fremdwerkzeuge ersetzen: objdump, Rizin, Cutter
- ✓ Umstellung auf die neueste MCP-Revision 2026-07-28 erledigt (ältere Revision nur noch als Übergang; Claude Code spricht bereits die neue)
- Hopper, IDA und JEB entfernen
- Dauerhafte Untersuchungsprojekte und persistente Engine-Projekte
- Ein Feature durchgängig belegen: Oberfläche → nativer Code → Wirkung
- Rekonstruktionen mit ausführbarem Nachweis
- Eigene Analyzer in der Engine, tiefere Typrückgewinnung
- Semantischer Vergleich zweier Builds
- Neue, schlanke Weboberfläche (Thymeleaf), zunächst als Status- und Monitor-Ansicht
- Einheitlicher Transport auf Windows, Anbindung von BSim und Function ID
- Ereignisbasierte Prozessbeobachtung
- Ein Fachmodul nach drei- bis fünftägiger Machbarkeitsprüfung
- Engine-Debugger als Laufzeitquelle prüfen, weitere Toolchain-Sprünge
GUI-Ausbau im Detail
Die Swing-Oberfläche von Ghidra wurde in fünf Wellen entfernt. Jede Welle wurde mit den Prüfläufen der Agentenschicht, den Engine-Unit-Tests und einem Netz headless Integrationstests abgesichert und einzeln committet.
| Welle | Inhalt | Umfang | Stand |
|---|---|---|---|
| Vorab | Ghidra-Server mit Dienstwrapper entfernt | Modul, Skripte, 21 Tests; Schwachstellen-Funde 153 → 12 | erledigt |
| Welle 1 | Module ohne Headless-Bedeutung: Debugger-Komplex, Systememulation, ByteViewer, Diff- und Graph-Ansichten, Screenshot-Generatoren | 28 Module; Distribution 723 MB | erledigt |
| Welle 2 | Quelldateien, die von keinem Headless-Pfad erreichbar sind, ermittelt per Klassengraph (jdeps); dazu die Tests entfernter GUI-Funktionen | rund 1.450 Produktiv- und über 200 GUI-Testdateien; Distribution 644 MB | erledigt |
| Welle 3 | Vom Kern benutzte Klassen der Fenster-Module ohne eigene Oberfläche (Einstellungen, Feldpositionen, Sortierzustand, Filterstrategien, Konstanten, Task-Grundtypen) in das GUI-freie Basismodul Generic verschieben; Java-Pakete bleiben gleich. Swing-Bausteine bleiben für Welle 4 | 69 Klassen und ihre Tests; geprüft mit 13 Lanes, 7.643 Unit- und 1.512 headless Integrationstests | erledigt |
| Welle 4 | Die Einfallstore entkoppeln, über die das Fenster-Framework mitkommt, in Teilschritten: 4a Optionen und Hilfe-Verweise (erledigt: Options-System und Ressourcensuche GUI-frei, Theme-Anbindung über eine Schnittstelle), 4b Farben und Icons (erledigt: Theme-Werte über eine Schnittstelle, Icon-Teil der Datentyp-Hilfen abgespalten), 4c Task-Ausführung (erledigt: Tasks, Rückfragen und HTML-Hilfen GUI-frei), 4d Kommentar-Annotationen, Skript-Header und Datei-Filter (erledigt), 4e Dialoge der Skript-API (erledigt; die Werkzeugschicht folgt mit Welle 5); reine Oberflächenteile fallen in Welle 5 mit ihren Fenstern weg | rund 166 Klassen der Fenster-Module, die der Headless-Betrieb heute zur Laufzeit lädt | erledigt |
| Welle 5 | Abräumen in Teilschritten: 5a Infrastruktur entkoppelt, die nur über eine Kante an der Oberfläche hing (Server-Client, Verknüpfungen, Ghidra-URL-Protokoll, Rückfragen, Theme-Werte), 5b Skript-API ohne Werkzeug (GUI-Methoden wie goTo, show, askValues entfernt, reine GUI-Skripte gelöscht), 5c Kanten gekappt (PDB-Symbolserver, Version-Tracking-API, Dienst-Anbieter per Name, Klick-Handler der Annotationen), 5d Fenster-, Hilfe- und Theme-Framework, Werkzeugschicht und die übrige Oberflächen-Welt gelöscht (rund 2.700 Klassen, 550 Testdateien); was headless gebraucht wird, etwa der SARIF-Import, Jython, der ISF-Server und 17 mitgelieferte Skripte, wurde entkoppelt statt gelöscht. Der Mehrbenutzer-Merge beim Einchecken entfällt (der Ghidra-Server war schon entfernt) | Startzeit 4,81 s → 4,12 s (−14 %), Klassensuche 958 → 386 ms, Modul-JARs 195 → 118; 13 Prüfläufe, 7.001 Unit- und 429 headless Integrationstests grün | erledigt |
Arbeitspakete der Engine
P0 = Voraussetzung, P1 = unmittelbarer Nutzen, P2 = Vertiefung, P3 = spätere Option.
G0 Engine eigenständig lauffähig auf LTS-Toolchain P0 erledigt
- Ziel
- Ein nachweislich bauender, getesteter Engine-Stand ohne Agentenschicht, von dem die Integration startet.
- Umfang
- Build auf Java 25 und aktuellem Gradle, Unit- und Integrationstests mit Abdeckungs-Baseline je Modul, Anhebung des Bytecode-Ziels, eigene Engine-CI, Abhängigkeits- und Schwachstellen-Scan.
- Ergebnis
- Alle Teilschritte erledigt; Ghidra-Server zusätzlich entfernt (153 → 12 Funde).
T0 Fehler beim erneuten Öffnen eines Ziels P0 erledigt
- Befund
- Ein erneutes Öffnen desselben Ziels startete die Engine sofort und konnte danach eine geänderte Quelldatei übersehen.
- Ergebnis
- Im Sitzungslebenszyklus behoben, mit Reproduktionstest; der Prüflauf besteht gegen den Eigenbau.
T1 Umbenennung in RHEXA P0 erledigt
- Umfang
- Anzeigename, Befehl
rhexa, MCP-Schlüssel, Konfigurationsdatei, Paketname, rund 210 Umgebungsvariablen (alte Namen eine Version lang weiter gültig), Dokumentation; Branding der Engine (Anwendungsname, Archiv- und Einstellungsnamen, Startskripte). Java-Pakete bleiben unverändert. - Abnahme
- RHEXA läuft unter eigenem Namen und kollidiert nicht mit einer parallelen Installation des Originals.
- Stand
- Umgestellt sind Name, Befehl
rhexa, MCP-Schlüssel, npm-Paketrhexa-agents, Konfiguration und Dokumentation, außerdem die UmgebungsvariablenRHEXA_*; gesetzteREA_*-Werte gelten mit Hinweis eine Hauptversion lang weiter. Die Prüf-Lanes heißenverify:engine*. Die Engine heißt Rhexa Engine und hat ein eigenes Archiv (rhexaengine_…) und Einstellungsverzeichnis, sodass ein paralleles Ghidra seine Einstellungen behält. Interne Präfixe (temporäre Verzeichnisse, Klassennamen der Brücke) bleiben bewusst, weil sie nach außen nicht sichtbar sind.
G1 Repo-Integration und Richtlinien P0 erledigt
- Umfang
- Lizenzdokumente beschreiben die Engine als abgeleitetes Werk, eigene Engine-Richtlinien für Herkunft, Einzelübernahmen aus Upstream und Sicherheitsdurchsicht, Build-Integration in die Repository-Werkzeuge.
- Abnahme
- Die TypeScript-Prüfungen bleiben unberührt vom Java-Teil; Lizenzdokumente nennen die Engine.
- Ergebnis
- Lizenzdokumente beschreiben Rhexa Engine als abgeleitetes Werk unter Apache 2.0. Alle 392 geänderten Upstream-Dateien tragen den von Apache 2.0 verlangten Änderungshinweis, die Engine-CI prüft das gegen den Upstream-Stand. Eigene Engine-Richtlinien regeln Herkunft, Übernahmen und Sicherheitsprüfung;
npm run engine:buildbaut die Engine aus den Repository-Werkzeugen.
G2 Brücke als Engine-Modul und gemeinsame Vertragsquelle P0 erledigt
- Umfang
- Die Brücke wird ein kompiliertes, mit JUnit getestetes Engine-Modul, aufgeteilt in Dispatcher, Serialisierer und Operationsgruppen. Der Vertrag wird als JSON Schema gepflegt, daraus entstehen Typen für TypeScript und Java; ein Handshake prüft die Vertragsversion.
- Abnahme
- Alle 28 Operationen laufen über das Modul, ein absichtlich verstimmtes Schema lässt beide Konformitätstests fehlschlagen, kein Java-Compiler zur Laufzeit.
- Stand
- Die Brücke ist ein Engine-Modul und läuft mit Rhexa Engine vorkompiliert; ein mitgebrachtes Ghidra übersetzt sie wie bisher. Zusammen mit einem umgestellten Windows-Analyzer lädt in keinem Prüflauf mehr eine JVM den Java-Compiler. Die 4.900 Zeilen der Brücke sind in Protokoll, Dispatcher und acht Operationsgruppen zerlegt, und 20 Integrationstests prüfen die Operationen direkt gegen ein importiertes Programm. Ein versionierter Vertrag mit allen 31 Operationen wird aus den Schemas der Agentenschicht erzeugt; beide Seiten prüfen gegen ihn und gegen aufgezeichnete Antworten der echten Brücke, und der Handshake lehnt eine fremde Protokollversion ab.
G3 Engine-Auslieferung und Installation P0 läuft
- Umfang
- Release-Archive je Plattform mit SHA-256-Manifest,
rhexa engine install|status|remove, Diagnoseprüfungen, ein separates Ghidra nur noch als Entwickler-Option. - Abnahme
- Auf einer frischen Maschine mit Java 25 liefert RHEXA nach Installation ohne weitere Schritte Pseudocode.
- Stand
- Für Linux x86-64 erfüllt:
rhexa engine installlädt die Engine von rhexa.janda.io, prüft Größe und SHA-256 und installiert sie; danach liefertrhexa decompilePseudocode, und jede Analyse nennt die Herkunft der Engine. Archive für macOS und Windows folgen.
G4 Startzeit und Ausbau der Swing-Oberfläche P1 läuft
- Ausgangslage
- Headless werden 3.878 von 19.996 Klassen geladen; die Oberfläche ist mit dem Kern nur an rund 165 Stellen verflochten (Einstellungen, Task-Monitore, Optionen, Farben).
- Umfang
- Wellenweise: ungenutzte Module entfernen, unerreichbare Klassen löschen, verflochtene Kernklassen in ein oberflächenfreies Modul verschieben, Fenster-, Hilfe- und Theme-Framework entfernen, GUI-only-Bibliotheken streichen; Startzeit über Klassenarchiv und schlankere Analyseprofile senken.
- Abnahme
- Nach jeder Welle bestehen Engine-Tests, Prüfläufe und Benchmark; Klassenliste und Startzeit vorher/nachher dokumentiert.
G5 Provider-Konsolidierung P1 läuft
- Reihenfolge
- objdump → Rizin-Einzelbefehle und Cutter (ersetzt durch kuratierte Engine-Skripte) → Hopper → IDA → JEB. Debug-Sitzungen bleiben bis G9.
- Abnahme je Schritt
- Paritäts-Matrix dokumentiert, Werkzeuge auf die Engine umgebunden oder mit Migrationshinweis entfernt, eigene Version mit Breaking-Change-Vermerk.
- Stand
- objdump: Paritäts-Matrix steht. Neues Werkzeug
inspect_object_fileliest Header, Sektionen, Symbole und Relocations von ELF-, PE- und Mach-O-Dateien direkt aus den Originalbytes über den Parser der Engine, große Tabellen seitenweise. Dazu kommen DWARF-Compilation-Units und Zeilentabellen;rhexa engine languageslistet die Prozessorsprachen der Engine mit ihren GNU-Namen.disassemble_rangelistet ganze Sektionen oder Adressbereiche, ohne Daten als Code zu dekodieren. Damit hat jede objdump-Operation ihr Gegenstück, undinspect_with_objdumpist entfernt (Breaking Change mit Migrationstabelle). Offen bleiben Mach-O-Chained-Fixups. Rizin und Cutter: Paritäts-Matrix steht. Freie Befehlszeilen ersetztrun_engine_scriptdurch einen festen, versionierten Skriptkatalog der Engine mit geprüften Parametern:raw_strings(jede Zeichenkette in den Dateibytes),instruction_search(reguläre Ausdrücke über den Befehlstext),function_graph(Basisblöcke und Kanten) undcpp_classes(C++-Klassen mit vtable, Typinfo und Methoden). Für alle übrigen Befehlsfamilien gab es schon ein Engine-Werkzeug. Als Nächstes werdenexecute_rizin_commandund die Cutter-Bridge entfernt.
G6 Persistente Engine-Projekte P1 Phase 3
- Umfang
- Eigenes Projektformat mit Manifest (Artefakt-Hash, Engine-Version, Analyseprofil, Vertragsversion), explizites Öffnen und Speichern, Invalidierung bei geändertem Artefakt, langlebiger Engine-Dienst mit mehreren Programmen.
- Abnahme
- Untersuchung nach Neustart fortsetzbar, geändertes Binary erzeugt eine neue Artefaktversion.
G7 Eigenständige Engine-Weiterentwicklung P1 Phase 4
- Umfang
- Entwicklerdokumentation, eigenes Versionsschema, eigene Analyzer und Loader statt Skript-Umwegen: Reparatur fehlerhafter No-Return-Annahmen, MIPS-Soft-Float, PSP, .NET NativeAOT.
- Abnahme
- Ein Engine-Feature lässt sich ohne Änderung an der Agentenschicht entwickeln, testen und ausliefern.
G8 Windows-Vereinheitlichung P2 Phase 5
- Umfang
- Ein Transportpfad für alle Plattformen, Windows verliert den Sonderstatus „nur lesend“.
G9 Engine-Debugger als Laufzeitquelle P3 Phase 6
- Umfang
- Machbarkeit prüfen, ob statische und dynamische Belege im selben Programmmodell zusammengeführt werden können; erst nach erfolgreicher Machbarkeit eine Entscheidung.
Arbeitspakete der Analyse
A Reproduzierbare Aufgaben-Benchmarks P0 Baseline liegt vor
- Problem
- Eine neue Funktion oder kürzere Antwort ist noch kein Nachweis für bessere Analyse.
- Umfang
- Korpus aus selbst gebauten Programmen mit bekannten Lösungen: Funktion finden, Dateischreibvorgang erklären, Änderung zwischen zwei Builds erkennen, statischen Aufruf dynamisch prüfen, Funktion nachimplementieren.
- Nächste Schritte
- Schwerere Varianten (gestrippte und optimierte Builds, indirekte Aufrufe), damit auch Qualitätsgewinne messbar werden.
B Aufgabenbezogene, sparsame Ergebnislieferung P0 erledigt
- Umfang
- Bei Inventarfragen zuerst Zusammenfassungen, gelesene Belege referenzieren statt erneut senden, doppelte Serialisierung vermeiden; optional hybride Suche aus Symbolen, Volltext und semantischer Suche.
- Abnahme
- Weniger Gesamt-Token im Benchmark bei gleicher Antwortqualität.
- Stand
- Erster Schritt erledigt: Das Opt-in-Profil
RHEXA_MCP_RESULT_TEXT_PROFILE=compactliefert Ergebnisse ohne doppelte Kopie und ohne wiederholtes Analyseprofil; die Sitzung behält die vollständigen Belege.rhexa setupsetzt es für Claude Code automatisch. Im Benchmark 30 % kleinere Tool-Antworten und 15,5 % weniger Token bei gleicher Qualität (30 von 30 Läufen). Eine neue Aufgabe auf einem großen, statisch gelinkten Programm zeigt: Agenten finden dort per Suche statt per Gesamtliste zum Ziel (6 von 6 richtig); eigene Inventar-Zusammenfassungen sind deshalb nicht nötig.
C Dauerhafte Untersuchungsprojekte P1 Phase 3
- Umfang
- Benannte Projekte mit automatischer Sicherung, Manifest, Hypothesen und Gegenbelegen, Wiederaufnahme nach Neustart.
- Abnahme
- Eine Untersuchung läuft nach Neustart weiter; widersprüchliche Belege werden sichtbar.
D Durchgängige Verfolgung eines Features P1 Phase 4
- Umfang
- Eine Frage wie „Was passiert beim Speichern?“ wird zu einer belegten Kette von der Oberfläche über den nativen Code bis zur Wirkung, statisch und zur Laufzeit.
- Abnahme
- Ein bekanntes Fixture liefert eine belegte Kette, auch unter Adressraum-Randomisierung.
E Ereignisbasierte Prozessbeobachtung P1/P2 Phase 6
- Umfang
- Plattformadapter für Prozessstart, Ende, Neustart und Kindprozesse.
- Abnahme
- Auch sehr kurzlebige Kindprozesse werden erkannt.
F Tiefere native Typ- und Aufrufanalyse P1/P2 Phase 4
- Umfang
- Struktur-Layouts, Argumenttypen, Funktionszeiger und virtuelle Aufrufe, berechnet in der Engine.
- Abnahme
- Ein selbst gebautes Fixture mit Vererbung und Funktionszeigern wird korrekt rekonstruiert.
G Semantischer Versionsvergleich P1/P2 Phase 5
- Umfang
- „Welche bisherigen Aussagen und Erweiterungspunkte müssen nach einem Update neu geprüft werden?“ – Zuordnung umbenannter und verschobener Funktionen über Builds hinweg.
- Abnahme
- Zwei Builds mit bekannten Änderungen werden korrekt zugeordnet.
H Von Rekonstruktion zu ausführbarem Nachweis P1 Phase 4
- Umfang
- Aus Anforderungen an eine Rekonstruktion entstehen Testgerüste und Eingabekorpora, die Original und Nachbau vergleichen.
- Abnahme
- Eine absichtlich falsche Rekonstruktion wird zurückgewiesen.
I Neue Analyseoberfläche P2 Phase 5
- Umfang
- Serverseitig gerenderte Weboberfläche mit Thymeleaf, zunächst als Status- und Monitor-Ansicht für Sitzungen, Engine-Prozesse, Provider und Benchmark-Läufe, danach als lesende Ansicht der Untersuchungsakte. Keine eigene Analyse in der Oberfläche.
- Abnahme
- Jede Schlussfolgerung lässt sich bis zu ihrem Beleg aufklappen; fehlende Abdeckung ist sichtbar.
Optionale Fachmodule
| Modul | Erster Umfang | Priorität |
|---|---|---|
| Spiele | Engine und Deploymentform erkennen, Ressourcen, Klassen und Erweiterungspunkte inventarisieren | P1 bei Spielefokus |
| Java/Spring | Ein Spring-Boot-Archiv untersuchen: REST-Routen, Services, Konfigurationsbezüge | P1 bei Enterprise-Fokus |
| .NET/C# | Decompiler-Export mit eindeutigen Memberidentitäten verbinden | P2 |
| Protokolle | Wiederkehrende Nachrichten in Mitschnitten strukturieren | P2 |
| Sicherheitsanalyse | Herkunftsbelegte Regeln zu riskanten API-Nutzungen und Datenflüssen | P2/P3 |
| Komponentenherkunft | Paketmetadaten in einen Herkunftsbericht überführen, SBOM-Export | P2 |
| Symbolische Analyse | Eine kleine reine Funktion, eine eng begrenzte Frage | P3 |
Grundsätze
Entscheidungen
- Quellbasis und ToolchainGhidra 12.1.4, Java 25 (LTS), jeweils aktuelle stabile Gradle-Version.
- Ein Repository, zwei StacksEngine als Quellkopie im Repository, eigene Build-, Test- und Lint-Gates je Stack.
- NameRHEXA für Produkt und Engine; Java-Pakete bleiben unverändert, Attribution bleibt erhalten.
- Ein VertragEine Schema-Quelle, generierte Typen und Konformitätstests für beide Seiten.
- Kein Merge mit UpstreamSicherheitskorrekturen werden beobachtet und einzeln mit Herkunft übernommen.
- HeadlessDie Swing-Oberfläche entfällt; eine neue Oberfläche entsteht nur bei Bedarf.
Qualitätsregeln
- Nachweisbarer NutzenJedes Paket braucht einen konkreten Analysefall und einen messbaren Mehrwert.
- BelegeArtefaktidentität, Engine- und Vertragsversion, Parameter, Fundstelle; Fakten, Ableitungen, Hypothesen und offene Fragen getrennt.
- Echte LäufeKeine Unterstützungszusage ohne echten Lauf auf der behaupteten Plattform.
- Untrusted InhalteZeichenketten und Code aus dem Zielprogramm sind Daten, niemals Anweisungen an den Agenten.
- Keine stillen NebenwirkungenStatische Analyse führt das Ziel nie aus; Laufzeitaktionen und Schreibwirkungen sind im Werkzeugvertrag sichtbar.
- Engine-ÄnderungenTest im betroffenen Modul, Eintrag im Herkunftsnachweis, keine Senkung der Abdeckung.
Risiken und Gegenmaßnahmen
| Risiko | Gegenmaßnahme |
|---|---|
| Fehlende Upstream-Sicherheitskorrekturen | Regelmäßige Durchsicht, Einzelübernahme mit Herkunft, eigene Regressionstests für Importer |
| GUI-Ausbau erschwert spätere Übernahmen | Kernklassen nur verschieben, nicht umschreiben; Analyzer, Loader und Prozessoren bleiben unverändert |
| Fähigkeitsverlust beim Entfernen von Providern | Paritäts-Matrix und Gate vor jeder Entfernung, Übergangsphase, Breaking-Change-Vermerk |
| Vertrag läuft auseinander | Eine Schema-Quelle, Generatoren, Golden-Beispiele für beide Seiten |
| Umfang wächst | Gates mit Benchmark; die Analyse-Pakete laufen unabhängig von der Engine-Arbeit |
Lizenz und Namensnennung
Agentenschicht
Beruht auf REA von morluto, veröffentlicht unter der MIT-Lizenz. Der ursprüngliche Copyright-Vermerk bleibt in allen Kopien erhalten.
Rhexa Engine
Abgeleitet von Ghidra, veröffentlicht unter der Apache License 2.0. Lizenztext,
NOTICE-Datei und alle Namensnennungen bleiben erhalten; jede Abweichung
ist in engine/UPSTREAM.md dokumentiert. Ghidra-Logos werden nicht
verwendet.