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, graphing, and scripting, along with hundreds of other features. Ghidra supports a wide variety of process 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 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.
Ghidra 9.1 is fully backward compatible with project data from previous releases. However, programs opened in 9.1 may no longer be accessible by an earlier Ghidra version if the processor model has been updated.
This release includes many new features and capabilities, performance improvements, quite a few bug fixes, and pull-request contributions. Many thanks to all those who have contributed their time, thoughts, and code. The Ghidra user community thanks you too!
NOTE: The Ghidra 9.0 server is compatible with Ghidra 9.0 and 9.1 clients, however the 9.1 server now requires clients to use a TLS secure connection for the initial RMI registry port access. If the Ghidra multi-user server is upgraded to 9.1, then all clients must upgrade to 9.1. A 9.1 Ghidra client will fall back to a non-TLS connection when accessing the RMI Registry on a 9.0 server. Note that all other server interaction including authentication were and continue to be performed over a secure TLS connection.
Minor Note: Ghidra-compiled .sla files are not backwards compatible due to the newly added OTHER space for syscalls support. In the pre-built ghidra, all .sla files are re-built from scratch. However if you have local processor modules, or are building ghidra from scratch, you may need to do a clean build. You will get an error if an old .sla file is loaded without recompilation of the .slaspec file. Any processor modules with changes are normally recompiled at Ghidra startup so this situation is rare.
Bitfields within structures are now supported as a Ghidra data type. Bitfield definitions can come from PDB, DWARF, parsed header files, and can also be created within the structure editor. All Data type archives delivered with Ghidra have been re-parsed to capture bitfield information. In addition, compiler bitfield allocation schemes have been carefully implemented. Full support for bitfield references within the decompiler is planned for a future release.
In support of creating bitfields within structures, a new bitfield editor within the structure editor has been added. The Bitfield Editor includes a visual depiction of the data type byte layout and the associated bits. The BitField Editor simplifies the creation of bitfields within a structure.
Ghidra now supports overriding indirect calls, CALLOTHER pcode ops, and conditional jumps via new overriding references. These references can be used to achieve correct decompilation of syscall-like instructions. A new script, ResolveX86orX64LinuxSyscallsScript, has been provided as part of this initial implementation. Future releases will automatically identify and apply system calls for other operating systems and versions.
To support system calls, the decompiler follows references into OTHER address space overlays. This allows users to create address spaces on the fly without worrying about conflicts with existing spaces. For example, instructions with a unique calling convention can be properly handled by adding a reference to a custom function signature.
A new set of tools designed to make processor specifications easier to create, modify, and validate have been added. The tools consist of a context sensitive Sleigh file editor, a pcode validation framework, an external disassembler field, and several scripts to make development easier. The Sleigh editor is a plugin for Eclipse and provides modern editor features such as syntax coloring, hover, navigation, code formatting, validation, reference finding, and error navigation. The test suite emulates the pcode to automatically validate the instructions most commonly used by the compiler for that processor.
DYLD shared cache images, extracted from an iOS image, can now be imported in their entirety. A DYLD's embedded DYLIB's are split into memory blocks, greatly enhancing follow-on analysis. Internal Macho headers are retained and marked up similarly to ELF and PE files, which includes tracking the origin of the program bytes from the initial import binary.
The Ghidra server now requires the client to use a TLS secure connection for the initial RMI registry port access. Previously, TLS was used for all remote object interactions and data transfers on the two other ports. This change will now ensure that all connections to the Ghidra Server utilize TLS. As noted above a 9.1 clients can connect to a 9.0 or 9.1 server, while clients prior to 9.1 will be unable to connect to a 9.1 server.
The Ghidra server has two additional authentication methods, Active Directory using Kerberos and Plugable Authentication Modules (PAM) using JAAS. To utilize these new methods you must configure the server.conf file and use either -a1 for windows authentication or -a4 along with -jaas. The JAAS mode will require setup of an additional configuration file (jaas.conf).
When importing files, the origin of all imported bytes can be tracked back to their offset within the original binary source. This change lays the ground work for exporting back to the original file after modifying the bytes. There are programmer API methods to get the bytes either from the memory block or the underlying original source bytes. To see the original bytes a memory block can be mapped onto the original filebytes. The source of each memory block within the memory map is shown in a new Byte Source column. When hovering on the bytes in the program listing, the origin of the bytes at that address are displayed.
The decompiler now implements a more detailed analysis of local variables on the stack. This change resolves many problems with disappearing structure initialization and incorrect dead code removal.
The decompiler now generates fewer duplicate assignments. For example, repeated assignment of the same value to a variable in two branches will now appear before either branch is taken.
In addition the decompiler now recognizes more optimization patterns used by compilers for signed division, resulting in simplified decompilation.
AARCH64-based binary decompilation will be cleaner due to better handling of zero extensions into larger registers. This improves data flow analysis and primarily affects functions using floating point Neon instructions.
Renaming a parameter in the decompiler will no longer commit the data types of all parameters, allowing data types to continue to "float" without getting locked into a potentially incorrect initial data type. In addition, the cumbersome warning dialog for renaming and retyping has been removed, improving your RE workflow.
There are many new processor specifications including SuperH4, MCS-96, HCS12X/XGATE, HCS08, and user-contributed specifications for MCS-48, SuperH1/2a, and Tricore.
The 16-bit x86 processor specification has been re-worked to include protected mode addressing, which the NE loader now uses by default. Handling of segmented or paged memory has been updated to use a newer scheme, hiding its complications from decompilation results. The implementation handles the HCS12X paging scheme as well.
Many improvements and bug fixes have been made to existing processor specifications: ARM, AARCH64, PIC, 68K, MIPS, PPC, JVM, Sparc, AVR8, 8051, 6502, and others.
Numerous other bug fixes and improvements are fully listed in the ChangeHistory file.
In case you missed it, in March 2019, a public version of Ghidra was released for the first time. Soon after, the full buildable source was made available as an open source project on the NSA github page. The response from the Ghidra Open Source community has been overwhelmingly positive. We welcome contributions from github including bug fixes, requests, scripts, processor modules, and plugins.
Bug fixes and improvements for 9.0.x are listed in the Change History file.