À quoi sert le Ghidra Script Manager ?
Le Script Manager est l’espace intégré de Ghidra pour rechercher et lancer des scripts. Il est utile lorsqu’une même inspection ou opération de nettoyage revient dans plusieurs projets : lister des fonctions, renommer des symboles, exporter des données sélectionnées, ajouter des commentaires ou réunir des éléments pour un rapport. Le résultat reste une action d’analyse Ghidra normale ; vérifiez-le donc dans CodeBrowser, Listing ou Decompiler.
Un script ne remplace pas la compréhension du binaire. Traitez-le comme une petite expérience vérifiable : définissez le projet cible, faites la modification minimale, conservez une copie si l’opération écrit dans le projet et notez les changements. Le tutoriel Ghidra pour débutants présente l’analyse statique ; cette page se concentre sur l’automatisation de ce flux.
Analysez uniquement les fichiers et systèmes que vous êtes autorisé à examiner. Le Script Manager peut modifier rapidement un projet : commencez avec une copie.
- Trouver les scripts fournis avec Ghidra ou stockés dans vos répertoires de scripts.
- Ouvrir un script, vérifier son langage et ses imports, puis l’exécuter sur le programme actif.
- Utiliser le modèle de programme et la console pour réaliser une petite modification répétable.
- Séparer l’automatisation du Script Manager de l’automatisation CPython native avec PyGhidra.
Ouvrir le Script Manager et trouver un script
Ouvrez un projet et lancez le Script Manager depuis les menus d’outils de Ghidra. L’emplacement exact peut varier légèrement selon l’outil et la version, mais l’espace contient une liste de scripts, une recherche ou des filtres, un éditeur et des actions pour exécuter ou actualiser la liste. Si un script copié récemment n’apparaît pas, actualisez d’abord la liste.
Commencez par un script en lecture seule ou destiné à produire un rapport. Lisez les commentaires d’en-tête et les imports avant de choisir Run. L’en-tête doit indiquer si le script attend un programme ouvert, une sélection, une fonction courante ou un processeur précis.
- 1
Ouvrir un projet d’exercice
Créez un projet non partagé et importez un binaire que vous avez le droit d’analyser. Gardez le fichier original et une copie du projet inchangés.
File > New Project > Non-Shared Project - 2
Lancer le Script Manager
Ouvrez l’espace de scripting depuis les menus d’outils, puis utilisez le filtre ou la recherche.
Window > Script Manager - 3
Vérifier avant d’exécuter
Contrôlez le langage, le contexte requis, les imports, la sortie et les éventuelles écritures sur les symboles, commentaires, types ou mémoires.
Lire l’en-tête et les imports - 4
Exécuter et vérifier
Lancez le script une fois sur une petite cible, lisez la console et vérifiez le programme dans Listing ou Decompiler.
Run > Run Script
Écrire un premier script court avec une limite claire
Le premier script doit répondre à une seule question : compter des fonctions, afficher des noms portant un préfixe, lister des chaînes définies ou signaler la sélection courante. Ne combinez pas analyse, renommage, export et nettoyage dès le premier essai. Un script limité est plus facile à relire et à relancer.
Utilisez le modèle de programme exposé par Ghidra plutôt que de récupérer des données dans l’interface visible. Demandez au programme ses fonctions, symboles, références, instructions ou blocs mémoire et envoyez un résultat court à la console. Consultez la référence de l’API GhidraScript pour confirmer les méthodes actuelles ; un ancien exemple de forum peut être obsolète.
Si le script modifie le programme, rendez la modification visible dans la sortie. Affichez les compteurs avant et après, l’adresse ou le nom du symbole, et arrêtez-vous sur un état inattendu. Cela rend les exécutions répétées auditables.
lire le contexte -> inspecter un objet -> afficher le résultat -> ne rien modifier -> répétercible : practice.bin | périmètre : programme actuel | écritures : aucune | résultat : 12 fonctions
Java, Python et la limite de Ghidra 12.1.3
Les recherches mélangent scripting Ghidra, scripts Ghidra et Python pour Ghidra, mais ces expressions ne désignent pas toujours le même environnement. Le Script Manager est le point d’entrée dans l’application. Les scripts Java sont le choix le plus prévisible pour une automatisation réutilisable avec les API Java de Ghidra. Python dépend de la manière dont le processus Ghidra a été lancé et de l’intégration installée.
Pour l’automatisation CPython native hors de la fenêtre de scripts, consultez le guide d’installation de PyGhidra. PyGhidra relie un processus CPython externe à l’API Ghidra, alors qu’un script du Script Manager s’exécute dans le contexte de l’application.
Identifiez d’abord l’environnement : Script Manager intégré, processus Ghidra démarré avec PyGhidra ou processus CPython externe. Choisissez ensuite la documentation et le diagnostic adaptés.
| Besoin | À utiliser d’abord | Pourquoi |
|---|---|---|
| Une petite action dans un projet ouvert | Script Manager | Retour rapide et contexte visible |
| Automatisation Java réutilisable | Script Java | Correspond au modèle d’API natif |
| Flux CPython natif | PyGhidra | Conçu pour un processus Python externe |
| Lot important et répétable | Script avec journal | Entrées, sorties et erreurs restent vérifiables |
Modèles Script Manager utiles dans un vrai projet
Un script utile comporte généralement quatre parties : établir le contexte, sélectionner un petit ensemble d’objets, effectuer une opération et expliquer le résultat. Le contexte peut être le programme, l’emplacement, la sélection ou la fonction courante. La sélection doit être explicite : filtre de noms, plage d’adresses, bloc mémoire, propriété de fonction ou références.
Structurez la sortie pour comparer deux exécutions. Un résumé sur une ligne aide, mais une ligne par objet avec une adresse ou un nom de symbole facilite le débogage. Pour un script lent, testez d’abord une fonction ou un bloc mémoire et affichez un marqueur de progression.
- Lire le programme et l’emplacement courants avant de demander un état global.
- Préférer une sélection ou un itérateur borné à un parcours sans limite.
- Vérifier adresses, symboles et types dans Listing comme éléments de preuve.
- Séparer la découverte en lecture seule des opérations d’écriture.
- Sauvegarder une copie avant les renommages, changements de types ou commentaires en masse.
contexte -> sélection -> opération -> preuve -> plan de retourRésoudre les problèmes courants de scripting Ghidra
Lorsqu’un script échoue, capturez d’abord le message exact et le contexte du runtime. Notez la version de Ghidra, le système, le langage, le programme ouvert, la sélection et la manière dont le processus a été lancé. Cette fiche évite d’appliquer une correction PyGhidra à un problème du Script Manager.
Vérifiez aussi le plus petit cas qui reproduit l’erreur. Un échec lié à un processeur, une fonction endommagée ou une sélection vide demande souvent un contrôle de limite plutôt qu’une réécriture générale.
Gardez le texte complet, le fichier ou projet minimal reproductible et la version du script. Ne publiez pas de binaire inconnu ni de données d’analyse sensibles dans une issue publique.
| Symptôme | À vérifier d’abord | Prochaine action sûre |
|---|---|---|
| Le script n’est pas listé | Actualisation, chemin, extension et répertoires | Recharger la liste et ouvrir le fichier directement si possible |
| Python est indisponible | Démarrage de Ghidra et configuration PyGhidra | Utiliser Java ou suivre le flux PyGhidra |
| Aucun programme ou sélection | Outil actif, projet, programme et sélection | Ouvrir le programme et tester une seule fonction |
| La sortie semble fausse | Architecture, adresses, Listing et types | Vérifier l’hypothèse dans CodeBrowser avant de modifier le script |
Une routine de scripting sûre et répétable
Pour une tâche ponctuelle, la routine peut rester courte. Pour une équipe ou une enquête répétée, notez l’entrée, le résultat attendu, la version du script, la version de Ghidra et les écritures effectuées. Le guide du Decompiler aide à vérifier le résultat ; le guide d’installation explique comment séparer application, JDK, projets et sauvegardes.
Commencez par une sortie en lecture seule, comparez-la à Listing, puis seulement activez les changements. Gardez les compteurs avant/après et un plan de retour ou une copie. Si le script devient un système avec entrées externes, tests et dépendance CPython, envisagez PyGhidra ou un harnais dédié.
- 1
Préparer
Fixez la version de Ghidra, ouvrez une copie du projet et notez le périmètre prévu.
version + entrée + périmètre - 2
Observer
Exécutez un script en lecture seule et conservez un petit échantillon avec adresses.
lecture seule d’abord - 3
Modifier
Faites une modification contrôlée, affichez le compteur et vérifiez le résultat dans les vues d’analyse.
une opération + preuve - 4
Conserver
Enregistrez script, notes, sortie et copie du projet pour comparer ou annuler l’exécution.
script + journal + copie
Questions sur le Ghidra Script Manager
Qu’est-ce que le Ghidra Script Manager ?
C’est l’espace intégré de Ghidra pour découvrir, modifier et exécuter des scripts sur le projet ou programme actif. Il convient aux petites automatisations vérifiables et n’est pas un processus CPython externe.
Puis-je utiliser Python dans le Script Manager ?
La disponibilité de Python dépend du runtime et du démarrage de Ghidra. Si Python est signalé comme indisponible, utilisez Java pour l’automatisation intégrée ou le guide PyGhidra pour CPython.
Le scripting Ghidra est-il identique à PyGhidra ?
Non. Le Script Manager s’exécute dans Ghidra, tandis que PyGhidra relie un processus CPython natif à l’API Ghidra. Les installations et diagnostics sont différents.
Pourquoi mon script n’apparaît-il pas dans la liste ?
Actualisez la liste, puis vérifiez extension, répertoire de scripts et filtres de langage. Vérifiez aussi que l’en-tête et les imports correspondent à la version actuelle.
Le premier script doit-il modifier un projet ?
Il vaut mieux commencer par un rapport en lecture seule. Une fois le résultat vérifié dans Listing ou Decompiler, testez une modification contrôlée sur une copie avec un compteur et un plan de retour.