Ce que fait le décompilateur Ghidra et ses limites
Ghidra analyse les instructions, le flux de contrôle, les conventions d'appel, les symboles et les types afin de représenter une fonction sous forme de pseudo-code lisible. Le décompilateur aide surtout à repérer les branches, boucles, arguments, valeurs de retour et relations entre appelants et fonctions appelées.
La sortie n'est pas le C ou C++ original. La compilation supprime noms et types, regroupe des expressions, réordonne des opérations et insère des fonctions. Considérez chaque nom, type et expression comme une hypothèse. Une conclusion fiable doit aussi correspondre aux instructions du Listing et aux références voisines.
Cette page se concentre sur Decompiler. Pour créer un projet, importer un fichier, lancer Auto Analysis et apprendre CodeBrowser, commencez par le tutoriel Ghidra pour débutants.
Le pseudo-code est une carte lisible du comportement machine, pas une preuve du code source original.
Ouvrir Decompiler et le synchroniser avec Listing
Ouvrez le programme dans CodeBrowser après la fin d'Auto Analysis. Si le panneau est masqué, choisissez Window > Decompiler. Sélectionnez une fonction définie dans Listing ou Symbol Tree : le pseudo-code doit changer et surligner l'instruction correspondante.
Partez d'un repère fiable plutôt que de parcourir le fichier au hasard : chaîne unique, appel d'API importé, symbole exporté, message d'erreur ou point d'entrée connu. Suivez les références vers l'appelant et attendez la fin de l'analyse en arrière-plan.
Si aucune fonction n'est reconnue, ne définissez ses limites que si le désassemblage et les références les confirment. Une mauvaise langue processeur ou une base d'image incorrecte doit être corrigée à l'importation.
- 1
Choisir un repère
Trouvez une chaîne, un symbole, un import ou une adresse lié au comportement étudié.
- 2
Suivre la référence
Ouvrez la fonction utilisatrice et vérifiez que Listing, Symbol Tree et Decompiler montrent le même emplacement.
- 3
Attendre l'analyse
Lisez ensuite les entrées, appels, conditions, écritures et valeur de retour.
Lire le pseudo-code Ghidra sans lui faire aveuglément confiance
Commencez par la signature : type de retour, paramètres et convention d'appel structurent toute la fonction. Des noms comme param_1, local_18, FUN_00401230 ou undefined8 indiquent un manque d'éléments, pas les identifiants du programme d'origine. Suivez la provenance, les transformations et l'utilisation de chaque valeur.
Repérez ensuite conditions, boucles, appels, accès mémoire et chemins de retour. Ouvrez une fonction appelée, revenez avec l'historique de navigation et examinez les références avant de lui attribuer un rôle. Le surlignage croisé relie une expression aux instructions exactes.
Les optimisations peuvent rendre une expression simple complexe ou fusionner plusieurs opérations dans une sortie trop propre. Vérifiez dans Listing la direction des branches, les constantes, le signe, l'arithmétique des pointeurs et les effets de bord.
| Indice | Sens probable | À vérifier |
|---|---|---|
| param_1 / local_10 | Paramètre ou variable inconnue | Usages, pile, appelants |
| FUN_... | Fonction sans nom | Appelants, chaînes, imports |
| undefined4 / undefined8 | Taille connue, type incertain | Registres, conversions, mémoire |
| goto / boucle étrange | Flux de contrôle reconstruit | Cibles et Function Graph |
| nombreuses conversions | Conflit de type ou signature | Signe, pointeur, prototype |
Améliorer la sortie avec noms, signatures et types
La qualité augmente quand le projet contient de meilleurs faits. Renommez une fonction seulement si appels, chaînes, imports ou flux de données soutiennent son rôle. Nommez les variables selon leur responsabilité et utilisez les commentaires pour consigner preuves et incertitudes.
Une mauvaise signature propage des conversions et calculs de pointeurs trompeurs chez tous les appelants. Corrigez retour, paramètres et convention d'appel. Appliquez structures, énumérations, tableaux et pointeurs lorsque des décalages ou constantes récurrents les justifient.
Effectuez une modification étayée à la fois puis examinez les appelants. Cette discipline permet d'annuler rapidement une hypothèse séduisante mais fausse.
- 1
Renommer les symboles stables
Utilisez un nom descriptif uniquement quand les preuves visibles soutiennent le rôle.
- 2
Corriger le prototype
Réglez retour, paramètres, convention et profondeur de pointeur avant les variables locales.
- 3
Appliquer des types réutilisables
Créez structures et énumérations pour des décalages ou constantes récurrents.
- 4
Contrôler les appelants
Vérifiez que la nouvelle signature clarifie les fonctions voisines sans contradiction.
Confirmer les conclusions dans Listing et Function Graph
Listing fournit les instructions et données adresse par adresse. Utilisez-le pour confirmer quelle comparaison pilote une branche, si une valeur est signée, où revient un appel et si une écriture mémoire se produit avant ou après un contrôle.
Function Graph aide avec les conditions imbriquées, retours précoces et boucles. Suivez les arêtes vraies et fausses, repérez les blocs communs, puis revenez au décompilateur pour résumer chaque chemin clairement.
Pour une découverte importante, notez l'adresse de la fonction, l'instruction ou le bloc décisif, les références pertinentes et votre niveau de confiance. Ces preuves restent utiles si les types modifient ensuite l'affichage.
Pourquoi la décompilation paraît incorrecte ou incomplète
Une mauvaise sortie vient souvent d'informations d'analyse manquantes. Vérifiez langue processeur, spécification du compilateur, carte mémoire, base d'image, limites de fonction, signature et résultats des analyseurs avant de conclure à une panne du décompilateur.
Obfuscation, code empaqueté, assembleur manuel, appels indirects, exceptions, optimisation agressive et code automodifiable limitent la récupération. Réduisez alors la question à une branche, une structure ou un appelant plutôt que d'attendre un source propre pour tout le programme.
| Symptôme | Cause probable | Contrôle suivant |
|---|---|---|
| Aucune fonction | Limites non définies | Références et désassemblage |
| Instructions incohérentes | Mauvaise langue ou base | Importation et carte mémoire |
| Trop de conversions | Signature ou types erronés | Prototype, signe, pointeurs |
| Appels manquants | Flux indirect ou analyse incomplète | XRefs et sites d'appel |
| Pseudo-code très complexe | Optimisation ou obfuscation | Petites zones et Function Graph |
Un exercice reproductible de 20 minutes
Utilisez un programme à vous, un binaire libre, un exercice pédagogique ou un fichier que vous êtes autorisé à analyser. Importez-le dans un laboratoire isolé, lancez Auto Analysis, trouvez une chaîne de succès ou d'erreur et expliquez la fonction décisive avec vos propres mots.
Renommez uniquement les symboles justifiés, corrigez une signature ou un type, comparez la condition essentielle dans Listing et utilisez Function Graph si le flux est ambigu. Terminez par une conclusion et les adresses qui la prouvent. Automatisez ensuite avec PyGhidra.
Consultez l'aide officielle Decompiler. Installez la version vérifiée avec le guide d'installation de Ghidra et sauvegardez les projets avant une mise à niveau.
- 0–5 minutes : trouver une chaîne, un import, un symbole ou une adresse fiable.
- 5–10 minutes : lire entrées, appels, conditions, écritures et retour.
- 10–15 minutes : améliorer un nom, une signature ou un type avec des preuves.
- 15–20 minutes : vérifier le chemin décisif et noter la conclusion.
FAQ sur le décompilateur Ghidra
Ghidra récupère-t-il le code source original ?
Non. Il produit un pseudo-code proche du C à partir du code machine et des données d'analyse. Noms, commentaires, types et structure exacte sont généralement perdus.
Comment ouvrir la fenêtre Decompiler ?
Ouvrez un programme dans CodeBrowser, choisissez Window > Decompiler si le panneau est masqué, puis sélectionnez une fonction définie dans Listing ou Symbol Tree.
Pourquoi Ghidra affiche-t-il undefined8 et beaucoup de conversions ?
La taille est connue mais le type manque de preuves, ou la signature est fausse. Contrôlez appelants, registres, signe, profondeur des pointeurs et décalages répétés.
Ghidra peut-il décompiler du C++ ?
Il peut analyser du code natif issu du C++, mais modèles, classes, exceptions, inlining, optimisation et symboles supprimés éloignent le résultat du source.
Faut-il faire confiance à Decompiler ou à Listing ?
Aux deux. Decompiler accélère la compréhension ; Listing fournit les preuves par adresse pour confirmer branches, appels, constantes, mémoire et effets de bord.