Abusing the Return Pointer

Created the Monday 18 March 2019. Updated 1 year, 2 months ago.

Abusing the return pointer is an anti-disassembling technique that involves using the return instruction (RETN) in a way that is not expected by the disassembler. This can make it more difficult for the disassembler to accurately reconstruct the program's original instructions and can also make it more difficult for analysts to understand the program's behavior.

The RETN instruction is normally used to return from a function call, by returning control to the calling function. It typically takes a single operand, which is the number of bytes that the caller should add to the stack pointer after the return has been executed. This allows the caller to clean up the stack and restore the registers to their original values before the call was made.

However, if the RETN instruction is used for another purpose, the disassembler may not be able to accurately interpret it and may generate incorrect disassembly output. For example, the RETN instruction could be used as a jump target for other instructions, such as a CALL or JMP instruction. This would cause the disassembler to prematurely terminate the function, because it would assume that the RETN instruction marks the end of the function.

Technique Identifier

U0213

Technique Tags

Abusing the return pointer Anti-disassembling Disassembler Debugger Control flow Return instruction (RETN) Function call Stack pointer Register

Code Snippets

Description

1) The code starts with a normal function call to establish legitimacy

2) Then it abuses the return pointer by:

Pushing a calculated address into the middle of function2
Using RET to jump there instead of actually returning

3) This tricks disassemblers because:

They expect RET to mark the end of a function
They can't easily track the dynamic control flow
They may miss the code after the jump target

Analysis Impact:

Static analysis tools will likely show incorrect control flow
Disassemblers may miss chunks of code entirely
Function boundaries become unclear
Makes it harder to understand the actual execution path

.386
.model flat, stdcall
.code

start:
    ; Legitimate looking function call to establish normal pattern
    call normal_function    
    
    ; Here's where we start the anti-disassembly technique
    push offset hidden_function + 5  ; Push address into middle of function
    ret                             ; Jump to that address instead of returning
                                   ; Most disassemblers will think code ends here
    
    ; Decoy instructions that may confuse analysis
    mov eax, 0
    jmp $
    
normal_function:
    push ebp
    mov ebp, esp
    
    ; Normal looking code to appear legitimate
    xor eax, eax
    inc eax
    
    pop ebp
    ret
    
hidden_function:
    ; First few bytes might never be executed
    push ebp
    mov ebp, esp
    
    ; This is where execution actually continues
    ; Disassemblers may miss this entirely
    mov ebx, 0DEADBEEFh    ; Hidden payload
    xor ecx, ecx
    add edx, ebx
    
    ; More anti-analysis tricks
    call $+5               ; Push next instruction address
    pop eax               ; Get that address in eax
    add eax, 10          ; Calculate next real instruction
    push eax
    ret                  ; Another obfuscated jump
    
    ; Hidden code continues...
    mov eax, 1
    pop ebp
    ret

end start

About Author Open Snippet

Author: 0x_ror / Target Platform: Windows

Additional Resources

External Links

The resources provided below are associated links that will give you even more detailed information and research on current evasion technique. It is important to note that, while these resources may be helpful, it is important to exercise caution when following external links. As always, be careful when clicking on links from unknown sources, as they may lead to malicious content.

https://www.malwinator.com/2015/11/27/anti-disassembly-techniques-used-by-malware-a-primer-part-2/