Quand recourez-vous à Ghidra ou IDA plutôt qu'à un débogueur comme x64dbg, et comment se complètent-ils ?
Réponse courte
Un désassembleur comme Ghidra ou IDA vous donne la carte statique complète : références croisées, pseudocode décompilé et chaque chemin de code, qu'il s'exécute ou non. Un débogueur comme x64dbg vous permet d'exécuter l'échantillon sous contrôle — poser des points d'arrêt, inspecter registres et mémoire, observer le déchiffrement se produire, et suivre le chemin que le code prend réellement avec de vraies entrées. On lit la structure et l'intention statiquement, puis on attache le débogueur pour résoudre ce que l'analyse statique ne peut pas : chaînes déchiffrées au runtime, API résolues dynamiquement, charges utiles empaquetées, et quelle branche une condition prend. Les deux ensemble comblent leurs lacunes mutuelles.
Le reverse engineering approfondi se déroule dans deux outils complémentaires : un désassembleur/décompileur statique et un débogueur runtime. Les recruteurs posent cette question pour voir si vous comprenez ce que chacun peut et ne peut pas vous dire, et que vous passez de l'un à l'autre délibérément plutôt que de vivre dans un seul.
Le désassembleur — la carte
Ghidra (gratuit, open source, doté d'un solide décompileur) et IDA Pro transforment le code machine en assembleur navigable et en pseudocode décompilé. Leur force est la complétude et le contexte : références croisées (qui appelle cette fonction, qui lit cette variable globale), le graphe d'appels complet, la récupération de types, et chaque branche exposée — y compris du code qui ne s'exécute jamais lors d'un run donné. On utilise le désassembleur pour comprendre la structure et l'intention : ce que fait une fonction, où la config est parsée, où vit la logique C2. On peut annoter, renommer et scripter (scripts Ghidra, IDAPython) pour automatiser la déobfuscation.
Le débogueur — la vérité terrain
Une vue statique cale sur tout ce qui est résolu au runtime. x64dbg (et WinDbg pour le travail noyau) permet d'exécuter sous contrôle : points d'arrêt logiciels et matériels, inspection mémoire et registres, exécution pas à pas et patching. Il brille exactement sur ce que l'analyse statique ne peut pas voir : chaînes déchiffrées en mémoire, API résolues dynamiquement via GetProcAddress, charges utiles dépaquetées qui n'existent qu'après l'exécution du stub, et quelle branche une vérification prend réellement avec des données vivantes.
Le workflow
Lire statiquement pour construire une carte mentale et trouver les fonctions intéressantes ; y poser des points d'arrêt dans x64dbg pour les observer avec de vraies valeurs ; reverser les observations (chaînes déchiffrées, adresses d'API résolues) dans le désassembleur sous forme d'annotations. Une réponse senior insiste sur cette boucle — le statique pour l'ampleur, le dynamique pour la vérité runtime que le statique ne peut atteindre.
Questions de suivi probables
- Comment le décompileur de Ghidra aide-t-il à comprendre une fonction plus vite que l'assembleur brut ?
- Quels types de points d'arrêt dans x64dbg aident à attraper les chaînes déchiffrées au runtime ?
- Pourquoi l'analyse statique seule ne peut-elle pas résoudre les API importées dynamiquement ?