Comment faire de la rétro-ingénierie de n'importe quoi avec Opus 5.5 ?

Pour faire de la rétro-ingénierie de n'importe quoi avec Opus 5.5, connectez le modèle à un moteur de désassemblage via REA, puis travaillez par étapes : routez la cible, cartographiez-la, décompilez les fonctions les plus sollicitées, demandez à Opus de les nommer et de les expliquer, rédigez une spécification purement comportementale, et reconstruisez à partir de cette spécification dans un contexte séparé. Adaptez le niveau d'effort à chaque étape et prouvez la reconstruction par des tests de parité.

Voilà la version courte d'un guide devenu viral sur X. Le 12 octobre 2026, le développeur Movez a publié un cours en 11 étapes sur la rétro-ingénierie avec Claude Opus 5.5. Il a dépassé le million de vues et 2 800 signets. Cet article confronte ses affirmations aux sources, corrige deux détails de benchmark et ajoute l'étape que la plupart des guides omettent : tester l'API à laquelle s'adresse une cible.

N'utilisez ceci que sur des logiciels que vous possédez ou que vous êtes autorisé à examiner. Le README de REA limite l'outil à « la recherche légale, l'éducation, l'interopérabilité, la préservation de logiciels et l'analyse de logiciels que vous possédez ou êtes autorisé à examiner ».

Pourquoi Opus 5.5 a besoin d'un outil pour lire un binaire

Opus 5.5 lit et écrit du texte ; il ne peut pas charger lui-même un fichier Mach-O ou ELF. REA est un serveur MCP qui se place entre votre agent et un moteur d'analyse (Hopper, Ghidra ou IDA pour le code natif), exécute l'analyse localement et renvoie des résultats accompagnés de leurs preuves : adresses, pseudocode, chaînes et sites d'appel. Le modèle lit ces résultats et pose la question suivante.

REA a franchi les 393 000 étoiles GitHub au 27 octobre 2026, contre environ 115 000 le 12 octobre. Nous avons couvert ce qu'est REA et comment il fonctionne ainsi qu'une boucle en six étapes pour reconstruire une fonctionnalité d'application lorsqu'il a commencé à être tendance. Ce guide se concentre sur le côté modèle : les prompts, les réglages d'effort et les limites.

Étape 1 : Installer REA et rédiger des règles internes

REA nécessite Node.js 22.23.4 ou une version ultérieure de la branche 22 (24.22.1+ ou 26.12.1+ fonctionnent aussi) ainsi que npm. La version npm actuelle est 6.8.0. Enregistrez-le auprès de votre agent :

npx rea-agents setup
npm install --global rea-agents
rea --help

Setup prévisualise ses modifications de configuration, sauvegarde ce qu'il touche et prend en charge Claude Code, Codex, Cursor, Gemini CLI et Grok Build. L'analyse native nécessite Hopper, Ghidra ou IDA ; l'inspection JavaScript, Electron et .NET ne nécessite aucun moteur.

Donnez ensuite à l'agent des règles internes. Le bloc CLAUDE.md du cours est le meilleur passage du thread :

# Reverse-engineering house rules
- Only analyze targets I own or am authorized to examine. State the basis once.
- Tag every claim: observation, inference, or unknown.
- Cite the evidence: address, bytes, pseudocode or call site.
- Start with the smallest overview. Expand only on a concrete gap.
- Separate static facts from runtime facts.
- Build from behavior and public specs, never from copied code or assets.
- Every recovered behavior needs a passing test before "done".

Étape 2 : Choisir un niveau d'effort pour chaque étape

Opus 5.5 prend en charge cinq niveaux d'effort : low, medium, high, xhigh et max. Selon la documentation d'Anthropic sur l'effort, Opus 5.5 est par défaut en medium, tandis que xhigh cible les longues exécutions agentiques et que max supprime toute limite sur la dépense de tokens. Vous le définissez avec output_config.effort côté API, ou via le réglage d'effort de votre agent.

La répartition proposée par le cours est un point de départ raisonnable, pas une règle mesurée :

Augmentez l'effort par fonction, pas par session.

Étape 3 : Router la cible avant d'ouvrir quoi que ce soit

L'erreur de débutant la plus courante consiste à ouvrir un désassembleur sur une application Electron dont le JavaScript est bien visible. REA couvre les installations de bureau, les binaires natifs, les applications JavaScript et Electron, les assemblys .NET, les APK Android, le WASM, les sites web et les captures réseau enregistrées, chacun avec son propre outil d'entrée. Votre premier prompt ne devrait servir qu'à identifier la cible :

I want to understand how [FEATURE] works in [APP] at [ABSOLUTE PATH].
First tell me what kind of target this is (native, Electron/JS, .NET, APK, WASM)
and which REA tool opens it. Don't start deep analysis yet.
Then give me a one-paragraph map and where you'd look first for [FEATURE].
Keep observations, inferences and unknowns separate.

Une cible Electron passe par analyze-javascript-application (modules, imports, frontières IPC, aucun moteur). Une cible native passe par open_binary.

Étape 4 : Cartographier les chaînes et classer les fonctions par références croisées

Ne lisez pas encore le code. Pour une cible native, commencez par un inventaire :

rea inspect /absolute/path/to/program --provider ghidra --json
rea search /absolute/path/to/program entry --kind procedures --provider ghidra --json

Les chaînes sont votre indice le plus rapide : URL, messages d'erreur et noms de fonctionnalités. Une URL de base ou une chaîne Authorization: Bearer vous indique aussi que le binaire communique avec une API, ce qui compte à l'étape 9.

Ensuite, classez les fonctions par références croisées (combien d'endroits les appellent). Une fonction avec 147 appelants relève probablement de l'infrastructure centrale, comme un chargeur de configuration ; une fonction avec deux appelants peut attendre. Lisez de haut en bas.

Étape 5 : Décompiler une fonction, puis laisser Opus la nommer

Décompilez une seule fonction critique :

rea function /absolute/path/to/program parseConfig --provider ghidra --json
rea decompile /absolute/path/to/program --procedure=parseConfig --provider ghidra --json

La sortie est brute (var_28, des casts partout). Confiez-la à Opus 5.5 en effort high avec une liste de contrôle fixe :

Here is decompiled pseudocode for a function with 147 cross-references.
1. Rename every variable based on how it is used.
2. State the function's purpose in one sentence.
3. List the data structures it reads and writes.
4. Name the pattern (singleton, factory, state machine, observer).
5. Flag missing error handling, validation or security checks.
Mark anything you're unsure of instead of guessing.

Les décompilateurs se trompent sur les détails. Dans la démonstration DX-Ball de REA, le premier pseudocode montrait une fonction de panoramique sonore ne prenant aucune entrée. Seule la vue des instructions révélait le paramètre. La reconstruction C finale passe 3 205 cas de test x86 d'origine et reproduit l'intégralité des 63 octets de fonctions compilées, parce que l'agent a recoupé le pseudocode avec l'assembleur et les appelants. Demandez rea instructions quand une signature semble étrange.

Étape 6 : Budgéter le code obfusqué, ne pas s'y acharner

C'est ici que le cours viral doit être corrigé. Il cite le benchmark d'obfuscation d'Elastic Security Labs comme un test de « Claude Opus ». L'étude d'Elastic, publiée le 21 avril 2026, a testé Claude Opus 4.6, et non Opus 5.5. Les chiffres :

Au total, Opus 4.6 a résolu 8 des 20 cibles évaluables (40 %). Les succès ont coûté en moyenne 2,39 $ et les échecs 4,83 $, donc un échec coûte environ le double d'un succès. Considérez ces chiffres comme un plancher, pas comme une mesure d'Opus 5.5 ; nous n'avons trouvé aucun équivalent publié pour 5.5.

Deuxièmement, le cours affirme qu'un outil appelé Caveman « supprime environ 75 % » du bruit de décompilation. Elastic décrit Caveman comme un plugin qui réduit la verbosité du modèle lui-même jusqu'à 75 %, et non comme un filtre de code décompilé.

La leçon reste valable : plafonnez la dépense par fonction obfusquée, demandez un score de confiance de 1 à 10 et mettez de côté tout ce qui est inférieur à 6 jusqu'à ce que ses voisins soient résolus.

Étape 7 : Découper les grosses cibles en un contrôleur et des workers

Une seule conversation ne peut pas contenir 500 fonctions ; elle oublie les noms et se contredit. La solution du cours est un contrôleur qui n'analyse jamais le code et des workers qui prennent chacun une fonction :

Controller: The function map is in functions.json (address, name, size, xrefs).
Cluster functions by call-graph proximity, order clusters by xref count,
send each cluster to a worker, inject already-resolved struct names into every
brief, and queue a second pass for any result with confidence below 6.
Report token spend after each cluster.

Chaque worker renvoie l'adresse, la finalité, un score de confiance de 1 à 10, les structures qu'il a utilisées ou trouvées et un code source propre, en réutilisant les noms de structures du contrôleur. Le benchmark d'Elastic utilisait la même forme contrôleur/worker.

Étape 8 : Rédiger une spécification purement comportementale dans un contexte propre

Une reconstruction en salle blanche copie ce que fait le logiciel, jamais son code. Demandez à Opus une spécification purement comportementale : interfaces publiques, modèle de données, chaque fonctionnalité sous forme d'exigence testable, formats de fichiers issus de standards publics et gestion des erreurs. Interdisez les adresses, les noms décompilés et tout élément copié.

Implémentez ensuite à partir de cette spécification dans un autre contexte qui ne voit jamais l'analyse. Cette séparation est la frontière de la salle blanche. Il s'agit de pratique d'ingénierie, et non d'un conseil juridique.

Étape 9 : Récupérer le contrat d'API et le tester avec Apidog CLI

Les chaînes de l'étape 4 révèlent souvent une URL de base et un en-tête d'authentification, ce qui signifie qu'une partie du comportement se trouve derrière une API. Votre reconstruction ne correspondra que si elle respecte aussi ce contrat, et le trafic le montre plus rapidement que l'assembleur.

Enregistrez un HAR sur un compte de test que vous possédez, et laissez REA le résumer :

rea inspect-web-network-capture /absolute/session.har har --json

Laissez ensuite votre agent transformer cette capture en un contrat testé avec Apidog CLI. Configurez-le une fois :

npm install -g apidog-cli@latest
apidog auth login --with-token <YOUR_TOKEN>
apidog skill install

Donnez un seul prompt à l'agent :

Import session.har into Apidog project <id>. List the endpoints it created,
remove anything that isn't part of [FEATURE], and write one test case per
endpoint that asserts status code, required fields and response schema.
Run them against the original-service environment, then against my rebuild's
environment, and report every endpoint where the two disagree.

L'agent exécute l'import, vérifie la forme des payloads avant d'écrire, puis exécute les deux environnements :

apidog import --project <id> --format har --file ./session.har
apidog endpoint list --project <id>
apidog cli-schema get test-case-create
apidog cli-schema validate test-case-create --file case.json
apidog test-case create --project <id> --file case.json
apidog test-case run --project <id> --endpoint <endpointId> -e <originalEnvId> -r cli,json
apidog test-case run --project <id> --endpoint <endpointId> -e <rebuildEnvId> -r cli,json

Les mêmes cas, deux environnements, un seul diff, rejouable à chaque commit avec -r junit (voir notre guide CI/CD d'Apidog CLI). Si vous préférez le piloter depuis Claude Code, consultez Apidog CLI dans Claude Code. Le forfait gratuit d'Apidog couvre jusqu'à 4 utilisateurs. Pour l'approche manuelle, voir la rétro-ingénierie d'API.

Étape 10 : Prouver la parité avant de livrer

« Je pense que ça correspond » n'est pas une preuve. Pour le comportement local, demandez à Opus de construire un harnais qui injecte les mêmes entrées dans l'original et dans la reconstruction :

Generate 50 inputs: 30 normal, 10 edge (empty, max size, unicode), 10 error
(malformed, missing fields, corrupt). Run each through both programs. Compare
byte-for-byte where possible, semantically otherwise. Report the match rate and
every divergence as cosmetic, behavioral or critical.

Avec l'exécution d'API de l'étape 9, vous obtenez deux chiffres à montrer à quiconque : un taux de correspondance local et un taux de correspondance d'API. Testez au fur et à mesure, pas à la fin.

FAQ

La rétro-ingénierie avec Opus 5.5 est-elle légale ? Cela dépend de votre juridiction, de la licence et de votre objectif. REA prend en charge la recherche légale, l'éducation, l'interopérabilité, la préservation et l'analyse de logiciels que vous possédez ou êtes autorisé à examiner. Demandez un avis juridique avant de livrer commercialement une reconstruction.

Quel niveau d'effort dois-je utiliser pour la rétro-ingénierie ? Commencez en medium pour le routage et la reconnaissance, passez à high pour annoter les fonctions, et réservez max au code obfusqué avec un budget par fonction. Opus 5.5 est par défaut en medium.

Comment Claude se débrouille-t-il avec les binaires obfusqués ? Le seul benchmark public, celui d'Elastic Security Labs, a testé Opus 4.6 : 40 % des 20 cibles Tigress résolues et 0 % des cibles lourdes multicouches. Aucun test équivalent d'Opus 5.5 n'a été publié.

Comment tester l'API qu'utilise une application rétro-ingénierée ? Capturez un HAR sur un compte de test, importez-le avec apidog import --format har, créez des cas de test avec Apidog CLI et exécutez-les à la fois contre le service d'origine et contre votre reconstruction.

REA téléverse-t-il mon binaire ? REA exécute l'analyse localement. Seuls les résultats que votre agent transmet au modèle (chaînes, pseudocode) atteignent votre fournisseur de modèle.