La plupart des gens qui essaient de rétroconcevoir un binaire l'ouvrent dans un éditeur hexadécimal, scrollent pendant vingt minutes, puis abandonnent.
Ils ne savent pas quel outil charger pour lire le fichier. Ils ne savent pas quel prompt utiliser pour en extraire la logique. Ils ne savent pas comment transformer un mur d'assembleur en quelque chose qu'ils peuvent réellement reconstruire.
Ce cours en 11 étapes va transformer Claude Opus 5.5 en une machine open source capable de tout faire.
Abonnez-vous à mon Substack pour recevoir les dernières pépites IA :
La rétro-ingénierie, ce n'est pas du cracking. C'est comprendre suffisamment bien une chose pour pouvoir construire la vôtre.
Le 7 octobre 2026, Amjad Masad, le PDG de Replit, a publié une seule ligne :
https://x.com/amasad/status/2107671204639465961
En réponse, un développeur nommé @morluto a sorti les preuves : un ensemble d'outils permettant aux agents de piloter Hopper et Ghidra pour aller très loin.
Ce projet s'appelle REA, et il a franchi les 110 000 étoiles sur GitHub en quelques jours.
https://github.com/morluto/rea
Ce n'est pas du vent. La même semaine, un projet open source appelé WordCraft a livré une reconstruction « clean room » de Microsoft et Adobe en pur Rust :
Il a été construit en observant le comportement de Word et d'Adobe et en lisant les spécifications publiques des formats de fichiers, sans jamais toucher à leur code.
Ce cours vous montre tout le chemin, d'un binaire verrouillé jusqu'à une reconstruction de ce type, avec Opus 5.5 qui se charge de la lecture.
01. Le moteur - comment un agent lit un binaire
Opus 5.5 ne peut pas exécuter un désassembleur tout seul. Il lit du texte et écrit du texte.
La rétro-ingénierie avec un agent fonctionne parce qu'un outil s'intercale entre le modèle et le binaire : il charge le fichier dans un véritable moteur de désassemblage, expose les résultats sous forme de fonctions appelables et permet au modèle de poser des questions.
Cet outil est REA, et le moteur qui tourne en dessous est Hopper, Ghidra ou IDA.
La boucle est simple et se répète : le modèle demande à REA d'inspecter la cible, REA renvoie ses découvertes accompagnées des preuves exactes (adresses, octets, pseudocode, sites d'appel), et le modèle utilise ces informations pour poser la question suivante ou pour écrire et tester une réimplémentation.
Tout s'exécute localement sur votre machine. Rien n'est envoyé, à part les éléments dont le modèle a besoin pour raisonner, et chaque conclusion est étiquetée comme observation, déduction ou inconnue.
**
02. L'installation - rea-agents plus un désassembleur
La configuration enregistre le serveur MCP de REA auprès de votre agent et installe les instructions de workflow correspondantes.
Une seule commande suffit : elle vous montre chaque modification avant d'écrire quoi que ce soit et sauvegarde ce qu'elle touche.
Vous apportez votre propre désassembleur : Hopper sur macOS est la voie la plus simple, Ghidra est gratuit et multiplateforme, IDA si vous le possédez déjà.
1# 1. Enregistrer REA auprès de votre agent (Claude Code, Codex, Cursor, Gemini CLI...)2npx rea-agents setup # affiche les modifications prévues, demande confirmation avant d'écrire34# 2. Un fournisseur d'analyse approfondie. Hopper est le plus fluide sur macOS ;5# setup peut l'installer après validation. Ghidra et IDA sont à fournir par vos soins.6# 3. Installer la CLI rea pour l'utilisation en terminal et les scripts7npm install --global rea-agents8rea --help910# 4. Redémarrer votre agent, puis confirmer que les outils sont actifs11claude12> /mcp13 rea: connected14 open_binary, binary_overview, analyze_function, decompile,15 list_procedures, search, xrefs, trace, inspect_artifact,16 analyze_javascript_application, inspect_managed_artifact ...
Les prérequis sont modestes : Node.js 22 ou plus récent et npm. L'analyse native nécessite l'un des trois moteurs ; l'inspection statique JavaScript et .NET n'en requiert aucun. Gardez REA à jour, car les versions apportent fréquemment des correctifs.
1# Règles internes de rétro-ingénierie ( CLAUDE.MD )23## Autorité4- Analyser uniquement les cibles que je possède ou que je suis autorisé à examiner. Énoncer la base légale une fois.5- Chaque affirmation est étiquetée : observation (vu), déduction (déduit) ou inconnue.6- Citer les preuves : adresse, octets, pseudocode ou site d'appel. Aucune affirmation non sourcée.78## Workflow9- Commencer par la vue d'ensemble la plus petite, pas un dump complet. N'approfondir que pour combler un manque précis.10- Réutiliser la session ouverte ; ne jamais relancer une analyse identique.11- Séparer les faits statiques des faits d'exécution. Ne jamais déduire un comportement d'exécution à partir de lectures statiques.1213## Reconstruction14- Construire à partir du COMPORTEMENT et des spécifications publiques, jamais à partir de code ou de ressources copiés.15- Tenir un registre des obligations : chaque comportement récupéré nécessite un test réussi avant d'être considéré comme "terminé".
Opus 5.5 propose cinq niveaux d'effort : low, medium, high, xhigh et max. Utilisez :
- Medium pour inspecter et naviguer
- High pour annoter les fonctions ordinaires
- Max pour le code obfusqué et tout ce qui implique des calculs de pointeurs complexes.
L'effort est le principal levier de qualité de tout ce cours.
03. Le routeur - 20 types de cibles, un outil chacune
La première erreur des débutants est de dégainer un désassembleur alors que la cible est une application Electron dont le JavaScript est juste là, sous leurs yeux.
REA route la cible vers le bon outil, et votre premier prompt devrait faire de même. Nommez le fichier, nommez la fonctionnalité, et laissez l'agent choisir l'outil d'entrée.
1Je veux comprendre comment [FONCTIONNALITÉ] fonctionne dans [APP], qui se trouve à [CHEMIN ABSOLU].23D'abord, dis-moi de quel type de cible il s'agit (natif, Electron/JS, .NET, Go, APK, WASM)4et choisis le bon outil REA pour l'ouvrir. Ne lance pas encore d'analyse approfondie.56Ensuite, donne-moi une cartographie en un paragraphe : avec quoi l'application est construite, sa taille, et7où tu chercherais en premier pour trouver [FONCTIONNALITÉ]. Sépare les observations, les déductions et les inconnues,8et cite tes preuves pour tout ce que tu affirmes.
Pointer REA vers une application Electron renvoie les modules, les imports et les limites IPC en quelques secondes, sans aucun désassembleur.
Le pointer vers un Mach-O ou un ELF natif ouvre une base de données Hopper et vous engage sur la voie native, plus ardue mais plus profonde. Savoir dans laquelle vous vous trouvez fait gagner des heures.
https://x.com/_vmlops/status/2106690704244420687
04. La reconnaissance - vue d'ensemble, chaînes de caractères et graphe d'appels
N'ouvrez aucun code pour l'instant. Demandez d'abord à REA une cartographie complète du fichier. Une seule commande vous indique sur quel type de machine il tourne, combien de fonctions il contient et tout le texte lisible qui y est enfoui.
Ce texte est l'indice le plus rapide dont vous disposez : adresses web, messages d'erreur et noms de fonctionnalités vous disent ce que fait l'application avant même d'avoir lu une seule ligne de code.
1rea.open_binary { path: "/Applications/Target.app/Contents/MacOS/Target" }2rea.binary_overview {}3 arch: arm644 functions: 1,284 identified5 segments: __TEXT __DATA __LINKEDIT6 entry: _main @ 0x1000051c078rea.search { query: "http" } # strings + code refs9 0x10004a2c0 "https://api.target.app/v3/sync"10 0x10004a300 "Authorization: Bearer "11 0x10004a330 "offline cache miss, falling back"1213rea.xrefs { address: "0x100012ab0" } # who calls this?14 147 references -> core config loader, called everywhere
REA compte également combien de fois chaque fonction est appelée (ce compteur s'appelle les références croisées, ou xrefs).
Une fonction appelée 147 fois est le cœur de l'application et mérite tous vos efforts. Une fonction appelée deux fois est un petit utilitaire que vous pouvez ignorer jusqu'à ce qu'il devienne important. Commencez par le haut de cette liste et descendez.
05. La décompilation - une fonction transformée en pseudocode
Choisissez maintenant l'une de ces fonctions très sollicitées et transformez-la en quelque chose de lisible. Un décompilateur prend les instructions machine brutes et les réécrit sous forme de code proche du C.
Le résultat est brut : des noms comme var_28, une logique emmêlée, des conversions de types partout. Mais vous pouvez le lire, et c'est tout ce dont Opus 5.5 a besoin.
Exécutez-le depuis la ligne de commande pour sauvegarder le résultat, ou directement dans un chat.
1# Décompiler une fonction par son adresse, au format JSON pour le rediriger ou le sauvegarder2rea decompile /Applications/Target.app/.../Target 0x100012ab0 \3 --provider hopper --json > fn_config_loader.json45# Ou chercher une fonction par son nom et suivre les références6rea function /path/to/Target parseConfig --provider hopper --json7rea xrefs /path/to/Target 0x100012ab0 --provider hopper --json8rea trace /path/to/Target "sync" --provider hopper --json
1// 0x100012ab0 xrefs: 1472void sub_100012ab0(void* arg0) {3 void* var_20 = objc_msgSend(cls_NSJSONSerialization,4 sel_JSONObjectWithData_options_error, arg0, 0x0, 0x0);5 if (var_20 != 0x0) {6 void* var_28 = objc_msgSend(var_20, sel_objectForKey, @"endpoints");7 void* var_30 = objc_msgSend(var_20, sel_objectForKey, @"auth_mode");8 void* var_38 = objc_msgSend(var_20, sel_objectForKey, @"retry_count");9 objc_msgSend(g_sharedConfig, sel_setEndpoints, var_28);10 objc_msgSend(g_sharedConfig, sel_setAuthMode, var_30);11 objc_msgSend(g_sharedConfig, sel_setRetryCount,12 objc_msgSend(var_38, sel_intValue));13 }14}
La démonstration officielle de REA suit un appel sonore dans le vieux jeu DX-Ball jusqu'à la fonction utilitaire qui gère la balance audio gauche-droite, puis transforme le pseudocode à moitié terminé en C.
Le résultat passe les 3 205 cas de test originaux et reproduit chacun des 63 octets compilés.
Tutoriel complet sur rea.tools/showcase.
06. L'annotation - faites nommer chaque variable par Opus
Ce code brut ne représente que la moitié du travail. Confiez-le maintenant à Opus 5.5 et demandez-lui de l'expliquer et de le nettoyer.
Il renomme les variables cryptiques avec de vrais noms, explique en une phrase à quoi sert la fonction, repère le motif utilisé et signale même les bugs laissés par l'application originale.
Collez ce prompt dans Claude :
1Voici le pseudocode décompilé d'une fonction ayant 147 références croisées.23Pour cette fonction :41. Renomme chaque variable avec un nom explicite basé sur son utilisation.52. Indique son objectif en une phrase.63. Liste les structures de données qu'elle lit et écrit.74. Nomme le motif (singleton, factory, machine à états, observer...).85. Réécris-la en Swift propre et idiomatique (ou dans le langage suggéré par les9 conventions d'appel), avec des commentaires de documentation.106. Signale toute gestion d'erreur manquante, validation d'entrée ou contrôle de sécurité absent.1112Réfléchis-y avec un effort xhigh avant de répondre : raisonne sur ce qu'est chaque13valeur avant de fixer les noms. Marque tout ce dont tu n'es pas sûr.1415[colle le pseudocode]
La décompilation vous dit ce que fait le code. Opus 5.5 vous dit pourquoi, et vous donne les noms pour le reconstruire.
https://x.com/0x0SojalSec/status/2108389060192706674
https://x.com/0x0SojalSec/status/2108031166502896035
Toutes les cibles n'ont pas besoin d'un désassembleur. La démonstration Notion de REA trouve la fonctionnalité de presse-papiers dans le JavaScript de l'application, la suit à travers les couches Electron jusqu'au processus principal, et montre exactement comment le presse-papiers enrichi est construit : une traçabilité complète sans la moindre ligne d'assembleur. Voir
07. L'obfuscation - le benchmark Tigress
Certaines applications sont conçues pour résister précisément à ce que vous faites. Leur code est volontairement brouillé : la logique est mélangée, le texte est chiffré et de fausses branches sont ajoutées pour vous faire perdre du temps.
C'est ce qu'on appelle l'obfuscation, et c'est le seul domaine où même le meilleur modèle peine. Elastic Security Labs l'a mesuré en confrontant Claude Opus au brouilleur Tigress sur 20 tâches. Gardez ces chiffres en tête.
Deux leçons pratiques se cachent dans ces chiffres.
- Premièrement, une tentative échouée coûte environ le double d'une réussite, car le modèle s'acharne de plus en plus avant d'abandonner. Fixez donc une limite de dépenses par fonction et arrêtez tôt.
- Deuxièmement, nettoyez le code décompilé de ses scories avant de l'envoyer (un outil gratuit appelé Caveman en supprime environ 75 %) afin que le modèle concentre son attention sur la vraie logique, pas sur le remplissage.
Voici les cinq techniques que vous rencontrerez réellement, et à quoi elles ressemblent quand vous ouvrez le code :
1Cette fonction semble obfusquée. Travaille avec un effort max.231. Identifie les techniques présentes (aplatissement du flux de contrôle, prédicats opaques,4 code mort, chiffrement des chaînes, découpage de fonctions) et montre où chacune apparaît5 dans ce code précis.62. Résous-les : supprime les branches mortes, évalue les prédicats opaques, désaplatisse le7 dispatch, déchiffre les chaînes inline si la clé est récupérable.83. Affiche la fonction propre qui en résulte.94. Note ta confiance de 1 à 10. En dessous de 6, dis-moi exactement quelles parties sont incertaines10 et quel contexte voisin permettrait de les résoudre. Ne devine pas en silence.1112[colle le pseudocode obfusqué]
08. L'essaim - un contrôleur qui pilote des workers
Un seul chat ne peut pas lire correctement 500 fonctions. Il oublie ce qu'il a vu, appelle la même chose par trois noms différents et finit par se contredire.
La solution est une petite équipe : un chat contrôleur qui distribue le travail, et plusieurs chats workers qui prennent chacun une fonction.
Le contrôleur garde la vue d'ensemble et recolle les morceaux.
Vous n'avez rien de spécial à construire pour cela, les deux prompts ci-dessous constituent toute la configuration.
1Tu es un contrôleur de rétro-ingénierie. La carte des fonctions est dans functions.json2(adresse, nom, taille, xref_count).341. Regroupe les fonctions par proximité dans le graphe d'appels ; ordonne les groupes par nombre de xrefs.52. Délègue chaque groupe à un worker. N'analyse jamais une fonction toi-même.63. Injecte les structs déjà résolues dans le brief de chaque worker pour que les noms restent cohérents.74. Quand un worker renvoie une confiance inférieure à 6, planifie une seconde passe avec le contexte8 de ses voisins résolus.95. Suis la consommation cumulée de tokens et rapporte-la après chaque groupe.
1Tu es un worker. Tu reçois une fonction décompilée et les structs résolues jusqu'ici.2Renvoie exactement : adresse, objectif, confiance (1-10), structs_used, structs_new,3clean_source, flags. Réutilise les noms de structs existants ; n'invente jamais un deuxième nom pour4une struct que le contrôleur t'a déjà donnée. Une seule fonction. Arrête-toi quand c'est fini.
https://x.com/victor_explore/status/2109466356454510612
09. Clean room - quatre règles pour rester dans la légalité
Une reconstruction « clean room » signifie que vous copiez ce que fait l'application, jamais le code qu'elle contient. Faites-le bien et ce que vous livrez vous appartient entièrement. Faites-le mal et vous portez le droit d'auteur de quelqu'un d'autre.
Quatre règles vous gardent du bon côté, et l'équipe de WordCraft vérifie automatiquement ces quatre points à chaque build.
- Observer, ne jamais copier. Exécutez la cible en boîte noire, observez ce qu'elle fait, capturez uniquement sa propre fenêtre. Ne lisez, ne désassemblez et ne collez jamais son code. Ne copiez aucune formulation au-delà des simples noms de fonctionnalités.
- Des specs, pas des sources. Les formats de fichiers proviennent de standards publics (OOXML est ECMA-376 / ISO 29500, ainsi que les spécifications publiées RTF et ODF), jamais de la lecture du parseur d'un concurrent ou d'un code GPL/LGPL.
- Ressources 100 % originales. Chaque icône, police, modèle et son est généré par code, dans le domaine public ou sous licence ouverte, avec une ligne dans un fichier d'attribution. Sinon, un contrôle CI fait échouer le build.
- Séparer les deux tâches. Un agent récupère le comportement et rédige une spécification. Un autre contexte implémente à partir de cette seule spécification, sans jamais consulter l'analyse originale. Cette séparation constitue la frontière de la clean room.
1À partir de l'analyse terminée, rédige une spécification clean room pour une réimplémentation.23Décris UNIQUEMENT le COMPORTEMENT. Inclus : chaque interface publique, le modèle de données, chaque4fonctionnalité visible par l'utilisateur sous forme d'exigence testable, les formats de fichiers lus et écrits5(selon le comportement observé et les specs publiques), et la gestion des erreurs.67N'inclus PAS : les adresses ou offsets, les noms de variables issus de la décompilation, l'assembleur,8ou quoi que ce soit de copié de l'original. Un développeur n'ayant jamais vu le binaire doit être9capable d'implémenter une version compatible à partir de ce seul document.1011Produis du markdown avec les sections : Architecture, Modèle de données, API publique, Formats de fichiers,12Cas de test.
Travailler à partir d'une description n'est pas seulement une couverture juridique. Cela vous permet de faire les bons choix pour votre propre langage et vos besoins, au lieu d'hériter de décisions prises par l'auteur original il y a des décennies.
WordCraft est plus rapide que Word à certains endroits précisément parce qu'il n'a pas copié les entrailles de Word.
10. Créer des applications - douze outils pros, une seule méthode
WordCraft n'est pas un cas isolé. C'est une application parmi douze proposées par l'équipe ArtCraft, chacune étant une reconstruction clean room d'un outil pour lequel vous payez déjà, toutes écrites de zéro en Rust et livrées gratuitement et en open source sur GitHub.
Leur slogan est « Douze applications. Un seul savoir-faire », et ce savoir-faire est la méthode de l'étape 9 : observer l'original, lire les spécifications publiques, construire une nouvelle version basée uniquement sur le comportement.
Le bénéfice de cette méthode partagée est le même partout. Pas d'Electron : chaque application est native sur macOS, Windows et Linux, et toutes sauf FilmCraft tournent aussi dans un onglet de navigateur via WebAssembly.
Et comme chaque action à l'intérieur est une commande nommée, les douze applications peuvent immédiatement être pilotées par un agent IA.
Chaque application Craft est construite de la même manière, et cette architecture vaut la peine d'être copiée. Chacune est empilée en couches, chaque couche n'utilisant que celle située juste en dessous, des mesures de base tout en bas jusqu'à la fenêtre affichée à l'écran tout en haut.
Voici les couches de WordCraft :
Et chaque action n'est qu'une commande nommée, de sorte qu'un clic de souris, un raccourci clavier et un agent IA déclenchent exactement la même chose. C'est ce qui rend n'importe laquelle d'entre elles pilotable par un agent.
1piloter WordCraft via MCP23# Automatisation de documents sans interface graphique4claude mcp add wordcraft -- wordcraft-cli mcp56# Ou piloter l'application de bureau en cours d'exécution7wordcraft --control 7981 &8claude mcp add wordcraft-app -- wordcraft-cli mcp --connect 127.0.0.1:7981910# Outils : list_commands, execute, batch, type_text, select_text,11# inspect_document, render_page, save_document (+ screenshot/click/key live)12> Ouvre report.docx, mets tous les titres en gras 14pt, exporte en PDF13 ✓ select.all-headings -> 12 sélectionnés14 ✓ format.font-size 14 · format.bold15 ✓ export report.pdf (texte sélectionnable, signets conservés)
https://x.com/yuhasbeentaken/status/2109235513102057828
11. Vérifier et livrer - prouver la parité, exposer le MCP
Vous n'avez jamais eu le code source de l'original, vous ne pouvez donc pas le comparer ligne par ligne.
Vous comparez plutôt les comportements : donnez les mêmes entrées à l'original et à votre reconstruction, et vérifiez qu'elles produisent la même sortie.
1Construis un harnais de tests comportementaux comparant le binaire original et ma reconstruction.23Génère 50 entrées : 30 normales, 10 extrêmes (vide, taille max, unicode, caractères spéciaux),410 erronées (malformées, champs manquants, corrompues). Exécute chacune sur les deux. Compare la sortie5octet par octet si possible, sémantiquement sinon. Rapporte le taux de correspondance, une liste des divergences6et une sévérité pour chacune (cosmétique / comportementale / critique). Sauvegarde dans report.md.
C'est aussi la preuve la plus convaincante que vous puissiez montrer à qui que ce soit (la démo RE tout en haut de l'article).
Publiez ensuite votre reconstruction comme l'ont fait REA et WordCraft : sous forme de serveur MCP, pour que l'agent de la personne suivante puisse la piloter exactement comme vous avez piloté REA.
Donnez à chaque fonction un nom et une description clairs, encapsulez-la dans un outil en ligne de commande simple et rendez son installation possible en une ligne.
https://x.com/0xMovez/status/2108884063515746410
Et testez au fur et à mesure, pas à la fin, car une erreur découverte après avoir construit trois couches par-dessus coûte beaucoup plus cher à corriger.
Six erreurs qui gâchent un week-end
- Ouvrir un désassembleur sur une application Electron. Si le JavaScript est juste là, routez vers analyze_javascript_application et ignorez complètement la voie native.
- Tout dumper avant d'avoir rien lu. Demandez d'abord un résumé à REA. Extraire toute l'application d'un coup noie la vraie logique dans le bruit et fait exploser la facture.
- Lire les fonctions dans l'ordre du fichier. Triez par nombre de références croisées. La fonction à 147 xrefs, c'est l'architecture ; l'utilitaire à 2 xrefs peut attendre.
- S'acharner sur une obfuscation de niveau 3. Le benchmark résout 0 % des couches multiples. Fixez un budget, capitalisez le contexte des voisins, revenez-y plus tard.
- Laisser le modèle copier du code dans votre reconstruction. Cela brise la clean room. D'abord les specs dans un contexte, puis l'implémentation à partir des specs dans un autre.
- Livrer sans rapport de parité. « Je pense que ça correspond » n'est pas une preuve. 50 tests comportementaux et un taux de correspondance, si.
Conclusion :
Installez REA. Lisez le binaire. Reconstruisez-le à votre façon.
Routez la cible, cartographiez sa surface, décompilez les fonctions critiques, laissez Opus 5.5 tout nommer, cassez l'obfuscation qui mérite de l'être, passez à l'échelle avec un essaim, puis spécifiez proprement et livrez la reconstruction via MCP.
Onze étapes. Un modèle. Zéro code copié.
