Les LLM ne rétro-ingénierient entièrement que 32 % des binaires réalistes — pour l’instant

Au 2 septembre 2026, le meilleur grand modèle de langage mis à l’essai ne parvenait à rétro-ingénierier entièrement qu’environ 32 % d’un ensemble exigeant de cibles binaires réalistes. C’est l’une des mesures de capacité de l’IA que D-Central suit avec le plus d’attention.

Ce n’est pas parce que 32 % produit un classement spectaculaire. Ce chiffre compte parce qu’une grande partie des logiciels qui commandent l’infrastructure physique n’arrive pas sous forme de code source lisible. Elle arrive sous forme d’image de micrologiciel compilée, d’exécutable, de chargeur d’amorçage, de bibliothèque ou de binaire suspect dont il faut reconstruire le comportement de l’extérieur.

Nos équipes connaissent bien ce terrain. Une part importante du travail derrière DCENT_OS a exigé une rétro-ingénierie patiente : examiner les artefacts, formuler des hypothèses, les confronter au matériel, documenter ce qui résiste aux essais, abandonner ce qui échoue et recommencer la boucle. Ce n’est pas une brillante requête réglée en un après-midi. Ce sont des mois d’exécution acharnée.

Des agents LLM plus compétents et plus autonomes peuvent comprimer ce cycle. Ils peuvent nous aider à inspecter davantage de chemins, à écrire plus d’outils d’analyse, à conserver davantage de contexte et à transformer plus d’observations en expériences vérifiables. Ils ne remplacent ni les ingénieurs chevronnés ni la validation sur du vrai matériel. Ils augmentent la vitesse à laquelle une bonne équipe peut avancer.

Ce que le chiffre de 32 % signifie vraiment

Ce résultat provient de SRE-Bench, une évaluation en salle blanche conçue pour mesurer la rétro-ingénierie logicielle de bout en bout plutôt que le rappel de code source. Le banc d’essai part de 19 programmes privés écrits de zéro, les compile en 262 instances binaires et divise chaque instance en six objectifs notés de façon déterministe. L’évaluation compte 1 572 tâches au total.

Le système en tête, GPT-5.6-sol, a produit un résultat évaluable sur 254 instances. Il a rempli les six objectifs sur 80 d’entre elles, soit 31,5 %. Sur les objectifs individuels, toutefois, sa note moyenne atteignait 3,69 sur 6, ou 61,4 %.

Ces chiffres ne se contredisent pas. Ils montrent la différence entre progresser et terminer le travail. Un agent peut retrouver un format de paquets sans reconstruire la machine à états complète. Il peut repérer plusieurs effets malveillants sans parvenir à en neutraliser un tout en préservant les données légitimes. Il peut obtenir un contrôle partiel d’un appareil émulé sans franchir la dernière barrière de privilèges.

Pour un vrai micrologiciel, cette distinction est fondamentale. Une explication plausible n’est pas un portage vérifié. Cinq conclusions exactes n’annulent pas une hypothèse destructrice. Le crédit partiel est précieux pendant la recherche, mais l’ingénierie de production ne se termine que lorsque toute la chaîne fonctionne de façon sûre et reproductible.

Pourquoi les bancs d’essai de programmation ordinaires ratent la difficulté centrale

Les LLM sont entraînés sur d’immenses quantités de code public. Les projets libres familiers et les défis publics de type capture du drapeau deviennent donc du matériel d’évaluation risqué. Un modèle peut reconnaître l’architecture, les noms, les comptes rendus ou le schéma d’une solution dans ses données d’entraînement au lieu de reconstruire un programme inconnu à partir du code machine.

L’autre raccourci consiste à générer de minuscules programmes privés. Cela limite la contamination, mais un binaire jouet de quelques dizaines ou centaines de lignes ne ressemble pas à une grande cible de micrologiciel ou de sécurité. L’échelle crée son propre problème : des milliers de fonctions, la machinerie de l’environnement d’exécution, des relations indirectes, des motifs répétés, des fausses pistes et un budget d’analyse limité.

SRE-Bench cherche à combler ces deux lacunes. Ses programmes comptent en moyenne 16 915,8 lignes de source avant compilation, couvrent C, C++, Rust et Go et n’ont jamais été publiés sous forme de source. Les agents reçoivent les artefacts compilés, un terminal et une trousse standard de rétro-ingénierie comprenant des décompilateurs, débogueurs, traceurs, outils d’exécution symbolique et utilitaires propres à chaque domaine. Leurs soumissions passent dans des évaluateurs adaptés à la tâche plutôt que devant un autre modèle chargé de décider si une explication semble convaincante.

Cette configuration est importante. On ne demande pas au LLM de fixer un mur d’hexadécimal et de deviner. Il agit comme un agent : il utilise des outils, recueille des preuves, écrit des scripts, lance des sondes, révise ses hypothèses et soumet un artefact qui fonctionne ou non. Le résultat mesure un système d’analyse complet, y compris le modèle, son harnais, ses outils, son budget de temps et sa stratégie.

Des cibles qui ressemblent à un vrai travail de rétro-ingénierie

Le banc d’essai couvre cinq domaines. Les cibles sont synthétiques et contenues de manière sécuritaire, mais leurs objectifs ressemblent aux problèmes rencontrés en pratique.

Le résultat du logiciel malveillant est particulièrement instructif. C’était le domaine le plus difficile pour le meilleur modèle, avec une note moyenne de 2,06 sur 6. Le défi ne consistait pas simplement à signaler quelque chose de suspect. Il exigeait une correction chirurgicale : supprimer chaque effet malveillant, laisser intact l’état légitime et rendre le nettoyage durable. C’est beaucoup plus proche d’une intervention réelle que d’une étiquette de logiciel malveillant choisie parmi plusieurs réponses.

Les tâches de micrologiciel nous concernent tout autant, même s’il ne faut pas les confondre avec un banc d’essai Antminer. Elles utilisent trois programmes privés sans système d’exploitation destinés à un microcontrôleur fictif et un émulateur non exposé. Leur valeur tient à la forme du travail : comprendre un appareil inconnu, retrouver l’encadrement des commandes, naviguer parmi les barrières et les leurres, comprendre un chemin de mise à jour et démontrer un contrôle croissant dans un budget d’interaction fixe.

La protection, bien plus que la compilation, forme le mur

L’un des constats les plus étranges est que les agents ne butent pas exactement sur les mêmes difficultés que les humains. L’optimisation par le compilateur et l’édition de liens statique ont à peine modifié la note du meilleur modèle. Le retrait des symboles a fait beaucoup plus mal.

Cela suggère que les agents LLM actuels dépendent fortement d’ancrages lexicaux. Les noms de fonctions et autres symboles donnent au modèle des poignées pour organiser un programme en langage naturel. Une fois ces poignées retirées, son raisonnement devient moins stable, même si les instructions demeurent accessibles.

Les protections réalistes contre l’analyse ont causé les dommages les plus importants. À configuration de compilation identique, la moyenne du système en tête est passée de 4,69 à 2,50 sur 6. Le modèle suivant est passé de 3,07 à 0,33. La suite de protection superposait notamment la tromperie du flot de contrôle, la reconstruction des chaînes à l’exécution, le chiffrement par page, l’antidébogage, les autovérifications, la virtualisation de la logique de chargement, les comportements anti-extraction et l’exécution de leurres.

C’est ce que rate le simple récit voulant que « l’IA sait maintenant programmer ». Le code source est écrit pour communiquer une intention aux compilateurs et aux humains. Un binaire protégé est volontairement construit pour cacher cette intention à l’analyste. Une grande capacité dans un dépôt de code ne traverse pas automatiquement cet écart.

Pourquoi D-Central suit cette mesure

DCENT_OS n’est pas construit dans le conteneur propre d’un banc d’essai. Notre travail rencontre de vraies cartes de contrôle, chaînes d’amorçage, voies de récupération, variantes d’appareils, documentations incomplètes et la rétroaction impitoyable du matériel physique. La rétro-ingénierie n’est qu’une partie de cet effort, mais elle est déterminante.

Dès aujourd’hui, les LLM compétents peuvent aider une équipe de micrologiciel à :

• Trier les artefacts plus vite. Les agents peuvent inventorier les sections, chaînes, fonctions importées, sous-systèmes probables et différences entre les versions.
• Transformer les observations en outils. Ils peuvent ébaucher des analyseurs, scripts d’extraction, émulateurs, sondes de protocole et harnais d’essai reproductibles.
• Maintenir une carte de l’enquête. Les longs projets de rétro-ingénierie produisent des centaines de faits, incertitudes, pistes abandonnées et dépendances. Un agent peut aider à garder cet état consultable et cohérent.
• Multiplier les hypothèses. Une équipe peut tester davantage d’explications plausibles au lieu de s’attacher trop tôt au premier récit lisible.
• Traduire la recherche en mise en œuvre. Une fois le comportement vérifié, un agent peut aider à transposer les constats dans les pilotes, interfaces, tests, documentations et procédures de récupération.

Le mot important est aider. L’accès au matériel, les connaissances électriques, la discipline de récupération, la portée juridique, les décisions de sécurité et la validation finale demeurent des responsabilités humaines. La sortie du modèle reste une hypothèse jusqu’à ce qu’une vérification indépendante en fasse une preuve.

Le levier est néanmoins réel. Si un agent peut accomplir de façon autonome une plus grande part de la boucle d’investigation avant de remettre un obstacle bien documenté, l’équipe consacre moins de temps à l’exploration mécanique et davantage aux décisions d’ingénierie difficiles. Passer de 32 % à 40 %, 50 % ou plus ne signifierait pas la création autonome d’un micrologiciel du jour au lendemain. Cela pourrait retrancher des semaines à un programme qui dure des mois.

Fable 5.1 pourrait faire monter le chiffre, mais n’a encore obtenu aucune note

Claude Fable 5.1 ne faisait pas partie des cinq modèles évalués. Au moment de cette photographie du 2 septembre, il n’avait pas encore été mis à l’essai sur SRE-Bench.

Nous nous attendons à ce que les nouveaux agents de pointe améliorent le résultat, et Fable 5.1 est un candidat évident. Ses gains annoncés sur de longues tâches de programmation et de science avec outils vont dans la bonne direction. Une meilleure persistance, un meilleur usage des outils et une meilleure gestion du contexte sont précisément ce dont une investigation de plusieurs heures a besoin.

Mais « probablement meilleur » n’est pas un résultat de banc d’essai. Cette évaluation démontre aussi que la force sur le code source ne se transfère pas directement à l’analyse de binaires protégés. Fable 5.1 pourrait établir un nouveau sommet, progresser surtout sur les cibles non protégées ou révéler un autre mode d’échec. Tant qu’il ne passe pas par le même harnais, les mêmes outils, les mêmes limites et le même évaluateur, 31,5 % demeure le plafond mesuré de résolution complète.

C’est pourquoi D-Central suit la mesure plutôt que le cycle de marketing. Nous voulons la reprise de l’évaluation. Nous voulons le sous-ensemble protégé. Nous voulons les résultats du micrologiciel et du logiciel malveillant séparés. Nous voulons le coût, le temps, les notes nulles, les refus et la reproductibilité. Un agent qui résout davantage de variantes faciles, mais s’effondre encore devant un micrologiciel dépouillé de ses symboles et durci, pourrait afficher une meilleure moyenne sans changer beaucoup notre travail.

Une rétro-ingénierie plus puissante est à double usage

L’analyse binaire sert le travail défensif : comprendre les logiciels malveillants, auditer du matériel acheté, maintenir des logiciels abandonnés, vérifier la chaîne d’approvisionnement des micrologiciels, comparer des correctifs de sécurité, retrouver des interfaces non documentées et rendre le matériel interopérable. La même capacité peut aussi aider un attaquant à repérer des protections ou à accélérer une exploitation.

Les équipes qui adoptent ces agents devraient les traiter comme des outils de sécurité, et non comme un robot conversationnel banal. Travaillez uniquement sur les systèmes que vous possédez ou que vous êtes autorisé à évaluer. Isolez les échantillons suspects. Limitez les réseaux et les identifiants. Conservez des originaux immuables. Journalisez les actions des outils. Exigez des tests déterministes chaque fois que possible. Ne laissez jamais un script de nettoyage non vérifié agir sur des données irremplaçables ni une image non révisée atteindre du matériel de production.

SRE-Bench respecte bien cette frontière : le logiciel malveillant est inerte et confiné, le micrologiciel est fictif, les secrets de l’évaluateur ne sont pas exposés et la réussite dépend de résultats vérifiables. Il mesure une capacité utile sans prétendre qu’une exploitation autonome sans contraintes serait sûre.

La réponse souveraine demeure le logiciel libre

Un décompilateur bien meilleur ne rend pas un micrologiciel fermé ouvert. La rétro-ingénierie récupère une approximation du comportement à partir d’artefacts. Elle ne recrée ni l’historique de conception, ni les commentaires, ni la suite de tests, ni l’environnement de compilation, ni la gouvernance d’origine.

La forme la plus forte de propriété technologique demeure un code source que vous pouvez inspecter, compiler, modifier et vérifier. C’est l’objectif de DCENT_OS et du mouvement plus large pour les micrologiciels libres. La rétro-ingénierie est le pont nécessaire lorsque les fabricants gardent les appareils opaques. Le logiciel libre empêche chaque future équipe de devoir reconstruire ce pont à partir de rien.

Le plafond de 32 % n’est pas un verdict sur ce que l’IA finira par accomplir. C’est la mesure du point où se trouvaient les agents les plus compétents mis à l’essai pendant que nos ingénieurs poursuivaient le travail.

Les prochains gains vont se multiplier

L’amélioration des modèles ne constitue qu’une partie de la trajectoire. De meilleures intégrations avec Ghidra et d’autres plateformes d’analyse, une mémoire persistante de l’enquête, des modèles spécialisés en binaire, une émulation consciente des appareils, la conception automatique d’expériences, des harnais de vérification plus solides et des passages plus propres entre les agents et les ingénieurs peuvent tous augmenter le rendement utile.

C’est pourquoi ce banc d’essai compte autant pour D-Central. Un taux de résolution complète proche du tiers est à la fois impressionnant et insuffisant. Il prouve que les agents savent déjà retrouver une part importante du comportement de binaires inconnus. Il prouve aussi que les protections réalistes et l’exactitude de bout en bout les arrêtent encore plus souvent qu’à leur tour.

Pour DCENT_OS, ces progrès n’ont rien d’abstrait. Chaque partie supplémentaire de la boucle de rétro-ingénierie qui peut être déléguée de manière sûre donne plus de vitesse à nos équipes. Chaque vérificateur plus robuste rend cette vitesse plus fiable. Après des mois de travail acharné, la possibilité est facile à comprendre : non pas remplacer les personnes qui ont appris le matériel, mais leur donner un collaborateur de plus en plus compétent qui ne se fatigue jamais devant la prochaine trace, la prochaine compilation ou la prochaine hypothèse.

Nous surveillons le 31,5 %. Nous nous attendons à le voir augmenter. Ce qui compte, c’est à quel point cette progression nous permettra de transformer plus vite des machines opaques en matériel que leurs propriétaires peuvent comprendre et contrôler.

Foire aux questions

Les LLM peuvent-ils rétro-ingénierier un micrologiciel aujourd’hui?

Oui, mais pas avec une fiabilité suffisante pour travailler sans supervision experte. Dans SRE-Bench, le meilleur agent mesuré a réalisé des progrès partiels importants et résolu entièrement 31,5 % de ses instances binaires évaluables. Les résultats de micrologiciel proviennent d’un microcontrôleur fictif, et non de matériel de minage commercial.

Une note de 61,4 % signifie-t-elle que le modèle a résolu 61,4 % des binaires?

Non. Il a obtenu en moyenne 61,4 % des points disponibles au niveau des tâches. Il a rempli chaque objectif requis sur 31,5 % des instances évaluables. Le taux de résolution complète est la mesure la plus exigeante.

Claude Fable 5.1 a-t-il été mis à l’essai?

Non. Il ne figurait pas dans les résultats publiés de SRE-Bench au 2 septembre 2026. Il pourrait relever le plafond mesuré, mais cela demeure une hypothèse tant qu’il n’est pas évalué dans les mêmes conditions.

Pourquoi cette mesure compte-t-elle pour DCENT_OS?

La rétro-ingénierie constitue une partie importante du travail de plusieurs mois mené par D-Central sur ses micrologiciels. Des agents plus autonomes peuvent accélérer le tri des artefacts, la création d’outils, la mise à l’essai d’hypothèses, la documentation et la mise en œuvre, tandis que les ingénieurs de D-Central gardent la responsabilité de la validation matérielle, de la sécurité et des décisions finales.

Recherche primaire examinée en août 2026 : SRE-Bench, un banc d’essai réaliste de rétro-ingénierie logicielle avec contrôle de la contamination. Contexte D-Central : DCENT_OS; les bancs d’essai de cybersécurité agentique et la sécurité de Bitcoin; la prévention et la suppression des logiciels malveillants sur les mineurs ASIC.