Frequently asked questions
Gee-druh. The G sounds like the G in goto, great, good, graph, and GitHub. The emphasis goes on the first syllable.
Download and install Java JDK 17 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.8 or later) to locate a version of Java that Ghidra supports (in this case, Java 17). If Ghidra fails to find Java 17 in the standard locations, you will be prompted to enter the path to Java 17'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.
Right here on GitHub!
Ghidra 10.3+ provides a dark theme out-of-the-box. To enable this theme, from the Front-End GUI, click Edit → Theme → Switch... → Flat Dark Theme.
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.
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).
X86 16/32/64, ARM/AARCH64, PowerPC 32/64/VLE, MIPS 16/32/64/micro, 68xxx, Java / DEX bytecode, PA-RISC, PIC 12/16/17/18/24, Sparc 32/64, CR16C, Z80, 6502, 8051, MSP430, AVR8, AVR32, and variants of these processors.
One of the "easiest" ways to extend Ghidra is to add a new processor or extend an existing one.
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: DebugSleighInstructionParse.java.
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.
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.
On Windows, try
Get-ChildItem -Recurse -Include *.sla | ForEach-Object { $_.CreationTime = Get-Date; $_.LastWriteTime = Get-Date }in the PowerShell console.