3 ms·
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 e
by kuroguro 5y ago
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.
- colejohnson66 5y agoThe 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.
- kuroguro 5y agoI 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/899630ba3d01cb98fcf7faf8bf05ebd6 https://gist.github.com/tostercx/899630ba3d01cb98fcf7faf8bf0...