Rétro-ingénierie : ce que j’ai retenu d’un atelier CLUSIR ARA, et où ISO 27001 s’invite

Jeudi, le CLUSIR ARA proposait un atelier d’introduction à la rétro-ingénierie logicielle, animé par l’équipe de Root-Me PRO. Ce n’est pas mon terrain. Ma cible, c’est la gouvernance et la sécurité des architectures de données et d’IA, pas le désassemblage de binaires. Et pourtant j’y suis allé, et j’en suis sorti avec plus de matière que prévu. Pas parce que je compte devenir reverser, mais parce que comprendre comment on dissèque un malware, c’est comprendre une brique que je vais croiser sans la manipuler moi-même. Le jour où je commande une analyse à un prestataire, ou que je lis un rapport d’incident, je veux savoir ce qu’il y a derrière.

Ce billet est de la veille assumée. Je raconte ce que j’ai compris, et surtout les deux ou trois endroits où mon œil de GRC a accroché.

Comment je m’y suis pris

J’ai suivi l’atelier en direct, pris des notes au fil des soixante slides, puis je suis revenu à froid sur le support et la transcription. La rétro-ingénierie est dense, et la première écoute laisse passer la moitié des choses. La relecture sert à ça : séparer ce qui est du vocabulaire (assembleur, registres, syntaxe Intel) de ce qui est de la méthode (comment on attaque un binaire sans tout lire).

Du gâteau au binaire

L’image qui m’a aidé, c’est celle du gâteau. Quand un développeur écrit du C ou du Go, un compilateur traduit son code une fois, en code machine. La traduction va dans un seul sens, et avec perte : les noms de variables, les commentaires, la structure d’origine sont jetés. On livre le gâteau, pas la recette. La rétro-ingénierie, c’est goûter le gâteau pour deviner les ingrédients et les étapes. Ça ne redonne jamais la recette exacte, juste une reconstruction crédible.

Cette perte change tout selon le type de langage. En interprété (Python, PHP), le code source voyage avec le programme, donc le lire est presque direct, et la difficulté se déplace vers l’obscurcissement volontaire. En compilé, on n’a que des octets, et il faut des outils pour remonter. Trois, essentiellement : le désassembleur, qui retraduit les octets en assembleur lisible ; le débogueur, qui exécute le programme pas à pas pour l’observer vivre ; le décompilateur, qui tente de reconstruire un pseudo-code proche du C, plus confortable mais approximatif. On ne fait jamais confiance aveuglément au décompilateur, on recoupe avec l’assembleur.

Je ne vais pas refaire le cours d’assembleur. Ce que je retiens, c’est qu’on tombe à un niveau où le programme n’est plus qu’un flux d’instructions élémentaires manipulant des registres et une pile, et qu’une bonne partie du travail consiste à renommer patiemment des fonctions anonymes pour leur redonner du sens. Un travail de documentaliste.

La méthode, et là où mon œil a accroché

Le moment où l’atelier est devenu vraiment intéressant pour moi, c’est la méthode. On distingue l’analyse statique (examiner le fichier à froid, sans l’exécuter : empreinte, structure, chaînes de caractères) et l’analyse dynamique (le détoner dans un environnement isolé pour observer son comportement réel : fichiers touchés, appels système, connexions réseau). Les deux sont complémentaires. L’une dit ce que fait le programme, l’autre comment.

Et surtout, ce principe que le présentateur a martelé : on ne reverse jamais un binaire de A à Z, c’est trop coûteux. On définit un objectif, une question précise, puis un périmètre, et on ignore le reste. On part d’un point d’entrée pertinent, une chaîne de caractères ou un appel d’API, et on boucle hypothèse, vérification, ajustement.

Là, j’ai entendu du scoping. C’est exactement la discipline de la clause 4.3 d’ISO 27001, déterminer le périmètre avant de travailler, et la logique d’une analyse de risque ISO 27005 : on ne traite pas tout, on cadre à la question qui compte. Le reverser et l’auditeur partagent le même réflexe, refuser l’exhaustivité pour viser le pertinent. Première accroche.

La deuxième, c’est une mise en garde glissée sur les sandbox. Beaucoup de ces environnements d’analyse en ligne ne garantissent aucune confidentialité de ce qu’on leur envoie. Donc avant de téléverser l’échantillon d’un client, on vérifie le périmètre de la mission. Pour moi, c’est du A.5.23 (sécurité de l’information pour l’utilisation des services cloud) appliqué sans le nommer : envoyer une donnée potentiellement sensible vers un tiers, c’est une décision de gouvernance, pas un geste anodin. Je garde ce réflexe, il va resservir un peu plus loin.

Le cas concret a réuni tout ça. Un faux jeu vidéo, en réalité un ransomware écrit en Go. L’analyse dynamique montre qu’il chiffre tous les fichiers du dossier et dépose une note de rançon avec un identifiant de cas. L’analyse statique permet de remonter le code et de comprendre la faille. Et la faille est belle : la clé de chiffrement AES est dérivée d’un condensat non réversible d’un horodatage, donc impossible à retrouver directement. Sauf que le même horodatage est réutilisé, lui de façon réversible, pour générer l’identifiant de cas affiché à la victime. On part de l’identifiant, on décode, on retrouve l’horodatage, on reconstruit la clé.

Ce n’est pas l’algorithme qui a cédé. C’est la gestion de la clé : un secret réutilisé qui fuit par un canal réversible. C’est du A.8.24 (utilisation de la cryptographie) en négatif. La leçon que je retiens, c’est que la cryptographie échoue presque toujours au key management, jamais au choix de l’algorithme. Le présentateur a d’ailleurs précisé que les vrais ransomwares, type LockBit, ne laissent pas ce genre de porte ouverte. C’était une erreur d’implémentation pédagogique, pas la réalité du terrain.

L’IA dans la boucle, et le trou de gouvernance

La fin de l’atelier portait sur l’IA, et c’est là que j’étais le plus à l’aise. Les modèles de langage sont bons pour reconnaître des motifs dans un binaire sans symboles : algorithmes cryptographiques, constantes, signatures de packers, anomalies. Et le MCP change la nature de l’interaction.

Le Model Context Protocol, c’est le standard ouvert publié par Anthropic le 25 novembre 2024 (annonce officielle), qui donne à un modèle un moyen structuré d’appeler des outils externes. Branché sur un désassembleur comme IDA, il ne se contente plus de lire : il appelle des fonctions, renomme des fonctions dans la base, recherche des constantes. Le présentateur a montré une démonstration où un modèle a reversé un infostealer Linux non détecté par VirusTotal, en une trentaine de minutes, pour environ deux euros de jetons, avec un rapport de trois cents lignes et le renommage de quatorze fonctions et vingt-trois variables. Le résultat m’a impressionné.

C’est aussi le moment où le réflexe de tout à l’heure revient. L’atelier a montré la capacité, mais n’a pas refermé la boucle de gouvernance, et c’est là que je me sens utile. À qui appartient le code qu’on envoie au modèle ? La même mise en garde que pour les sandbox vaut mot pour mot : envoyer du code décompilé, parfois propriétaire, parfois sous NDA, vers un service tiers, c’est une décision de confidentialité. On retrouve A.5.23. Ensuite, la traçabilité : le modèle a modifié la base de travail, il a muté la preuve, donc qui valide, qui rejoue le raisonnement ? Sur une tâche à fort coût d’erreur, je reste convaincu qu’il faut un humain dans la boucle, du semi-autonome plutôt que du tout-automatique. Et le tri du modèle sur les indicateurs de compromission et la cartographie MITRE ATT&CK, c’est de la threat intelligence, donc du A.5.7 dès qu’on l’intègre proprement dans un dispositif.

Pour qui prépare une certification de management de l’IA, le pendant naturel de tout ça, c’est ISO 42001. La capacité technique avance vite. Le cadre de gouvernance qui dit qui décide, qui trace et qui assume, lui, reste à construire. C’est précisément le terrain sur lequel je veux être utile.

Ce que ça change, et pour qui

Je ne deviendrai pas reverser, c’est entendu. Ce n’est ni ma cible ni mon carburant. Mais cette culture sert directement un profil GRC, et pas qu’un peu. Quand un RSSI ou un responsable conformité commande une analyse de malware ou un pentest, il doit pouvoir lire le livrable, comprendre la différence entre statique et dynamique, savoir ce qu’est un indicateur de compromission, et poser les bonnes questions de périmètre et de confidentialité au prestataire. Sans cette culture, on signe un bon de commande sans comprendre ce qu’on achète.

Pour une PME ou un sous-traitant industriel sans équipe sécurité interne, ça compte encore plus. La personne qui fait l’interface avec le prestataire est rarement technique, et c’est pourtant elle qui devrait porter ces réflexes de gouvernance. C’est un rôle que je vois bien.

Ce qui reste ouvert

Je n’ai pas tranché sur la limite. Jusqu’où déléguer une analyse sensible à un modèle hébergé chez un tiers, sachant ce qu’on ne maîtrise pas sur le traitement réel des données envoyées ? La démonstration était convaincante, mais une démonstration sur un échantillon préparé n’est pas un cadre opérationnel. Et je n’ai pas creusé la souveraineté : faire tourner ce genre de pipeline sur un modèle hébergé en propre, plutôt que sur une API tierce, change tout le raisonnement de confidentialité. C’est un fil que je veux suivre.

La veille à suivre

Quelques pistes que je garde de côté. Le MCP appliqué à la sécurité, offensive comme défensive, parce que la question de la gouvernance des identités non humaines qui agissent dans nos outils ne fait que commencer. Les règles YARA, côté détection, que l’atelier a mentionnées sans creuser. Et, plus modestement, les quelques challenges d’introduction proposés par Root-Me pour mettre les mains dedans, parce que lire de l’assembleur dix minutes vaut mieux que d’en parler une heure.

Sources : atelier n°33 du club Root-Me PRO, « Introduction à la rétro-ingénierie logicielle », présenté au CLUSIR ARA. Référentiel ANSSI pour l’évaluation de sécurité (cert.ssi.gouv.fr). Annonce officielle du Model Context Protocol par Anthropic (anthropic.com).