A Silly Anti-Disassembly Trick

Re:A Silly Anti-Disassembly Trick by kuroguro on Sunday April 25, 2021 @05:30AM (#26931449)

For x86 disassembly probably the easiest thing to do is cause a "desync" of some sort - add a dummy byte before one of the instructions (and jump over it) and everything after that is dissembled incorrectly (as most instructions are multi-byte).

Similar results can be achieved by overlapping parts two multi-byte instructions and jumping back in the middle of the first instruction.

[ Parent | on HN ]

Re:A Silly Anti-Disassembly Trick by colejohnson66 on Sunday April 25, 2021 @07:15PM (#26937622)

The first one is solved using control flow disassembly (like what IDA does). Find the entry point and only disassemble code that is reached. If bytes are jumped over and never executed, don’t disassemble them. It takes much longer than naive disassembly, but it’ll get you the most accurate view of what’s happening.

Of course, jumping into the middle of an instruction will throw the control flow analysis out of whack.

[ Parent | on HN ]

Re:A Silly Anti-Disassembly Trick by kuroguro on Monday April 26, 2021 @01:38PM (#26945407)

I think the proper technique was using conditional jumps (that always end up jumping) so the disasm thinks the next instruction should come right after it (in case the jump isn't taken). It then becomes undecidable which is the correct path.

_edit_

Huh, you're right, IDA works around some basic examples I threw at it. Who knew.

_edit_

Oh, I forgot to strip symbols... successfully managed to confuse IDA with a few tries :)

https://gist.github.com/tostercx/899630ba3d01cb98fcf7faf8bf0...

[ Parent | on HN ]