1

After I reference this website, I want to simulate a simple buffer overflow bug
My environment is ubuntu 10.10
gcc version is 4.4.5
I also download the execstack to enable the executable stack of my file.
the following is my code

char code[] = "\x90\x90\x90\x6a\x00\xe8\x39\x07\x00\x00\x90\x90\x90";<
char msg[] = "run !!\n";
int main()
{     
     int *ptr;     
     int i;  
     for(i=1;i<128;i++){     
          ptr = (int *)&ptr + i;
          (*ptr) = (int)code;   
     }    

     return 0;
}

I use gcc -fno-stack-protector -g -static -o main.out main.c to compile my source code.
However when I use gdb to debug this executable file,
something weird happened.
here is the gdb output looks like:

(gdb) x/i 0x8048492
   0x8048492 <__libc_start_main+402>:   call   0x8048bd0 <exit>
(gdb) x/5b 0x8048492
0x8048492 <__libc_start_main+402>:  0xe8    0x39    0x07    0x00    0x00
(gdb) x/i 0x80ce02e
   0x80ce02e <code+6>:  call   0x80ce76c <_dlfcn_hooks+44>
(gdb) x/5b 0x80ce02e
0x80ce02e <code+6>: 0xe8    0x39    0x07    0x00    0x00

It seems like the the pattern of these two address are the same, but the instructions are different.
can somebody help me and explain why this happen.
thanks a lot!

1
  • But if the five raw bytes is the same, why the instruction is different. one is "call 0x8048bd0" and another is "call 0x80ce76c" but the raw bytes is \xe8\x39\x07\x00\x00
    – mike820324
    Commented May 1, 2011 at 19:44

1 Answer 1

2

You have a buffer overflow for sure, but this line

 (*ptr) = (int)code;

stores the address of code in each location, not the content of the code array.

3
  • tks for reply. I know I have a buffer overflow bug. I change the return address of the main function, so when main function is ended, the eip will point to the data section and execute the shellcode which is simply an exit call. What I don't understand is that why the raw bytes of the two address is the same, but the instruction of the two address is different.
    – mike820324
    Commented May 1, 2011 at 19:46
  • 1
    The code E8 is a CALL with a relative offset, meaning that the following bytes give the distance to the target, not an absolute address. If used in different places it will give different results.
    – Bo Persson
    Commented May 1, 2011 at 20:09
  • OH!! that solves the problem. Tks a lot. So, the gcc will use a relative offset call instead of a absolute address. Thank u very much.
    – mike820324
    Commented May 1, 2011 at 21:03

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.