Re: N00b questions :\

["Janus N." Tøndering <janus () bananus dk>]

On Sun, 2003-05-25 at 01:52, Diode Trnasistor wrote:
> Playing with these challenges (and thanx so much for
> posting these) i came across some things which aren't
> so clear and i'm hoping someone can explain them to
> me.
>
>
> I wrote a simple program i was hoping will demonstrate
> the standard stack based overflow for me.  It looks
> like this:
>
> void main() {
>     char buffer[12];
>     char longbuffer[30];
>     int i;
>
>     memset(longbuffer, 'A', 30);
>     longbuffer[29] = 0;
>
>     strcpy(buffer, longbuffer);
> }
>
> After compilation, inside gdb, disassemble main i get
> this:
> 0x8048440 <main>:       push   %ebp
> 0x8048441 <main+1>:     mov    %esp,%ebp
> 0x8048443 <main+3>:     sub    $0x38,%esp
> 0x8048446 <main+6>:     add    $0xfffffffc,%esp
> ...etc etc.
>
> Now up untill main+3 it makes sense.  Why is this
> enormous number being added to stack pointer is beyond
> me.  Shouldn't this completelly ruin the stack? 
> Doesn't the stack start at the highest adress and grow
> down?  WTF?
0xfffffffc should be interpreted using 2's complement. So this
is actually a negative number (-4).

> Moving on i write another sample program:
> void function(int i, int b, int c) {
>     char buffer[12];
>     char buffer2[5];
>
>     return;
> }
>
> int main(void) {
>     function(1, 2, 3);
>     return 0;
> }
>
> disassemble function with gdb yields:
> 0x80483d0 <function>:   push   %ebp
> 0x80483d1 <function+1>: mov    %esp,%ebp
> 0x80483d3 <function+3>: sub    $0x28,%esp
> ...etc etc
> WTF?!  ok so it sets up a new stack frame and then
> makes room for the local auto variables.  Now i'm not
> very good at math but last i checked 12 + 8 made 20. 
> Not 40.  Again, WTF?  Is gentoo using unicode or
> something crazy like that?  God i cry...
GCC sometimes allocates more memory for each variable on the stack than
is actually requested. I have no idea exactly why and what is does --
but I assume it is some small optimization.

> Moving on, i try to abuse the obvious strcpy in
> vulndev2.c, so i run it with obvious 
> (gdb) run `perl -e 'print "A"x200'` two
>
> And what happens?  Segmentation fault 0x41414141 in
> strcpy?  Hell no!  I get a completelly baffling:
> Segmentation fault.
> 0x40085013 in _IO_getline_info () from /lib/libc.so.6
>
> 0x40085013?  _IO_getline_info?  Where did that come
> from? Looking at begining of vulndev2.c..
>
> main(int argc, char *argv[])
> {
>         char    *bfp;
>         char    buf[BFSIZE];
>         FILE    *f1;
>
> I'd assume that buf was on the stack.  Why doesn't
> writing WAY past the end of this buffer cause a jump
> to 41414141?  I am SO confused HALP!
You do actually overwrite the return address but the return address 
will only be jumped to by a call to return. exit does _not_ use the
return address.

Hope this helps a little.

Janus N. Tøndering