Playing with stack

[Tubee]

I was doing some testing with stack, and noticed that I can't change the return address of the main()-function. Why it's not working? Isn't the return address supposed to be in the stack? I managed to change the return address in one of my functions but not in main... Seems like it doesn't have return address or I can't get to it. Does anyone know what is the problem? Some of my code:

#include <stdio.h>
int main()
{
        char c[4];
        gets(c);
        return 0;
}

If I give random input, return address doesn't change(debugged with gdb), but if I put those instructions to a function, it changes the return address? Anyone have any information about stack when main() is called? Platform is Linux, compiler gcc. Appreciate your help!

[matsp]

And what processor, is it an x86 or say arm? x86 has the return address on the stack, that's for sure. If it's some other processor, it may not have the actual return address on the stack - a typical example would be ARM that has a register (LR aka R14 I think) to hold the return address. LR is pushed on the stack by the function if it calls other functions, so leaf-functions do not need to store/retrieve LR.

--
Mats

[Tubee]

x86. I have the above code compiled, and input for example:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaa

Then I debug it, check the registers, EIP's value is not 4x'a' in hex. If I do that with a function, it changes the EIP's value, so stack and return address get overwritten, but the same thing doesn't happen in main() for some reason..

[matsp]

x86. I have the above code compiled, and input for example:aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa aaaa

Then I debug it, check the registers, EIP's value is not 4x'a' in hex. If I do that with a function, it changes the EIP's value, so stack and return address get overwritten, but the same thing doesn't happen in main() for some reason..

It probably does, but there may be more "gunk" on the stack than you expect, perhaps.

--
Mats

[Tubee]

I get segmentation fault after I try to overflow the character buffer in gets(), so it seems like the stack is there kind of write protected.. This doesn't happen in my own functions. So the return address might as well be there, but I just can't overwrite it, at least like that. Anyways thanks for replies.

[MK27]

I get segmentation fault after I try to overflow the character buffer in gets(), so it seems like the stack is there kind of write protected.. This doesn't happen in my own functions. So the return address might as well be there, but I just can't overwrite it, at least like that. Anyways thanks for replies.

The reason you got a seg fault is because you succeeded in overwriting the return address, so the program cannot complete, silly.

[matsp]

I get segmentation fault after I try to overflow the character buffer in gets(), so it seems like the stack is there kind of write protected.. This doesn't happen in my own functions. So the return address might as well be there, but I just can't overwrite it, at least like that. Anyways thanks for replies.

Like MK27 says, if you overwrite the stack with "aaaaaaa", then it will jump to address 0x61616161, which is most likely not a valid address, so it will segfault.

--
Mats

[nonoob]

Who's to say that c[4] is necessarily in the stack segment for main. Perhaps it's in the data segment.

[QuantumPete]

Who's to say that c[4] is necessarily in the stack segment for main. Perhaps it's in the data segment.

Erm, the standard?

Variables declared in scope go on the stack unless they're static.

QuantumPete

[matsp]

Erm, the standard?

Variables declared in scope go on the stack unless they're static.

QuantumPete

Of course, that's not to say that the "data stack" is the same piece of memory as the "return stack". In architectures where the processor return stack is small, you could consider a separate "local variable" stack.

Likewise, there are processors where the return value for several layers can be held in a register (29K comes to mine, where there are 128 registers used for "local variables and return address" in a circular buffer style - the back end of the buffer is spilled to memory when it's full, and filled back from memory when it gets empty. In between, the values are not in memory. However, memory is used for local variables that use up larger chunks of memory, such as strings or structs, so overflowing a string or writing outside of a struct may cause "strange" things to happen, but it will not necessarily affect the return address).

--
Mats

[Elysia]

Who's to say that c[4] is necessarily in the stack segment for main. Perhaps it's in the data segment.

The point is, on x86, the return address and local variables are stored on the stack. Period.