Vulnerability Development mailing list archives

Re: Studying buffer overflows [maybe OT]


From: Syzop <syz () dds nl>
Date: Tue, 09 Apr 2002 16:27:22 +0200

*bored*...

$ gdb ./bla
GNU gdb 4.17.m68k.objc.threads.hwwp.fpu.gnat
[..]
(gdb) break bla.c:3
Breakpoint 1 at 0x8048446: file bla.c, line 3.
(gdb) run
Starting program: /delta/tmp/blah/./bla

Breakpoint 1, f () at bla.c:4
4               b =  a + 0x8;
(gdb) bt
#0  f () at bla.c:4
#1  0x8048472 in main () at bla.c:11
#2  0x4003a65f in   ()
(gdb) info frame 0
Stack frame at 0xbffffbbc:
 eip = 0x8048446 in f (bla.c:4); saved eip 0x8048472
[..]
Saved registers:
  ebp at 0xbffffbbc, eip at 0xbffffbc0
(gdb) s
5               (*b) += 0x8;
(gdb) x/x b
0xbffffbc0:     0x08048472
[ok, looks like you are at the right place (saved ip at 0xbffffbc0)]
(gdb) s
6       }
(gdb) x/x b
0xbffffbc0:     0x0804847a
[ok, it's modified, but were are we jumping to?]
(gdb) disassemble main
Dump of assembler code for function main:
0x8048460 <main>:       pushl  %ebp
0x8048461 <main+1>:     movl   %esp,%ebp
0x8048463 <main+3>:     subl   $0x18,%esp
0x8048466 <main+6>:     movl   $0x0,0xfffffffc(%ebp)
0x804846d <main+13>:    call   0x8048440 <f>  <-- your function
0x8048472 <main+18>:    movl   $0x1,0xfffffffc(%ebp) <-- x =1
0x8048479 <main+25>:    addl   $0xfffffff8,%esp <-- printf() stuff starts here
0x804847c <main+28>:    movl   0xfffffffc(%ebp),%eax
0x804847f <main+31>:    pushl  %eax
0x8048480 <main+32>:    pushl  $0x80484e4
0x8048485 <main+37>:    call   0x8048344 <printf>
0x804848a <main+42>:    addl   $0x10,%esp
0x804848d <main+45>:    leave
0x804848e <main+46>:    ret
End of assembler dump.
(gdb)
[ So instead of returning to 0x8048472 you want to return
   to 0x8048479, that's +0x7 instead of +0x8]
--
test:
$ ./bla
0

Btw if you use optimization (-O, -O2, etc) you'll get wrong results
because compilers are (trying to be) smart :).

Cya,

    Syzop.

darko wrote:

I want, after the call to f(), the program jump to printf() so the value of x
should remain 0, not 1. I always get segmentation faults, bus errors, etc.
and never that fuc*ing "x = 0" !!
Tested on a Celeron 433, red hat 7.2, gcc 2.96.


Current thread: