Re: N00b questions :\

[Diode Trnasistor <ffddfe () yahoo com>]

Thanx for responses, it's slightly clearer now.  A few
more clarifications:

Memory alignment is clear, but word aligned this
number should be 20 (5 byte buffer gets padded to 8
and 12 stays at 12).  I write this off to gcc behaving
erratically.

The enormous number being "added" to the stack makes
sense if interpreted as two's compliment, question is,
how did you know to interpret it as two's compliment
:]

And finally, strcpy  causing a segfault at seemingly
unrelated adress is still not clear to me.  The given
explonation was that i indeed do overwrite the saved
EIP on the stack, but due to return never being
called, process never jumps to that adress.  Now
correct me if i'm wrong but here's how i imagine the
memory layout of vulndev2.c

stack top [buff][base pointer][saved eip] stack bottom

So now we call strcpy, strcpy writes way past buff,
overwriting the bp, and eip.  Then strcpy called
return and that works fine since strcpy's stack frame
is closer to the stack top than the buff, and the mess
we made.  Then execution keeps going untill the
function main calls return (i modified vulndev2.c to
call return instead of exit).  Now when this return is
called, what i think should happen, is the piece of
memory i labeled saved eip should get poped into eip
register, and voila, the process should try to execute
instructions at adress 0x41414141 causing a
segmentation fault. Instead, i get this:
0x40085013 in _IO_getline_info () from /lib/libc.so.6

and i'm confused.  Halp.

ps: someone else suggested that grsecurity patch may
be applied to my kernel.  It indeed is not, i am
running standard-run of the mill-off the
shelf-vanilla-kernel.org supplied 2.4.20 unmodified
linux kernel.  Any pointers would be most helpfull. 
Also if anyone else is getting the same results, or
even different results, do let me know.  Thanx.


--- northern snowfall <dbailey27 () ameritech net> wrote:
> > 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.
> FYI, compilers (are supposed to) align memory to the
> requirement of the
> underlying architecture. Most processors will throw
> an alignment_error
> exception if an opcode attempts to pass an unaligned
> address to it.
> This is done simply by padding the stack so that
> each auto variable is
> given a properly aligned memory address.
> Don
> http://deadchildren.org/~north_

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com