4 ms·

Oh, I thought it was going to be something sneaky. Like .. oh I don't know ... sprinkling in a lot of conditional branches that actually can never fall through,

Oh, I thought it was going to be something sneaky. Like .. oh I don't know ... sprinkling in a lot of conditional branches that actually can never fall through, and following them by a (never executed) instruction with a 64 bit literal, with the literal containing code that actually is jumped into from elsewhere. Possibly by using a runtime-calculated indirect jump that a disassembler won't be able to figure out because Entscheidungsproblem.

sudosysgen 6y ago
Wouldn't this be pretty easy to see through with a debugger?
alfiedotwtf 6y ago
Checking for an `INT 3;` was the usual anti-dissassembly trick
- innocenat 6y ago
  Isn't that anti-debugger trick?
  - kuroguro 6y 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 6y ago
      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.
      - kuroguro 6y ago
        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/899630ba3d01cb98fcf7faf8bf05ebd6 https://gist.github.com/tostercx/899630ba3d01cb98fcf7faf8bf0...

sudosysgen 6y ago

Wouldn't this be pretty easy to see through with a debugger?

alfiedotwtf 6y ago

Checking for an `INT 3;` was the usual anti-dissassembly trick

innocenat 6y ago
Isn't that anti-debugger trick?
- kuroguro 6y 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 6y ago
    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.
    - kuroguro 6y ago
      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/899630ba3d01cb98fcf7faf8bf05ebd6 https://gist.github.com/tostercx/899630ba3d01cb98fcf7faf8bf0...