Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Messing with the stack in assembly and c++

Tags:

assembly

hook

I want to do the following:

I have a function that is not mine (it really doesn't matter here but just to say that I don't have control over it) and that I want to patch so that it calls a function of mine, preserving the arguments list (jumping is not an option).

What I'm trying to do is, to put the stack pointer as it was before that function is called and then call mine (like going back and do again the same thing but with a different function). This doesn't work straight because the stack becomes messed up. I believe that when I do the call it replaces the return address. So, I did a step to preserve the return address saving it in a globally variable and it works but this is not ok because I want it to resist to recursitivy and you know what I mean. Anyway, i'm a newbie in assembly so that's why I'm here.

Please, don't tell me about already made software to do this because I want to make things my way.

Of course, this code has to be compiler and optimization independent.

My code (If it is bigger than what is acceptable please tell me how to post it):

// A function that is not mine but to which I have access and want to patch so that it calls a function of mine with its original arguments
void real(int a,int b,int c,int d)
{

}

// A function that I want to be called, receiving the original arguments
void receiver(int a,int b,int c,int d)
{
 printf("Arguments %d %d %d %d\n",a,b,c,d);
}

long helper;

// A patch to apply in the "real" function and on which I will call "receiver" with the same arguments that "real" received.
__declspec( naked ) void patch()
{
 _asm
 {
  // This first two instructions save the return address in a global variable
  // If I don't save and restore, the program won't work correctly.
  // I want to do this without having to use a global variable
  mov eax, [ebp+4]
  mov helper,eax

  push ebp
  mov ebp, esp

  // Make that the stack becomes as it were before the real function was called
  add esp, 8

  // Calls our receiver 
  call receiver

  mov esp, ebp
  pop ebp

  // Restores the return address previously saved
  mov eax, helper
  mov [ebp+4],eax

  ret
 }
}

int _tmain(int argc, _TCHAR* argv[])
{
 FlushInstructionCache(GetCurrentProcess(),&real,5);

 DWORD oldProtection;
 VirtualProtect(&real,5,PAGE_EXECUTE_READWRITE,&oldProtection);

 // Patching the real function to go to my patch
 ((unsigned char*)real)[0] = 0xE9;
 *((long*)((long)(real) + sizeof(unsigned char))) = (char*)patch - (char*)real - 5;

 // calling real function (I'm just calling it with inline assembly because otherwise it seems to works as if it were un patched
 // that is strange but irrelevant for this
 _asm
 {
  push 666
  push 1337
  push 69
  push 100
  call real
  add esp, 16
 }

 return 0;
}

Prints (and has to):

Arguments 100 69 1337 666

Edit:

Code i'm testing following Vlad suggestion (Still not working)

// A patch to apply in the real function and on which I will call receiver with the same arguments that "real" received.
__declspec( naked ) void patch()
{
    _asm
    {
        jmp start

        mem:

        nop
        nop
        nop
        nop

        start :

        // This first two instructions save the return address in a global variable
        // If I don't save and restore the program won't work correctly.
        // I want to do this without having to use a global variable
        mov eax, [ebp+4]
        mov mem, eax

        push ebp
        mov ebp, esp

        // Make that the stack becomes as it were before the real function was called
        add esp, 8

        // Calls our receiver 
        call receiver

        mov esp, ebp
        pop ebp

        // Restores the return address previously saved
        mov eax, mem
        mov [ebp+4],eax

        ret
    }
} 
like image 338
user246100 Avatar asked Apr 12 '10 16:04

user246100


1 Answers

The following code excerpts have been checked with mingw-g++, but should work in VC++ with minor modifications. The full sources are available from Launchpad: 1

The only way we can safely save call-specific data is to store it on the stack. One way is to rotate part of the stack.

patch.s excerpt (patchfun-rollstack):

sub esp, 4          # allocate scratch space

mov eax, DWORD PTR [esp+4]  # first we move down
mov DWORD PTR [esp], eax    # our return pointer

mov eax, DWORD PTR [esp+8]  # then our parameters
mov DWORD PTR [esp+4], eax
mov eax, DWORD PTR [esp+12]
mov DWORD PTR [esp+8], eax
mov eax, DWORD PTR [esp+16]
mov DWORD PTR [esp+12], eax
mov eax, DWORD PTR [esp+20]
mov DWORD PTR [esp+16], eax

mov eax, DWORD PTR [esp]    # save return pointer
mov DWORD PTR [esp+20], eax # behind arguments

add esp, 4          # free scratch space
call    __Z8receiveriiii

mov eax, DWORD PTR [esp+16] # restore return pointer
mov DWORD PTR [esp], eax

ret

We omitted the ebp here. If we add that, we will need to use 8 bytes of scratch space and save and restore the ebp as well as the eip. Note that when we restore the return pointer, we overwrite the a parameter. To avoid that we would need to rotate the stack back again.


The other way is to have the callee know about the extra data on the stack and ignore it.

patch.s (patchfun-ignorepointers):

push    ebp
mov ebp, esp
call    receiver
leave
ret

receiver.cc:

void receiver(const void *epb, const void *eip, int a,int b,int c,int d)
{
 printf("Arguments %d %d %d %d\n",a,b,c,d);
}

Here I included the epb, if you remove it from the asm all that remains is the call and the ret, and receiver would only need to accept and ignore the eip.


Of course, all of this is mostly for fun and curiosity. There really is no major advantage over the simple solution:

void patch(int a,int b,int c,int d)
{
 receiver(a,b,c,d);
}

The generated assembly would be shorter than our stack-roll, but would need 16 bytes more of stack, because the values are copied to a fresh area below the patch() stack frame.

(Actually the gcc-generated asm allocates 28 bytes on the stack even though it uses only 16. I'm not sure why. Maybe the extra 12 bytes are part of some stack-smashing protection scheme.)

like image 51
clacke Avatar answered Oct 20 '22 10:10

clacke