ReAgent : reconstruire des fonctions C/C++ depuis un binaire compilé

Le problème : retrouver du code source à partir d'un binaire sans traitement de masse

Un décompilateur classique rend du pseudo-code lisible mais rarement compilable. ReAgent vise le chaînon suivant : produire une fonction C/C++ qui se compile, passe les tests configurés et reste structurellement cohérente avec le binaire d'origine. Le README précise que l'outil génère des implémentations candidates et ne modifie pas automatiquement l'arbre source d'origine. Le public visé est donc l'ingénieur qui travaille sur un projet dont il possède déjà la base Ghidra et les sources partielles, par exemple une reconstruction de jeu ou un composant dont le code a été perdu. Les profils livrés (generic-cpp, windows-x64, gta-reversed, openrct2) donnent une idée du terrain : des projets où l'on connaît déjà les conventions de compilation et où l'on peut compiler la cible.

Reverser, checker, portes de validation : quatre conditions indépendantes

L'architecture décrite dans le README est un pipeline. La commande re-agent reverse sélectionne des fonctions selon un ordre de dépendance, easiest-first ou high-impact, puis rassemble le contexte : décompilation, xrefs, structures, énumérations, vtables, globales, chaînes, ainsi que le P-code normalisé, le CFG et l'assembleur. Un modèle reverser propose une implémentation, un modèle checker l'évalue, et une boucle de correction bornée s'exécute en nombre de tours et d'investigations limité. Vient ensuite un vérificateur structurel qualifié de conservateur, puis une superposition candidate soumise aux portes de compilation, de test et d'exécution définies dans la configuration. La parité est classée GREEN, YELLOW ou RED. Le README énonce quatre conditions pour qu'un reversal soit considéré comme réussi : le checker renvoie PASS, le vérificateur objectif ne trouve pas de divergence structurelle forte, la validation candidate satisfait la politique d'acceptation, et la parité n'est pas bloquée par la politique RED/YELLOW. La documentation est explicite : il s'agit d'une vérification conservatrice, pas d'une preuve d'équivalence sémantique. C'est la phrase la plus importante du dépôt, et elle doit guider l'usage.

Installation : PyPI, bridge Ghidra et configuration YAML

L'installation recommandée passe par PyPI avec l'extra du bridge : python3 -m pip install --upgrade "auto-re-agent[ghidra-bridge]>=0.4.0". Pour les exports Ghidra sans interface, l'extra headless s'installe de la même façon. Le bridge lui-même s'initialise dans le projet cible avec ghidra-bridge init, qui crée ghidra-bridge.yaml, puis ghidra-bridge export all, ghidra-bridge build-map pour la carte source, et ghidra-bridge info pour confirmer que les exports sont visibles. Côté ReAgent, re-agent init --profile generic-cpp écrit un re-agent.yaml. Le README indique que lancer re-agent init sans profil conserve les valeurs par défaut héritées de GTA-reversed, ce qui est un piège pour un nouveau projet : mieux vaut un profil explicite. La configuration minimale couvre le fournisseur LLM (claude-cli, codex, ou une API compatible OpenAI), le chemin du bridge via backend.cli_path, les chemins source et les commandes de validation. Un exemple du README montre un checker sur un fournisseur différent du reverser, ce qui est cohérent avec l'idée de modèles indépendants.

Ce que la version 0.4.0 change pour les manifestes et Windows

La 0.4.0 ajoute trois commandes qui ne consomment pas d'appels de modèle : re-agent plan construit des manifestes de fonctions bornés, re-agent evidence --manifest exporte les preuves stockées en paquets JSON liés avec des index TSV, et re-agent status --manifest rapporte la couverture, les résultats périmés et le détail des vérifications. re-agent reverse --manifest reconstruit une sélection de fonctions à travers plusieurs classes, avec ordre de dépendance et validation cumulative dans une copie isolée du projet. Sur le plan pratique, la validation par compilation et test accepte désormais des tableaux d'arguments exécutés directement sous Windows et POSIX ; sous Windows natif, il faut convertir les chaînes shell en tableaux, les chaînes héritées exigeant encore /bin/sh. re-agent doctor signale l'absence de shell. Ce détail compte : une configuration de validation recopiée depuis un projet Linux peut échouer silencieusement sur une machine Windows si elle reste au format chaîne.

La vérification conservatrice a un coût, et le périmètre est étroit

Le point faible est assumé par la documentation elle-même : aucun des quatre critères ne prouve l'équivalence sémantique. Un checker LLM peut renvoyer PASS sur une fonction qui se compile et passe les tests tout en divergeant sur un cas limite non couvert. La valeur de ReAgent dépend donc presque entièrement de la qualité des portes de validation que vous fournissez : sans commandes de compilation et de test réalistes, il ne reste que l'avis du checker et l'analyse structurelle. Autre contrainte : le projet suppose une chaîne Ghidra opérationnelle et un bridge configuré. Si vous n'avez pas de projet Ghidra exportable, l'outil n'a rien à se mettre sous la dent. Le coût en appels de modèle n'est pas chiffré dans le matériel fourni, et la boucle reverser/checker avec investigations bornées reste une dépense récurrente par fonction. Enfin, l'absence de homepage et une documentation qui renvoie largement vers le dépôt du bridge laissent plusieurs zones grises, notamment la politique exacte de parité et le format complet des manifestes.

Face à un décompilateur classique : changer d'objectif plutôt que de méthode

Un décompilateur comme celui intégré à Ghidra produit du pseudo-code pour un humain, sans garantir qu'il compile. ReAgent déplace l'objectif vers un artefact compilable et testable, en acceptant l'incertitude sur la sémantique. La différence n'est pas une question de qualité de sortie mais de critère d'arrêt : là où un décompilateur s'arrête quand la sortie est lisible, ReAgent s'arrête quand quatre conditions sont remplies, dont deux dépendent de votre propre configuration de build et de test. Si vous voulez une sortie déterministe et reproductible à coût nul, un décompilateur seul reste le bon outil. Si vous voulez reconstruire des centaines de fonctions avec une trace de validation par fonction, l'approche agentique a un sens, à condition d'accepter que le résultat soit un candidat et non une vérité.

Maintenance, licence et coût d'exploitation

Le dépôt est actif : trois versions entre juillet et septembre 2026, la dernière datant du jour du dernier push. La licence est MIT, ce qui autorise la réutilisation et la modification, y compris dans un contexte commercial, avec conservation du texte de licence ; ce n'est pas un avis juridique et les dépendances du bridge Ghidra ont leurs propres licences, à vérifier séparément. Le coût de maintenance se répartit sur trois axes. Le premier est la configuration : re-agent.yaml et ghidra-bridge.yaml doivent suivre les évolutions de vos sources et de vos commandes de validation. Le deuxième est le bridge, distribué hors de ce dépôt et dont les extras (ghidra-bridge, headless) doivent rester alignés avec la version de ReAgent. Le troisième est le coût par appel de modèle, qui dépend du fournisseur choisi et de la taille des prompts envoyés au checker. La commande re-agent status --manifest est l'outil à utiliser pour repérer les résultats périmés après une modification de source, plutôt que de relancer une reconstruction complète.

Conclusion éditoriale

ReAgent convient aux équipes qui disposent déjà d'un projet Ghidra exportable et d'un CLI Claude ou Codex authentifié, et qui acceptent qu'une reconstruction soit validée par un faisceau d'indices plutôt que par une preuve. Il ne convient pas à qui cherche un décompilateur déterministe, ni à qui ne peut pas fournir de commandes de compilation et de test pour la cible. Avant d'adopter, lancez re-agent doctor, vérifiez que ghidra-bridge info voit bien les exports, et faites tourner le profil generic-cpp sur une seule fonction pour mesurer le coût en appels de modèle.

Sources officielles

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