After a CALL instruction, jumping to RETN

Question

I'm trying to analyze a piece of code, I'm confused about the following line:

CALL  fct.00402589

Then after that, I come across a block beginning with RETN.(See below)
Here are a couple of lines of that code-block:

RETN
NOP
PUSH EBP
MOV EBP,ESP
LEA ESP, DWORD PTR SS:[ESP-0X2D0]
PUSH ESP
CALL ntdll.RtCaptureContext
......
......
INT 3 
NOP

So as I said, after the call I am in the line RETN. But when I want to go further(click on the "step over"-button of ollydbg) then it jumps back to the next line after the call-instruction. In the line before the last instruction "NOP", there is the instruction INT 3.

I have figured out that in some cases, especially as anti-debugging technique, the program inserts the opcode 0xCC of INT 3 to confuse the debugger. The debugger thinks that it is a breakpoint because normally, the debugger uses OxCC to set breakpoints.

So, I change the debugging options of ollydbg (Options -> Debugging Options -> Exceptions and then click the INT 3 breaks-Box). From now on, the debugger does not trap the exception, it passes the exception to the program.

When I start the program again, and come to the call-instruction, then the following appears(again i copy some lines):

JMP DWORD PTR DS: [<%crtdll._GetMainArgs>] 
NOP
NOP
ADD BYTE PTR DS:[EAX], AL
ADD BYTE PTR DS:[EAX], AL
JMP DWORD PTR DS: [<%crtdll._strcmpi>]
NOP
NOP
ADD BYTE PTR DS:[EAX], AL
ADD BYTE PTR DS:[EAX], AL
JMP DWORD PTR DS: [<%crtdll._atoi>]
NOP
NOP
ADD BYTE PTR DS:[EAX], AL
ADD BYTE PTR DS:[EAX], AL
JMP DWORD PTR DS: [<%crtdll._exit>]
NOP
NOP
ADD BYTE PTR DS:[EAX], AL
ADD BYTE PTR DS:[EAX], AL
JMP DWORD PTR DS: [<%crtdll._memcpy>]
NOP
NOP
----

And so on, has anyone a clue? Or can someone explain me what is going on here?

Answer 1

The int3 that you see in your disassembly exists for the purposes of debugging, because it is hit when there is a bug in the executing code. It is intended to transfer control to a debugger in order to present the user (i.e. developer) with a more meaningful information about the location and possibly the cause of the problem. In the absence of a debugger, it will force termination of the program to occur, which is the safest possible action. For example, in the case of heap corruption, continued execution could result in exploitation and execution of arbitrary code.

There are other reasons for int3 instructions to appear - they can be unused padding between routines, particular for hot-patch-aware functions, among other things. The presence of int3 is not always an indication of anti-debugging techniques. In fact, it could be said that it is more likely to be not an anti-debugging technique at all.

edit: after your comment clarified your question a bit better - what you're asking about is not a jump to a return, but a jump to a routine that returns. That's quite different.

So, a call to a routine leaves the return address on the stack. That return address is the line immediately after the call instruction. When a routine executes the ret instruction, the code resumes after the call. The jump instruction is merely a transfer of control to a routine which will return, allowing the code to continue executing.

A transfer of control to an exit() routine, irrespective of the name, does what it suggests: it causes the process to terminate. If you are tracing through code and you hit that, then the process is done. If you think that it should do more, then you need to watch the code that executed prior to that transfer of control. Perhaps the program expects particular command-line options to be set, in order to do any work.