Hi Rolf,
I read your blog article on this little baby at the time, but only now do I have a version of IDA capable of testing it.
I have spent far too much of the 5 years writing de-obfu for a
rx
an
obfuscation, which seems to have been designed explicitly to befuddle IDA, most commonly by splitting a function into as many chunks as possible then attempting to play 3 card monte with the stack pointer.
As far as I can tell, the rules of the game are:
- Never
retn
when you can use lea
+ jmp
- Never
jmp
when you can use lea
+ retn
- Never manipulate
rsp
directly when you can push
it elsewhere, and pop rsp
- Never use an 8bit
mov imm
if a 32bit mov imm
would be more annoying
cmov
is great for everybody
- Never overrate the importance of have an aligned stack.
test rsp, 0Fh
then conditionally push 10h
or push 18h
, and arrange for that value to be applied to the stack at the end.
Not having your brilliance with intermediate disassembly languages (or willingness to commit to Ghidra), this has all been done with byte patching, aided by regex, brace expansion, and nasm -- eventually requiring the re-stitching and relocation of entire functions so that IDA can properly read them.
I'm looking forward to see how much help this project will be, though I fear that it will only be able to help if the stack actually balances.
I'm also looking forward to looking at your ComRAT4 idbs, as I'm also a C++ guy (though I use python for IDA), and it's always educational to see how C++ is actually implemented (though not always simple or fun). Don't even get me started on GCC COW string classes.
Keep up the excellent work, I would definitely take your C++ course -- my hobby (converting Javascript's underscore library to C++latest) is a never ending source of challenges and new skills to be learned.