why dosent buffer gets overflowed

R

raashid bhatt

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

void func(char *p)
{
char i[5];
strcpy(i, p);
}

int main(int argc, char **argv)
{

func("AAAAAAAAAA"); // i have supplied 2 X 5 char to it
system("pause");
return 0;
}
 
R

raashid bhatt

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"

What makes you think the buffer isn't being overflowed?
int main(int argc, char **argv)
{
func("AAAAAAAAAA"); // i have supplied 2 X 5 char to it

Then you're trying to store more data in the array than it has room for,
and you don't provide any safeguards against that, so you're overflowing
that buffer, and the result is that the program exhibits undefined
behaviour - i.e. the rules of C don't tell you what will happen.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

i am using a debugger to track EIP but its this program exits nornally
 
J

Jens Thoms Toerring

raashid bhatt said:
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"

What makes you think the buffer isn't being overflowed?
int main(int argc, char **argv)
{
func("AAAAAAAAAA"); // i have supplied 2 X 5 char to it

You actually supply 11 characters here, don't forget about the
trailing '\0' character!
i am using a debugger to track EIP but its this program exits nornally

Looks as if you have read that using a buffer overrun it's possible
to change the flow of control of a program. But it's luckily not
that simple - you need to understand rather well how things work on
a certain architecture to write a program that exploits a buffer
overrun to achieve that effect (if it's possible at all and which
then only works on the target architecture). In general you can't
predict what happens as the result of a buffer overrun, at least
as far as guarantees go the C language make, it's just undefined
behaviour as Richard pointed out, so it would also be an allowed
result that running the program sets your computer on fire.

Just for fun try to replace your function func() with this:

void func( char *p )
{
int i = 0;
char i[ 5 ];
int j = 0;

printf( "Before strcpy(): i = %d, j = %d\n", i, j )
strcpy( i, p );
printf( "After strcpy(): i = %d, j = %d\n", i, j )
}

It may or may not print out different values for i or j. But if
it does that doesn't mean that it will do the same on a different
machine.
Regards, Jens
 
J

James Kuyper

raashid said:
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"

What makes you think the buffer isn't being overflowed?
....
i am using a debugger to track EIP but its this program exits nornally

So, why does that make you think that the buffer isn't being overflowed?
 
R

raashid bhatt

raashid said:
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"
What makes you think the buffer isn't being overflowed?
...
i am using a debugger to track EIP but its this program exits nornally

So, why does that make you think that the buffer isn't being overflowed?

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
 
B

Bartc

raashid said:
raashid said:
On Aug 21, 10:45 pm, Richard Heathfield <[email protected]>
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"
What makes you think the buffer isn't being overflowed? ...
i am using a debugger to track EIP but its this program exits
nornally

So, why does that make you think that the buffer isn't being
overflowed?

i mean if buffer gets overflowed then EIP should contains my A's and

EIP is a register, it's unlikely to be full of As (or 0x41s).
as per as definition of EIP (pointer to code) which contains A's
should cause the program to crash

Since you have a debugger you might like to investigate exactly where those
extra 5 As end up, if anywhere, and what that memory would otherwise have
been used for. Then you can find out why your program doesn't crash.
 
R

Richard Tobin

raashid bhatt said:
i mean if buffer gets overflowed then EIP should contains my A's

Why do you think that? When the buffer overflows, the characters
will go into whatever happens to follow the buffer. That may not be
anything important.

-- Richard
 
V

vippstar

Why do you think that? When the buffer overflows, the characters
will go into whatever happens to follow the buffer. That may not be
anything important.

They don't need to. When the buffer "overflows", what really happends
is that undefined behavior is invoked. Once that happends, that's it.
You can't predict the behavior.
 
K

Kenny McCormack

They don't need to. When the buffer "overflows", what really happends
is that undefined behavior is invoked. Once that happends, that's it.
You can't predict the behavior.

While this is true in the totally artificial CLC/C-Standard sense, it is
not true in the real world.

HTH - no thanks necessary for this obvious correction to your otherwise
stirling post.
 
R

Richard Tobin

Why do you think that? When the buffer overflows, the characters
will go into whatever happens to follow the buffer. That may not be
anything important.
[/QUOTE]
They don't need to. When the buffer "overflows", what really happends
is that undefined behavior is invoked. Once that happends, that's it.

Child: [tries to stick his finger in an electric socket]
Parent: Don't do that, it violates safety regulation EIC/3/981b.
Onlooker: The electricity might kill you. Even if it doesn't
this time, it might next time.
Parent: That's not required. What really happens is that you
violate safety regulation EIC/3/981b.

-- Richard
 
C

cr88192

raashid said:
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"

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...
 
C

cr88192

William Pursell said:
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...

 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top