ReAgent: C/C++-Funktionen aus Binaries rekonstruieren, mit Ghidra und LLM-Kreuzprüfung

Ein Problem, das klassische Dekompiler offen lassen

Ein Dekompiler liefert Pseudocode, der kompiliert, aber selten dem Original ähnelt. Variablennamen sind verloren, Strukturen sind zu Byte-Offsets verflacht, und ob die rekonstruierte Funktion sich semantisch wie das Original verhält, sagt der Dekompiler nicht. ReAgent setzt genau an dieser Lücke an: Das Projekt beschreibt sich als Agent, der C/C++-Funktionen aus kompilierten Binaries rekonstruiert und anschließend validiert. Zielgruppe sind laut README Reverse-Engineering-Arbeiten an größeren C++-Codebasen, für die Profilnamen wie gta-reversed und openrct2 als Beispiele genannt werden. Es geht also nicht um einzelne Crackmes, sondern um Funktionen, die in einen bestehenden Quellbaum passen müssen.

Der Ablauf: Kontext sammeln, schreiben, gegenprüfen, bauen

Der dokumentierte Ablauf von re-agent reverse beginnt mit Konfiguration aus YAML, Umgebungsvariablen und CLI-Flags. Danach folgt die Funktionsauswahl, wählbar über dependency-order, easiest-first oder high-impact. Für die gewählte Funktion sammelt der Agent Kontext: Dekompilat, Xrefs, Structs, Enums, Vtables, Globals und Strings, dazu normalisierten High-P-Code, CFG, Assembly und benachbarten Projektquelltext. Ein Reverser-Modell erzeugt einen Kandidaten, ein Checker-Modell prüft ihn, und eine begrenzte Fix-Schleife läuft, bis die konfigurierten Runden oder Investigations aufgebraucht sind. Danach greifen ein struktureller Verifier, ein Kandidaten-Overlay mit Build-, Test- und Runtime-Gates sowie ein Parity-Gate, das GREEN, YELLOW oder RED ausgibt. Wichtig für die Erwartungshaltung: Das Tool patcht den Originalquellbaum nicht. Es erzeugt Kandidaten, die ein Mensch übernehmen muss.

Vier Bedingungen statt einer Bestätigung

ReAgent akzeptiert eine Rekonstruktion nur, wenn vier voneinander unabhängige Bedingungen erfüllt sind: Das Checker-Modell gibt PASS zurück, der objektive Verifier findet keine starke strukturelle Abweichung, die Kandidatenvalidierung erfüllt die konfigurierte Akzeptanzrichtlinie, und die Parity ist nicht durch die RED/YELLOW-Richtlinie blockiert. Das README formuliert die Grenze selbst: konservative Verifikation, kein Beweis semantischer Äquivalenz. Diese Formulierung ist ehrlich und sollte ernst genommen werden. Ein PASS des Checkers ist ein Modellurteil, kein Theorem. Wer ReAgent einsetzt, um Binäräquivalenz nachzuweisen, missversteht das Design. Wer es einsetzt, um Kandidaten zu sortieren, die ein Mensch danach prüft, nutzt es wie vorgesehen.

Installation und Konfiguration: Bridge zuerst, Modell danach

Der Einstieg läuft über PyPI und setzt Python 3.10 oder neuer sowie Git voraus. Die Installation inklusive Ghidra-Bridge lautet python3 -m pip install --upgrade "auto-re-agent[ghidra-bridge]>=0.4.0". Für headless Exporte gibt es das Extra headless, das PyGhidra mitbringt. Vor dem ersten Reverse-Lauf muss die Evidenzbasis stehen: ghidra-bridge init erzeugt ghidra-bridge.yaml, deren Ghidra-Projekt- und Programmpfade zu editieren sind, danach folgen ghidra-bridge export all, optional ghidra-bridge build-map und zur Kontrolle ghidra-bridge info. Im Zielprojekt erzeugt re-agent init --profile generic-cpp die Datei re-agent.yaml. Mindestens zu setzen sind ein LLM, der Pfad zur Bridge und die Quellpfade. Das README zeigt als Beispiel llm.provider: claude-cli mit model: sonnet und optional einen abweichenden Checker, etwa agents.checker.provider: codex mit model: gpt-5.4. Als Backend dient backend.type: ghidra-bridge mit cli_path: ghidra-bridge. Ohne --profile bleiben die ursprünglichen GTA-reversed-Defaults aktiv, was für neue Projekte eine stille Fehlerquelle ist.

Manifeste, Evidenz und Status: der Nutzen von 0.4.0

Version 0.4.0 ergänzt Arbeitsabläufe, die ohne Modellaufrufe auskommen. re-agent plan baut begrenzte Funktionsmanifeste. re-agent reverse --manifest rekonstruiert ausgewählte Funktionen über mehrere Klassen hinweg, mit Abhängigkeitsreihenfolge und kumulativer Validierung in einer isolierten Projektkopie. re-agent evidence --manifest exportiert gespeicherte Evidenz in verlinkte JSON-Pakete und TSV-Indizes, und re-agent status --manifest meldet Abdeckung, veraltete Ergebnisse und einzelne Validierungsprüfungen. Für größere Codebasen ist das der praktischste Teil des Releases: Man kann den Umfang festlegen und den Fortschritt beobachten, ohne für jede Planungsfrage ein Modell zu bezahlen. Die Release Notes nennen außerdem, dass Evidenzlücken explizit bleiben und Manifeste nach Backend-Fehlern mit leeren Meldungen lesbar bleiben.

Validierungskommandos: der Windows-Stolperstein

Die Release Notes zu 0.4.0 benennen eine Einschränkung, die vor dem ersten Lauf geklärt werden sollte. Build-, Test- und Runtime-Validierung unterstützen Argument-Arrays, die direkt unter Windows und POSIX ausgeführt werden. Unter nativem Windows müssen Shell-Strings in Arrays umgewandelt werden, und Altbestände mit Strings benötigen weiterhin /bin/sh. re-agent doctor meldet eine fehlende Shell. Das ist keine Randnotiz: Wer auf Windows arbeitet und die Validierungskommandos aus einer älteren Konfiguration übernimmt, bekommt möglicherweise keine belastbare Kandidatenvalidierung, und damit fällt eine der vier Akzeptanzbedingungen weg. Die Dokumentation verweist dazu auf docs/configuration.md und den Abschnitt zu portablen Validierungskommandos sowie auf den Setup-Workflow in docs/agent-setup.md.

Kosten, Wartung und Lizenz

Der Ablauf ist modellgetrieben: Reverser, Checker und die begrenzte Fix-Schleife erzeugen mehrere Aufrufe pro Funktion. Das README empfiehlt in der Setup-Anweisung ausdrücklich, einen kleinen Modellaufruf-Grenzwert zu setzen und die API-Kosten vorab zu klären. Wer den Agenten über ein Manifest auf hunderte Funktionen laufen lässt, sollte diese Grenze bewusst wählen. Als Wartungsaufwand kommen drei bewegliche Teile zusammen: die Python-Pakete auto-re-agent und ghidra-bridge, die Ghidra-Installation samt Bridge-Konfiguration und die Provider-Anbindung, sei es ein API-Schlüssel wie ANTHROPIC_API_KEY oder OPENAI_API_KEY oder eine authentifizierte lokale claude- beziehungsweise codex-CLI. Die Lizenz ist MIT, was die Nutzung und Weitergabe des Codes erlaubt; ob und wie die Lizenz der analysierten Binaries oder des rekonstruierten Quellcodes die Veröffentlichung von Rekonstruktionen einschränkt, regelt ReAgent nicht, und das ist eine Frage für die Rechtsabteilung, nicht für dieses Werkzeug.

Wann ein anderer Ansatz besser passt

Der naheliegende Vergleich ist Ghidras eingebauter Dekompiler, der ohne Modellkosten und ohne Provider-Konfiguration auskommt und dessen Ausgabe deterministisch ist. ReAgent nutzt Ghidra-Exporte als Eingabe und legt eine Ebene darüber: Modellkreuzprüfung, Build- und Testgates, Parity-Bewertung. Der Preis dafür ist Nichtdeterminismus, Abhängigkeit von externen Diensten und ein Setup, das ohne funktionierende Bridge nicht startet. Für eine einmalige Analyse, bei der ein erfahrener Analyst den Pseudocode ohnehin selbst liest, ist der zusätzliche Apparat schwer zu rechtfertigen. Interessant wird ReAgent dort, wo viele Funktionen gegen einen bestehenden Quellbaum rekonstruiert und die Ergebnisse reproduzierbar dokumentiert werden müssen, etwa mit den Profilen gta-reversed oder openrct2 und den Manifest-Werkzeugen aus 0.4.0.

Redaktionelles Fazit

Sinnvoll ist ReAgent für Teams, die bereits eine Ghidra-Bridge betreiben, mehrere LLM-Provider zur Verfügung haben und pro Funktion einen Modellaufruf-Budgetrahmen akzeptieren. Wer nur schnell Pseudocode lesen will, ist mit Ghidras eigenem Dekompiler besser bedient. Vor dem ersten Lauf mit re-agent doctor prüfen, ob Shell, Bridge und Provider erkannt werden, und die Validierungskommandos auf Argument-Arrays umstellen, weil unter nativem Windows Shell-Strings laut Release Notes weiterhin /bin/sh erfordern.

Offizielle Quellen

1. Dryxio/reagent on GitHub
2. Issues
3. License: MIT
4. README
5. Releases