Comprendre un binaire.
Justifier chaque réponse.

Quand on analyse un programme sans son code source, il faut retrouver les fonctions utiles, suivre leurs appels et examiner les données qu’elles manipulent. Comprendre une validation demande souvent de passer de l’une à l’autre.

J’ai choisi ce projet pour travailler à la fois sur la cybersécurité et l’IA. Je voulais vérifier si un agent pouvait choisir les bonnes inspections, retrouver la logique d’un programme et appuyer son explication sur ce qu’il avait réellement observé.

J’ai comparé trois façons de donner accès aux informations du binaire. Pour chaque modèle, j’ai mesuré ce que ces approches permettent de résoudre, leur consommation et leurs limites. L’autonomie de l’agent et la fiabilité de son exécution font aussi partie de l’évaluation.

Ghidra est un outil de reverse engineering : il aide à examiner un programme compilé lorsque son code source n’est pas disponible. Il repère les fonctions, chaînes de caractères et références, expose les instructions machine et reconstruit du pseudo-C.

Le pseudo-C n’est pas le code source original. Types, noms et structures peuvent être approximatifs. Le périmètre validé ici est l’analyse statique de binaires Windows PE x86-64.

J’ai écrit le programme Python qui fait travailler ensemble Ghidra, les outils d’inspection et les modèles, puis évalue les réponses. Le modèle propose une action sous forme structurée. Python vérifie ses arguments et les budgets disponibles avant de l’exécuter.

• Extraction structurée et sessions identifiées par empreinte du binaire.
• Outils pour fonctions, chaînes, références, appels et décompilations. Onze outils en V2.5 avec mémoire bornée, désassemblage et blocs de base.
• Budgets de temps, tours, fonctions et lectures. Accès natifs du modèle désactivés.
• Preuves conservées, citations vérifiées, traces et rejeux hors réseau.
• Corpus avec vérité terrain et barème déterministe, sans juge LLM.

Python standard library · Ghidra · Java · PowerShell · Codex app-server isolé

Ghidra analyse le binaire sur ma machine. Les observations sélectionnées sont ensuite envoyées aux modèles distants via Codex et le routeur : les modèles ne tournent donc pas localement.

Ouvrir le schéma en grand

Python limite les actions aux outils prévus. Le modèle ne dispose pas d’un accès libre au shell ou aux fichiers.

1. Préparer le binaire dans une session Ghidra locale.
2. Envoyer l’objectif et un contexte borné au modèle.
3. Contrôler sa décision, puis exécuter l’outil autorisé.
4. Conserver l’observation et mettre à jour l’investigation.
5. Accepter une conclusion seulement si ses citations sont vérifiables.

iVar1 = strcmp(param_1,"banana42");
  return iVar1 == 0;

La V2 conserve 120 résultats : 20 challenges × 3 approches × 2 modèles. Chaque case garde son résultat, y compris les échecs. Les objectifs et critères de résolution sont communs. Les contraintes interactives propres à l’agent sont évaluées séparément.

Les résultats se lisent séparément pour chaque modèle. Ils permettent de comparer les approches sur ce corpus, sans établir qu’un modèle serait meilleur en général.

Après la V2, j’ai ajouté la lecture mémoire bornée, le désassemblage et les blocs de base. Pour maîtriser le budget, les validations V2.5 utilisent uniquement Muse Spark 1.3 avec un effort high.

Dernière validation ciblée : contrôle court réussi, puis MODEL_RESPONSE_INVALID après quatre tours et un outil réussi. Aucun timeout sur cet essai, aucune conclusion évaluable. Les 397 tests déterministes passent. Audits et rejeux sont conformes.

Aucun nouveau garde n’a déclenché dans ce dernier essai : les mesures amont à son déclenchement restent validées par simulation uniquement. Les échecs historiques ne sont pas effacés. La version est figée avec ces limites explicites.

• Données manquantes : en V2, permutation expose la logique mais pas les octets du secret. Des outils trop limités peuvent bloquer une résolution correcte.
• Sélection incomplète : call_chain place un helper au-delà des dix fonctions du résumé fixe.
• Mesures partielles : un compteur Muse Spark 1.3 incomplet est exclu du calcul des tokens, pas des scores. Versions Codex, plafonds de contexte et préparations diffèrent historiquement.
• Transport et protocole : délais, retries et sorties JSON invalides ne démontrent pas une incapacité à résoudre le challenge. La cause exacte du dernier incident reste indéterminée.
• Portée du benchmark : corpus pédagogique avec symboles en V2, une réponse retenue par case, PE x86-64 uniquement. Aucune garantie statistique ou généralisation à tous les binaires réels.

La préparation froide historique contient une mesure exceptionnellement longue dont la cause est inconnue. Elle n’est ni assimilée à du temps CPU ni mélangée aux courbes de réponse.

Ce projet m’a appris à contrôler les actions d’un agent et à vérifier ses preuves. J’ai aussi dû distinguer une réponse incorrecte d’un défaut du barème ou d’un incident technique, pour que les mesures reflètent ce qui s’était réellement passé.