Skip to content

Frequently asked questions

Ryan Kurtz edited this page Apr 4, 2019 · 13 revisions

How do you pronounce Ghidra?

Gee-druh. The G sounds like the G in goto, great, good, graph, and GitHub. The emphasis goes on the first syllable.

When I run Ghidra, all I see is "Java runtime not found..." How do I get Ghidra to run?

Download and install OpenJDK 11 and add its bin directory to your system's PATH. For detailed instructions on adding Java to your PATH, see the Ghidra Installation Guide.

My system requires Java 8 (or another Java) to be on the PATH for other software to function correctly. How can I get Ghidra to run without altering the PATH?

Ghidra uses an existing Java runtime on the PATH (Java 1.7 or later) to locate a version of Java that Ghidra supports (in this case, Java 11). If Ghidra fails to find Java 11 in the standard locations, you will be prompted to enter the path to Java 11's installation directory. Note that this path should be Java's installation directory (also called "java home"), not the bin directory found within the installation directory.

Where is the complete Ghidra source code?

Right here on GitHub!

Does Ghidra have a dark theme?

Ghidra provides the ability to invert the colors of its GUI, providing a "darkish" "theme." Icons and help documents are not affected by the color inversion. To invert the colors from the Front End GUI, do Edit → Tool Options... → Tool, enable "Use Inverted Colors," and restart Ghidra.

How do I change Ghidra's key bindings?

You can change the key binding of any top level menu or context sensitive menu item (except items in the Code Browser's "Window" menu). Simply hover on the menu item and hit the F4 key to change the key binding. Alternatively, you change the key bindings of your current tool via Edit → Tool Options... → Key Bindings.

Why is auto-analysis is slow? Why does auto-analysis fail completely?

Generally, analysis time is proportional to the size of the binary. Large binaries (~100MB) can take hours, or even days, to analyze.

In order to make progress on analysis for a problematic binary you can try disabling various analyzers before you perform the initial analysis via the Analysis Options Dialog. Using this debugging approach will not only allow your analysis to finish (minus the disabled analyzers), but it will also allow you to identify the broken analyzer(s).

There are missing instructions or bad instructions. What can I do?

You have a couple of options: First, you can submit an issue. Second, you can modify the Sleigh specification yourself. If you anticipate substantial changes, e.g., supporting a new variant, we recommend you make a copy of the .slaspec file, name it appropriately, and update the .lspec file to include it. Optionally, you may submit a patch or pull request with your modifications if you'd like to contribute them to the broader community. Please see our contribution guidelines for more information.

The Sleigh source consists of the .sinc and .slaspec files in the data/languages directory of each processor module. When these are updated, Ghidra should automatically compile them, producing .sla files, the next time the processor is used. You may need to restart Ghidra to convince it to recompile. The documentation for our Sleigh language is at docs/languages/index.html. There is also a useful script for debugging: Put you cursor at the start of the faulty/missing instruction and run it for a rather verbose dump as it attempts to parse the instruction.

Why am I getting Access Denied errors running Ghidra from a read-only installation?

It's likely Ghidra is trying to recompile its Sleigh files. If it's truly read-only, then it's not likely a user is modifying the Sleigh specs. Rather, it's likely the timestamps of the installation files were inadvertently updated. If the .slaspec or .sinc files have a later timestamp than the .sla files, Ghidra will atttempt to recompile them, writing them to the installation directory. If you unpacked the installation and then copied it to the read-only location, be certain the timestamps are preserved by the copy. If you are using an unofficial installer package, it's likely the timestamps were inadvertently modified by the packagers. You should be able to fix this by updating the timestamps of the .sla files. On Linux, try

touch `find . -name '*.sla'`

from the installation directory.

Clone this wiki locally
You can’t perform that action at this time.