Ghidra: NSA Reverse Engineering Software

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.


What's New in Ghidra 10.2

The not-so-fine print: Please Read!

Ghidra 10.2 is fully backward compatible with project data from previous releases. However, programs and data type archives which are created or modified in 10.2 will not be useable by an earlier Ghidra version.

This release includes many new features and capabilities, 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!

IMPORTANT: Ghidra requires Java 17 JDK to run. A newer version of Java may be acceptable, but has not been tested. Please see the Ghidra Installation Guide for additional information.

NOTE: Please note that any programs imported with a Ghidra beta versions or code built directly from source outside of a release tag may not be compatible and may have flaws that have been corrected. 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. As an example, Ghidra 10.1 beta had an import flaw affecting symbol demangling that was not correctable. 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.

NOTE: Ghidra Server: The Ghidra 10.2 server is compatible with Ghidra 9.2 and later Ghidra clients. Ghidra 10.2 clients are compatible with all 10.x and 9.x servers.

NOTE: Platform-specific native executables can be built directly from a release distribution. The distribution currently provides Linux 64-bit, Windows 64-bit, and MacOS x86 binaries. If you have another platform, for example a MacOS M1 based system or a Linux variant, the support/buildNatives script can build the Decompiler, demangler, and legacy PDB executables for your plaform. Please see "Building Ghidra Native Components" section in the the Ghidra Installation Guide for additional information.

Distribution

A Software Bill of Materials (SBOM) is now included in the Ghidra release. The SBOM follows the CycloneDX standard, and can be used with tools such as Dependency-Track to help identify risk in the software supply-chain.

Debugger

The Debugger improvement highlights include:

Decompiler

The Decompiler has a myriad of improvements in the latest-release. Many have been long-requested features or improvements. Highlights of the changes include:

Data Types

With this release of Ghidra, support for Pointer Typedefs has been expanded to facilitate the use of specialized data type settings. Improvements have also been made to ensure that such settings are preserved within data type archives and merge situations. These settings are not supported at the instance-level and are intended to be an attribute of the associated pointer. The Typedef provides the ability to tailor a pointer for a specific use. It is highly recommended that all required Pointer Typedef settings be applied prior to using the data type (e.g., for defined data, data type components, and variables) since there is currently no change propagation for such modifications.

The following Pointer Typedef settings have been introduced with this release:

NOTE: The use and consumption of Pointer Typedef settings is in its early stages and may not be utilized by various analyzers. In addition, some settings are not relevant to some analyzers where instruction semantics will dictate pointer dereferencing.

At the API level, the PointerTypedef and PointerTypedefBuilder classes have been added to simplify the creation of a Pointer Typedef. While an explicit Typedef name may be used, Pointer Typedefs also support an auto-naming mechanism (constructed with a null/empty name) which will simply use the pointer name followed by the settings as an attribute list; example:

int * __((space(ram)))

Within the GUI, using the New->Typedef on <pointer> action on a selected pointer within the Data Type Tree is the quickest way to create one. Once this is done, use the Settings... action on the selected Pointer Typedef. The Settings dialog will be displayed allowing the various settings to be applied to the Typedef. Settings should be made to Typedef prior to applying it since settings change propogation is very limited.

C Header File Parsing

C-Parser support has been added for missing C specification syntax from C11 and C23, such as tags, macros with varargs, and _NoReturn. Numerous parsing errors have also been fixed, including for arrays of function pointers, array definitions, and placement of compiler directives. In addition, parsing time of extremely large header files has been drastically reduced.

Error handling and reporting from the Pre-Processor and C-Parser have been improved.

Several scripts to parse header files outside of the GUI have been included, including one that specially parses AVR8 data types and memory-mapped register definitions from header files for each AVR8 processor variant. The scripts are CreateAVR8GDTArchiveScript.java, CreateExampleGDTArchiveScript.java, CreateJNIArchivesScript.java, and CreateDefaultGDTArchives.java.

Finally, data types in open archives can be used during parsing for undefined data types in a header file. At the start of parsing, use of open archives can be chosen or ignored without closing open archives. The header files must still parse without error, however a missing data type or unfound header file may not cause the parsing to fail if an open archive contains a missing, but needed data type definition.

Mach-O Binary Import

Mach-O binary analysis continues to improve. Support has been added for new file formats introduced in iOS 16 and macOS 13. Improvements have also been made to function identification, symbol detection, and Objective-C support.

Android

Import and analysis of the entire existing set of Android binaries up to version 13.x is now supported, including new support for the Multi-DEX format. The type of binaries supported include: Android Run-Time (ART), Ahead-of-Time (OAT)/ELF, Dalvik Executables (DEX), Multi-DEX, Compact DEX (CDEX), Verified DEX (VEX), Boot Image, and Boot Loader formats. Also included are Sleigh modules for DEX files covering each major release of Android; the optimized instructions vary across versions.

A new Android APK loader will load all DEX files at one time and link the method_lookup sections using external references. The new APK loader uses the manifest file to determine the Android version.

Analysis

The option Assume Contiguous Functions Only, for the Shared Return Analyzer, has been turned on by default. The Shared Return Analyzer turns jump instructions into a call if the jump target is, or should be, considered a function. When turned on, the option treats a jump over a known function entry point to be a call, even if there is only one jump to that location. The option improves thunk function recovery as well as decompilation results by using a call to the function instead of including the called functions code within the calling function.

The option has been turned on by default for all processor types except ARM. ARM Thumb binaries can sometimes use BL instructions, normally used as calls, as an internal jump within a large function. If this option were on by default for such a binary it would cause additional erroneous functions to be created. The option can be used on ARM binaries, however they should be all ARM code; otherwise any Thumb code using BL for far jumps must be fixed using the Fix_ARM_Call_JumpsScript and Override_ARM_Call_JumpsScript.

Machine Learning

An optional MachineLearning extension has been added containing the Random Forest Function Finder Plugin. The plugin finds undiscovered functions within a binary using classifiers to identify potential function starts. The plugin trains classifiers using data sets created from known functions within a binary. These classifiers can then be used by the plugin on the original binary or other binaries to find additional functions missed by initial analysis.

The extension can be installed from the Ghidra Project Window via File->Install Extensions...

Processors

Updated ARM32 and AARCH64 to version v9.3 to include vfp4 instructions.

Improvements and bug fixes have been made to many processors to include: AARCH64, ARM, AVR8, AVR32, Coldfire, JVM, MIPS, MSP430, PA-Risc, PowerPC, RISC-V, SuperH, Tricore, V850, X86, 6502, and 68K.

Sleigh now supports inst_next2 as well as inst_next to support branching around the next instruction when its length is unknown. Many processors have conditional skip instructions which can be used on any instruction, including another skip instruction. Some sleigh processor developers have tried to use the delayslot() directive to accomplish instruction skipping. Unfortunately, the use of the delayslot() directive can cause nested delay slots or the potential for branches into the delay slotted instruction, both of which are not supported.

User Interface Improvements

The Go To... dialog now provides navigation to file offsets. In addition, a new File Offset field is available in the Listing. The field must be added to the Listing using Edit Listing Fields. These new features can greatly simplify correlating bytes in program memory with their original location within the file from which they were imported. Example: to go to the memory location which corresponds to the first byte in the original file, enter file(0) in the Go To... dialog.

Import Formats

Support has been added for loading WinDbg and APPORT dump files.

Redesigned the Importer's library loading options to provide finer-grained control over where libraries are searched for on disk and in the project, as well as where newly loaded libraries are saved to.

Additional Bug Fixes and Enhancements

Numerous other bug fixes and improvements are fully listed in the ChangeHistory file.


https://www.nsa.gov/ghidra