Cannot execute shellcode using buffer overflow

Question

As a home exercise I'm trying to achieve buffer overflow attack by running a simple char array program that stores the input argument in the program stack and then overflowing that stack with long enough input so that EIP gets overwritten with one of the NOP instructions and then it would slide to the shellcode and execute it.

I'm currently running Ubuntu 16.04 32-bit in Virtualbox, with kernel ASLR set to disabled.

My C code:

#include <stdio.h> #include <string.h> int main(int argc, char **argv) { char buffer[500]; strcpy(buffer, argv[1]); printf("%s\n", buffer); return 0; } 

I compiled the code with options: -z execstack -fno-stack-protector

When I'm trying to execute the code in gdb using some bash code to generate the input, I manage to change the register value to the one containing the NOPs but the code just throws segmentation fault and I am unable to execute the shellcode.

I started with 504 byte input, 476 NOPs + 24 shellcode + 4x 0x45 bytes.

I was able to find my input in the memory. I took the address somewhere between the NOPs (0xbfffed60).

To overwrite the ESP register, I grew the total input length to 508 bytes, which consisted of: 476 NOPs + 24 shellcode + 2x memory address (0xbfffed60, with bytes in inverted order \x60\xed\xff\xbf).

When I run the code with that input, I'm just receiving segmentation fault and not getting the shellcode to execute.

It seems to go in the exact spot where I'm telling it to go but it does not execute the NOPs nor the shellcode.

Answer 1

The EIP is pointing to the address 0x90909090, which is an invalid memory address. Essentially, your raw data (NOPs) are being interpreted as an address that points to the next instructions to execute. You need to fill EIP with the address of your NOPs.

If you find out exactly which four NOPs are ending up in the EIP, then you can place the address of your shellcode at that location.

Next steps: Try finding out exactly what the offset is that ends up controlling EIP. The pattern create tool from peda (https://github.com/longld/peda) can help here. Insert the pattern (of length 476) in your payload instead of the NOPS, and see what address ends up in EIP. Then use pattern search to find out what offset that is.