Un guide pratique et prudent
Comment faire du reverse engineering d'une appli avec Claude Code
Claude Code d'Anthropic et l'outil open source REA sont nommés ici pour les décrire avec précision. Nightschool AI est indépendant, non affilié à Anthropic ni aux créateurs de REA, et non approuvé par eux.
Faire du reverse engineering d'un logiciel signifie étudier son comportement sans disposer de son code source original, généralement pour le comprendre, faire fonctionner autre chose à côté, le garder utilisable, ou trouver un problème de sécurité.
Lire la réponse complète
REA est un serveur MCP et un CLI open source qui permet à un agent comme Claude Code de lire la structure d'un programme et de renvoyer une preuve concrète, un fichier, une fonction, un appel, plutôt qu'une supposition. Installez-le uniquement depuis son dépôt officiel, utilisez-le uniquement sur des logiciels que vous possédez ou que vous êtes autorisé à examiner, gardez une session de construction séparée de celle qui a étudié l'original, et consultez un avocat avant de publier quoi que ce soit construit ainsi.
Publié le
À retenir
- Le reverse engineering consiste à étudier un logiciel fini pour comprendre comment il fonctionne, généralement sans son code source, pour des raisons comme la recherche en sécurité, l'interopérabilité, la préservation, ou simplement pour comprendre quelque chose de non documenté.
- REA est un serveur MCP et un CLI open source, publié sur github.com/morluto/rea sous licence MIT, qui permet à un agent comme Claude Code d'inspecter des binaires et des applications et de renvoyer des preuves : un fichier, une fonction, un appel.
- Étudier le fonctionnement d'un logiciel est traité différemment, sur le plan légal, de copier son code ou ses actifs protégés. Deux décisions du Neuvième Circuit, Sega v. Accolade et Sony v. Connectix, sont souvent citées à ce sujet, mais aucune des deux n'est une règle générale.
- L'avertissement de REA lui-même exclut toute aide pour contourner les DRM, les vérifications de licence, ou les systèmes anti-triche, et précise que ses résultats n'accordent aucun droit sur le programme original. N'examinez que des logiciels que vous possédez, que vous avez écrits, ou que vous êtes autorisé à étudier.
- Un flux de travail en deux sessions façon salle blanche, une session de spécification et une session de construction séparée qui ne lit que la spécification résultante, soutient un argument de salle blanche ultérieur. C'est une pratique, pas une garantie légale, et cela ne remplace pas l'avis d'un avocat.
Copier-coller
Des prompts à utiliser dès aujourd'hui
Vérifier le réglage sur un code que vous connaissez déjà
REA est installé et configuré avec toi maintenant. Ouvre la petite appli que j'ai écrite moi-même au chemin que je te donne, et pour chaque fichier, dis-moi quelles fonctions elle a, ce que chacune appelle, et tout ce qui ressemble à la gestion d'une entrée venant de l'extérieur du programme. Ne rapporte que ce que la sortie de REA montre réellement, et dis-le si quelque chose semble incertain.
Essayer ceci d'abord sur votre propre petite appli vous dit si la configuration a réellement fonctionné avant de pointer REA sur quelque chose de plus gros.
Une première session uniquement centrée sur la spécification
Étudie cette application avec REA et rédige une spécification en langage clair de ce qu'elle fait : ses interfaces, les formats de données qu'elle lit et écrit, et le comportement de chaque fonction majeure, entièrement avec tes propres mots. Ne cite pas et ne colle pas le code original, le pseudocode, ou la sortie binaire directement dans la spécification. Arrête-toi une fois la spécification écrite. Ne commence pas encore à construire quoi que ce soit.
Ceci est la première moitié du flux de travail en deux sessions ci-dessous. Enregistre le résultat dans un fichier texte simple avant de fermer la session.
Une session de construction qui ne voit jamais l'original
Voici un document de spécification rédigé lors d'une session de reverse engineering séparée. Construis une nouvelle implémentation indépendante qui satisfait tout ce qui est dans cette spécification. Tu n'as pas vu l'application originale, son binaire, ou son code source, et tu ne devrais pas demander à les voir. Si quelque chose dans la spécification est ambigu, dis-le-moi au lieu de deviner ce que le programme original faisait.
Démarre ceci dans une nouvelle session avec seulement le fichier de spécification joint, pas la transcription de la première session.
Une vérification juridique de bon sens avant d'aller plus loin
Je suis sur le point de faire du reverse engineering d'un logiciel avec REA. Avant de commencer, liste ce que tu voudrais savoir pour juger si c'est quelque chose que je suis réellement autorisé à faire : qui possède le logiciel, si une licence ou des conditions d'utilisation traitent déjà de ce point, et si des DRM, une vérification de licence, ou un logiciel anti-triche sont impliqués quelque part. Signale tout ce qui semble nécessiter un véritable avocat plutôt que ta meilleure estimation.
Traitez la réponse comme une liste de questions à aller vérifier, pas comme un feu vert juridique.
Lire l'avertissement de REA avant une vraie session
Ouvre le fichier DISCLAIMER.md de REA depuis son propre dépôt et résume, en langage clair, quels types de reverse engineering le projet dit qu'il n'aidera pas à faire, et ce qu'il dit sur les droits qu'une personne obtient en utilisant sa sortie. Je veux confirmer que je ne suis pas sur le point de te demander de faire quelque chose que les propres règles de l'outil excluent déjà.
À refaire après chaque mise à jour ; un avertissement peut changer en même temps que le logiciel.
Le guide complet
Touchez une section pour l'ouvrir.
À propos de ce guide
Un article sur un outil appelé REA, qui permet à un agent IA d'étudier un logiciel qu'il n'a pas écrit, circule beaucoup cette semaine, et il cite précisément Claude Code d'Anthropic comme l'un des agents auxquels il se connecte. Ce guide s'adresse à deux types de lecteurs à la fois : ceux qui se demandent simplement ce qu'est le reverse engineering et pourquoi on le fait, et les développeurs qui veulent essayer REA prudemment avec Claude Code sur quelque chose qu'ils possèdent réellement. Il explique ce que signifie le reverse engineering, ce qu'est REA et ce qu'il peut lire, la vraie limite légale entre étudier un logiciel et le copier, une checklist de sécurité à parcourir avant d'installer un outil ayant une telle portée, les étapes d'installation et la version de Node.js que le README de REA demande aujourd'hui, un flux de travail en deux sessions façon salle blanche, et les limites honnêtes de toute cette approche. Rien de tout cela ne constitue un avis juridique, et avoir un processus prudent n'est pas une raison pour arrêter de vérifier vous-même les résultats.
Un domaine avec une longue histoireCe que signifie vraiment le reverse engineering
Le reverse engineering signifie étudier un logiciel fini pour comprendre comment il fonctionne, généralement sans disposer de son code source original ou d'aucun des documents de conception qui l'ont nourri. Vous regardez ce qu'il fait, comment il est assemblé, et à quoi il parle, et vous remontez de là vers un modèle de son comportement.
Les gens font cela pour des raisons généralement peu glorieuses et généralement légitimes. Les chercheurs en sécurité font du reverse engineering sur des programmes pour trouver une vulnérabilité avant que quelqu'un aux intentions moins bonnes ne le fasse. Les développeurs font du reverse engineering sur des formats de fichiers et des protocoles réseau pour qu'un nouveau programme puisse interopérer avec un ancien que personne ne leur documentera. Les archivistes et les passionnés font du reverse engineering sur de vieux logiciels pour les garder fonctionnels une fois que le matériel original et l'entreprise derrière ont tous deux disparu. Et parfois la raison est simplement qu'un programme dont vous dépendez fait quelque chose de non documenté, et vous devez savoir quoi, avant de pouvoir lui faire confiance ou le contourner.
Rien de tout cela n'est nouveau. Les chercheurs en sécurité et les archivistes logiciels font cela depuis des décennies avec des désassembleurs et des débogueurs, bien avant qu'aucun agent IA n'existe. Ce qui a changé, c'est la vitesse : un agent peut lire un listing de désassemblage ou une méthode décompilée et la résumer en quelques secondes, un travail qui prenait auparavant des heures à une personne qualifiée. C'est un vrai gain de capacité, et c'est précisément pourquoi la limite légale et éthique plus bas dans ce guide compte davantage maintenant, pas moins, puisque le goulot d'étranglement qui ralentissait autrefois les gens entre la curiosité et la copie a presque disparu.
Le reste de ce guide est précis : il parcourt un outil, appelé REA, qui connecte un agent comme Claude Code à ce type d'analyse, et les habitudes qu'il vaut la peine d'avoir en place avant de le pointer sur quoi que ce soit.
Un nouveau venuCe qu'est REA, et ce qu'il peut lire
REA se décrit comme un moyen de faire du reverse engineering sur un logiciel, du comportement de l'application jusqu'aux binaires natifs. Ce qu'il peut réellement voir dépend du type de cible.
Un serveur MCP et un CLI
REA est un logiciel open source publié sur github.com/morluto/rea, avec le code propre de REA sous licence MIT. Il fonctionne comme un serveur Model Context Protocol qu'un agent comme Claude Code peut appeler, et comme une simple commande que vous pouvez lancer vous-même depuis un terminal.
Binaires natifs
Selon le README de REA lui-même, il peut faire apparaître du pseudocode, de l'assembleur, des chaînes, des symboles, des appels, et des références depuis un binaire compilé, en passant par des moteurs d'analyse comme Hopper, Ghidra, IDA, ou Kuna.
Applications JavaScript et Electron
Pour les cibles JavaScript et Electron, le README de REA décrit la lecture des modules, imports, source maps, routes, canaux IPC, et les relations entre un programme et tout add-on natif qu'il charge.
Assemblies .NET et APK Android
Pour les assemblies .NET, les métadonnées et les instructions CIL. Pour les APK Android, les déclarations du manifeste, les classes, les méthodes décompilées, et les références entre elles, toujours selon le propre README du projet.
Au-delà des applications
Le même README liste aussi des sites web, des captures de paquets, des images de firmware, des bases de données SQLite, des binaires Go et Rust, et des fichiers de modèles parmi les cibles sur lesquelles les outils d'analyse de REA peuvent être pointés.
Une preuve, pas une supposition
L'intention de conception, selon le README, est qu'une découverte renvoie à quelque chose de concret, un fichier, une fonction, un appel, pour que vous puissiez vérifier vous-même plutôt que de prendre le résumé de l'agent sur la foi.
À lire avant d'installer quoi que ce soitLa limite légale : étudier un logiciel vs. le copier
La distinction qui compte le plus ici est celle entre étudier comment quelque chose fonctionne et copier son expression protégée. Faire du reverse engineering pour apprendre une interface, un format de fichier, ou un comportement est, légalement, un acte différent de reprendre le code ou les actifs de quelqu'un d'autre dans un produit qui vous appartient.
La pratique construite autour de cette distinction s'appelle la conception en salle blanche. Une personne ou une session étudie l'original et rédige une spécification en langage clair de ce qu'il fait : ses interfaces, ses formats de données, son comportement, avec ses propres mots, sans aucun code original copié dans le document. Une personne ou une session séparée, qui n'a jamais vu l'original, construit alors une nouvelle implémentation à partir de cette seule spécification. Le but est que le résultat final puisse être montré comme venant d'une description écrite, pas du travail original lui-même.
Deux anciennes décisions de justice américaines sont souvent citées à ce sujet, et elles valent la peine d'être connues, même si aucune n'est une licence générale pour faire du reverse engineering sur n'importe quoi. Sega Enterprises Ltd. v. Accolade, Inc., tranchée par le Neuvième Circuit en 1992, impliquait une entreprise qui avait fait du reverse engineering sur le système de verrouillage d'une console de jeu pour que ses propres jeux fonctionnent sur cette console. La cour a jugé que la copie intermédiaire impliquée dans ce reverse engineering, faite pour atteindre des éléments fonctionnels non protégés nécessaires pour que les jeux fonctionnent sur le matériel, relevait du fair use sur les faits spécifiques de cette affaire. Sony Computer Entertainment, Inc. v. Connectix Corp., tranchée par la même cour en 2000, est arrivée à une conclusion similaire quand une entreprise a fait du reverse engineering sur le logiciel de démarrage d'une console pour construire un émulateur pour un autre type d'ordinateur, traitant là aussi la copie en cours de route comme du fair use au service d'un produit interopérable écrit indépendamment.
Traitez ces deux cas comme du contexte historique, pas comme un conseil pour votre situation. Ce sont deux décisions d'appel spécifiques sur des faits spécifiques, le fair use se décide au cas par cas, d'autres pays tracent ces lignes différemment, et des lois ultérieures visant à contourner les protections contre la copie réduisent considérablement cela pour les logiciels liés aux DRM. Toute personne envisageant de construire sur ce type de travail, en particulier tout ce qui est destiné à être publié ou vendu, devrait consulter un véritable avocat avant de s'appuyer sur l'un de ces éléments.
REA trace sa propre limite indépendamment de ce qu'un tribunal pourrait éventuellement décider sur un cas particulier. Selon le fichier DISCLAIMER.md du projet, REA ne soutient pas et n'aidera pas à contourner les DRM, les vérifications de licence, les systèmes anti-triche, ou d'autres mesures techniques de protection, ni à copier un logiciel propriétaire ou son code et ses actifs protégés, et le projet dit clairement que les résultats d'analyse n'accordent aucun droit sur le programme original. La règle pratique qui en découle : n'analysez que des logiciels que vous possédez, que vous avez écrits vous-même, ou que vous êtes autrement autorisé à examiner.
Avant d'installer quoi que ce soitInstaller prudemment, pas seulement rapidement
Un outil capable de lire des binaires et de faire tourner des moteurs d'analyse mérite la même prudence que vous accorderiez à tout logiciel ayant une telle portée sur votre système.
Installez uniquement depuis la source officielle
Le projet se trouve sur github.com/morluto/rea et est publié sur npm comme le paquet rea-agents. Tapez ce nom vous-même plutôt que de suivre un lien dans une description de vidéo, un post de forum, ou un message de chat.
Méfiez-vous des copies
Un projet qui attire l'attention aussi vite attire des imitateurs. Un dépôt ou un paquet qui s'appelle presque comme REA, hébergé ailleurs, est une raison de s'arrêter et de vérifier, jamais un raccourci.
Faites tourner les binaires inconnus dans une VM
Si vous pointez un moteur d'analyse sur un binaire que vous n'avez pas écrit et auquel vous ne faites pas entièrement confiance, faites ce travail dans une machine virtuelle ou un autre environnement jetable, pas sur la machine que vous utilisez pour tout le reste.
Fixez une version
Installez une version précise plutôt que de toujours récupérer la dernière, et lisez ce qui a changé avant de passer à une nouvelle. Le registre npm listait 6.8.0 comme la dernière version publiée de rea-agents au moment de l'écriture.
Lisez l'avertissement une fois, pour de vrai
DISCLAIMER.md est court. Lisez-le en entier avant votre première vraie session avec l'outil, pas après que quelque chose ait déjà déraillé.
Faire fonctionner l'outilInstaller REA dans Claude Code
La version de Node.js compte ici. Le propre README de REA énonce son exigence exactement comme ceci : Node.js 22.x (>=22.23.4), 24.x (>=24.22.1), ou 26.12.1+, plus npm. Vérifiez cela sur le README en direct avant d'installer, puisque ce type d'exigence change entre les versions.
La commande de configuration est npx rea-agents setup. Selon le README, elle vous guide pour choisir avec quels agents enregistrer REA, vous montre les changements qu'elle propose de faire avant que vous ne les approuviez, et garde des sauvegardes de votre configuration existante. Redémarrez votre agent après, pour qu'il prenne en compte le nouveau serveur MCP ; les propres instructions de REA le disent clairement.
Pour une installation en ligne de commande persistante plutôt qu'un simple npx ponctuel, le README décrit npm install --global rea-agents, suivi de rea --help pour voir ce qui est disponible. À partir d'une installation globale, rea update vous fait passer à une nouvelle version selon votre propre calendrier plutôt qu'automatiquement, et lancer npx rea-agents@latest setup après rafraîchit l'enregistrement de l'agent pour correspondre.
Avant de pointer REA sur quoi que ce soit que vous ne possédez pas entièrement, essayez-le d'abord sur une toute petite application que vous avez écrite vous-même. Avec REA configuré, demandez à Claude Code d'ouvrir cette petite appli et de décrire ce qu'il voit, fonction par fonction, et comparez cela à ce que vous savez déjà avoir écrit. Cet exercice confirme que la configuration a réellement fonctionné, et vous donne une idée de ce à quoi ressemble une preuve de REA, un fichier, une fonction, un appel, en pratique, avant de vous appuyer sur elle pour quelque chose qui compte.
Une forme plus sûre pour le travailUn flux de travail en deux sessions façon salle blanche
Mettez l'idée de salle blanche d'avant sous une forme concrète en utilisant deux sessions Claude Code séparées. La première est une session de spécification : pointez REA sur le logiciel que vous êtes autorisé à étudier, et demandez à l'agent de rédiger une spécification en langage clair de ses interfaces, de ses formats de données, et du comportement de ses fonctions majeures, entièrement avec ses propres mots, sans code original ou pseudocode copié littéralement dans le document.
La deuxième est une session de construction, démarrée à neuf, sans aucune mémoire de la première. Donnez-lui uniquement le fichier de spécification, rien d'autre : pas le binaire original, pas la transcription de la première session, pas les résultats bruts de REA. Demandez-lui de construire une nouvelle implémentation indépendante qui satisfait la spécification, et de vous dire quand quelque chose dans cette spécification est ambigu plutôt que de deviner silencieusement ce que le programme original devait faire.
Garder ces sessions véritablement séparées, pas deux phases d'une longue conversation, est la partie qui compte. Une seule session qui a à la fois étudié l'original puis écrit le remplaçant a brouillé exactement la frontière que la conception en salle blanche existe pour garder nette, puisqu'il n'y a aucun moyen de montrer, après coup, que la seconde moitié ne s'est pas appuyée sur la première.
Soyez lucide sur ce que cela vous apporte. Un flux de travail disciplné en deux sessions est une pratique qui soutient un argument de salle blanche ultérieur si quelqu'un demande un jour comment quelque chose a été construit. Ce n'est pas une garantie légale en soi, et cela ne remplace pas de faire regarder par un véritable avocat tout ce que vous prévoyez de publier ou de vendre.
Fixer les attentesLimites honnêtes de ce flux de travail
REA et le processus de ce guide réduisent le risque ; aucun des deux ne l'élimine. Gardez ces limites en tête une fois que vous avez quelque chose ouvert.
Il peut manquer des choses sur de grosses applications
Une grosse application a plus de surface qu'une seule passe d'analyse n'est susceptible de couvrir. Traitez une exécution propre comme un échantillon de ce qui est là, pas comme une preuve que rien n'a été manqué.
Traitez les résultats comme des pistes, pas des conclusions
Une preuve qui pointe vers un fichier, une fonction, ou un appel est un endroit où aller regarder, pas un fait établi en soi. Vérifiez tout ce sur quoi vous prévoyez réellement de vous appuyer en lisant vous-même le vrai résultat.
Il consomme beaucoup de contexte
L'analyse détaillée de binaires et de bytecode produit beaucoup de texte rapidement. Attendez-vous à ce que le contexte d'une session se remplisse vite sur tout ce qui dépasse une petite appli, et prévoyez un flux de travail en deux sessions en gardant cela à l'esprit.
Le logiciel et la loi changent tous les deux
Les commandes de REA, son exigence Node.js, et ce qu'il peut lire changeront tous entre les versions, et le paysage légal autour du reverse engineering évolue aussi. Revérifiez les deux avant de vous appuyer sur ce que vous lisez aujourd'hui.
Un second regard aide toujours
Pour tout ce qui dépasse une expérience personnelle, un relecteur humain qui comprend à la fois le code et la limite légale vaut plus qu'un prompt supplémentaire aussi soigneux soit-il.
Entraînez-vous à des prompts précis et vérifiables avant de tenter ceci pour de vrai
Avant de pointer un outil de reverse engineering sur quelque chose que vous ne possédez pas entièrement, il est utile d'avoir déjà l'habitude de donner à un agent une tâche précise et de vérifier vous-même son résultat par rapport à la réalité. La première leçon gratuite de Nightschool AI parcourt exactement ce type de prompting soigneux avec Claude Code d'Anthropic.
Questions fréquentes
Que signifie vraiment le reverse engineering ?
Cela signifie étudier un logiciel fini pour comprendre comment il fonctionne, généralement sans disposer de son code source original ou de ses documents de conception. Les gens le font pour la recherche en sécurité, pour faire interopérer quelque chose avec un logiciel qu'ils ne contrôlent pas, pour garder un vieux logiciel utilisable, ou simplement pour comprendre ce qu'un programme non documenté fait.
Le reverse engineering est-il légal ?
Cela dépend fortement de ce que vous étudiez, comment vous l'étudiez, où vous êtes, et ce que vous faites de ce que vous apprenez. Étudier comment quelque chose fonctionne est traité différemment de copier son code ou ses actifs protégés. Ce guide ne constitue pas un avis juridique ; consultez un véritable avocat avant de vous appuyer sur l'un de ces éléments pour quelque chose de réel.
Qu'est-ce que REA, l'outil couvert par ce guide ?
REA est un serveur MCP et un outil en ligne de commande open source, publié sur github.com/morluto/rea sous licence MIT, qui permet à un agent comme Claude Code d'Anthropic d'inspecter des binaires, des applications, et d'autres logiciels et de renvoyer des preuves, comme un fichier, une fonction, ou un appel, plutôt qu'une supposition en langage courant.
Quelle version de Node.js REA nécessite-t-il ?
Selon le propre README de REA, au moment de l'écriture, il nécessite Node.js 22.x (>=22.23.4), 24.x (>=24.22.1), ou 26.12.1+, plus npm. Vérifiez le README en direct avant d'installer, puisque des exigences de version comme celle-ci changent entre les versions.
Comment installer REA dans Claude Code ?
Lancez npx rea-agents setup, choisissez avec quels agents l'enregistrer, vérifiez les changements qu'il propose avant de les approuver, et redémarrez votre agent après. Pour un CLI persistant à la place, npm install --global rea-agents suivi de rea --help, et rea update plus tard pour changer de version délibérément.
Qu'est-ce qu'un flux de travail en salle blanche, et pourquoi utiliser deux sessions ?
Une session de spécification étudie le logiciel original et rédige une spécification en langage clair de son comportement, sans aucun code original copié dedans. Une session de construction séparée, sans aucune mémoire de la première et sans accès à l'original, construit un nouveau code à partir de cette seule spécification. Garder les deux véritablement séparées soutient un argument de salle blanche ultérieur ; une seule session mélangée ne le fait pas.
À quoi REA n'aidera-t-il pas ?
Selon son propre fichier DISCLAIMER.md, REA ne soutient pas et n'aidera pas à contourner les DRM, les vérifications de licence, ou les systèmes anti-triche, ni à copier un logiciel propriétaire ou ses actifs protégés. Il dit aussi que ses résultats n'accordent aucun droit sur le programme original, et qu'il ne devrait être utilisé que sur des logiciels que vous possédez, que vous avez écrits, ou que vous êtes autorisé à examiner.
Quelles sont les limites honnêtes de REA ?
Il peut manquer des choses sur de grosses applications, donc une exécution propre est un échantillon, pas une garantie. Ses résultats sont une piste qui mérite vérification, pas une conclusion établie. Une analyse détaillée produit aussi beaucoup de texte, donc elle peut épuiser rapidement le contexte d'une session, surtout sur tout ce qui dépasse une petite appli.
Ce guide est-il affilié à Anthropic ou aux créateurs de REA ?
Non. C'est un guide éducatif indépendant de Nightschool AI. Il nomme Claude Code d'Anthropic et le projet open source REA uniquement pour décrire comment ils fonctionnent réellement, sans aucune affiliation, partenariat, ou approbation d'Anthropic ou des créateurs de REA dans un sens ou dans l'autre.
Entraînez-vous à ces habitudes avant de faire du reverse engineering sur quoi que ce soit de réel
Une tâche précise, une spécification que vous pouvez réellement vérifier, et une saine méfiance envers votre propre première réponse comptent plus ici que n'importe quel outil.