GHIDRA FOR IDA USERS
If you are an experienced IDA Pro user interested in giving Ghidra a test run, either as a curiosity or as a more permanent transition, you may be familiar with many of the concepts presented in this book. This appendix is intended to map IDA terminology and usage to similar functionality in Ghidra, without providing instruction on Ghidra functionality. For specific usage of any Ghidra feature mentioned here, please refer to the relevant chapters in this book that discuss the features in far more detail.
We make no attempt to compare the performance of the two tools, nor do we argue for the superiority of one over the other. Your choice of which to use might be motivated by price or a specific feature offered by one and not the other. What follows is a whirlwind tour through the topics of the book from the perspective of an IDA user.
The Basics
As you begin your journey, you may find it useful to bring along a guide to help you learn an entirely new set of hotkeys. The Ghidra Cheat Sheet (https://ghidra-sre.org/CheatSheet.html) is a useful trifold that lists common user actions and their associated hotkeys and/or tool buttons. Shortly, we’ll cover how to remap hotkeys in the event that you miss your trusted IDA favorites.
Database Creation
Whereas IDA imports one binary into one database and is inherently single user, Ghidra is project oriented, can contain multiple files per project, and can support collaborative reversing by many users working together on the same project. The concept of an IDA database most closely maps to a single program within a Ghidra project. Ghidra’s user interface is split into two main components: Project and CodeBrowser.
Your first interaction with Ghidra is to create projects (shared or non-shared) and import “programs” (binaries) into those projects through the Project window. When you use IDA to open a new binary, and ultimately create a new database, you and IDA perform the following actions:
(IDA) Query every available loader to learn which loaders recognize the newly selected file.
(IDA) Display the load file dialog, presenting a list of acceptable loaders, processor modules, and analysis options.
(User) Choose the loader module that should be used to load file content into the new database, or accept IDA’s default choice.
(User) Choose the processor module that should be used when disassembling database content, or accept IDA’s default choice (which may be dictated by a loader module).
(User) Choose any analysis options that should be used when creating the initial database, or accept IDA’s default choices. You may also elect to disable analysis altogether at this point.
(User) Confirm your choices by clicking OK.
(IDA) The selected loader module populates the database with byte content taken from the original file. IDA loaders generally do not load the entire file into the database, and it is generally not possible to re-create the original file from content available in the new database.
(IDA) If analysis is enabled, the selected processor module is used to disassemble code identified by the loader and any selected analyzers (IDA calls analyzers kernel options).
(IDA) The resulting database is displayed in IDA’s user interface.
Ghidra has analogues for each of the listed steps; however, the process is broken into two distinct phases: import and analysis. The Ghidra import process is generally initiated from the Project window and includes the following steps:
(Ghidra) Query every available loader to learn which loaders recognize the newly selected file.
(Ghidra) Display the import dialog, presenting a list of acceptable formats (roughly loaders) and languages (roughly processor modules).
(User) Choose the format for importing the file into the current project, or accept Ghidra’s default choice.
(User) Choose the language for disassembling program content, or accept Ghidra’s default choice.
(User) Confirm your choices by clicking OK.
(Ghidra) The loader associated with the selected format loads byte content taken from the original file into a new “program” in the current project. The loader creates program sections and processes the binary’s symbol, import, and export tables, but performs no analysis involving disassembly. Ghidra loaders generally load the entire file into your Ghidra project, though some portions of the file may not be displayed by the CodeBrowser.
Though this process is similar to IDA database creation, some steps are missing. With Ghidra, analysis takes place in the CodeBrowser. Once you have successfully imported a file, double-clicking that file in the Project view opens the file in Ghidra’s CodeBrowser. When you open a program for the first time, Ghidra performs the following steps:
(Ghidra) Open the CodeBrowser and display the results of the import process, asking whether you would like to analyze the file.
(User) Decide whether to analyze the file. If you elect not to analyze the file, you are dropped into the CodeBrowser, where you can scroll through byte content but will have no disassembly. In this case, you may choose Analysis ▸ Auto Analyze to analyze the file at any time. In either case, when you decide to analyze the file, Ghidra displays a list of “analyzers” compatible with the current file format and language setting. You may choose which analyzers to run and then modify any options the analyzer utilizes before allowing Ghidra to perform its initial analysis.
(Ghidra) Execute all selected analyzers and drop the user into the CodeBrowser to begin working with the fully analyzed program.
For more information about the import and analysis stages, refer to the appropriate chapters in this book. IDA has neither an analogy for Project view nor any collaborative reversing capabilities other than the shared Lumina database. Project view is introduced in Chapter 4. Shared projects and support for collaborative reverse engineering are discussed in Chapter 11. The CodeBrowser is introduced in Chapter 4, with more depth beginning in Chapter 5 and continuing through the remainder of the book.
The CodeBrowser is a Ghidra tool and is your primary interface for analyzing programs. As such, it is the Ghidra component most similar to IDA’s user interface, so we will spend some time relating IDA user-interface elements to their CodeBrowser equivalents.
Basic Windows and Navigation
In its default configuration, the CodeBrowser is a container for multiple specialty windows that display information about features of a program. Detailed discussion about the CodeBrowser begins in Chapter 5 and continues, with coverage of related data displays, through Chapter 10.
Listing View
At the center of the CodeBrowser is the Ghidra Listing window, which provides a classic disassembly similar to your IDA View in text mode. To customize the format of your listings, the Browser Field Formatter enables you to modify, rearrange, and delete individual listing elements. As in IDA, navigation within the Listing windows is primarily accomplished by double-clicking labels (IDA names) to navigate to the address associated with a label. Right-click, context-sensitive menus provide access to common operations associated with labels, including renaming and retyping.
Similar to IDA, each function in the listing has a header comment that lists the function’s prototype, provides a summary of the function’s local variables, and displays cross-references that target the function. The Ghidra equivalent of IDA’s Stack view is accessible only by right-clicking in a function’s header and selecting Function ▸ Edit Stack Frame.
If you enjoy IDA highlighting all occurrences of a string that you click (such as a register name or instruction mnemonic), you may be disappointed to learn that this is not a default behavior in Ghidra. To enable this behavior, visit Edit ▸ Tool Options ▸ Listing Fields ▸ Cursor Text Highlight and change Mouse Button to Activate from MIDDLE to LEFT. Another feature you may love or hate is Markup Register Variable References, which causes Ghidra to automatically rename registers that are used to hold a function’s incoming parameters. To disable this behavior and have Ghidra use register name instruction operands, navigate to Edit ▸ Tool Options ▸ Listing Fields ▸ Operands Fields and uncheck Markup Register Variable References.
Finally, if you are longing for Ghidra to “do the right thing” when muscle memory causes you to use your favorite IDA hotkey sequences, you’ll want to spend some time in Edit ▸ Tool Options ▸ Key Bindings to reassign default Ghidra hotkeys to match those that you use in IDA. This is such a common task for IDA users that third-party key binding files have been published to automate reassignment of all your favorite hotkey sequences.1
Graph View
Ghidra’s Listing window is a text-only view. If you prefer working in IDA’s graph view, you’ll need to open a separate Function Graph window in Ghidra. Like IDA’s graph view, Ghidra’s Function Graph window can display a single function at any one time, and you can manipulate the items in the Function Graph window just as you would in the Listing window.
By default, Ghidra’s graph layout algorithm may route edges behind basic block nodes, which may make tracing the edge more difficult. You can disable this behavior by visiting Edit ▸ Tool Options ▸ Function Graph ▸ Nested Code Layout and checking Route Edges Around Vertices.
The Decompiler
Ghidra includes decompilation capability for all supported processors. By default, the Decompiler window appears to the right of the Listing window and will display decompiled C source code whenever your cursor is positioned within a function in the Listing view. If you like to add and view end-of-line comments in the generated C source, you’ll need to enable them at Edit ▸ Tool Options ▸ Decompiler ▸ Display by checking Display EOL comments. On the same options tab, you’ll also find Disable printing of type casts, which can improve readability in some cases by dramatically decluttering the resulting code.
The decompiler also has a tendency to aggressively optimize the code it generates. If you find yourself reading the disassembled version of a function and feel like behaviors are missing in the decompiled version, the decompiler may have eliminated what it believes to be dead code within the function. To display that code in the Decompiler window, navigate to Edit ▸ Tool Options ▸ Decompiler ▸ Analysis and deselect Eliminate dead code. The decompiler is discussed further in Chapter 19.
The Symbol Tree
The CodeBrowser’s Symbol Tree window provides a hierarchical view of all symbols contained in a program. The Symbol Tree contains six top-level folders representing six classes of symbols that may exist within a program. Clicking a name in any Symbol Tree folder will navigate the Listing window to the corresponding address:
Imports The Imports folder is relevant for dynamically linked binaries and provides a listing of external functions and libraries referenced by the program. This most closely correlates to IDA’s Imports tab.
Exports The Exports folder lists any symbols in the program that are publicly visible outside the program. The symbols in this folder are often similar to those output by the nm utility.
Functions This folder contains an entry for each function in the program listing.
Labels This folder contains entries for any additional nonlocal labels within the program.
Classes This folder contains the names of any C++ classes for which Ghidra has located Runtime Type Identification (RTTI).
Namespaces This folder contains an entry for each namespace created by Ghidra during program analysis. Refer to Ghidra Help for more information on Ghidra namespaces.
Data Type Manager
The Data Type Manager maintains all of Ghidra’s knowledge about data structures and function prototypes. Each folder in the Data Type Manager is the rough equivalent of an IDA type library (.til). The Data Type Manager fills the role of IDA’s Structures, Enums, Local Types, and Type Libraries windows and is discussed in detail in Chapter 8.
Scripting
Ghidra is implemented in Java, and its natural scripting language is Java. In addition to routine scripts, the primary Java extensions to Ghidra include analyzers, plugins, and loaders. Ghidra analyzers and plugins together take on the role that IDA’s plugins fill, while Ghidra loaders perform essentially the same role as IDA loaders. Ghidra supports the concept of processor modules; however, Ghidra processors are defined using a specification language known as SLEIGH.
Ghidra includes a basic script editor for routine scripting tasks as well as an Eclipse plugin to facilitate the creation of more complex Ghidra scripts and extensions. The use of Python is supported via Jython. The Ghidra API is implemented as a class hierarchy that represents the features of a binary as Java objects, and convenience classes are provided for easy access to some of the most commonly used API classes. Ghidra scripts are discussed in Chapters 14 and 15 and extensions are discussed in Chapters 15, 17, and 18.
Summary
Ghidra’s capabilities are quite clearly similar to those of IDA. In some cases, Ghidra’s displays are similar enough to IDA’s that the only things that will slow you down are new hotkeys, tool buttons, and menus. In other cases, information is presented in a different manner than in IDA, and your learning curve will be steeper. In either case, whether you take advantage of Ghidra’s customization capabilities to make it drive like IDA or you take the time to learn a new way of doing things, you’re likely to find that Ghidra meets most of your reverse engineering needs and in some cases opens up entirely new ways of getting things done.