Question on stack frame allocation space

A

asm

Hello all, I need your help on this problem.

I wrote a little program as follows. (BTW, I worked on a new dell
latitude, runing Linux kernel 2.4.19, i686).

Program was compiled with gcc 3.2

void foo() {
char t[20];
strcpy(t, "012345678901234567890123456789012345678");
printf("t is %s\n", t);
}

int main() {
foo();
return 0;
}

Note that I copied 39 characters into the string t, which was defined to
be of 20-byte long. With the '\0' character, t was able to hold 40 bytes
in total. If I just add one more character (so that I'd be copying 41
bytes), I get "invalid instruction error"
I compiled it into assembly code, and the first few lines of 'foo' looks
like this

foo:
pushl %ebp
movl %esp, %ebp
subl $40, %esp

this confirms that the stack frame for "foo" has allocated 40 bytes for
the string t.

I wanted to test the "buffer overflow bug", and tried to overwrite the
returned address of foo, which - as far as I know, should be 48 bytes
from t. However, this does not seem to be the case, as the overwriting
runs fine, and the program returns as if nothing happens.

My questions are:

1. Why allocated 40 bytes on the stack?

2. Is it true the old frame pointer and the return address are right
after those 40 bytes?

Thanks a lot in advance for any hint,
ASM
 
M

Mike Wahler

asm said:
Hello all, I need your help on this problem.

I wrote a little program as follows. (BTW, I worked on a new dell
latitude, runing Linux kernel 2.4.19, i686).

Program was compiled with gcc 3.2

void foo() {
char t[20];
strcpy(t, "012345678901234567890123456789012345678");

Undefined behavior.
printf("t is %s\n", t);
}

More undefined behavior. Invocation of a variadic
function with no prototype in scope.
int main() {
foo();
return 0;
}

Note that I copied 39 characters into the string t,

Twenty characters were copied. Whatever happened after
that is undefined.
which was defined to
be of 20-byte long. With the '\0' character, t was able to hold 40 bytes

The array 't', by definition, can hold a maximum of
twenty characters. The result of your attempt to
copy characters outside the array is undefined.
in total. If I just add one more character (so that I'd be copying 41
bytes), I get "invalid instruction error"

Or you might get a bloody nose. Or a sex change. Or something
else. Or nothing at all. The behavior is undefined.
I compiled it into assembly code, and the first few lines of 'foo' looks
like this
Irrelevant.


foo:
pushl %ebp
movl %esp, %ebp
subl $40, %esp

this confirms that the stack frame for "foo" has allocated 40 bytes for
the string t.

C has no such thing as 'stack frames'.
I wanted to test the "buffer overflow bug",

What you've done is produce undefined behavior. "Testing"
it is meaningless.
and tried to overwrite the
returned address of foo, which - as far as I know, should be 48 bytes
from t.

No you don't know that, nor can you know anything else
about the program, since it produces undefined behavior.
However, this does not seem to be the case, as the overwriting
runs fine, and the program returns as if nothing happens.

The set of possible manifestations of undefined behavior
includes the appearance of normalcy.
My questions are:

1. Why allocated 40 bytes on the stack?

Because it rained in Milwaukee last Thursday.
2. Is it true the old frame pointer and the return address are right
after those 40 bytes?

Yes. No. Maybe. C knows nothing of 'frame pointers'.

Thanks a lot in advance for any hint,

Hint: Don't Do That.

-Mike
 
C

CBFalconer

asm said:
.... snip ...

My questions are:

1. Why allocated 40 bytes on the stack?

2. Is it true the old frame pointer and the return address are
right after those 40 bytes?

You are OT for c.l.c, which worries about the language, not the
particular implementation. In this case you should see the
appropriate gnu newsgroup, possibly one on gcc.
 
M

Michael Str.

asm said:
Hello all, I need your help on this problem.

I wrote a little program as follows. (BTW, I worked on a new dell
latitude, runing Linux kernel 2.4.19, i686).

Program was compiled with gcc 3.2

void foo() {
char t[20];
strcpy(t, "012345678901234567890123456789012345678");
printf("t is %s\n", t);
}

int main() {
foo();
return 0;
}

Note that I copied 39 characters into the string t, which was defined to
be of 20-byte long. With the '\0' character, t was able to hold 40 bytes
in total. If I just add one more character (so that I'd be copying 41
bytes), I get "invalid instruction error"
I compiled it into assembly code, and the first few lines of 'foo' looks
like this

foo:
pushl %ebp
movl %esp, %ebp
subl $40, %esp

this confirms that the stack frame for "foo" has allocated 40 bytes for
the string t.

I wanted to test the "buffer overflow bug", and tried to overwrite the
returned address of foo, which - as far as I know, should be 48 bytes
from t. However, this does not seem to be the case, as the overwriting
runs fine, and the program returns as if nothing happens.

My questions are:

1. Why allocated 40 bytes on the stack?

2. Is it true the old frame pointer and the return address are right
after those 40 bytes?

Thanks a lot in advance for any hint,
ASM


Hi !

First, allocated space always will be more than 20 bytes, because it
used not only for local variables. It used for save registers, return
address from subroutine, address of previous stack frame etc, depends
of your platform.
See "C function calling conventions" for your compiler.

Accidentally, it takes the same length ( 40 bytes ).

Second, if it is noly one place of allocation code in your function (
that you provide in assembler ), it should be stack space for all,
include frame pointer and return address and saving registers etc.

Regards
Michael
 

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

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top