Hot answers tagged

13

Although these terms are being used interchangeably, there is an intrinsic difference between disassembler and decompiler definitions traditionally. Let's first consider common steps involved in converting low level code to high level human readable code. This is similar to compilation where you convert high level code to low level machine code or an ...


9

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 ...


9

Visual Studio is inlining the function. You will need to tell VS to not do that: __declspec(noinline) void someFunction() { printf("im scared world, i dont understand.\n"); }


8

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 ...


8

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, .., ...


7

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 ...


7

Ghidra Export Binary Feature UPDATE AS OF June 2021: The preliminary release notes list this as a feature for Ghidra 10, which should be released "mid to end of June 2021": New exporters that write programs imported with the PE and ELF loaders back to their original file layout have been added. Any file-backed bytes that were modified by the user ...


7

Try Window -> Function Graph Its even conveniently zoomable.


7

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 ...


7

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 ...


7

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 ...


6

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 ...


6

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: print(f.getSignature().getPrototypeString()) The output: Signatures.py> Running... char * strcpy(char * __dest, char * __src) ...


6

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 ...


6

This is annoyingly hard to find the answer to. This is a good starting point, but I don't think I found everything yet. Variable names From Function.java: param_ local_ local_res temp_ 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 ...


6

From Ghidra.re: 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 ...


6

The only way I'm aware of is to reimport the tool. Specifically: From the Ghidra Project window, right click on the code browser tool and click Delete... Tools -> Import Default Tools... Select defaultsTools/CodeBrowser.tool, then OK Worth noting, while in your case it makes sense to delete the current (i.e. broken) tool, that's not a strict requirement....


5

"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-...


5

you can right click the file you import at Active Project tab in ghidra main window, and select Set Language


5

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 ...


5

You can configure the timeout in decompiler options. Go to Edit->Tool Options...->Decompiler and change "Decompiler Timeout (seconds)" to the desired value.


5

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 in ...


5

I turns out that the python script can be used with headless analyzer script. Using the following command I can run it, just like the java file: ./analyzeHeadless ghidra-project-directory -import binary-file -postscript yourpythonscript Apparently all the classes defined for java can be used directly in the python script. Particular class can be imported ...


5

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. Processor: MIPS Variant: 64-32addr Size: 32 Endian: little Compiler: default The disassembly is the same as that of IDA. Using readelf shows that there are relocations of type R_MIPS_26 at the said ...


5

Well, rubber ducking really works. I found it myself, go to Edit > Tool Options > Listing Fields > Address Field and check Show Block Name


5

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 ...


5

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 ...


5

You can use currentProgram.getImageBase() to obtain the base address. This returns an Address object. Example >>> currentProgram.getImageBase() 00400000 >>> type(currentProgram.getImageBase()) <type 'ghidra.program.model.address.GenericAddress'> >>> currentProgram.getImageBase().getOffset() 4194304L >>> hex(...


5

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 ...


5

TL;DR: 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. As ...


Only top voted, non community-wiki answers of a minimum length are eligible