Reverse engineering de binaires par LLM — NES ROMs, jeux DOS, code compile¶
Resume¶
Plusieurs demos virales la meme semaine (mars 2026) montrent que les LLM frontier (GPT-5.4, Codex 5.4) sont desormais capables de reverse-engineer du code compile sans source :
- @skirano (1.9K + 2.2K likes, 427K + 312K vues) : GPT-5.4 analyse un ROM NES (Mario), identifie les events en RAM, expose les hooks memoire, et genere un emulateur JavaScript ou chaque personnage du jeu est controle par une IA. "3 prompts. No code is safe anymore."
- @ammaar (3.8K likes, 507K vues) : Codex 5.4 reverse-engineer un jeu DOS (SkyRoads) sans code source. 6 heures d'execution autonome. Decompresse les assets, desassemble l'EXE, reconstruit le renderer, et livre une reimplementation complete en Rust.
Analyse critique¶
Ce qui est reel¶
Les demos sont credibles. Les ROMs NES sont des binaires 6502 relativement simples (~32-256 KB), et la structure memoire est bien documentee par la communaute emulation depuis 30 ans. Un LLM entraine sur du code d'emulation NES, des docs 6502, et des write-ups de reverse engineering peut raisonnablement identifier les registres RAM, les events, et generer du code d'interface.
Le cas SkyRoads (DOS, x86 16-bit) est plus impressionnant parce que le format est moins documente et le binaire plus complexe. Mais la methode reste la meme : le LLM utilise des patterns connus de reverse engineering (identification de fonctions par signature, analyse de data segments, reconstruction de structures) qu'il a vus dans son corpus d'entrainement.
La phrase de skirano — "No code is safe anymore" — est la bonne synthese.
Ce qui est exagere¶
Les demos sont sur des binaires tres petits et tres documentes (NES = 8-bit, ROM publique analysee des milliers de fois ; DOS = 16-bit, ecosysteme retro bien connu). Extrapoler a "on peut reverse-engineer n'importe quel binaire" est premature. Un ELF 64-bit avec obfuscation, anti-tampering, et ASLR est un ordre de grandeur plus complexe.
La phrase "3 prompts" de skirano est trompeuse — ca suppose que le LLM a deja dans son corpus toute la connaissance necessaire sur le format NES et la structure RAM de Mario. Ce n'est pas de la deduction pure, c'est du pattern matching sur des connaissances preexistantes.
Le signal securite reel¶
Meme avec ces nuances, le signal est important : le code compile n'est plus une barriere de protection suffisante contre l'analyse. Si un LLM peut reconstruire la logique d'un binaire NES en 3 prompts et d'un jeu DOS en 6 heures, la trajectoire est claire. Les binaires plus complexes suivront a mesure que les modeles grandissent et que les techniques de reverse engineering automatise s'ameliorent.
Pour les logiciels proprietaires, ca signifie que l'obfuscation de code et la compilation fermee perdent progressivement leur valeur comme protection de propriete intellectuelle. C'est le meme signal que la fiche Claw Code (2026-04-03) : si une IA peut reecrire un logiciel LGPL en MIT en 5 jours, et une autre peut reverse-engineer un binaire en 6 heures, le code source n'est plus un moat.
Pertinence ProbatioVault¶
Impact modere — pas d'action technique, mais signal strategique sur la protection du code.
Ce que ca change pour ProbatioVault¶
Notre positionnement sur la protection du code a deja ete analyse dans la fiche Claw Code (2026-04-03). Le tableau des moats y est clair :
| Moat | Reproductible par IA ? |
|---|---|
| Code source | Oui (traduction triviale, cf. Claw Code) |
| Code compile | Oui (reverse engineering par LLM, cette fiche) |
| Infrastructure (HSM, WORM, certs) | Non (physique + reglementaire) |
| Brevets | Non (protection legale) |
| Conformite (eIDAS, NF Z42-013) | Non (processus humain + audit) |
| Workflow constitutionnel | Non (capital organisationnel) |
Le reverse engineering par LLM renforce la ligne 2 : meme le code compile n'est plus une protection. La valeur de ProbatioVault est dans l'infra physique (HSM, WORM), la conformite reglementaire, et le workflow de gouvernance — pas dans le code.
Implication pour la securite applicative¶
Si un attaquant peut reverse-engineer les binaires de ProbatioVault-app (iOS, React Native compilé), il peut potentiellement identifier des failles dans la logique d'authentification, les patterns de chiffrement, ou les mecanismes anti-tampering. Notre module natif de detection jailbreak/Frida (PD-262) est concu pour resister au reverse engineering, mais la barre monte.
A surveiller : si les LLM deviennent capables de reverse-engineer les modules natifs Swift/Kotlin compiles, il faudra renforcer les protections cote serveur (ne plus faire confiance au client pour les decisions de securite — principe deja en place chez nous via HSM + verification serveur).
Action recommandee¶
Pas d'action immediate. Ce signal renforce deux convictions existantes : (1) le code n'est pas un moat, (2) la securite doit etre cote serveur, pas cote client. Les deux sont deja dans notre architecture. A citer comme argument supplementaire dans la communication sur le positionnement ProbatioVault.