CODEWITHSUNDEEP
csecurityassemblystackbuffer-overflow
Mostafa Saeed
Mostafa Saeed

Reputation: 21

x86 assembly function stack

i am honing my assembly for buffer overflow exploitation.

Machine specs : kali linux 32 bit running in virtual box.

i am running this code 

#include <stdio.h>

getinput(){

  char buffer[8]; //allocating 8 bytes
  gets(buffer); //read input
  puts(buffer); // print;

}

main() {

  getInput();
  return 0 ;
}

My understaning is that when the function getInput() is invoked the following happens :

1 - the address of the next instruction in main is pushed on the stack. 2 - ebp register is pushed on the stack. 3 - 8 bytes are allocated on the stack for the buffer.

That a total of 16 bytes.. but

As you can see in the image , just before reading the input in the getInput() function it shows a total of 24 bytes of the stack. specifically, i don't know why there is an extra 0x0000000 on the top of the stack

moreover, when i try to over-write the return address by inputing something like (ABCDABCDABCDABCD[desired address for target program]) it justs over-writes everything.

And if i try to input something like \xab\xab\xab\xab it gives a segementation fault , although this is only 4 bytes and should fit perfectly into the 8 bytes buffer.

Thank you in advance.

Upvotes: 0

Views: 145

Answers (2)

Seva Alekseyev
Seva Alekseyev

Reputation: 61331

In real life buffer overflow attacks, you never know the size of the stack frame. If you discover a buffer overflow bug, it's up to you to determine the offset from the buffer start to the return address. Treat your toy example exactly like that.

That said, the structure of the stack frame can be driven by numerous considerations. The calling convention might call for specific stack alignment. The compiler might create invisible variables for its own internal bookkeeping, which may vary depending on compiler flags, such as the level of optimization. There might be some space for saved caller registers, the number of which is driven by the register usage of the function itself. There might even be a guard variable specifically to detect buffer overflows. In general, you can't deduce the stack frame structure from the source alone. Unless you wrote the compiler, that is.

Upvotes: 2

Mostafa Saeed
Mostafa Saeed

Reputation: 21

After diassembling the getInput routin , it turned out that the extra 4 bytes came from the compiler pushing $ebx on the stack for some reason.

After testing with various payloads , it appeared that i was not considering the deceptive null byte that is added at the end of the string. so i only need to add one extra byte to mitigate the effect of the null byte.

The proper payload was : printf "AAAAAAAAAAAAA\xc9\x61\x55\x56" | ./test

Upvotes: 0

Related Questions