As of 2020.11.13 the 9.2 release is available which includes this feature.
For registers you can do it:
Right click in the Decompiler → Commit Locals.
Right click on the variable → Split out as New Variable.
as per https://github.com/NationalSecurityAgency/ghidra/issues/975#issuecomment-593425470 in the issue that Jeff Muizelaar mentioned.
According to ...
I wanted to comment but it grew up so answering
CONCAT is Concatenation
22 is a suffix that denotes concatenate two bytes with two bytes
it takes two bytes from first location two bytes from second location and produces a 4 byte result
here it is probably making a wide character string
you can see the difference of two bytes in the address too ...
In the SleighDevTools folder, there is a pcodetest folder, with a README.txt (which is unfortunately very brief).
The documentation on SLEIGH can be found in <ghidra install dir>/docs/languages/index.html, which explains what goes in the .slaspec file for your new processor.
Some documentation on what goes in the other files like .cspec, .ldefs, .., ...
Check my answer here.
All you have to do is to use ./analyzeHeadless script, which comes with ghidra:
./analyzeHeadless ghidra-project-directory -import binary-file -postscript yourpythonscript
You can either use java or python 2.7. You can check the ghidra api here.
You can write the script (in python) in the following way:
from ghidra.app.decompiler ...
By default, there is a setting in Code Browser that allows Ghidra to eliminate unreachable code, you would have to change the setting by editing the options for Code Browser. This can be done by going to Edit -> Tools Options. This would bring you to a page as seen in the screenshot below
Under the Analysis options in the Decompiler folder, there is a ...
From everything I've read pseudo code can't be edited in realtime but can be edited as assembly
This is not entirely correct. Quite the opposite even: Decompilers cannot be perfect (the compilation step looses too much information). Hence they need some help by a human (the reverse engineer). Giving this help is, at least in my opinion, the most important ...
For an individual instruction, yes, sure. See this recent blog post of mine and search for "Jenga". If you're talking about inspecting the pcode after the decompiler has done its business with it, there's a couple of scripts that user d-millar has repeatedly linked on the Ghidra GitHub that demontrate how to use that form of the pcode from the API, as well ...
You can use FunctionManager to get all the functions in the current program and then, from it iterate and get signatures of each.
fm = currentProgram.getFunctionManager()
functions = fm.getFunctions(True)
for f in functions:
char * strcpy(char * __dest, char * __src)
I can only properly answer your first question:
I think this is fundamentally impossible to achieve with IDA, but in Ghidra it works and is fairly easy to use (though a bit hard to find)
If your "firmware" is a filesystem that you can unpack, you can automatically load the libraries by:
Opening the regular Import File... dialog
Clicking Options inside ...
Sometimes you will see warnings in the decompiler view stating that there are too many branches to recover a jumptable.
One reason for this is that there actually is a jump table, but the decompiler can’t determine bounds on the switch variable
For your example, this is saying there may a jump table (which is really just an array of ...
I don't know the exact length of string. But, few things to note here are as follows:
Ghidra and IDA has a minimum bound on size of string to recover correct type (ghidra has a limit - or lower bound of 5).
This is necessary to avoid any false positives or conflicting types. And recover correct types without marking a pointer as a string. Check out this ...
I'm looking for the same thing and for now I found the class PcodeSyntaxTree having a method called getBasicBlocks(), which returns an array of PcodeBlockBasic elements. This second class has methods like getIn and getOut which retrieve incoming and outgoing nodes (basic blocks), respectively. So I think using this methods should be the interface for ...
This has something to do with the way Ghidra handles relocations. Loading the SLUS_204.99 binary with the following processor options and relocations disabled.
The disassembly is the same as that of IDA.
Using readelf shows that there are relocations of type R_MIPS_26 at the said ...
When you have just raw bytes without proper headers tools might not know how to process as the code might not start from offset 0. They could try to analyze the bytes to detect if there's code, data or something else but you might also get some false-positives.
In your case, you instruct r2 to display those bytes as code (pd - print disassembly) and it does ...
1) you demangle the function names for these which are called within the function
2) you learn the arguments of these functions and apply the names to local variables which are passed as arguments to the functions
3) you learn the structures and apply them to stack variables, so that you can name more stack variables which are assigned to the structure ...
You can use currentProgram.getImageBase() to obtain the base address. This returns an Address object.
The firmware is incorrectly dumped. In your file all occurrences of the byte 0A have been replaced with 0D 0A. Looks like a line ending issue. May be the tool which you have used to dump the firmware have prepended a 0D to each 0A.
After replacing all instances of 0D 0A with 0A, it has an exact size of 256 KiB (262144 bytes) as it should be. Previously it ...
This is not an error from Ghidra. The values are just a naming convention, and the real instructions are correctly disassembled.
Ghidra assigns variable names based on the function entry point, and displays offsets based on that.
It seems Ghidra behaviour is like this to have a universal way to assign names, independently from the compiler.
So, I found out the reason. By default when the ghidra asks for options when we load the binary, Decompiler Parameter ID option is disabled. Once you enable it, you will have the function parameters correctly. It will take longer time to make the analysis once this option is enabled.
This is annoyingly hard to find the answer to. This is a good starting point, but I don't think I found everything yet.
From database.cc <-- this function has most (maybe all?) of the variable naming logic. There are multiple pieces of this function that I don't yet understand; I'm ...
Not sure if you ask about one line or the whole program.
One assembly line can be obtain for example by such script:
addr = toAddr(<address>)
if we are talking about the whole program
for instr in currentProgram.getListing().getInstructions(True):
but I guess the last one ...
Ghidra Export Binary Feature
Note that the Binary export is not broken, it is simply misunderstood. This exporter simply dumps the initialized memory blocks defined within Ghidra in binary form. The blocks are appended sequentially. It was never intended to recreate a loadable/executable binary. While this is certainly a desirable feature, it does not yet ...
So once in an architecture that has Thumb (ARMv7+) selecting the region of interest and pressing CTRL+R will bring up the Set Register Value editor, and selecting TMode and setting value 1.
If you have the Edit -> Tool Options -> Options | Listing Fields | Register Field | Display Hidden Registers set, you will have annotations like
assume TMode = 0x1
"File" -> "Parse C Source..." ... then parse the ddraw.h
But warning it doesn't work as smooth as expected. I could only get small headers to parse correctly.
A good video about it: https://www.youtube.com/watch?v=u15-r5Erfnw
Maybe you could ask that guy on Github to include the ddraw.h into his data type collection: https://github.com/0x6d696368/ghidra-...