Processor Specific Decompiler Rules

[astrelsky]

This could be done two ways.

1. Utilizing the rule compiler and having the rule file specified in in the ldefs file. The compiler does appear to be functional. However extreme care is required as it will happily dereference an uninitialized pointer. This does need a bit of work. Dealing with the uninitialized pointer dereference can be dealt with a custom "smart" pointer template class. This class would default it's value to nullptr and it would check prior to dereferencing to provide a proper explanation of what went wrong in the low level error.

2. Via an exported vector of rules from a user created dynamic library.

This would help ease the burden of developing new rules and would also ease the pain of dealing with rules that only apply for specific processors.

[hedgeberg]

I'd really like to see something like this, and also something to allow extensions or even end users to add rules that could be enabled/disabled at runtime. One of ghidra's biggest weaknesses, currently, is the limited ability to do any kind of transformation on the output of the decompiler from the java UI. User-controlled rules that could be invoked at the end of the decompilation pipeline to do things like apply transformations to the resolved syntax tree would open up a whole new realm of possibilities for manipulating the output of the decompiler. I could even see it being useful for decompiling to things like non-C/C++ languages.

[msm-code]

I just got around to blogging about this. If you're still interested in how this DSL works, check out https://msm.lt/re/ghidra/rulecompile/

[astrelsky]

I just got around to blogging about this. If you're still interested in how this DSL works, check out https://msm.lt/re/ghidra/rulecompile/

I did not know it was possible to make the decompiler use them automatically when running in the UI. From what I can remember from a few years ago, the language seemed incomplete and it was very easy to cause the decompiler to segfault. There was no verification of the rules.

[msm-code]

It's still not possible, I solved this with a dirty hack - basically I hardcoded a path, and forced the decompiler to always load rules from there. Obviously not a proper solution, but I wanted to check if that really works.

I'm not sure about the completeness of the language (it's powerful enough to write many useful rules), but what you say about segfaults is absolutely true. When testing this, I witnessed dozens of segfaults. Doing anything wrong, for example a typo in a variable name, causes a segfault. Clearly it's not production ready - probably why it was disabled in the first place.

[astrelsky]

It's still not possible, I solved this with a dirty hack - basically I hardcoded a path, and forced the decompiler to always load rules from there. Obviously not a proper solution, but I wanted to check if that really works.

I'm not sure about the completeness of the language (it's powerful enough to write many useful rules), but what you say about segfaults is absolutely true. When testing this, I witnessed dozens of segfaults. Doing anything wrong, for example a typo in a variable name, causes a segfault. Clearly it's not production ready - probably why it was disabled in the first place.

At this point it's practically abandonware. However, I could see it being used in it's current state for something like fuzzing to find flaws or bad assumptions about the state of varnodes in other decompiler rules.

It's just unfortunately because it is clear that someone put some thought and work into this at some point.

[msm-code]

Yeah. I would really, really, like to have a way to influence decompiler output (more than currently possible). I work with obfuscated code a lot, and that would be great capability to have. This discussion didn't much attention 3 years ago, but who knows, maybe 2025 will be the year of ghidra decompiler.