emteere
commented
2 years ago We are working on a mechanism to provide pseudoOps for instructions like this that can have a variety of attached pcode, currently called pcode injection, that could be specified based on the use. For example in emulation or theorem proving, you would want full semantics while in the decompiler you may just want to see the input/output for the operation such as ROL/ROR.
The same could be said for other instructions like the AARCH64 PAC instructions where you might want to see their effects in the decompiler to some extent, but would want the psuedoop not to appear at all in the decompilation if you just want clean code and not artifacts of pointer checking that the compiler added in.
Without this configuration there is a conflict between our current automated pcode verification methods (emulation) and the decompiler output.
The decompiler does have some mechanisms to simplify complexity such as this, so we can consider that as well.
We can also consider changing the emulator to processor an rol() pseudoOP, and let the deompiler just show the rol() pseudoop.
As a hack, you can go into the ia.sinc file for x86 and temporarily make them an ROL pseudoop, which is essentially what we will be doing in a near future version. When you re-open ghidra with that program up, then the x86 will be automatically re-compiled. Not the best solution, but it would work. We sometimes do this for very complex operations when tuning a language for decompilation.
PatchByte
Is your feature request related to a problem? Please describe. When reverse engineering functions that use ROR or ROL, you often have scrambled code (decompiled code) that is not really able to read. If you then want to use that code to decrypt or reverse a encryption its often hard to replicate the code!
Describe the solution you'd like A Solution like Hex Ray's IDA with having a signature or somehow detecting ROL ROR and simplifying that code.
Additional context Encrypted Pointers... See Screenshot!
~ Hendrik (PatchByte)