A lot of my colleagues use Ghidra a lot now and complain about its decompiler regularly.
Is there any new approach in the works? Maybe something ML-based for optimization? Would be sad if Hex-Rays output is "as good as it's gonna get".
Are your colleagues decompiling obfuscated code (for example malware)? Publicly available decompilers are not working well for that, but I assume that many specalists have their own little improvements and plugins that they don't share with others because it's their core business.
For non-obfuscated code, Ghidra has served me very well, even for entire applications. Often, it has to be pushed into the right direction (for example, by manually specifying the type of a variable) and it sometimes misses some obvious simplifications especially when arrays are involved, but I think those issues could be solved relatively easily by polishing/extending its heuristics. Nothing where I would say that ML is needed, although it would be possible. At the end, most programs contain the same patterns and an ML-based system could help identifying them.
But yeah, obfuscated code, that's something else. There are some academic publications about the usage of ML for that. No idea what's happening inside the company labs, though.
Of course it wasn't obfuscated and there were a couple of mistakes here and there but overall it'd work perfectly fine for someone to understand what the program was doing if they didn't had access to the source code.
Sometimes it would just straight up ignore (functional) assembly for apparently no reason. Or it would turn simple code into a myriad of nested conditionals and loops, achieving the same goal, but looking nothing like a human would write.
It was still very helpful in understanding blocks of assembly much faster than I otherwise would, and it's possible I was lacking some configuration that a more experienced user could do to help the decompiler out.
probably code it thinks is unreachable. (Jmp or ret right in front of it and no jmp/call into that address, probably a computed jump/call)
> Or it would turn simple code into a myriad of nested conditionals and loops
Ran into that myself, usually a switch case. (Dunno how to get ghidra to deal with that properly myself)
The biggest help you can give ghidra is defining structs, naming the fields, and setting the right types.
Or dead assignments. I've seen it with HexRays: if you don't tell it that e.g. var_16 is actually 32 bytes long, not 4, it will completely ignore any code that reads/writes stack between var_16 + 4 and var_48 (which is at var_16 + 32). It's quite an amusing sight to see: you have an 8 lines-long decompiled function from 300 lines of assembly, you edit a variable's annotation, boom, the decompiled function is now 40 lines long, with all kinds of interesting computations in its body.
Unfortunately it looks like the maintenance state of the pieces around Rellic isn't very good, and it's quite rocket science to get it building. It doesn't have as much UI/GUI as Ghidra either so it's a bit far from accessible right now.
...note: from LLVM bitcode.
bool found = false;
for (...) {
if (...) {
found = true;
break;
}
}
if (found) {
// A
} else {
// B
}
for (...) {
if (...) {
// A
goto end;
}
}
// B
end:;
[1] This kind of optimization pass runs at a stage when the code is basically treated entirely as a CFG and there's no such thing as if statements or jumps or gotos, just conditional and unconditional branches terminating basic blocks. Any reflection of the code outside of this form is therefore somewhat imprecise.
Suppose you implement a state machine with gotos. So, for a simple (and contrived) example, suppose you have something that absorbs the decimal digits of a number and keeps track of the value of the number modulo 3 by having three states. Something like this (pseudocode):
def mod3():
state0:
d = getdigit()
if d == FINISHED: return 0
if d is 0, 3, 6, 9: goto state0
if d is 1, 4, 7: goto state1
if d is 2, 5, 8: goto state2
return ERROR
state1:
d = getdigit()
if d == FINISHED: return 0
if d is 0, 3, 6, 9: goto state1
If you have tail-call optimization you can turn this into conventionally structured code, more or less:
def state0():
d = getdigit()
if d == FINISHED: return 0
if d is 0, 3, 6, 9: return state0()
if d is 1, 4, 7: return state1()
if d is 2, 5, 8: return state2()
return ERROR
Or else you can have an explicit state variable:
def mod3():
state = 0
loop:
if state == 0:
d = getdigit()
if d == FINISHED: return 0
if d is 0, 3, 6, 9: state = 0
else if d is 1, 4, 7: state = 1
else if d is 2, 5, 8: state = 2
else: return ERROR
else if state == 1:
...
else:
...
Doesn't WebAssembly implement that already, via Relooper?
I'm doing a PhD on this.
My goal is to detect known functions from obfuscated binaries.
The biggest challenge by far is building a good dataset. Unlike computer vision (millions of pictures with the label "dog") the number of training examples for a typical function is one. For now I'm focusing on C standard libraries, since there are a handful of real-world implementations plus some FOSS or students samples available for things like strlen and atoi.
If anyone wants to collaborate, feel free to message me.
That said I assume I'm missing something here.
The worst are symbols that are used inconsistently within the same function, like a parameter which is passed in as a long and then used as a pointer to a struct or even as a function.
The Ghidra community basically says you should not expect the exported decompiled code to be valid [1,2]. Which is fine, since rount-trip compile-decompile-compile is not exactly Ghidra's purpose.
Maybe there's a setting to make Ghidra export asm literals when it can't figure out a valid disassembly, but I am pretty new to Ghidra so it could just be my own ignorance.
[1]: https://github.com/NationalSecurityAgency/ghidra/issues/236
[2]: https://github.com/NationalSecurityAgency/ghidra/issues/3553
Split into new variable. Sounds like ghidra has trouble telling whether it is a reused stoarge location or actually the same variable.
Best guess = something that looks approxinately fitting for the relevant assembly
fuzzing = tweaking the source code to get what it compiles to closer to the actual assembly.
as in, generate a function, see how close its compilation resembles the assembly, tweak until you find a match
As for generating functions, I'll have to think about what that loss function would look like. I've been looking at asm2vec[1] and structure2vec[2] for inspiration. I'm currently looking at different kinds of graph embeddings, because even answering the basic question of "are these N bytes of assembly semantically similar to these other N bytes" is a challenge.
Or maybe I can figure out how to tell LLVM to do some extreme strength reduction and target an ultra reduced subset of some ISA. Great food for thought, thanks!
Hence HexRay can get away with not doing much and just collecting license fees from existing customers yearly, as there isn't a better alternative anyway.
They're both amazing, they're both quirky, and they're both buggy. But one is free and the other has its support. Pick which one matters to you :-)
And especially, software tweakers and improvers. Not all software is open source.