Rétro-ingénierie : apprendre à démonter pour mieux bâtir

J'ai passé des années à bâtir des logiciels avant de m'intéresser sérieusement à la façon dont on les démonte. C'est l'ordre inverse qu'il aurait fallu.

Quand on écrit du code, on pense en fonctionnalités : ce que le programme doit faire, et comment il doit le faire. Quand on démonte un programme, on pense en surfaces : par où entrer, quoi contourner, quelle valeur suffit à changer pour que tout le reste cède. Ce sont deux métiers, et le second rend le premier bien meilleur.

Voici ce que j'ai appris en apprenant à ouvrir des exécutables — et ce que ça a changé dans ma manière de construire les miens.

Comprendre l'attaquant pour construire la défense

C'est le principe fondamental de la sécurité offensive : on ne protège correctement que ce qu'on a déjà su casser. Comprendre exactement comment quelqu'un dissèque un exécutable, contourne une validation ou intercepte un paquet réseau change radicalement la façon de concevoir ses propres systèmes.

Quand j'architecture une plateforme — du React, du TypeScript, une base temps réel — savoir où un script malveillant ou une requête forgée va tenter de s'infiltrer me fait sécuriser le code à la racine plutôt qu'en rustine. On passe du développement à une vraie approche DevSecOps, et la différence n'est pas cosmétique : elle se voit dans l'architecture, pas dans une liste de correctifs.

Trois terrains d'exploration

La sécurité applicative et web. Le terrain de l'OWASP Top 10 : exploiter activement les failles d'injection, les mauvaises configurations d'API, les faiblesses d'authentification — pour mieux les corriger. Un bagage en architecture logicielle donne ici une longueur d'avance énorme, parce qu'on sait déjà où les développeurs prennent des raccourcis.

La rétro-ingénierie. Décortiquer un maliciel, comprendre comment un rançongiciel chiffre un disque, auditer le micrologiciel obscur d'une carte mère d'engin électrique ou de machinerie. C'est là que mon passé en robotique industrielle et en télécom sert le plus : le logiciel branché sur du matériel réel, c'est un terrain que je connais.

Le matériel et la radio. L'audit des protocoles Sub-GHz, du NFC, de l'émulation de badges, de l'injection de frappes clavier. Toute la dimension physique de la cybersécurité, celle qu'on oublie quand on ne pense qu'en logiciel.

La trousse à outils

• Analyseur de structure — Detect It Easy (DIE) : dissèque l'en-tête PE, identifie le compilateur, repère les compresseurs et les signatures d'obfuscation. C'est toujours le premier outil qu'on ouvre.
• Décompilateur .NET — dnSpyEx ou ILSpy : transforme le bytecode MSIL en C# lisible.
• Désassembleur — Ghidra ou IDA Pro : analyse l'assembleur natif, génère les graphes de flux de contrôle, décompile le C et le C++.
• Débogueur — x64dbg ou WinDbg : exécution pas à pas, points d'arrêt, inspection des registres et de la mémoire vive en temps réel.
• Analyseur réseau — Wireshark ou HTTP Toolkit : interception et décodage des communications HTTP/HTTPS et des flux TCP/UDP.

Les quatre phases

1. L'analyse statique. On étudie le fichier au repos. On extrait les chaînes de caractères, on regarde les fonctions importées — quelles API du système le programme appelle-t-il ? — et on cartographie les blocs logiques. Rien n'est exécuté, donc aucun piège ne se déclenche.

2. L'analyse dynamique. Dans un environnement contrôlé, sous la surveillance d'un débogueur. On observe le comportement réel : registres modifiés, appels système, fichiers temporaires créés, tentatives de connexion. C'est souvent là que le programme dit ce que son code cachait.

3. Le contre-pied des protections. Face à de l'obfuscation par mutation, des routines anti-débogage ou de la virtualisation de code, le code source n'est plus lisible directement. Il faut identifier les routines de détection avant de pouvoir avancer.

4. Le point de bascule. C'est la leçon la plus utile pour un développeur, et la plus inconfortable : casser un algorithme complexe est rarement nécessaire. Un seul drapeau logique — un saut conditionnel, une fonction booléenne — porte souvent tout le poids de la décision. Toute la protection tient à une seule ligne. Si ça vous semble familier, regardez votre propre code d'autorisation.

Lire un rapport d'analyse

Quatre choses à regarder quand DIE vous rend son verdict :

L'architecture. PE32 ou PE64 : 32 ou 64 bits. C'est l'information la plus simple, et elle oriente tout le reste.

Le compilateur. Si la ligne indique .NET, le programme est en C# ou VB.NET et se décompile presque intégralement. Microsoft Visual C/C++ ou Delphi, c'est du natif, nettement plus long à lire. PyInstaller ou Electron, c'est du Python ou du web encapsulé — souvent le plus facile des trois.

Le protecteur. VMProtect, Themida, Enigma, UPX : le code a été compressé ou chiffré. Si cette zone ne signale rien d'autre que l'éditeur de liens, le fichier est probablement en clair.

L'entropie. Une mesure du désordre dans le fichier. Un binaire normal tourne entre 4 et 6. Proche de 8, il est massivement chiffré ou obfusqué — et vous savez déjà que la soirée sera longue.

Quand le binaire est vraiment blindé

Il arrive qu'un rapport empile toutes les protections d'un coup. J'en ai croisé un cas d'école : une application .NET — donc en principe très lisible — recouverte de plusieurs couches agressives.

• Obfuscation. Le code est passé au mixeur : plus de CheckLicense() lisible, mais des variables renommées en caractères aléatoires et des opérations mathématiques factices ajoutées uniquement pour égarer le lecteur.
• Virtualisation. La protection la plus coriace. Le code original est transformé en un jeu d'instructions sur mesure, exécuté par une machine virtuelle embarquée dans le programme lui-même.
• Anti-analyse. Le logiciel détecte qu'on l'observe et se saborde volontairement.
• Compression. Le cœur du programme est compressé et chiffré. Le vrai code n'existe pas en clair sur le disque : il ne se déploie qu'en mémoire vive, à l'exécution.

Ouvrez ça dans un décompilateur et vous ne trouvez pas une coquille vide avec quelques requêtes HTTP en clair. Vous trouvez un mur.

C'est une leçon en soi. Quelqu'un a investi sérieusement pour rendre son travail illisible — et ça se respecte, même quand ça agace.

Ce que ça change pour mes clients

Je ne fais pas de la sécurité offensive un service. J'en fais une habitude.

Concrètement : je ne mets jamais une décision d'autorisation dans le client. Je pars du principe que tout ce qui part dans le navigateur est lisible et modifiable, parce que je sais avec quels outils on le lit. Je vérifie ce que mes propres clés exposent avant de les publier, pas après. Et quand je choisis où ranger une donnée, je me demande d'abord ce qu'un curieux verrait s'il tirait sur le fil.

Ce n'est pas de la paranoïa, c'est de l'économie. Une faille corrigée à l'architecture coûte une conversation. La même faille corrigée après coup coûte une réputation.