Ghidra Decompiler - CLI guide
Ghidra Decompiler - CLI guide
Ghidra has a decompiler that unlike the rest of the program (written in java) is written in C++. This caught my attention so I started to hack on it. Unfortunately, there isn't much written on the decompiler if one wants to use it standalone, in the terminal without the ghidra GUI. This article tries to fill that void.
Building The Decompiler
Fetch and unzip the ghidra package from their github release page
$ unzip ghidra_11.1.2_PUBLIC_20240709.zip
cd into the decompiler directory and build it
$ cd ghidra_11.1.2_PUBLIC/Ghidra/Features/Decompiler/src/decompile/cpp
$ make decomp_opt -j $(nproc --all)
You should end up with a executable called decomp_opt.
Running the Decompiler
While inside the directory, export the SLEIGHHOME env variable so our decompiler can find it, then run the executable.
$ export SLEIGHHOME=/home/shreeyash/ghidra_11.1.2_PUBLIC
$ ./decomp_opt
[decomp]>
The compiler is running now waiting for commands.
Note:
Remember to always export the environment variable before running decomp_opt. You could consider tossing the two commands into a script, making life easier for you.
Decompile and view an ELF executable
Let's start with a trivial c++ program with some control flow, compile it into an executable (ELF) and decompile it.
Here's the program, save and compile it:
$ cat a.cpp
#include <iostream>
#define THRESHOLD 20
int foo() {
return 10;
}
int main() {
int b = foo();
std::cout << "The threshold is " << THRESHOLD << '\n';
std::cout << "You returned " << b << '\n';
if (b < THRESHOLD) {
std::cout << "get in\n";
} else {
std::cout << "get out!\n";
}
}
$ g++ -no-pie a.cpp -o a
$ ./a
The threshold is 20
You returned 10
get in
The executable is ready, what's left now is decompilation.
Let's start the decompiler, and load our file:
$ ./decomp_opt
[decomp]> load file a
a successfully loaded: Intel/AMD 64-bit x86
We've loaded our executable in the decompiler. c++ is an abstract language with constructs that do not make any sense
to a CPU. These include, but are not limited to: functions, structs, loops etc. In order to implement these, the
compiler has to translate abstractions into concrete implementation which manifests itself in the form of control flow
instructions like branch, compare, and jump. If we peep into an executable, we'll notice what we called functions are
now 'addresses' i.e. a number that represents a location in memory. Functions are run by jumping (i.e. setting the
program counter) to an address. Essentially, if we wish to decompile a function we had in source, we'll have to find
the corresponding address at which it resides. a.cpp has two functions: main and foo. To find the address where a
functions resides in the executable, we could use objdump.
$ objdump -C -D a
...
00000000004011c5 <main>:
4011c5: f3 0f 1e fa endbr64
4011c9: 55 push %rbp
4011ca: 48 89 e5 mov %rsp,%rbp
4011cd: 48 83 ec 10 sub $0x10,%rsp
4011d1: e8 e0 ff ff ff call 4011b6 <_Z5todayv>
4011d6: 89 45 fc mov %eax,-0x4(%rbp)
4011d9: 48 8d 05 24 0e 00 00 lea 0xe24(%rip),%rax # 402004 <_IO_stdin_used+0x4>
4011e0: 48 89 c6 mov %rax,%rsi
4011e3: 48 8d 05 96 2e 00 00 lea 0x2e96(%rip),%rax # 404080 <_ZSt4cout@GLIBCXX_3.4>
4011ea: 48 89 c7 mov %rax,%rdi
4011ed: e8 9e fe ff ff call 401090 <_ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc@plt>
4011f2: 48 89 c2 mov %rax,%rdx
4011f5: 8b 45 fc mov -0x4(%rbp),%eax
...
Searching for 'main' reveals its label which resides at address
0x4011c5.
[decomp]> load addr 0x4011c5 main
Function main: 0x004011c5
load addr takes an address and an optional 'label'.
Label is essentially a name that we assign to that address. In this
case, it was 'main'—could've been anything for what its worth.
[decomp]> decompile
Decompiling main
Decompilation complete
[decomp]> print C
xunknown8 main(void)
{
int4 iVar1;
xunknown8 xVar2;
iVar1 = func_0x004011b6();
xVar2 = func_0x00401090(0x404080,0x402004);
xVar2 = func_0x004010c0(xVar2,0x14);
func_0x004010a0(xVar2,10);
xVar2 = func_0x00401090(0x404080,0x402016);
xVar2 = func_0x004010c0(xVar2,iVar1);
func_0x004010a0(xVar2,10);
if (iVar1 < 0x14) {
func_0x00401090(0x404080,0x402024);
}
else {
func_0x00401090(0x404080,0x40202c);
}
return 0;
}
[decomp]>
Just like that, we've decompiled our program. Notice how the names are garbled. This is because names (of variables and functions) are really neccessary to execute a program.
Let's analyze the decompiled output. The latter part of all function
names are their address. This means, we can look them up in the
objdump. Moreover, if the set of commands that got us
main s decompilation we to be repeated for all the
functions present in in the output, the resulting decompilation of main
would replace all address with the labels we assign to them. Looking up
in objdump, we find func_0x004011b6 to be
foo:
...
00000000004011b6 <foo()>:
4011b6: f3 0f 1e fa endbr64
4011ba: 55 push %rbp
4011bb: 48 89 e5 mov %rsp,%rbp
4011be: b8 0a 00 00 00 mov $0xa,%eax
...
func_0x00401090 is not present in the executable, however,
the calls to this function are shown in the objdump thusly:
4011ed: e8 9e fe ff ff call 401090 <std::basic_ostream<char, std::char_traits<char> >& std::operator<< <std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*)@plt>
Its quite obvious from the hint that func_0x00401090 is the operator \<\< overloaded to accept a
std::basic_ostream object and a const char \*. The \@plt at the end indicates that this
function can be found in the .plt section of the executable. .plt which stands for Procedure
Linkage Table is a redirection table of external functions that can be found in shared objects. So,
func_0x00401090 is operator\<\< found in libstdc++.so that the program is
linked to. It takes two arguments: both addresses to objects. A search reveals that the first argumnet is the object
std::cout of which the definition resides in an external library (libstdc++.so) and the
other argument is a char literal that can be found in the .rodata section of the executable.
$ objdup -s -j .rodata a
Contents of section .rodata:
402000 01000200 54686520 74687265 73686f6c ....The threshol
402010 64206973 2000596f 75207265 7475726e d is .You return
402020 65642000 67657420 696e0a00 67657420 ed .get in..get
402030 6f757421 0a00 out!..
Indeed, the string \"The threshold is \" is present at
address 0x0402004.
Likewise, all following functions till func_0x004010a0 are
overloads of operator\<\< that handle different types of
data. What remains is the control flow. It checks if iVar1
which is b in the original source is less than
0x14 (THRESHOLD) and calls the familiar
func_0x00401090 i.e. (operator\<\<).
Conclusion
Our work was made much easier by the fact that the executable was not 'stripped'. Stripping is a process that gets rid of all the symbols that are not absolutely neccessary for execution (greatly reduces executable size). In the real world, especially if we are dealing with propreitary software, executables might be stripped. Unstripped executables allows us to tread faster by simply searching for symbols like we did to find main. Stripped executables require us to trace, find and deduce what we need. In a later article, I may demo decompilation of stripped executables.