Ghidra is a software reverse engineering (SRE) framework developed by NSA's Research Directorate. This framework includes a suite of full-featured, high-end software analysis tools that enable users to analyze compiled code on a variety of platforms including Windows, MacOS, and Linux. Capabilities include disassembly, assembly, decompilation, debugging, emulation, graphing, and scripting, along with hundreds of other features. Ghidra supports a wide variety of processor instruction sets and executable formats and can be run in both user-interactive and automated modes. Users may also develop their own Ghidra plug-in components and/or scripts using the exposed API. In addition there are numerous ways to extend Ghidra such as new processors, loaders/exporters, automated analyzers, and new visualizations.
In support of NSA's Cybersecurity mission, Ghidra was built to solve scaling and teaming problems on complex SRE efforts and to provide a customizable and extensible SRE research platform. NSA has applied Ghidra SRE capabilities to a variety of problems that involve analyzing malicious code and generating deep insights for NSA analysts who seek a better understanding of potential vulnerabilities in networks and systems.
This release includes new features, enhancements, performance improvements, quite a few bug fixes, and many pull-request contributions. Thanks to all those who have contributed their time, thoughts, and code. The Ghidra user community thanks you too!
Ghidra 11.0 is fully backward compatible with project data from previous releases. However, programs and data type archives which are created or modified in 11.0 will not be useable by an earlier Ghidra version.
This distribution requires JDK 17 to run, and provides Linux x86-64, Windows x86-64, and macOS x86-64 native components. If you have another platform or wish to use a newer JDK, please see the Ghidra Installation Guide for additional information.
NOTE: Ghidra Server: The Ghidra 11.0 server is compatible with Ghidra 9.2 and later Ghidra clients. Ghidra 11.0 clients are compatible with all 10.x and 9.x servers. Although, due to potential Java version differences, it is recommended that Ghidra Server installations older than 10.2 be upgraded. Those using 10.2 and newer should not need a server upgrade.
NOTE: Any programs imported with a Ghidra beta version or code built directly from source code outside of a release tag may not be compatible, and may have flaws that won't be corrected by using this new release. Any programs analyzed from a beta or other local master source build should be considered experimental and re-imported and analyzed with a release version. Programs imported with previous release versions should upgrade correctly through various automatic upgrade mechanisms. Any program you will continue to reverse engineer should be imported fresh with a release version or a build you trust with the latest code fixes.
A major new feature called BSim has been added. BSim can find structurally similar functions in (potentially large) collections of binaries or object files. BSim is based on Ghidra's decompiler and can find matches across compilers used, architectures, and/or small changes to source code.
As you've reverse engineered software, you've likely asked the following questions:
BSim is intended to help with these questions (and others) by providing a way to search collections of binaries for similar, but not necessarily identical, functions.
BSim can compare functions within a binary, within a collection of binaries or object files in a project on a local system, or within a large collection of binaries utilizing a PostgreSQL or an Elasticsearch server. Using BSim locally does not require setting up a PostgreSQL or Elastic server or having administrator access.
There is a BSim tutorial that walks through use of BSim locally. Using BSim locally and the tutorial is the best way to try out BSim before deciding if you need to set up a server.
GhidraGo is an experimental feature that adds integration support for Ghidra URL's and Ghidra Tools. The main use of GhidraGo is embedding hyperlinks within web pages to pre-ingested programs within a Ghidra multi-user repository. Clicking on the hyperlink causes Ghidra to display the previously ingested program. No data other than the Ghidra URL is transferred to Ghidra, and no socket is open within Ghidra listening for commands. GhidraGo must be enabled by installing a plugin in the Ghidra project manager, and must also be configured as a protocol handler in your web browser. GhidraGo is not setup or enabled by default. For details on setting up GhidraGo, please see the included GhidraGoREADME.html or search for GhidraGo within help.
Auto Version Tracking has been sped up, made customizable, and improved to find more matches. The mechanism to identify good matches from duplicate match sets has been improved and sped up. Implied matches are now created and will be applied if the vote minimum and conflict maximum limits are met. In addition, the ability to choose which correlators are run as well as setting the options of most correlators has been added. The Auto Version Tracking script has been updated to prompt for all options in a single dialog. The script now works in headless mode and an example prescript to allow setting of options in headless mode is included.
Version Tracking can also use the new BSim function matching capability in a new correlator called the BSim Correlator. Auto Version Tracking does not use the new BSim Correlator yet.
The function comparison window, used by Version Tracking and BSim, has been overhauled a bit:
A new multi-option script dialog has been added to the scripting API that can present and get all user inputs a script needs in one dialog. The askValues() scripting method replaces the cumbersome process of prompting the user for each input separately.
Initial support for Rust compiled binaries, mainly demangling of Rust method names and Rust in DWARF information, has been added. In addition, Rust strings are marked up so that the decompiler will display Rust strings correctly. There is more work to do, especially with mapping Rust parameter passing. Custom storage may be required in some instances.
Golang reverse engineering within Ghidra is much improved by:
A new action in the Search menu, Search -> For Encoded Strings..., can help find and create strings encoded in alternate character sets and alphabets. Valid strings are based on runs of bytes that would be valid in a particular character set and alphabet. There are currently no additional models for defining valid words within other languages.
The CaRT file format is now supported. The CaRT format is used to store and transfer malware along with metadata about the malware in a neutered form such that it cannot be executed. It is encrypted so anti-virus software will not flag the file under analysis.
Headless importing of binaries from container files, such as .zip files, with multiple embedded files is now possible. This includes loading referenced .dll and .so files also found within the container file.
The Headless Analyzer can now recurse into supported GFileSystem container files when a recursion depth of one or more is specified on the command line.
Support for the Mach-O binary file format has continued to receive updates. Improvements have been made to library linking and loading, as well as thunk creation. Additionally, dyld_shared_cache components extracted from Ghidra's DyldCacheFileSystem can now be added together on-demand with the Add To Program feature. Broken references can be automatically resolved by right-clicking on them and clicking References -> Add To Program.
The PDB data types processing has been changed to use a resolve-as-you-go model. The change eliminates the dependency graph and reduces the memory footprint required to load all PDB types. The change allows larger PDB's to load successfully and improves the accuracy of some data types.
Overlay spaces now support multiple memory blocks in the same overlay. After creating the initial memory block as an overlay, the new overlay memory space will become available when adding new memory blocks. All overlay memory blocks can be manipulated in the same way as normal memory blocks. The new feature is useful when analyzing binaries meant to run on multiple processors with tasks running on each processor in their own overlapped virtual memory space such as an RTOS.
Support for the Loongson processor architecture has been added. All known instructions should disassemble. However semantics for a large number of instructions use pseudoOp calls currently.
Numerous other new features, improvements, and bug fixes are fully listed in the ChangeHistory file.