0

This assembly is for Intel x86-64 bit, seems to be too baffling to me.

enter image description here

  • How come the jz instruction jump to a non-instruction (0x400AC9)?
  • How come the call invokes a non-existing address?

For curious ones, the binary is here.

4

How come the jz instruction jump to a non-instruction (0x400AC9)?

It does not. There is no such thing as "an instruction". Jumps do not jump to instructions, they jump to addresses.

How come the call invokes a non-existing address?

It does not. If you check what the code actually does, you will find this call will never be executed.


Here is the relevant part of your code, prefixed with their original hex bytes.

400AC7:  66 b8 eb 05             mov    ax,0x5eb
400ACB:  31 c0                   xor    eax,eax
400ACD:  74 fa                   jz     0x400AC9
400ACF:  e8 0f b6 45 b0          call   0xffffffffb045b61c
400AD4:  3c 38                   cmp    al,0x38
400AD6:  0f                      .byte 0xf
400AD7:  85                      .byte 0x85
400AD8:  bc                      .byte 0xbc

If you assume the instruction at 400AC7 executes, it loads ax with some value but it gets immediately discarded by the next instruction, which clears it to 0. Because of that, the jump will always be taken!

The jump goes to 400AC9, and if we disassemble starting at that, we get some other code:

400AC9:  eb 05                   jmp    0x400AD0
400ACB:  31 c0                   xor    eax,eax
400ACD:  74 fa                   je     0x0
400ACF:  e8 0f b6 45 b0          call   0xffffffffb045b61a
400AD4:  3c 38                   cmp    al,0x38
400AD6:  0f                      .byte 0xf

and it looks like you did not get any further, because there are still weird calls and undefined codes. However, look at the first instruction! It jumps again into the middle of something what appears to be an instruction at this point – but if you start disassembling there, you will see that everything from that address on is perfectly ordinary code.*

* Since this is a "crackme" and you already failed the first of its tests, I will not spoil the rest of it.

1

IDA disassembled the instructions incorrectly. You need to manually change the instruction after jz to data and then change the jz destination to code.

  • How will jz come out of the loop? – Holmes.Sherlock Jan 11 '17 at 17:47
  • Change the mov instruction to data and change the data at location 400AC9 to code. That will disassemble into a jump instruction that will jump out of the loop. – yellowbyte Jan 11 '17 at 18:16
0

You should patch the ptrace the program uses to check if it's being traced by a debugger and then use gdb or another debugger to see what's going on @runtime, if you insist on statically analyzing it you'll have to manually fix up the jump as yujyet said.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.