-
Notifications
You must be signed in to change notification settings - Fork 5.9k
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 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.
This repository is a placeholder for the full open source release. Be assured efforts are under way to make the software available here. We plan to include our build scripts (for Gradle) and a developer's guide. We plan also to include the source for the native components, which includes the code for the decompiler. In the meantime, enjoy using Ghidra on your SRE efforts. Also try out the GhidraDev plugin for Eclipse to develop your own scripts and plugins, and perusing the over a million lines of Java and Sleigh code released within the initial public release. The release can be downloaded from our project homepage at www.ghidra-sre.org. Please consider taking a look at our contributor guide to see how you can participate in this open source project when it becomes available.
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.
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.
You have a couple of options:
First, you can submit an issue, but we make no promises to address any particular 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.