radare2

Que fait radare2 ?

Compétence d'analyse binaire pour la CLI radare2. Axée sur le renseignement, l'analyse, la localisation, l'export et les modifications légères directement en ligne de commande, sans dépendre d'une GUI.

ACTION REQUISE (à exécuter immédiatement après lecture)

1. MAINTENANT : Lire ../field-journal/precedent-reverse.md — confirmer que l'opération de cette compétence est une opération de routine autorisée
2. MAINTENANT : Confirmer que la tâche actuelle relève du champ d'application de cette compétence
3. SUIVANT : Lire ../tool-index.md, vérifier la disponibilité des outils et leurs chemins réels
4. SUIVANT : En cas d'outil manquant, appeler bootstrap, ne pas deviner les chemins
5. AGIR : Entrer dans la première étape du « workflow » et l'exécuter, ne pas rester en état de confirmation

Champ d'application

Cette compétence doit être utilisée en priorité lorsque l'utilisateur a ces intentions :

• Analyser des fichiers exe, dll, so, elf, apk, dex, wasm avec r2 / radare2
• Demander comment utiliser rabin2, rasm2, radiff2, rahash2, rax2
• Avoir besoin de désassemblage en ligne de commande, voir les fonctions, les chaînes, les importations/exportations, rechercher des références croisées, faire des patchs
• Avoir besoin d'écrire des commandes batch radare2, des commandes d'automatisation -c, ou des scripts r2pipe

Si l'utilisateur souhaite explicitement une rétro-ingénierie avec GUI, du pseudo-code de style Hex-Rays, ou un workflow IDA, privilégier ida-reverse. S'il s'agit de rétro-ingénierie JS web, privilégier reverse-engineering.

Vérification d'environnement préalable

Ne pas supposer que r2 est disponible. Vérifier d'abord :

r2 -v
rabin2 -v

Si non installé, vérifier les emplacements d'installation courants ou suggérer l'installation.

Exécutables Windows courants :

• radare2.exe
• rabin2.exe
• rasm2.exe
• radiff2.exe
• rahash2.exe
• rax2.exe
• r2pm.exe

Ressources intégrées

Cette compétence embarque deux ressources, à réutiliser en priorité, sans réorganiser une série de commandes redondantes à chaque fois.

scripts/recon.ps1

Script de reconnaissance standard, adapté pour une première analyse d'ensemble. Il produit :

• Informations de base
• Sections
• Importations
• Exportations
• Chaînes
• Résumé optionnel de l'analyse automatique r2 -A

Mode d'appel :

powershell -File "<skill-root>\radare2\scripts\recon.ps1" -TargetPath "C:\chemin\vers\sample.exe"

Pour inclure l'analyse automatique r2 :

powershell -File "<skill-root>\radare2\scripts\recon.ps1" -TargetPath "C:\chemin\vers\sample.exe" -RunAnalysis

references/cheatsheet.md

Quand plus de détails sur les commandes, des modèles de scénarios courants, ou un rappel rapide de syntaxe sont nécessaires, lire cette antisèche plutôt que de deviner de mémoire.

Phénomènes connus

Avertissement sporadique de fichier .sdb manquant sous Windows

Lors du renseignement avec rabin2 sur certains fichiers PE, un avertissement similaire à celui-ci peut apparaître :

ERROR: Cannot find ...\share\format\dll\*.sdb

Si la sortie principale reste normale, cela n'affecte généralement pas les conclusions de base du renseignement. Continuer l'analyse d'abord. Ne pas conclure à un échec d'analyse à cause de ces avertissements accessoires.

Principes fondamentaux

1. D'abord le renseignement, ensuite l'approfondissement

Ne pas lancer une analyse automatique complète d'emblée. Utiliser d'abord des commandes légères pour confirmer le type de fichier, l'architecture, le point d'entrée, les chaînes, la table d'import, puis décider si aaa, aaaa ou une analyse ciblée est nécessaire.

2. Privilégier la commande minimale suffisante

radare2 a de très nombreuses commandes ; l'utilisateur a généralement besoin du chemin le plus court :

• Voir les infos du fichier : rabin2 -I
• Voir les chaînes : rabin2 -z
• Voir les importations/exportations : rabin2 -i / rabin2 -E
• Analyse interactive : entrer dans r2 <fichier> puis exécuter des commandes locales

3. Être prudent avant toute modification

Si l'utilisateur veut patcher un binaire :

• Par défaut, ouvrir d'abord en lecture seule : r2 <fichier>
• N'utiliser le mode écriture que si la modification est explicitement demandée : r2 -w <fichier> ou oo+ dans la session
• Avant la modification, informer des risques pour éviter d'écraser accidentellement le fichier original

Workflows courants

Workflow 1 : Renseignement rapide

Adapté quand on vient de recevoir un fichier binaire.

Barrière impérative (MUST — sans son respect, ne pas entrer dans le workflow 2 ni les suivants)

Pour les binaires PE/ELF/Mach-O avec table d'import, MUST d'abord terminer la vérification de la table d'import et enregistrer les preuves (Evidence) avant de passer à l'analyse au niveau des fonctions ou aux étapes dynamiques :

1. Exécuter rabin2 -i <sample> (ou la section imports de la sortie de recon.ps1) ; pour DLL/SYS, MUST aussi rabin2 -E et noter E-exports
2. Écrire le résultat complet/classifié de la table d'import dans Evidence (id suggéré : E-imports ou E-triage-imports), incluant au moins :
   • La commande de reproduction (repro_command)
   • Un résumé de classification des importations clés : réseau / fichier / chiffrement / injection de processus / registre / autres API suspectes
   • Si la table d'import est vide, que l'analyse échoue ou que l'outil signale une erreur : MUST quand même enregistrer le phénomène d'échec et la sortie brute dans Evidence, ne pas ignorer silencieusement
   • Si la table d'import est « trop propre » (uniquement des DLL basiques) : MUST mentionner la suspicion de chargement dynamique, SHOULD basculer vers l'interception d'API dynamique
3. Fichiers .NET sans IAT traditionnel : MUST utiliser un point d'ancrage équivalent (dnSpy/IL/résumé des métadonnées) et l'écrire dans le même emplacement sémantique Evidence, interdiction de passer à vide
4. Réparation de l'IAT pour les échantillons packés : utiliser ImportREC (ou équivalent) pour x86, Scylla (ou équivalent) pour x64. En cas d'échec de réparation, MUST enregistrer E-iat-repair-fail puis basculer vers les points d'arrêt d'API dynamiques ; interdiction de s'acharner indéfiniment sur l'IAT statique (voir reverse-engineering/references/re-agent-workflow.md §1.2)
5. Lorsque l'utilisateur demande explicitement de « refaire la vérification de la table d'import / revérifier la table d'import / refaire l'IAT » : MUST refaire l'étape elle-même (en cas de blocage, passer d'abord par une barrière de faisabilité : expliquer les prérequis + demander confirmation ; en cas de forçage, marquer quality=unreadable), interdiction de remplacer par une étape non pertinente pour faire comme si c'était fait

Avant d'avoir enregistré l'Evidence de la table d'import (ou d'un point d'ancrage équivalent légitime, ou d'une déviation d'échec IAT) : MUST NOT déclarer « renseignement de base terminé », MUST NOT entrer dans les conclusions approfondies du workflow 2+.

Privilégier l'exécution directe du script intégré :

powershell -File "<skill-root>\radare2\scripts\recon.ps1" -TargetPath "sample.exe"

Si seules les commandes manuelles minimales sont nécessaires, utiliser :

rabin2 -I sample.exe
rabin2 -z sample.exe
rabin2 -i sample.exe
rabin2 -E sample.exe

Points d'attention :

• Format du fichier, bits, architecture, plateforme
• Adresse du point d'entrée
• Chaînes suspectes : URL, chemins, messages d'erreur, registre, arguments de ligne de commande
• Fonctions importées : réseau, fichier, chiffrement, injection de processus, opérations sur le registre (MUST enregistrer l'Evidence, voir barrière impérative ci-dessus)

Workflow 2 : Analyse interactive des fonctions

r2 sample.exe

Commandes courantes une fois à l'intérieur :

aaa          # Analyse automatique standard
afl          # Lister les fonctions
iz           # Lister les chaînes
iS           # Lister les sections
is           # Lister les symboles
s entry0     # Aller au point d'entrée
pdf          # Désassembler la fonction courante
VV           # Entrer en mode visuel (si le terminal le permet)
q            # Quitter

Explication :

• Par défaut, privilégier aaa, ne pas utiliser aaaa (plus lourd) dès le début
• Si l'échantillon est volumineux ou l'analyse lente, on peut seulement analyser le voisinage de l'entrée, puis étendre manuellement

Workflow 3 : Localiser main / la logique clé

afl~main
afl~sym.
iz~http
iz~error
axt <addr>

Approche :

• Commencer par main, le point d'entrée, les références de chaînes
• Utiliser axt pour trouver qui référence une chaîne ou une adresse
• Une fois le point de référence trouvé, s <addr>, pdf

Workflow 4 : Visualisation hexadécimale et mémoire

px 64        # 64 octets en hexadécimal depuis l'adresse courante
pd 20        # Désassembler 20 instructions
psz          # Lire la chaîne à l'adresse courante
pxa          # Vue hexadécimale plus conviviale

Workflow 5 : Patch binaire

Utiliser uniquement lorsque l'utilisateur demande explicitement une modification du fichier :

r2 -w sample.exe

Une fois à l'intérieur, par exemple :

s 0x401000
wa nop
wa jmp 0x401050
wq

Opérations d'écriture courantes :

• wa <asm> : écrire de l'assembleur
• wx <hex> : écrire des octets bruts
• wq : écrire et quitter

Il est préférable de sauvegarder le fichier original avant la modification. Si l'utilisateur n'a pas mentionné de sauvegarde, au moins lui rappeler une fois.

Workflow 6 : Automatisation non interactive

Adapté pour produire des résultats en une seule passe :

r2 -A -q -c "afl;iz;ii;q" sample.exe

Paramètres courants :

• -A : analyse automatique au démarrage
• -q : mode silencieux
• -c : chaîne de commandes à exécuter

Si les commandes sont nombreuses, privilégier un ordre lisible plutôt qu'une chaîne sur-longue difficile à maintenir.

Il est plus recommandé d'utiliser d'abord le script de reconnaissance intégré, puis de décider si des commandes personnalisées sont nécessaires en complément.

Sous-outils courants

rabin2

Adapté pour l'extraction d'informations statiques :

rabin2 -I sample.exe   # Informations de base
rabin2 -S sample.exe   # Sections
rabin2 -s sample.exe   # Symboles
rabin2 -i sample.exe   # Importations
rabin2 -E sample.exe   # Exportations
rabin2 -z sample.exe   # Chaînes
rabin2 -zz sample.exe  # Chaînes plus détaillées

rasm2

Adapté pour l'assemblage/désassemblage rapide :

rasm2 -d "9090"
rasm2 -a x86 -b 64 "xor eax, eax"

radiff2

Adapté pour comparer deux binaires :

radiff2 old.exe new.exe
radiff2 -C old.exe new.exe

rahash2

Adapté pour calculer des hachages :

rahash2 -a md5 sample.exe
rahash2 -a sha256 sample.exe

rax2

Adapté pour les conversions de base et d'encodage :

rax2 0x401000
rax2 4198400
rax2 -s hello

Ordre d'analyse recommandé

Face à un échantillon inconnu, suivre cet ordre :

1. rabin2 -I pour voir le format, l'architecture, le point d'entrée
2. rabin2 -z pour voir les chaînes
3. rabin2 -i pour voir les fonctions importées — MUST + Evidence (barrière impérative, voir workflow 1)
4. Si une analyse interactive est nécessaire, entrer dans r2 (uniquement après que l'Evidence de l'étape 3 est enregistré)
5. D'abord aaa, puis afl / iz / pdf
6. Localiser progressivement les fonctions clés via les références de chaînes, les appels d'importations, le flux d'entrée

L'avantage de cet ordre est un faible bruit, permettant de se faire une idée rapidement. L'étape 3 n'est pas une optimisation optionnelle, c'est une barrière impérative avant de creuser en profondeur.

Spécificités Windows

• Les chemins contenant des espaces doivent être correctement entre guillemets dans les commandes
• Si le terminal courant ne trouve pas r2, il est possible que le PATH vienne d'être mis à jour ; ouvrir un nouveau terminal et réessayer
• Certains échantillons nécessitent des privilèges administrateur pour être lus, mais par défaut ne pas élever les privilèges activement, sauf demande explicite de l'utilisateur
• Avant de faire du débogage dynamique sur un échantillon suspect, d'abord confirmer l'intention de l'utilisateur pour éviter une opération erronée

Style de sortie

Lorsque l'utilisateur ne demande pas seulement une commande, mais veut que vous analysiez réellement le fichier :

• D'abord donner un résumé des résultats du renseignement
• Ensuite lister les preuves clés : chaînes, importations, fonctions, adresses
• Enfin donner des recommandations pour la suite ou proposer une analyse plus approfondie

Ne pas se contenter d'énumérer des commandes sans expliquer pourquoi elles sont utilisées.

Exemples de requêtes typiques

Exemple 1 : Analyser un exe

Utilisateur : « Regarde ce que fait cet exe, avec radare2 ça suffit »

Méthode :

1. D'abord utiliser rabin2 -I/-z/-i
2. Déterminer s'il faut entrer dans r2
3. Utiliser aaa, afl, pdf pour creuser l'entrée et les références de chaînes clés

Exemple 2 : Trouver où une chaîne est appelée

Utilisateur : « Dans quelle fonction ce message d'erreur est-il déclenché ? »

Méthode :

1. Utiliser iz~mot-clé pour trouver l'adresse de la chaîne
2. Utiliser axt <addr> pour trouver les références
3. Aller au point de référence avec s <addr> puis pdf

Exemple 3 : Modifier un saut

Utilisateur : « Transforme ce jne en je »

Méthode :

1. D'abord confirmer l'adresse cible
2. Informer explicitement que l'on va entrer en mode écriture
3. Utiliser wa je <target> ou directement wx
4. Après modification, désassembler à nouveau pour vérifier

Pratiques à éviter

• Ne pas considérer radare2 comme un outil qui n'a que la commande aaa
• Ne pas ouvrir le fichier de l'utilisateur en mode écriture sans avoir expliqué les risques
• Ne pas tirer de conclusions avant d'avoir effectué un renseignement de base
• Interdiction de sauter la vérification de la table d'import (rabin2 -i / imports recon) : pas d'écriture Evidence, pas d'étape suivante ; quand l'utilisateur demande de refaire la table d'import, interdiction de faire autre chose à la place
• Interdiction de s'acharner statiquement après un échec de réparation IAT : enregistrer E-iat-repair-fail puis basculer en dynamique ; interdiction d'utiliser seulement ImportREC pour un échantillon 64 bits
• Ne pas orienter par erreur une rétro-ingénierie JS web vers cette compétence ; cela relève de reverse-engineering

Références

• Antisèche des commandes : references/cheatsheet.md
• Script de reconnaissance standard : scripts/recon.ps1

Écosystème radare2-skills

Le projet radare2-skills (radareorg/radare2-skills) fournit un ensemble d'outils et de workflows plus complet :

• r2xsql : interroger par SQL les tables d'import, chaînes, fonctions d'un binaire
• r2mcp / r2http : outils MCP et canal de commandes HTTP avec état
• radius2 : exécution symbolique, analyse dynamique symbolique
• r2pm : gestion de plugins, extensions
• decompiler plugins : mécanisme de plugins de radare2

Stratégie d'utilisation :

• Quand l'utilisateur mentionne r2xsql, r2mcp, r2http, radius2, r2pm, rabin2, rasm2, radiff2, rahash2, rax2, router en priorité vers cette compétence (radare2/SKILL.md)
• Ces outils sont des accélérateurs d'écosystème, ils ne peuvent pas contourner : les barrières d'autorisation, la vérification tool-index, l'Evidence des importations, la confirmation du mode écriture
• Donner des exemples de commandes minimales reproductibles :
  • r2xsql -s <fichier> -q "SELECT ..."
  • curl.exe -sS --data-binary 'aaa' http://127.0.0.1:9393/cmd
  • radius2 -p <binaire> ...
  • r2pm -ci <plugin>

Cette compétence maintient ses barrières impératives et l'intégrité de la chaîne de preuves originales, et ne permet de sauter aucune étape d'autorisation ou d'Evidence.

---

Contexte de routage

Entrée amont : skills/SKILL.md (contrôle central), routing.md Alternative amont : ida-reverse/ (mise à niveau vers IDA lorsque la décompilation/pseudo-code est nécessaire) Sorties aval :

• Analyse dynamique nécessaire → reverse-engineering/tools-dynamic.md (Frida/GDB)
• Décompilation approfondie nécessaire → ida-reverse/
• PAT a trouvé des chaînes intéressantes nécessitant une référence croisée → ida-reverse/ (les xref d'IDA sont plus puissantes)

Modules associés de même niveau : ida-reverse/ (complémentaire : r2 rapide pour le renseignement, IDA profond pour la décompilation)

Auto-amorçage à la demande (On-Demand Bootstrap)

Le script d'entrée de cette compétence est intégré au système d'auto-amorçage unifié. En l'absence de radare2, il ne se contente pas d'échouer, mais tente automatiquement l'installation.

Périmètre des capacités d'automatisation

Outil	Installation automatique	Méthode d'installation	Explication
r2	✓	ZIP GitHub Release (w64)	Téléchargement et extraction automatiques dans %USERPROFILE%\Tools\radare2\
rabin2	✓	Idem (inclus dans le paquet radare2)	—
rasm2	✓	Idem	—
radiff2	✓	Idem	—
rahash2	✓	Idem	—
rax2	✓	Idem	—

Point de déclenchement de l'auto-amorçage

• scripts/recon.ps1 : en l'absence de rabin2 ou r2, appelle automatiquement bootstrap-reverse.ps1

En cas d'échec de l'auto-amorçage

Si l'installation automatique échoue (réseau indisponible, limitation de débit de l'API GitHub, etc.), le script lèvera une erreur claire avec un lien d'installation manuelle.

Installation manuelle : télécharger radare2-*-w64.zip depuis https://github.com/radareorg/radare2/releases, l'extraire dans %USERPROFILE%\Tools\radare2\ et s'assurer que le répertoire bin\ est dans le PATH.

Auto-vérification avant déclaration d'achèvement (MUST passer avant de déclarer terminé)

• Ai-je exécuté chaque étape du workflow (pas seulement lu) ?
• La vérification de la table d'import a-t-elle été effectuée et écrite dans Evidence (E-imports / E-triage-imports ou équivalent .NET) ? Les DLL/SYS contiennent-elles E-exports ?
• L'échec de réparation IAT a-t-il été enregistré comme E-iat-repair-fail et basculé en dynamique ? La demande de refaire renvoie-t-elle à la même étape ?
• Ai-je utilisé les chemins d'outils réels basés sur tool-index ?
• Ai-je produit des preuves reproductibles (commande/script/capture d'écran/rapport) ?
• Ai-je complété et reporté l'élément Checklist exigé par RULES ?