RHEA
Retargetable Headless Executable Analyzer
Reverse Engineering für KI-Agenten: Ein Agent stellt eine konkrete Frage an ein Programm, RHEA beantwortet sie über mehrere Analyseverfahren hinweg und legt jeden Befund mit Belegen offen. Die statische Tiefenanalyse übernimmt die Rhea Engine, eine eigenständig weiterentwickelte, rein headless Ableitung von Ghidra, die fest in RHEA integriert ist.
Überblick
RHEA 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 Rhea 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
RHEA 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 RHEA 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.
RHEA 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 RHEA 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. RHEA bestimmt Format, Architektur und passenden
Analysepfad.
Analysieren
Die Rhea 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 RHEA 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 und 28 Module 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. Prüfung läuft.
- 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 9.750 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 |
| 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 | 9.750 Fälle, bekannte Fehlschläge fast nur in GUI-Tests |
| Headless Integrationstests | 1.832 Tests, 0 Fehlschläge |
| Headless geladene Engine-Klassen | 3.878 von 19.996 |
| Von Headless-Pfaden unerreichbare Klassen | 5.124 (Kandidaten für Welle 2) |
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
- Welle 1: 28 Module ohne Headless-Bedeutung (in Prüfung)
- Welle 2: rund 2.000 Quelldateien, die von keinem Headless-Pfad erreichbar sind
- Weitere Wellen: Kernklassen von Oberflächen-Typen lösen, dann Fenster-, Hilfe- und Theme-Framework entfernen
- Startzeit messen und senken
- Umbenennung in RHEA einschließlich Branding der Engine
- Brücke zur Engine als echtes, getestetes Engine-Modul
- Ein gemeinsamer, versionierter Vertrag mit Generatoren für beide Stacks
- Sparsamere, aufgabenbezogene Ergebnislieferung
rhea engine installmit geprüften Release-Archiven je Plattform- Startzeit verkürzen, GUI-Ausbau abschließen
- Erste Fremdwerkzeuge ersetzen: objdump, Rizin, Cutter
- 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
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 RHEA P0 Phase 1
- Umfang
- Anzeigename, Befehl
rhea, MCP-Schlüssel, Konfigurationsdatei, Paketname, 79 Umgebungsvariablen (alte Namen eine Version lang weiter gültig), Dokumentation; Branding der Engine (Anwendungsname, Archiv- und Einstellungsnamen, Startskripte). Java-Pakete bleiben unverändert. - Abnahme
- RHEA läuft unter eigenem Namen und kollidiert nicht mit einer parallelen Installation des Originals.
G1 Repo-Integration und Richtlinien P0 Phase 1
- 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.
G2 Brücke als Engine-Modul und gemeinsame Vertragsquelle P0 Phase 1
- 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.
G3 Engine-Auslieferung und Installation P0 Phase 2
- Umfang
- Release-Archive je Plattform mit SHA-256-Manifest,
rhea engine install|status|remove, Diagnoseprüfungen, ein separates Ghidra nur noch als Entwickler-Option. - Abnahme
- Auf einer frischen Maschine mit Java 25 liefert RHEA nach Installation ohne weitere Schritte Pseudocode.
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 Phase 2–3
- 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.
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 Phase 1
- 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.
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.
- NameRHEA 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.
Rhea 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.