REA récupère-t-il le code source original ?

Non. Rien ne récupère le code source original à partir d’un binaire — les noms de variables, les commentaires et la structure que l’auteur a écrits disparaissent au moment de la compilation. Ce que produisent les décompilateurs, c’est du pseudocode : une approximation lisible de ce que fait le code machine. La contribution de REA est de travailler à partir de ces preuves de façon systématique et d’écrire une spécification du comportement, ce dont une reconstruction fidèle a réellement besoin.

Est-il légal de rétro-ingénierer une application ?

Cela dépend de l’application, de la raison et du lieu. Rétro-ingénierer votre propre logiciel, mener une recherche en sécurité de bonne foi et travailler pour atteindre l’interopérabilité sont largement acceptés et, dans certaines juridictions, légalement protégés ; la licence d’un produit peut restreindre davantage, et contourner les DRM ou les contrôles d’accès est interdit dans de nombreux endroits, quelle que soit l’intention. La documentation même de REA le limite à la recherche autorisée et licite — et vous devriez en faire autant. Quand la réponse compte commercialement, c’est une question pour un avocat de votre juridiction, pas pour un outil.

Ai-je encore besoin d’avoir Ghidra installé pour utiliser REA ?

Pour les binaires natifs, oui — REA est une couche d’orchestration, pas un moteur. Il pilote un moteur d’analyse installé (Ghidra, IDA Pro ou Hopper) et vérifie chacun avec sa commande doctor. Les APK passent par JADX, et certaines cibles — applications JavaScript et Electron, sites web, captures réseau — n’ont besoin d’aucun moteur natif. L’installation prend un après-midi, une seule fois ; l’endurance de l’agent est la partie que vous ne pourriez pas embaucher.

Les agents IA peuvent-ils rétro-ingénierer votre application ?

By John · Former Microsoft engineer with 20 years of experience.

REA — Reverse Engineer Anything — est un serveur MCP et un outil en ligne de commande open source qui permet à un agent de codage d’utiliser des logiciels professionnels de rétro-ingénierie : pointez l’agent vers une application ou un binaire publié, et il inspecte le code avec de vrais décompilateurs, écrit le fonctionnement d’une fonctionnalité sous forme de spécification, reconstruit la fonctionnalité et compare la reconstruction à l’original. Il est devenu l’un des projets GitHub à la croissance la plus rapide en octobre 2026, et il change l’économie d’un fait ancien : tout ce qui s’exécute sur la machine d’un utilisateur peut être lu par cet utilisateur. Cet article explique ce qu’est réellement REA, la pile d’outils qu’il pilote, le flux de travail qui rend ses résultats dignes de confiance, et ce qu’un développeur qui publie un logiciel devrait en faire.

Ce qu’est REA

REA (le dépôt est morluto/rea, sous licence MIT, installé depuis npm sous le nom rea-agents) n’est pas un décompilateur. Il ne décompile rien lui-même. C’est une couche d’orchestration qui parle le Model Context Protocol — la même interface que le travail de préparation aux agents de ce site aborde du côté site web — et expose les opérations de rétro-ingénierie comme des outils qu’un agent de codage tel que Claude Code, Codex ou Cursor peut appeler : désassemble ce binaire, décompile cette fonction, liste les chaînes, suis les références croisées, montre les preuves. Le gros du travail est fait par les moteurs sous-jacents, que l’agent pilote comme le ferait un analyste humain, sauf qu’il peut se permettre d’être exhaustif.

Cette division du travail est précisément le point. La sortie d’un décompilateur est énorme et le plus souvent ennuyeuse ; la compétence rare en rétro-ingénierie n’a jamais été d’exécuter l’outil, mais de décider quoi regarder ensuite et de savoir quand une réponse est prouvée. REA associe les moteurs à des instructions de flux de travail — enquêter dans un ordre défini, consigner des preuves pour chaque affirmation, déclarer ce qui n’a pas pu être résolu — de sorte que la sortie de l’agent n’est pas un tas de pseudocode mais un ensemble de conclusions étayées par des justificatifs. Pour les binaires natifs, il pilote Ghidra, IDA Pro ou Hopper ; pour les paquets Android, il pilote JADX ; pour le comportement en direct, il peut lire des captures HAR et mitmproxy. Une interface, de nombreux moteurs, et l’agent fournit l’endurance.

La pile en une seule carte

Le cœur d’analyse. Ghidra est le décompilateur gratuit de la NSA, sous licence Apache-2.0, et le moteur par défaut pour la plupart des gens ; IDA Pro est le vétéran commercial que beaucoup de professionnels préfèrent encore. Ce qui est nouveau, ce n’est ni l’un ni l’autre de ces outils, mais leurs ponts : GhidraMCP et ida-pro-mcp exposent une session Ghidra ou IDA en cours à un agent via MCP, de sorte que l’agent peut interroger directement la base de données de désassemblage au lieu de lire des captures d’écran. REA se situe un niveau au-dessus d’eux, choisissant les moteurs et séquençant le travail.

Mobile et applications. jadx décompile les APK Android en Java lisible ; Apktool déballe les ressources et le smali d’un APK et peut le reconstruire ; Frida instrumente une application en cours d’exécution, accrochant les fonctions au moment où elles s’exécutent — la moitié dynamique que la décompilation statique ne peut pas voir ; et ILSpy fait pour les assemblages .NET ce que jadx fait pour les APK. (Pour un premier aperçu sans installation des déclarations d’un APK plutôt que de son code, l’APK Analyzer de ce site lit le manifeste, les autorisations et les certificats de signature dans votre navigateur.)

Binaire et bas niveau. radare2 et son fork plus convivial rizin sont des cadres de rétro-ingénierie scriptables et centrés sur le terminal ; x64dbg est le débogueur Windows vers lequel se tournent la plupart des analystes ; ImHex est un éditeur hexadécimal doté d’un langage de motifs pour décrire les formats de fichiers ; et angr est un moteur d’exécution symbolique capable de raisonner sur chaque chemin à travers une fonction plutôt que sur une seule exécution. Ce sont les outils pour les questions auxquelles les décompilateurs répondent mal : binaires compressés ou protégés, formats de fichiers étranges, « cette entrée peut-elle seulement atteindre cette branche ».

Réseau et exécution. mitmproxy se place entre une application et ses serveurs et enregistre la conversation — pour beaucoup d’applications, le trafic de l’API explique plus que le code, et c’est le format de capture que REA lit nativement. dnSpy débogue et modifie les applications .NET en direct, et raddebugger est le débogueur graphique moderne d’Epic pour Windows. Autour de tout cela se trouvent les cartes : deux listes sélectionnées, awesome-ai-reverse-engineering (122 dépôts de l’ère des agents, chacun lu et noté) et celle de l’auteur même de REA, awesome-reverse-engineering, sont liées dans les sources ci-dessous.

La boucle en salle blanche : spécifier, reconstruire, vérifier

Le flux de travail que REA encourage est plus ancien que l’IA : c’est l’ingénierie en salle blanche, la discipline autrefois utilisée pour cloner un BIOS sans le copier. L’agent enquête sur la cible et écrit SPEC.md — une spécification de ce que fait le logiciel, en langage simple, avec les preuves de chaque comportement jointes. Ce n’est qu’ensuite que la reconstruction commence, à partir de la spécification plutôt que du code décompilé, et la reconstruction est jugée selon des critères d’acceptation : mêmes entrées, mêmes sorties, mêmes cas limites. Quand le juge dit non, la boucle revient aux preuves — pas à une supposition — et enquête à nouveau.

C’est pourquoi l’artefact intéressant est la spécification, pas le pseudocode. Une spécification accompagnée de preuves peut être vérifiée par un second agent, par une suite de tests ou par un humain ; une décompilation brute n’est rien de tout cela. C’est aussi l’étape juridiquement significative : une reconstruction à partir d’une spécification comportementale est un acte différent de la copie d’une implémentation, raison pour laquelle la boucle insiste sur les preuves et les critères plutôt que sur les impressions. Quiconque évalue des outils d’agents — pour la rétro-ingénierie ou pour autre chose — devrait s’approprier ce modèle : le livrable est une affirmation vérifiée, pas une réponse assurée.

Ce que cela signifie si vous publiez un logiciel

Rien de tout cela ne rend le code côté client secret ; il ne l’a jamais été. Cela rend sa lecture bon marché. Un analyste compétent avec Ghidra a toujours pu extraire de votre application les points de terminaison de l’API, les commutateurs de fonctionnalités et la logique de licence — les outils de la classe de REA signifient qu’un junior muni d’un abonnement à un agent peut faire le premier passage en un après-midi. Les conséquences pratiques sont les mêmes que toujours, désormais avec des délais plus courts : un secret intégré dans un binaire publié — une clé d’API, un point de terminaison privé, l’unique et véritable règle de remise — est de fait publié ; l’obfuscation élève le coût de lecture mais reste un retard, pas une barrière ; et tout ce dont le secret fait dépendre votre activité doit vivre sur votre serveur, derrière une authentification, et non dans l’application.

Les défenses sont tout aussi peu glamour et elles fonctionnent : gardez les secrets et les décisions de tarification et de licence côté serveur, émettez des jetons de courte durée et de portée limitée plutôt que des clés permanentes, utilisez l’attestation de plateforme (Play Integrity, App Attest) là où le risque le justifie, et partez du principe que le comportement de votre client est entièrement observable lorsque vous concevez les contrôles anti-abus. C’est l’image en miroir de la leçon de préparation aux agents de ce site : là, l’idée était que les agents lisent la surface de votre site destinée aux machines, que vous l’ayez conçue ou non ; ici, les agents lisent le binaire de votre application de la même manière. Dans les deux cas, le coup gagnant consiste à décider délibérément ce que dit la surface destinée aux machines.

Usages légitimes — et les limites

La rétro-ingénierie a des usages honorables et établis, et la documentation même de REA en donne la même liste : analyser votre propre logiciel (y compris la copie dont vous avez perdu le code source), la recherche en sécurité et l’analyse de vulnérabilités, l’investigation de logiciels malveillants et d’incidents, l’interopérabilité — faire fonctionner votre produit avec un autre —, les compétitions CTF et l’éducation. Dans de nombreuses juridictions, certains de ces usages sont protégés même face à une clause de licence qui prétendrait les interdire, en particulier l’interopérabilité et la recherche en sécurité de bonne foi, bien que les détails varient et que cet article ne constitue pas un conseil juridique.

Les limites sont tout aussi claires. Une licence MIT sur les outils n’est pas une licence sur la cible : elle n’autorise pas à cloner le produit d’un concurrent à partir de son binaire, à vaincre les DRM ou l’application des licences, ni à distribuer ce que vous extrayez. La boucle en salle blanche de la section précédente existe précisément pour maintenir une reconstruction du bon côté de cette ligne — comportement et preuves, pas implémentation copiée. Les propres outils d’analyse de ce site adoptent la même ligne en miniature : statiques, locaux, en lecture seule, sans exécution, sans contournement — un premier aperçu, le travail lourd et juridiquement sensible étant laissé aux outils et aux personnes qui peuvent en assumer la responsabilité.

Essayez-le vous-même

REA nécessite Node.js 22 ou plus ; une seule commande — npx rea-agents setup — enregistre son serveur MCP auprès des agents de codage qu’il trouve et installe les instructions de flux de travail correspondantes, et la propre commande doctor de REA vérifie chaque moteur (un moteur natif tel que Ghidra doit être installé pour les binaires natifs ; JADX couvre les APK). Pointez-le vers un logiciel qui vous appartient ou un échantillon que vous êtes autorisé à inspecter — un petit utilitaire que vous avez écrit est la première cible parfaite — et demandez-lui comment fonctionne une fonctionnalité. Lisez la spécification qu’il produit avant de lire le moindre pseudocode : les liens vers les preuves sont là où se trouve la vérité.

Si vous voulez la version sans installation de la première étape, c’est à cela que sert le Binary File Inspector de ce site : déposez un fichier PE, ELF ou Mach-O dans la page et lisez ses en-têtes, sections, importations et chaînes dans votre navigateur — sans téléversement, sans exécution, sans chaîne d’outils. Il ne décompilera rien, et il le dit ; c’est le triage de cinq minutes qui vous dit si le traitement complet par REA vaut la peine d’être configuré, et pour quel moteur.