«

"raashid bhatt" <> wrote in message
news:df3ca2a0-4ad4-4e5e-84d4-...
On Aug 22, 3:31 am, James Kuyper <jameskuy...@verizon.net> wrote:
> raashid bhatt wrote:
> > On Aug 21, 10:45 pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> raashid bhatt said:
>
> >>> #include <stdio.h>
> >>> #include <string.h>
> >>> #include <stdlib.h>
> >>> void func(char *p)
> >>> {
> >>> char i[5];
> >>> strcpy(i, p);
> >> Subject line: "why dosent buffer gets overflowed"
>

<snip>

> i mean if buffer gets overflowed then EIP should contains my A's and
> as per as definition of EIP (pointer to code) which contains A's
> should cause the program to crash

however...

you need to keep track of the memory layout as well, and although on x86
(implied by reference to EIP) the buffer may overflow and thrash the return
address, one needs to take into account certain things, like exactly how
much is on the stack, how the compiler has organized it, ...

now, as it so happens, you may well have only partially overwritten EBP
here, which will not change the return address, but it may (depending on
compiler and settings) crash if you try to use local variables...


of course, since these kinds of things usually have nefarious uses, I will
refrain from describing the details too much further...

"William Pursell" <> wrote in message
news:f3d2a2a7-3c60-48c4-9e9c-...
>
> I think we've had this discussion enough on
> other threads, but gets() is always a potential
> source of buffer overflow.
>

or, alternatively:
"I wants it bigger buffer";
"why I take this it not gets bigger";
he takes more, and then overflows just prior to crashing...


> --
> William Pursell