Ghidra-Versionen und Downloads

Neueste Ghidra-Versionen und Downloaddetails

Das neueste geprüfte Release ist Ghidra 12.1.2, veröffentlicht am 5. Juni 2026 unter dem Tag Ghidra_12.1.2_build. Das lauffähige Asset ghidra_12.1.2_PUBLIC_20260605.zip umfasst 572.803.866 Byte und eignet sich für Windows, macOS und Linux. Der veröffentlichte SHA-256-Wert lautet b62e81a0390618466c019c60d8c2f796ced2509c4c1aea4a37644a77272cf99d.

Eine normale Installation benötigt das benannte PUBLIC-ZIP und nicht die von GitHub erzeugten Source-code-Archive. Installieren Sie ein 64-Bit-JDK 21, prüfen die Datei, entpacken sie in ein neues Verzeichnis und starten unter Windows ghidraRun.bat oder unter Linux und macOS ./ghidraRun. Die Anwendung ist portabel und hat keinen plattformübergreifenden Einrichtungsassistenten.

Offizielle Ghidra-Versionen auf GitHub verlinken What's New, Change History und Getting Started für den jeweiligen Tag. Lesen Sie diese Dokumente vor einem Upgrade von Produktionsanalysen, gemeinsamen Servern, Erweiterungen oder Skriptsammlungen. Ein Wartungsrelease kann wichtige Korrekturen enthalten, auch wenn die Oberfläche unverändert aussieht.

Dokumentieren Sie bei wichtigen Arbeitsumgebungen zusätzlich Release-Tag, Prüfsumme, verwendetes JDK und installierte Erweiterungen. So lässt sich eine Analyse später reproduzieren und eine getestete Umgebung kontrolliert auf einen neuen Stand übertragen.

Ghidra-Versionen lassen sich anhand von Tag, Datum und Prüfsumme eindeutig vergleichen. Notieren Sie Ghidra-Versionen zusammen mit JDK, Betriebssystem und Erweiterungen, damit Tests und spätere Updates reproduzierbar bleiben.

Aktuelle Ghidra-Versionen im Überblick

Die Tabelle verzeichnet öffentliche Release-Seiten, die die offizielle GitHub-API bei dieser Aktualisierung geliefert hat. Sie erleichtert die Navigation, ersetzt aber keine Releasehinweise. GitHub bleibt maßgeblich für Assets, Prüfsummen, Daten, Sicherheitshinweise und jede Ausgabe nach dem Seitenstand vom 20. Juli 2026.

Bevorzugen Sie das neueste kompatible Wartungsrelease, sofern nicht ein Projekt, eine Erweiterung, ein Kurs oder eine reproduzierbare Forschung eine bestimmte Version verlangt. Ältere Releases können bekannte Schwachstellen und Fehler enthalten. Dokumentieren Sie bei Versionsbindung Tag, Asset-Prüfsumme, Java-Version, Erweiterungen und Analyseoptionen.

Sollten Sie eine ältere Ghidra-Version herunterladen?

Verwenden Sie ein älteres Release nur aus einem konkreten Kompatibilitäts- oder Reproduzierbarkeitsgrund. Ein Kurs kann identische Bildschirmbilder verlangen, eine Erweiterung eine neue API noch nicht unterstützen, ein Team Clients und Server angleichen oder eine Forschung eine dokumentierte Werkzeugkette benötigen. Bequemlichkeit allein ist kein guter Grund für eine Version mit bekannten Problemen.

Suchen Sie Ghidra 11.3.2, 12.0 oder andere historische Ausgaben nicht auf zufälligen Spiegeln. Nutzen Sie offizielle Ghidra-Versionen auf GitHub und prüfen, dass die Seite zu github.com/NationalSecurityAgency/ghidra gehört. Jede Release-Seite nennt Tag und lauffähiges Asset. Lesen Sie die jeweilige README oder Getting Started, weil sich Java- und Plattformanforderungen ändern.

Bewahren Sie alte Installationen in getrennten, klar benannten Ordnern auf. Speichern Sie Projekte außerhalb der Anwendung und nehmen nicht an, dass ein mit einer neueren Version gespeichertes Projekt rückwärtskompatibel ist. Öffnen Sie bei einer Migration eine Sicherung oder verwenden Save As nach Prüfung des Upgradehinweises.

• Version festschreiben, wenn eine geprüfte Erweiterung sie erfordert.
• Für reproduzierbare Analyse zusätzlich die Prüfsumme dokumentieren.
• Ghidra-Server-Clients an die unterstützte Serverversion angleichen.
• Nicht nur wegen der Installation des aktuellen JDK zurückstufen.
• Aktuelle Installation niemals mit einem alten Archiv überschreiben.

Ghidra aktualisieren, ohne Projekte zu verlieren

Ghidra-Updates sind parallele Installationen und keine Patches im bestehenden Ordner. Laden Sie das neue PUBLIC-ZIP, prüfen die Summe und entpacken es in ein frisches Verzeichnis. Überschreiben Sie die alte Version nicht. So bleiben alte Module und Starter während der Validierung verfügbar.

Sichern Sie Projektdaten vor dem Öffnen. Ein lokales Ghidra-Projekt enthält normalerweise eine .gpr-Datei und einen zugehörigen .rep-Ordner. Kopieren Sie beide bei geschlossenem Ghidra. Beim Öffnen alter Daten kann ein Upgrade angeboten werden. Gespeicherte aktualisierte Daten lassen sich möglicherweise nicht mehr in der alten Version öffnen. Verwenden Sie Save As, wenn ein Rückweg wichtig ist.

Die neue Installation nutzt häufig das Profil der zuletzt verwendeten Ghidra-Version. Das erhält Werkzeugkonfigurationen, kann jedoch alte Voreinstellungen übernehmen. Die offizielle Anleitung empfiehlt Tools > Default Tools... im Project Manager für frische Konfigurationen. Testen Sie eigene Skripte und kompilierte Erweiterungen separat, da diese an eine bestimmte API gebunden sein können.

1. 1

   Projekte sichern

   Ghidra schließen und jede .gpr-Datei samt vollständigem .rep-Ordner kopieren.

   Projekt.gpr + Projekt.rep/
2. 2

   Neues Release laden

   PUBLIC-Asset der offiziellen GitHub-Seite verwenden und prüfen.

   ghidra_12.1.2_PUBLIC_20260605.zip
3. 3

   Neben alter Version entpacken

   Alten Ordner behalten, bis Release und Erweiterungen getestet sind.

   ghidra_12.1.2_PUBLIC/
4. 4

   Gesichertes Projekt öffnen

   Upgradehinweise prüfen und bei Rückwärtsbedarf Save As verwenden.

   File > Save As

Offizielle Ghidra-Versionen verifizieren

Verwenden Sie offizielle Ghidra-Versionen auf GitHub für Nummern, Daten, Assets und releasebezogene Prüfsummen. Getting Started des Tags beschreibt Plattform und Installation, What's New und Change History die Änderungen, Security Advisories die Schwachstellen. Vertrauen Sie nicht dem „sicher“-Abzeichen eines Downloadspiegels.

Das Projekt-Repository ist die Hauptquelle für Code, Probleme, Dokumentation und Release-Assets. Die Ghidra-Website der NSA bietet Projektnavigation, aber die direkte Prüfung ist auf dem getaggten GitHub-Release am einfachsten. Diese unabhängige Website fasst Angaben zusammen und leitet jeden Download zum offiziellen Repository; sie garantiert keine Fehlerfreiheit.

Zur Automatisierung kann die GitHub-Releases-API das neueste Release und seine Assets nennen. Eine Produktionsseite sollte diese Daten zwischenspeichern und prüfen. Versionsnummer, Dateiname, Datum, Bytegröße, Prüfsumme, Anforderungen und Hinweise müssen gemeinsam aktualisiert werden.