L'ingénierie inverse nécessite-t-elle un modèle plus grand ?

Ce que les modèles plus performants ont changé

Depuis août 2026, j'explore combien de rétro-ingénierie un agent peut effectuer avec accès à un programme et un moyen de vérifier son travail. La majeure partie de mon expérience vient de la reconstruction de jeux, en particulier Touhou. Au fur et à mesure que j'ai changé de modèle, les référentiels ont conservé une trace de ce que chaque session a réussi à récupérer.

Une grande partie du travail vise une reconstruction exacte : nous compilons le code maintenu avec une chaîne d'outils de l'époque dont les versions sont fixées, puis vérifions si elle reproduit la fonction cible. Quand un modèle ultérieur débloque le travail, les changements du code permettent de comprendre ce qui a rendu ce progrès possible.

Les variables temporaires nécessitaient des durées de vie qui se chevauchaient

Une grande partie de la logique d'une fonction d'attaque TH09 avait déjà été reconstruite, mais le compilateur stockait toujours les résultats temporaires différemment de l'original. Le problème restant était de savoir combien de temps ces résultats devaient rester en vie et quand leur stockage pouvait être réutilisé.

Un GPT-6-Sol enregistrement de session a signalé cette incohérence après avoir testé plusieurs arrangements de code source ordinaires. Lorsque GPT-6.1-Sol a réexaminé le problème, il a proposé une hypothèse utile sur la durée de vie de ces variables temporaires.

La fonction produisait des résultats temporaires et les copiait dans des positions d'animation. En C++, un résultat temporaire reste actif jusqu'à la fin de l'expression qui l'utilise. Le regroupement des opérations réelles en une seule expression permettait de conserver ces résultats ensemble, de sorte que le compilateur ne pouvait plus réutiliser le même stockage pour chacun d'entre eux.

Un résultat partageait encore son espace de stockage avec une valeur utilisée plus tard pour les collisions. Donner à cette valeur une durée de vie distincte a éliminé le dernier chevauchement. Après plusieurs expériences ciblées, une recompilation propre a confirmé que la fonction entière correspondait à l'original.

Je suis intéressé par la façon dont la découverte et les tests se sont soutenus mutuellement. L’hypothèse sur la durée de vie des objets temporaires a donné une nouvelle direction à l’agent IA. Les retours du compilateur l'ont aidé à affiner cette hypothèse en un arrangement de code source correspondant.

Un graphique de flux de contrôle différent

Une deuxième fonction TH09 montre pourquoi cette nouvelle direction peut être importante. Ici, l'obstacle était la façon dont plusieurs branches partageaient leur travail final. Les travaux antérieurs de GPT-6.1-Sol ont permis de faire correspondre certaines parties de la fonction, mais les branches se sont toujours jointes différemment de l'original.

GPT-6-Astra a modifié le graphique de flux de contrôle environnant. Les chemins principaux menaient désormais à une mise à jour finale et à un retour partagés. Dans cette structure source, le compilateur combinait les branches de la même manière que l'original. La fonction complète correspondait et une vérification de reconstruction distincte l'a confirmée.

Changer la représentation a ouvert un espace de recherche plus productif. Les deux cas me donnent une raison de prendre au sérieux la capacité générale du modèle : un agent peut continuer à essayer des variantes locales pendant longtemps avant de trouver une meilleure façon d'exprimer le travail environnant.

Les sessions ultérieures ont aussi hérité du code précédent et des échecs documentés. Ce travail accumulé faisait partie de leur avantage. L'historique permet d'examiner les découvertes et leurs vérifications ; une comparaison contrôlée aiderait à séparer l'effet du modèle de celui de l'expérience héritée.

C'est ce qui rend la question intéressante pour moi. Certains progrès sont venus de la recherche d'une nouvelle représentation. Une grande partie du travail restant consistait à tester différentes dispositions de code source par rapport à un compilateur familier. Dans quelle mesure cela nécessite-t-il une grande capacité de raisonnement ? Combien un modèle pourrait-il apprendre en travaillant de manière répétée avec ce compilateur et ce code ?

Pourquoi un modèle d’IA spécialisé pourrait-il fonctionner correctement ?

Touhou nous donne une raison concrète d'attendre que cette expérience nous aide. Une grande partie du code du jeu provient du même auteur, ZUN, les habitudes récurrentes constituent donc une hypothèse de départ raisonnable. Les référentiels confirment cela avec des exemples utiles : les boucles associées et les arrangements d'assistance ont fourni des hypothèses à travers les jeux.

Ces modèles de source deviennent plus spécifiques lorsque nous incluons le compilateur. Sous une version et un ensemble d'options particuliers, de petites modifications dans la source peuvent produire des différences reproductibles dans le code machine. Certaines de ces différences sont étonnamment obscures.

Dans TH095, par exemple, même le nom d'une variable locale peut affecter l'endroit où VC7.1 la stocke. Le déplacement de sa déclaration n'a pas résolu la configuration du stockage. Cependant, une fonction d'arrière-plan antérieure avait révélé un modèle de dénomination qui affectait le choix du compilateur. Cela suggère une hypothèse plus prometteuse pour reconstruire Supervisor::LoadDat.

La réutilisation de ce modèle pour la variable de taille de fichier a produit la mise en page requise sans ajouter de stockage. La fonction complète correspondait alors.

Il s’agit d’un détail très spécifique qu’un modèle d’IA à usage général peut ne pas connaître lorsqu’il rencontre le problème pour la première fois. Un modèle spécialisé pour ce compilateur pourrait détecter de nombreux cas de ce type et découvrir quelles variantes du code source méritent d'être testées en premier.

L’opportunité est particulièrement évidente dans les problèmes d’appariement final dont nous comprenons déjà le comportement. Nous nous demandons alors quel arrangement de code source ordinaire ce compilateur transforme en instructions observées. La spécialisation pourrait aider le modèle à proposer ces formes plus efficacement, tandis que la cible détermine toujours quelles hypothèses survivent.

Les modèles utiles doivent conserver leur contexte. TH08 utilise une version Visual C++ antérieure à TH095 et TH09. TH04 utilise un compilateur différent de l'ère DOS. Sa reconstruction du code du joueur nécessitait différentes hypothèses sur les modèles de code source et sur la manière dont le code compilé était lié à un exécutable. Avoir le même auteur nous donne une attente initiale, mais chaque cible nous dit si elle s'applique. Un modèle spécialisé devrait distinguer ces contextes.

Où cette expérience doit-elle être stockée ?

Avant de décider d'enseigner ces modèles via la formation de modèles, j'examinerais les connaissances que nous conservons déjà dans le référentiel. Dans l'essai précédent, j'ai écrit qu'il deviendrait la mémoire de travail du projet. Cette mémoire comprend les leçons du compilateur, ainsi que la source et les expériences ratées qui les ont rendues utiles.

En récupérant cet enregistrement, un agent peut partir d’un résultat connu et inspecter comment nous l’avons atteint. Cela peut également éviter des alternatives qui ont déjà échoué dans le même contexte. Le point de départ s'améliore sans modifier les paramètres entraînés du modèle.

Lors de la reconstruction de la fonction de TH09 pour créer des ennemis, une session GPT-6-Luna-max a pris une hypothèse à partir du code source TH08 associé. Ce code précédent suggérait comment organiser la boucle et gérer les échecs à l'intérieur. Le propre témoignage de TH09 a fourni des détails spécifiques au jeu. Les reconstructions à partir des sources ont confirmé que la fonction complète correspondait.

"Le modèle ne connaissait pas cette bizarrerie du compilateur" et "le modèle n'a pas pu l'utiliser" sont des problèmes différents. La récupération peut résoudre le premier, mais transformer ce fait en un candidat utile demande encore du travail. Et si le code source candidat échoue, le modèle doit décider de la signification du résultat pour sa prochaine tentative. Connaître le modèle pertinent n’est que le début de ce processus.

Pour cette raison, j’inclurais un modèle d’IA à usage général plus petit avec une bonne récupération dans toute comparaison. Lui donner la même bibliothèque d'expériences nous aiderait à identifier ce que la formation ajoute : une meilleure génération de candidats, de meilleures décisions après feedback, ou les deux.

Apprendre la prochaine expérience utile

Ces décisions après retour d’information sont ce que j’aimerais le plus étudier. En reconstruction agentique, le modèle propose une explication et la teste par rapport au programme. Même lorsque le code source candidat échoue, le résultat peut réduire les possibilités restantes et suggérer une prochaine expérience plus utile.

Prenons à nouveau l'exemple des résultats temporaires. Sa source finale montre l'arrangement qui a fonctionné, mais l'itinéraire vers cette source contient plus d'informations. Chacune des expériences suivantes a permis d’identifier ce qui devait encore changer.

Expériences sélectionnées de la reconstruction de la fonction d'attaque ci-dessus, regroupées selon ce qu'elles nous ont appris.

Un dossier de formation qui conserve cette séquence peut enseigner plus que la seule source finale. Il relie chaque changement proposé à un résultat observé et à la décision suivante. Conserver des variantes inefficaces est également important : elles indiquent à un agent ultérieur quelles hypothèses ont déjà été testées dans ce contexte.

Je voudrais que le modèle apprenne à utiliser les retours. Un résultat neutre est une raison pour reconsidérer la variation ; une inadéquation modifiée peut indiquer une autre cause. Lorsque les modifications locales cessent d’être informatives, l’agent doit être en mesure de revoir la représentation source ou d’inspecter à nouveau les preuves.

Apprendre à faire ces choix nécessite de l’autonomie. Parfois, l'étape suivante utile consiste à inspecter un autre appelant plutôt que de compiler une autre modification. Une séquence rigide de réécritures requises supprimerait ce choix, ainsi qu'une partie du comportement que nous souhaitons que le modèle apprenne.

Pourquoi l'ingénierie inverse est intéressante pour l'apprentissage par renforcement

La reconstruction limitée nous offre un environnement pratique pour étudier ces choix. Une fois les versions de la cible et du compilateur fixées, de nombreuses expériences sources produisent des retours rapides et reproductibles. L'agent peut compiler un candidat, inspecter l'inadéquation et utiliser cette observation pour choisir la prochaine étape.

L'apprentissage par renforcement pourrait entraîner ce processus de prise de décision grâce aux retours qu'il reçoit. Un candidat accepté par un contrôle défini nous donne un résultat concret, tandis que la séquence des tentatives nous permet d'observer combien de travail il a fallu pour y parvenir.

Il existe déjà des recherches soutenant cette direction. LLM4Decompile étudie les modèles spécialisés pour la décompilation. AutoDecompiler entraîne le raffinement multi-tours à l'aide des retours du compilateur et de l'exécution. Leurs études portent sur la restauration du comportement. Pour ce travail, je les utiliserais comme point de départ pour la tâche connexe consistant à trouver du code source qui correspond à la sortie d'un compilateur historique.

Cependant, pour atteindre une tâche aussi bien définie, nous devrons peut-être d’abord établir quelles ressources possède une fonction ou concevoir une nouvelle manière d’observer le comportement du programme pendant son exécution. Dans TH08, par exemple, une différence de collision a conduit à la manière dont le programme d'origine gérait les calculs à virgule flottante. Avant que l’agent puisse tester une correction utile, il devait déterminer quoi mesurer.

Cela suggère un autre rôle pour un modèle largement performant : contribuer à rendre le problème vérifiable en premier lieu. Une fois que cette vérification existe, nous pouvons étudier jusqu’où une politique de recherche apprise peut aller avec elle.

Lorsque le vérificateur est erroné

Dès qu'une vérification sert à l'entraînement, sa couverture fait partie de l'environnement d'apprentissage. J'appelle oracle cette référence ou ce vérificateur. Même une réponse reproductible doit être comprise à partir de ce qu'elle vérifie réellement.

TH08 a montré tout ce qui peut se cacher en dehors de cette couverture. Certaines fonctions reconstruites ont réussi leurs comparaisons exactes avec de mauvaises constantes flottantes. Le comparateur a ajusté les adresses déplacées avant de vérifier les instructions, mais il a vérifié les valeurs derrière ces adresses uniquement lorsqu'elles avaient été explicitement enregistrées pour vérification. D'autres références littérales pourraient passer sans que leurs valeurs soient examinées.

Pour combler cette lacune, un audit plus large a détecté des constantes incorrectes dans les fonctions qui avaient déjà réussi la vérification. Dans un calcul, le code source reconstruit a ajouté 1.0f, tandis que l'original a ajouté 32.0f.

Un modèle récompensé par l'ancien contrôle de vérification pourrait apprendre à produire une reconstruction incorrecte. Nous n'avons pas entraîné de modèle RL à l'aide de ce vérificateur. L’échec que nous avons constaté concernait le contrôle lui-même. Mais si nous l’utilisions comme récompense, le même angle mort deviendrait partie intégrante de l’environnement d’apprentissage.

Un test fonctionnel peut avoir un angle mort similaire. Des recherches utilisant le fuzzing différentiel sur les décompilateurs LLM ont révélé des différences de comportement en dehors des tests fournis. Il faut donc comprendre une épreuve de réussite en fonction des cas qu'elle exerce. De même, une correspondance d’instructions doit être comprise en termes d’octets et de données qu’elle vérifie.

Avant d’utiliser l’un ou l’autre type de contrôle de vérification comme récompense, je le testerais avec des résultats délibérément incorrects. Je garderais également l'acceptation finale séparée du code source que l'agent IA peut modifier. Le modèle doit réussir la vérification en reconstruisant correctement le programme. Sinon, la simple copie d'un tableau d'octets à partir de la cible pourrait tromper un système de notation naïf sans récupérer le code source utile.

Améliorer le modèle et améliorer son vérificateur relèvent du même problème de recherche. Plus le modèle sait optimiser le retour que nous lui donnons, plus il devient important de comprendre ce retour.

Une comparaison qui vaut la peine d'être menée

Une fois ces contrôles en place, je commencerais la comparaison sur une famille de tâches VC7.1 fixe. Premièrement, j’établirais les bases d’un modèle d’IA à usage général solide et d’un modèle plus petit. L'ajout de connaissances sur le référentiel au modèle plus petit montrerait les changements apportés à la récupération. À partir de là, une spécialisation supervisée et une version formée par RL nous permettraient d'examiner ce que la formation ajoute.

Pour rendre ces comparaisons informatives, chaque modèle recevrait les mêmes preuves et outils cibles. Pour les comparaisons spécifiques à la formation, je conserverais également le modèle de base et les connaissances disponibles fixes. Des essais répétés permettraient de distinguer une stratégie de recherche fiable d'une solution candidate qui réussit par hasard.

Je séparerais alors deux conditions de départ : reconstruire une fonction à partir de ses instructions, et fermer les dernières différences dans le source maintenu. Un modèle d’IA spécialisé peut être excellent pour la deuxième tâche, tandis qu’un modèle d’IA à usage général effectue une grande partie du travail nécessaire pour y parvenir. Les mesurer séparément révélerait cette division du travail.

Les deux tâches nécessitent des exemples de test exclus de la formation et de la récupération. Les jeux Touhou associés partagent le code moteur. L'exclusion d'un jeu de l'entraînement pourrait néanmoins laisser des fonctions presque identiques dans l'ensemble d'entraînement. Au lieu de cela, j'exclurais des groupes entiers de code source associé et garderais leurs réponses vérifiées hors des données de formation et de la bibliothèque de récupération.

Pour ces exemples, le résultat serait des correspondances complètes et vérifiées de manière indépendante. Des budgets égaux pour les propositions de candidats ou les tentatives de compilation aideraient à comparer la qualité de la recherche. Mesurer le temps et le coût totaux, y compris la compilation, montrerait si cette qualité produit un flux de travail efficace. Les coûts de formation doivent être mesurés séparément.

Les deux mesures comptent. Une proposition bon marché peut conduire à un flux de travail coûteux si elle entraîne davantage de compilations ne fournissant aucune information utile. À l’inverse, un modèle plus lent peut être plus économique s’il trouve plus tôt une expérience utile. La comparaison doit inclure ces coûts.

Compter les résultats acceptés aide aussi à interpréter les progrès intermédiaires. Un candidat pour la sauvegarde des replays de TH09 semblait prometteur : la fonction compilée avait la taille attendue. Pourtant, la comparaison complète montrait encore des différences importantes. Un autre ordre des instructions peut donner l’impression que le candidat se rapproche sans résoudre le problème de fond. Ces diagnostics guident l’expérience suivante, mais je vérifierais toute récompense pour ce rapprochement avec le contrôle complet d’acceptation.

Je serais intéressé par la tendance de ces résultats. Si un modèle d’IA spécialisé fonctionne bien au sein d’une famille de compilateurs familière, cet avantage survit-il à un changement de chaîne d’outils ? Et une fois que les deux modèles d’IA ont une bonne récupération, combien la formation ajoute-t-elle encore ? Les réponses nous aideraient à décider où chaque type de modèle est le plus utile.

Quel type d’agent IA cela suggère-t-il ?

Si les modèles s’avèrent utiles à différentes étapes, un arrangement utile pourrait être un agent large ayant accès à un modèle d’IA spécialisé. Une fois qu’une tâche devient une recherche familière du compilateur, elle peut demander des candidats au modèle d’IA spécialisé. Si les résultats n’ont plus de sens, l’agent au sens large pourrait revenir aux preuves cibles ou enquêter sur la mesure elle-même.

Dans cet arrangement, la spécialisation devient un outil que l’agent peut choisir au fur et à mesure que l’enquête se développe. L’agent conserve la liberté de changer de direction qui a rendu possible les percées antérieures.

Cela découle naturellement du virage industriel que j’ai décrit dans l’essai précédent. Être capable de mener beaucoup plus d’expériences change la façon dont nous organisons le travail. Cela nous donne également une raison de nous demander quelles décisions nécessitent un jugement large et lesquelles s'améliorent grâce à une expérience répétée avec un métier particulier.

Pour l'instant, le modèle général le plus puissant a gagné sa place dans mon travail en résolvant des problèmes que j'avais laissés en suspens. Ces réussites me donnent envie d'étudier le processus : quelle part dépend de ses capacités générales, et quelle part pourrait être confiée à un modèle formé pour ce type de reconstruction ?

Les référentiels nous permettent de tester la question. J'aimerais utiliser cet enregistrement pour établir la comparaison et voir ce que nous apprenons.