1

Firstly I'd like to say that I've looked online and have yet to find anything of value. I have here a very VERY simple, standard BOF file to attack. I've compiled it in 64 bit mode:

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

int main(int argc, char **argv)
{
    if(argc!=2) return 1;
    char buffer[500];
    strcpy(buffer, *(argv+1));  //vulnerable function
    return 0;
}

Compiled with:

gcc -fno-stack-protector -ggdb -z execstack -o output vulnerable.c

Now, overflowing if I'd have added -m32 is very easy and I'm very used to it. However, overwriting the RIP does not seem to be possible.

gdb -q output


Reading symbols from /Files/ASM/a.out...done.
(gdb) run $(python -c 'print "A"*100')
Starting program: /Files/ASM/a.out $(python -c 'print "A"*100')
You said:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Program received signal SIGSEGV, Segmentation fault.
0x000000000040059e in main (argc=2, argv=0x7fffffffe658) at vuln.c:10
10  }
(gdb) 

Register values:

(gdb) info reg
rax            0x0  0
rbx            0x0  0
rcx            0x400659 4195929
rdx            0x7ffff7dd8e10   140737351880208
rsi            0x7ffff7ff8000   140737354104832
rdi            0x0  0
rbp            0x4141414141414141   0x4141414141414141
rsp            0x7fffffffe578   0x7fffffffe578
r8             0x1  1
r9             0x4141414141414141   4702111234474983745
r10            0x0  0
r11            0x7ffff7acea40   140737348692544
r12            0x400440 4195392
r13            0x7fffffffe650   140737488348752
r14            0x0  0
r15            0x0  0
rip            0x40059e 0x40059e <main+82>
eflags         0x10206  [ PF IF RF ]
cs             0x33 51
ss             0x2b 43
ds             0x0  0
es             0x0  0
---Type <return> to continue, or q <return> to quit---
fs             0x0  0
gs             0x0  0
(gdb)

There seems to be almost NO documentation online from which I can learn BOFing a 64 bit application.

Upon setting a breakpoint directly after strcpy function, I find that the end of the parameter is in the RCX register.

Goodies
  • 4,439
  • 3
  • 31
  • 57

0 Answers0