Dealing with obfuscated PUSH PUSH RET instructions

Question

I wanted to run an app on a VM but there are PUSH PUSH RETs stopping me from looking at their anti VM code. There is a messagebox when I run it on a VM. I set a breakpoint at MessageBoxA and it gets triggered as well as EAX is showing the message for the VM. It's all good until now.

I'm using x64dbg and I opened Call Stack tab and double-clicked on the address after user32.MessageBoxA (basically 2nd record), so I could trace back the calls before the actual MessageBoxA. It landed me here:

I heard that PUSH RET is like a jmp, PUSH PUSH RET is like a call. How do they work? Can they be deobfuscated with a tool/plugin or something?

PUSH 0xC9DFBF leads me here:

PUSH 0xA4DB49 leads me here:

When I follow that jmp, it leads to similar code to PUSH 0xC9DFBF's image which ends with a jmp to MessageBoxA.

What could you recommend me to step into the code before the actual MessageBoxA call, so I can find their anti VM code and patch it? Do I need to step the instructions from the beginning one by one?

Dumps: http://ufile.io/56c5b2z6. Rebase to 0x1270000 and find 0181E65C address. This address is in the executable file. I attached two dumped DLLs as well, because they were referenced.

Answer 1

Technically,

PUSH A
RET

is equivalent to

JMP A

and

PUSH A
PUSH B
RET

is equivalent to

CALL B
JMP A

You can write a x64dbg script which searches for the above pattern and replaces it with the simplified assembly.

---

Example

PUSH + RET has the byte pattern

0:  68 44 33 22 11          push   0x11223344
5:  c3                      ret 

The following script replaces it with JMP and the remainder (if any) with NOP.

$base = 0x91e000
$search_size = 0x100

findall $base, "68 ?? ?? ?? ?? c3", $search_size
$count = $result

next:
    dec $count
    $addr = ref.addr($count)
    $jmp_addr = dis.imm($addr)
    asm $addr, "jmp 0x{$jmp_addr}"
    $asm_size = $result
    $remainder = 6 - $asm_size

    fill_nop:
        dec $remainder
        asm $addr+$asm_size+$remainder, "nop"
        test $remainder, $remainder
        jnz fill_nop

    test $count, $count
    jnz next

msg "Done"

Similarly for PUSH + PUSH + RET,

0:  68 44 33 22 11          push   0x11223344
5:  68 dd cc bb aa          push   0xaabbccdd
a:  c3                      ret 

The following script replaces it with CALL + JMP.

$base = 0x91e000
$search_size = 0x100

findall $base, "68 ?? ?? ?? ?? 68 ?? ?? ?? ?? c3", $search_size
$count = $result

next:
    dec $count
    $addr = ref.addr($count)
    $ret_addr = dis.imm($addr)
    $call_addr = dis.imm($addr+5)
    asm $addr, "call 0x{$call_addr}"
    $asm_size = $result
    asm $addr+$asm_size, "jmp 0x{$ret_addr}"
    add $asm_size, $result
    $remainder = 0xb - $asm_size

    fill_nop:
        dec $remainder
        asm $addr+$asm_size+$remainder, "nop"
        test $remainder, $remainder
        jnz fill_nop

    test $count, $count
    jnz next

msg "Done"

---

However there are some caveats with the above approach:

1. PUSH + PUSH + RET can be converted to CALL + JMP only if the callee uses RET instruction to return back to the caller (which is normal in cdecl). It won't work if it obfuscates the return using a JMP instruction. That is instead of RET there is

   ADD ESP, 4
   JMP DWORD PTR [ESP-4]
   

2. Pattern search will work in most cases. However if parts of the code are encrypted it can return false positives and you may be inadvertently overwriting wrong data.

Answer 2

The RET instruction transfers control to the return address located on the stack. Normally this is used to go back from a function to where the function was called, as the address of the next instruction was pushed into the stack by the CALL instruction.

However, RET can be misused: a PUSH before a RET instruction is a typical obfuscation technique. In this case, when executing the RET, instead of coming back to the caller function, it behaves like a jump to the previously pushed address. This is not something your decompiler expects, which may result in a jump to a memory zone that hasn't been decompiled or has been incorrectly decompiled.

PUSH PUSH RET can be used to implement a CALL as you mention. In that case, the first PUSH pushes the return address into the stack (the one after the RET). The second PUSH pushes the function address. The RET (as explained before) jumps to the function address (and removes this address from the stack). When the function address executes its RET, it jumps back to the address currently located on the stack (the one of the first PUSH), coming back to the caller of the function. Note though that this is not your case. In your case the first address pushed is not in the current function. This means that this is not implementing a CALL. Most likely this it is used as an obfuscation technique, making more complicated to follow the calls and maybe tricking your disassembly to show you the code incorrectly.

Also, note that executing a PUSH doesn't lead you anywhere. It just pushes the address into the stack. It is the RET instruction which actually jumps to the last pushed address. This also means that the second pushed address is visited before the first one. This means that the code you are looking for is reached from A4DB49 (the first address to which RET jumps) that is another JUMP.

I recommend you to check the Anti-Disassembly chapter of the Practical Malware Analysis Book, where this kind of techniques are covered in detail and with examples.