Versions de Ghidra et téléchargements

Dernières versions de Ghidra et détails du téléchargement

La dernière version vérifiée est Ghidra 12.1.2, publiée le 5 juin 2026 sous l’étiquette Ghidra_12.1.2_build. L’archive exécutable ghidra_12.1.2_PUBLIC_20260605.zip fait 572 803 866 octets et fonctionne sous Windows, macOS et Linux. Son SHA-256 publié est b62e81a0390618466c019c60d8c2f796ced2509c4c1aea4a37644a77272cf99d.

Une installation normale nécessite le ZIP PUBLIC, pas les archives Source code générées par GitHub. Installez JDK 21 64 bits, vérifiez le fichier, extrayez-le dans un nouveau répertoire et lancez ghidraRun.bat sous Windows ou ./ghidraRun sous Linux et macOS. L’application est portable et n’a pas d’assistant d’installation multiplateforme.

Les versions officielles de Ghidra sur GitHub renvoient vers What's New, Change History et Getting Started de chaque étiquette. Lisez-les avant de mettre à niveau une analyse de production, un serveur collaboratif, une extension ou une collection de scripts. Une version de maintenance peut contenir des corrections importantes malgré une interface inchangée.

Versions récentes de Ghidra

Le tableau reprend les pages publiques récentes retournées par l’API GitHub officielle lors de cette mise à jour. Il facilite la navigation mais ne remplace pas les notes de version. GitHub reste l’autorité pour archives, empreintes, dates, avis et toute édition postérieure au 20 juillet 2026.

Préférez la version de maintenance compatible la plus récente, sauf si un projet, une extension, un cours ou une recherche reproductible exige autre chose. Les anciennes versions peuvent contenir des vulnérabilités ou erreurs connues. Si vous figez une version, consignez étiquette, empreinte, Java, extensions et options d’analyse.

Faut-il télécharger une ancienne version de Ghidra ?

Utilisez une ancienne version uniquement pour une raison précise de compatibilité ou de reproductibilité. Un cours peut normaliser ses captures, une extension peut ne pas suivre une nouvelle API, une équipe peut aligner clients et serveur, ou une recherche peut dépendre d’une chaîne enregistrée. La commodité seule ne justifie pas de conserver une édition comportant des problèmes connus.

Ne cherchez pas Ghidra 11.3.2, 12.0 ou une autre version historique sur des miroirs aléatoires. Utilisez les versions officielles de Ghidra sur GitHub et vérifiez que la page appartient à github.com/NationalSecurityAgency/ghidra. Chaque page indique son étiquette et son archive. Consultez le README ou Getting Started propre à la version, car Java et les plateformes évoluent.

Gardez les anciennes installations dans des répertoires distincts et clairement nommés. Stockez les projets hors des dossiers de l’application et ne supposez jamais qu’un projet enregistré par une version récente peut revenir en arrière. Ouvrez une copie ou utilisez Save As après avoir lu l’avertissement de mise à niveau.

• Figez une version lorsqu’une extension testée l’exige.
• Pour une analyse reproductible, consignez aussi son empreinte.
• Alignez les clients Ghidra Server sur la version du serveur.
• Ne rétrogradez pas seulement pour éviter le JDK actuel.
• Ne recouvrez pas l’installation actuelle avec une ancienne archive.

Mettre Ghidra à jour sans perdre les projets

Les mises à jour sont des installations côte à côte, pas des correctifs appliqués au dossier actuel. Téléchargez le nouveau ZIP PUBLIC, vérifiez son empreinte et extrayez-le dans un répertoire neuf. Ne le fusionnez pas avec l’ancienne version. Vous conservez ainsi anciens modules et lanceurs pendant la validation.

Sauvegardez les données avant de les ouvrir. Un projet local comprend généralement un fichier .gpr et un dossier .rep. Copiez les deux avec Ghidra fermé. L’application peut proposer une mise à niveau des anciennes données. Rien n’est écrasé avant l’enregistrement, mais le fichier original peut ne plus s’ouvrir dans l’ancienne version. Utilisez Save As si le retour en arrière compte.

La nouvelle installation réutilise souvent le profil récent. Cela conserve les configurations mais peut aussi garder de vieux réglages. Le guide recommande Tools > Default Tools... dans Project Manager pour repartir des outils par défaut. Testez scripts et extensions séparément, car les extensions compilées peuvent dépendre d’une API précise.

1. 1

   Sauvegarder les projets

   Fermez Ghidra et copiez chaque .gpr avec son dossier .rep.

   Projet.gpr + Projet.rep/
2. 2

   Télécharger la nouvelle version

   Utilisez l’archive PUBLIC officielle et vérifiez son empreinte.

   ghidra_12.1.2_PUBLIC_20260605.zip
3. 3

   Extraire à côté de l’ancienne

   Gardez l’ancien dossier jusqu’aux tests de la version et des extensions.

   ghidra_12.1.2_PUBLIC/
4. 4

   Ouvrir une copie du projet

   Lisez les messages et utilisez Save As si l’ancienne version reste nécessaire.

   File > Save As

Où vérifier les versions officielles de Ghidra

Utilisez les versions officielles de Ghidra sur GitHub pour numéros, dates, archives et empreintes. Consultez le Getting Started de l’étiquette pour les exigences, What's New et Change History pour les changements et Security Advisories pour les vulnérabilités, plutôt que le badge « sûr » d’un miroir.

Le dépôt du projet est la source principale pour code, problèmes, documentation et archives. Le site de la NSA offre une navigation générale, mais la vérification est plus simple sur la page GitHub étiquetée. Ce site indépendant résume les faits et dirige chaque bouton vers le dépôt ; il ne certifie pas qu’une version est exempte de vulnérabilité.

Pour l’automatisation, l’API GitHub Releases identifie la dernière publication et ses archives. Un site de production doit mettre en cache et contrôler ces données. Version, nom, date, taille, empreinte, exigences et notes doivent évoluer ensemble.