REA permet à un agent de développement d’examiner un programme compilé au moyen d’outils de rétro-ingénierie. Dans l’essai publié par Korben, Claude Code utilise le serveur MCP comme passerelle vers Ghidra afin de lire un binaire, confronter plusieurs représentations de son fonctionnement et produire du code à partir de cette analyse. Le fait nouveau ne tient donc pas à une meilleure réponse conversationnelle : l’agent accède directement à un environnement spécialisé et agit sur les informations qu’il en extrait, selon le compte rendu de Korben.
Le serveur MCP ouvre les outils de rétro-ingénierie
REA, pour « Reverse Engineer Anything », relie des agents comme Claude Code, Codex ou Cursor à Ghidra, Hopper et IDA, ainsi qu’à des analyseurs destinés notamment aux applications Electron et .NET. Le serveur ne remplace pas ces logiciels : il rend leurs fonctions accessibles à l’agent, qui peut alors ouvrir un programme compilé, parcourir son pseudo-code et examiner son assembleur, d’après la présentation et le test publiés par Korben.
Ce mécanisme change la nature de la tâche confiée au modèle. Sans accès à l’outil d’analyse, celui-ci ne dispose que des fichiers ou des explications transmis dans la conversation. Avec REA, il peut interroger la structure du binaire et recouper les représentations produites par Ghidra. Dans le premier exercice rapporté, l’agent revient ainsi à l’assembleur lorsqu’une rotation de bits apparaît sous une forme difficile à interpréter dans le pseudo-code.
Pour un éditeur de logiciel ou une PME disposant d’un ancien utilitaire sans documentation exploitable, l’usage précis serait l’exploration technique avant une maintenance ou une réécriture. Le test établit que la chaîne peut extraire une logique d’un programme compilé. Il ne démontre pas qu’elle reconstitue automatiquement une application entière, ses dépendances ou ses choix de conception.
Illustration conceptuelle du parcours reliant l’agent, le serveur MCP et l’outil d’analyse du binaire.
Le générateur de clés valide la lecture du binaire
L’auteur a créé une fausse application dotée d’un système de licence afin de conserver l’expérience dans un cadre contrôlé. À partir de son binaire pour Mac ARM, l’agent a analysé la vérification de la clé puis produit un générateur en Python. Korben rapporte une exécution en deux minutes, un coût API de cinquante centimes et un essai sur 479 noms aléatoires, tous acceptés par le programme, dans son compte rendu détaillé.
Ce résultat atteste ici deux opérations complémentaires : retrouver une règle enfouie dans un exécutable, puis la réimplémenter dans un autre langage. Le volume de noms testés vérifie le générateur face à ce programme précis. Il ne mesure ni la robustesse de REA sur d’autres protections ni sa capacité à traiter des mécanismes plus complexes.
La précaution prise par l’auteur compte également dans la lecture du résultat. Le programme et son faux système de licence lui appartiennent. Cette démonstration ne constitue donc pas une autorisation générale d’analyser, de contourner ou de reproduire le fonctionnement de logiciels tiers.
Le patch combine analyse et modification manuelle
Le deuxième exercice va au-delà de l’explication du code. L’agent doit modifier un petit compteur de lignes et de mots afin qu’il affiche aussi les caractères. REA et Ghidra ne changeant pas directement les octets de l’exécutable dans cette configuration, l’agent place de nouvelles instructions dans une zone inutilisée, détourne des instructions existantes vers cette zone, puis signe de nouveau le fichier pour que macOS puisse l’exécuter, rapporte Korben.
Cette séquence montre où se situe l’apport de l’agent : il coordonne l’analyse issue de Ghidra avec des opérations réalisées hors de l’outil. Il ne se contente pas de commenter le binaire. Il conçoit un chemin d’exécution modifié et prépare un fichier lançable dans l’environnement testé.
Pour une équipe chargée d’un logiciel ancien, ce type de résultat peut servir à qualifier une correction ciblée lorsque le code source manque. La démonstration reste toutefois celle d’un utilitaire volontairement simple. Elle ne fournit pas de mesure sur la stabilité du patch, sa maintenance après une mise à jour ou son comportement dans une application comportant davantage de branches et de dépendances.
Illustration conceptuelle du détournement d’instructions et de la nouvelle signature du binaire patché.
La reproduction d’une fonction reste partielle
Un autre exercice porte sur une fonction d’Amphetamine qui maintient un Mac éveillé lorsqu’une application choisie fonctionne. REA refuse d’abord le binaire universel réunissant les architectures Intel et ARM. L’agent extrait alors lui-même la partie ARM, identifie une assertion d’énergie du système et la surveillance des applications actives, puis écrit un outil en Swift reproduisant ce comportement, selon l’essai.
Le test avec la Calculatrice fonctionne, mais révèle une contrainte : l’outil attend le nom de l’application dans la langue du système, à moins de recevoir son identifiant. Ce détail empêche de confondre reproduction fonctionnelle et copie complète. L’agent a recréé un comportement observé, avec une condition d’utilisation encore visible.
Les éléments publiés décrivent des réussites sur un poste, avec un modèle, un moteur d’analyse et des programmes déterminés. Ils ne présentent pas de protocole comparatif permettant d’isoler précisément l’apport de REA, ni de série d’essais sur des logiciels de complexité variée. Pour une PME, la décision raisonnable est donc de considérer REA comme un accès agentique à tester sur un binaire maîtrisé, et non comme une preuve d’automatisation générale de la rétro-ingénierie. Le prochain signal utile sera un test reproductible sur plusieurs architectures et niveaux de complexité.
