Débogueur Ghidra : lancer, attacher et avancer dans le code

Ghidra possède-t-il un débogueur ?

Oui. Le framework de débogage de Ghidra peut lancer ou connecter une cible, enregistrer une trace, afficher registres et mémoire, puis avancer avec des points d’arrêt. Il ne remplace pas Decompiler : Decompiler interprète les octets de façon statique, tandis que le débogueur observe un état d’exécution précis.

Une première session relie trois vues. GDB ou un autre agent contrôle le processus, Ghidra enregistre les changements dans une trace et le programme statique apporte noms, fonctions et contexte. Les conclusions solides comparent ces trois éléments au lieu de faire confiance à un seul panneau.

Préparer Ghidra, GDB et un laboratoire sûr

La vérification du 6 août 2026 a trouvé Ghidra 12.1.2 dans la version officielle de NationalSecurityAgency/ghidra. Publiée le 5 juin 2026, elle conserve l’exigence JDK 21 64 bits indiquée dans le guide d’installation. Installez d’abord l’archive officielle et vérifiez que Ghidra démarre avant de diagnostiquer le débogueur.

Les exemples utilisent une cible native et des concepts GDB. Les champs varient selon le système et l’agent, mais il faut toujours choisir la bonne architecture, noter les arguments, utiliser un chemin simple et distinguer lancement local, attachement à un processus et connexion distante.

• Choisissez un petit exécutable dont l’entrée et la sortie sont prévisibles.
• Conservez l’original, son hash et le projet Ghidra dans des dossiers séparés.
• Commencez par l’analyse statique si la cible est inconnue : l’exécution n’est pas obligatoire.
• Consultez le cours officiel du débogueur Ghidra pour les agents spécifiques.

Lancer une première cible avec le débogueur Ghidra

Créez un projet non partagé et importez l’exécutable d’exercice afin de disposer de la vue statique. Ouvrez ensuite l’outil Debugger. Le premier objectif n’est pas de reconstruire parfaitement le code source, mais de vérifier le lancement, l’architecture et l’arrivée d’un état exploitable dans la trace.

Choisissez le lanceur GDB local et relisez chaque champ avant Launch. Image correspond au fichier, Arguments aux valeurs de ligne de commande, gdb command à l’exécutable GDB, et Architecture/Endian doivent correspondre à la cible. En cas de doute, vérifiez le format plutôt que de répéter une configuration incorrecte.

1. 1

   Créer le projet

   Dans la fenêtre de projet, choisissez File > New Project, puis Non-Shared Project et un dossier de laboratoire. Importez le fichier que vous allez lancer.

2. 2

   Ouvrir Debugger

   Démarrez Debugger et l’action d’agent adaptée à votre environnement. Gardez le programme statique visible pour le comparer à la trace.

3. 3

   Relire les champs

   Définissez le chemin, les arguments, la commande GDB, l’architecture, l’endianess et éventuellement le terminal. Évitez les caractères spéciaux au premier essai.

4. 4

   Lancer puis arrêter

   Lancez la cible, attendez le premier arrêt et vérifiez thread, compteur de programme, Listing et console avant le pas à pas.

S’attacher à un processus ou connecter une cible distante

Launch démarre une nouvelle cible sous le contrôle du débogueur. Attach part d’un processus déjà lancé, tandis qu’une connexion distante utilise un agent tel que GDB server. Ces modes ajoutent permissions, architecture, cartes mémoire et variables réseau : faites d’abord fonctionner le lancement local.

Pour Attach, identifiez un processus dans un laboratoire autorisé, choisissez le connecteur adapté et vérifiez l’architecture. Pour une cible distante, contrôlez hôte, port, version du serveur, symboles et frontière de confiance. Une connexion réussie peut rester incomplète si registres, mémoire ou modules ne sont pas exposés.

1. 1

   Choisir le mode

   Utilisez Launch pour un nouveau processus local, Attach pour un processus local existant ou le flux distant approprié pour GDB server.

2. 2

   Faire correspondre la cible

   Vérifiez processeur, endianess, système et espace d’adressage. Chargez les symboles correspondants si la cible est dépouillée.

3. 3

   Valider le premier arrêt

   Inspectez thread, compteur, modules et console. Un simple message de connexion ne signifie pas que l’état est disponible.

Comprendre l’espace de travail du débogueur

L’espace de travail affiche plusieurs versions du même état. Commencez par le compteur de programme et le thread sélectionné, puis utilisez un panneau pour répondre à une question précise. Ouvrir toutes les vues simultanément rend souvent la première session plus difficile à diagnostiquer.

Registers est un instantané, pas une explication. Une valeur modifiée indique ce que la cible observait à un arrêt ; vérifiez la raison avec l’instruction de Listing, la pile ou la mémoire et la relation appelant/appelé du programme statique.

Utiliser les points d’arrêt et le pas à pas

Un point d’arrêt est utile lorsque vous pouvez expliquer la raison de l’arrêt. Commencez par l’entrée, une fonction connue ou une branche liée à l’entrée de test. Resume continue, Interrupt reprend le contrôle, Step Into entre dans un appel, Step Over reste au même niveau et Step Out revient à l’appelant.

Si un point reste en attente ou ne devient jamais effectif, vérifiez le chargement du module, le mappage de l’adresse, les permissions et la correspondance statique/dynamique. Une fonction optimisée ou inline peut demander une instruction voisine.

• Commencez avec un seul point d’arrêt.
• Notez compteur, thread et registre important avant chaque pas.
• Après un arrêt significatif, écrivez l’entrée, la branche, la mémoire et la conclusion.
• Supprimez ou désactivez les points temporaires avant de partager le projet.

Relier l’état vivant à CodeBrowser et Decompiler

Le débogueur devient plus utile lorsque la trace et le programme statique sont mappés. Utilisez compteur, module, fonction et octets pour retrouver le même code dans CodeBrowser. Lisez ensuite Decompiler comme une hypothèse et vérifiez les conclusions importantes dans Listing et l’état vivant.

C’est la différence avec un terminal GDB isolé. GDB contrôle l’exécution, tandis que Ghidra conserve la trace avec symboles, blocs mémoire, références et contexte decompilé. Si le mappage est faux, vérifiez base du module, architecture, relocation et programme importé plutôt que de forcer une correspondance.

1. 1

   Localiser l’adresse dynamique

   Utilisez le compteur ou un point d’arrêt pour identifier module et adresse actuels.

2. 2

   Trouver la correspondance statique

   Ouvrez la position dans CodeBrowser et vérifiez octets, limites de fonction et mappage du module.

3. 3

   Expliquer le comportement

   Comparez Listing, Decompiler, registres, mémoire et pile ; séparez observation et inférence.

Problèmes courants du débogueur Ghidra

Les premiers échecs viennent généralement d’un mauvais paramètre et non d’une fonction absente. Changez une seule variable à la fois et conservez la sortie console. Une petite cible connue est préférable pour valider la chaîne avant un programme complexe.

Une connexion réussie ne suffit pas. Vérifiez thread, compteur, modules et au moins un panneau d’état rempli. Avec une cible dépouillée ou fortement optimisée, prévoyez du temps pour les symboles et le mappage des adresses.

Après la première session de débogage

Répétez le cycle lancement-arrêt sur deux ou trois petits programmes autorisés avant de passer à une cible distante ou multithread. Entraînez-vous à expliquer une branche depuis l’entrée, le point d’arrêt, la modification d’un registre ou de la mémoire, jusqu’à la fonction statique correspondante.

Le tutoriel Ghidra pour débutants couvre projet, Auto Analysis, références et Function Graph. La guide Decompiler aide à améliorer noms et types ; revenez au guide d’installation si le problème vient du JDK ou du lanceur. Le cours officiel du débogueur détaille les agents spécifiques.