Reverse engineering IA : quand Claude Code met les mains dans le cambouis
La semaine dernière, un client m’appelle. Un vieux logiciel métier tournant sur un Windows 7 fantôme, éditeur disparu, licence bloquée. Le genre de dossier où tu sais déjà que tu vas passer la nuit. J’ai vu ce bug des dizaines de fois en quinze ans de dépannage. Et pourtant, cette fois, j’ai testé un truc nouveau : filer le binaire à une IA et la laisser faire du reverse engineering à ma place. Le résultat m’a franchement secoué.
Le sujet du jour, c’est REA, un serveur MCP qui vient se brancher sur Claude Code pour transformer le reverse engineering ia en quelque chose de réellement praticable. Korben a publié un retour d’expérience dessus, et comme je teste tout ce qui peut m’éviter de perdre trois heures sur un désassemblage à la main, je me suis penché sur la question. Autant dire que mon avis est plus nuancé que celui des youtubeurs qui crient au miracle toutes les deux semaines.
Pour être honnête, je partais sceptique. Un LLM qui analyse du code machine, sur le papier, c’est le même genre de promesse que les antivirus « boostés à l’IA » qu’on m’installe sur les postes clients. Ça brille dans la pub, ça brille moins dans l’atelier.
REA, c’est quoi ce bazar branché sur Claude Code ?
REA, pour faire court, c’est un serveur MCP. Comprends : un module qui donne à Claude Code des outils concrets pour fouiller un binaire compilé. Décompilation, analyse de chaînes, repérage de routines, patch. L’IA ne se contente plus de te pondre du code à partir d’une description, elle ouvre le fichier, le lit, et te raconte ce qu’elle y trouve. Mine de rien, c’est un changement de nature, pas juste de degré.
Le test de Korben tient en quatre exercices. Un keygen à reconstituer. Un patch de binaire compilé. De la triche sur Wolfenstein 3D. Et la recréation d’une fonction d’Amphetamine, ce petit utilitaire qui empêche ton Mac de dormir. Il a tout fait une fois avec REA, une fois sans, histoire de comparer. C’est exactement la méthodologie que j’aime : pas de blabla, des résultats.
Ce qu’il faut comprendre, c’est que sans REA, Claude Code reste un assistant de programmation. Il te parle d’assembly de loin, comme un prof qui aurait lu le chapitre la veille. Avec REA, il a les mains dedans. Nuance énorme.
- Un keygen reconstitué à partir de l’analyse du binaire
- Un binaire patché sans éditeur hexa ouvert à la main
- Wolfenstein 3D triché en modifiant la logique du jeu
- La fonction d’Amphetamine recréée de zéro
Le reverse engineering IA face au vrai travail d’atelier
Ce que ça change concrètement
Je vais te sortir un exemple que j’ai vécu. Un jour, un client débarque avec un logiciel de caisse dont le mot de passe admin avait été perdu, et l’éditeur avait fermé boutique. Binaire compilé, pas de source, pas de doc. J’ai passé deux soirées dessus. Avec un outil comme REA, je ne dis pas que ça aurait pris dix minutes, mais ça aurait probablement pris une soirée. Une seule. C’est déjà énorme.
La force du reverse engineering ia version REA, c’est l’enchaînement. L’IA repère une routine, te la commente, propose un patch, tu testes, tu itères. Sans ça, tu passes ton temps à basculer entre Ghidra, un terminal, un éditeur hexa et ta doc. Autant dire que le gain n’est pas dans l’intelligence brute, il est dans le flux de travail.
Mais attention. Je ne suis pas certain à 100% que ça tienne sur du binaire obfusqué sérieusement. Les protections commerciales modernes, celles qui te filent des migraines pendant trois jours, je doute qu’un LLM les avale comme ça. Du coup, méfiance sur les démos trop propres.
Là où je ne suis pas d’accord avec les enthousiastes
J’ai lu des gens dire que ça allait remplacer les reversers. Foutaise. Un LLM hallucine. Sur du code machine, une hallucination ne se traduit pas par une phrase bizarre, elle se traduit par un patch qui fait planter le binaire ou, pire, qui casse une vérification de sécurité sans que tu t’en rendes compte. Et ça, en prod chez un client, c’est la catastrophe assurée.
Mon avis tranché : REA est un accélérateur formidable pour quelqu’un qui sait déjà lire de l’assembly et qui sait reconnaître quand l’IA raconte n’importe quoi. Pour un débutant, c’est un piège. Il va croire le résultat, patcher à l’aveugle, et venir me voir après. Ce métier a toujours eu une barrière à l’entrée, l’IA ne l’a pas supprimée, elle l’a juste déplacée.
Les cas d’usage qui m’intéressent vraiment en tant que tech indépendant
Je ne fais pas de reverse engineering pour le sport. Je le fais quand un client est coincé. Du coup, mes cas d’usage sont moches, contrairement aux démos léchées des articles tech.
Le premier, c’est la récupération de données dans un format propriétaire. Un logiciel comptable qui crache des fichiers que plus personne ne sait ouvrir, et le module d’export qui refuse de tourner parce que la machine virtuelle est cassée. Là, comprendre la structure du binaire peut débloquer la situation. REA, sur ce genre de dossier, mine rien de miraculeux, mais il te fait gagner le temps de compréhension initial.
Le deuxième, c’est le patch de compatibilité. Un vieux soft qui refuse de démarrer sur un Windows récent parce que l’éditeur a codé en dur une vérification de version débile. Évidemment Windows a encore tout cassé avec une MAJ, comme d’habitude. Patcher ça à la main, c’est faisable. Avec REA, c’est plus rapide, à condition de savoir ce qu’on cherche.
Le troisième, et c’est celui qui me fait le plus douter : la recréation de fonctionnalité. Le test d’Amphetamine dans l’article, c’est exactement ça. Tu prends un utilitaire, tu comprends ce qu’il fait, tu refais la même chose proprement. Sauf que dans le monde réel, tu ne refais jamais « la même chose », tu refais une version qui doit tenir sur des machines que l’original n’a jamais vues. Et là, l’IA t’aide à comprendre, pas à livrer.
- Récupération de données d’un format propriétaire abandonné
- Patch de compatibilité sur logiciel ancien
- Recréation d’une fonctionnalité dont l’éditeur a disparu
- Audit rapide d’un binaire suspect avant exécution
REA contre Claude Code tout seul : le vrai match
Le point le plus intéressant de l’article de Korben, c’est la comparaison. Claude Code sans REA, sur les mêmes exercices, galère. Il parle du binaire sans le voir, propose des pistes génériques, tourne en rond. Avec REA, il a les outils, il avance. La différence n’est pas dans le modèle, elle est dans ce qu’on lui donne à mâcher.
Ça me rappelle une discussion que j’ai eue avec un confrère il y a deux ans. Il me disait que l’IA n’apporterait rien au dépannage parce qu’elle ne peut pas « sentir » la machine. Il avait raison sur un point, et il l’a reconnu depuis : l’IA ne sent rien, mais si tu lui branches les bons capteurs, elle peut aller très vite là où toi tu t’épuises. REA, c’est exactement un capteur pour binaire compilé.
Pour être honnête, je pense que ce genre d’outil va devenir la norme dans cinq ans. Pas parce que c’est magique, mais parce que les reversers expérimentés vont l’adopter discrètement et que les autres vont suivre. C’est toujours comme ça que ça se passe dans notre métier. On rigole trois ans, puis on installe.
Les limites que personne ne met en avant
Un LLM, ça coûte des tokens. Sur un gros binaire, tu peux exploser ton budget en une session. Personne n’en parle dans les articles enthousiastes, mais en indépendant, la facture compte. Du coup, REA est probablement génial sur des cibles petites ou moyennes, et beaucoup moins pertinent sur un monstre de 200 Mo.
Deuxième limite : la traçabilité. Quand tu patches un binaire client, tu dois savoir exactement ce que tu as changé. Si l’IA a touché à trois endroits et que tu n’as pas tout noté, tu es mal. C’est un point où la méthode humaine reste supérieure, parce qu’on documente par réflexe. Avec l’IA, on a tendance à faire confiance et à sauter cette étape. Erreur.
Troisième limite, et c’est la plus vicieuse : le binaire que tu analyses peut être piégé. Un malware qui détecte l’analyse, une cible qui joue avec l’IA pour lui faire produire n’importe quoi. Sur ce terrain, un humain méfiant bat un LLM confiant. Toujours.
Mon verdict de tech indépendant, sans langue de bois
REA, c’est un bon outil. Pas une révolution. Il transforme le reverse engineering ia en quelque chose de praticable pour qui a déjà les bases, et il fait gagner du temps sur des dossiers où ce temps est facturé. C’est déjà beaucoup.
Mais je refuse de dire que ça remplace le métier. Le métier, c’est de savoir quand le binaire ment, quand la doc ment, quand le client ment. L’IA ne sent pas ça. Elle calcule. Et un calcul juste sur un problème mal posé, ça reste une connerie propre.
Du coup, mon conseil : teste REA sur un petit binaire que tu connais déjà. Un truc dont tu sais à l’avance ce qu’il contient. Tu verras vite si l’outil te suit ou s’il te raconte des histoires. Et si tu ne sais pas déjà lire de l’assembly, laisse tomber pour l’instant. Apprends d’abord, l’IA ensuite. Sinon tu vas patcher à l’aveugle et appeler quelqu’un comme moi après.
Mine de rien, c’est peut-être ça la vraie nouvelle : pas que l’IA fasse le boulot, mais qu’elle rende le boulot plus rapide pour ceux qui le font déjà bien. Le reste, c’est du marketing.
Pour aller plus loin
Si tu veux le détail des quatre exercices et le vrai comparatif REA contre Claude Code tout seul, je te renvoie à la source qui m’a servi de base pour cet article. Korben a fait le boulot sérieusement, avec des résultats bruts, ce qui est assez rare pour être signalé.
REA – J’ai testé le reverse engineering par agent IA
Source : article original
