main() - activation frame

[Klueless]

I'm running Fedora Core 6 and have been experimenting with kdbg. I've written a program in C that is similiar to . . .

void foo()
{
}

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

When foo() is done running and is going to be popped off the stack, I see in kdbg that main's EBP and EIP are stored in the bytes below foo's EBP. So when foo pops off, then ESP gets reset. Looking at the similiar bytes after main's EBP, the value in EIP aren't any of the bytes after EBP. What is stored in the memory address stored in EIP? Do the bytes after main's EBP have anything to do with my program?

[the_unforgiven]

Yes and no.

When you compile your program, it gets linked to the standard C library which has the startup code that initializes the process environment. At the end of this initialization, the C library calls the main() function; so when your code is run, the OS directly doesn't transfer control to your main() function - in fact, the OS kernel/dynamic loader doesn't know anything about main(), it is the standard C library (glibc) that passes control to your main().

So, when you look at the stack, after main() returns, it goes back to glibc which goes on to clean up the process environment that it setup for your application - like closing the file descriptors (stdin, stdout and stderr + the ones you opened and forgot to close :P) etc.

So, yes, the code after main is related to your program - it runs in the same process address space as your program; but no, you haven't coded it - it's part of glibc .

HTH

[Klueless]

Makes sense. I've read that logic elsewhere too. But still, why aren't any of the bytes after main's EBP equal to the EIP reported by kdbg? Isn't that where EIP should be stored or is the activation frame for main set up differently than the frame for anything successive functions. That'd be news to me.

[the_unforgiven]

I don't think that main()'s frame is set up any differently than any other function.

However, what EIP reports at the end of main() is the next instruction (which would most likely be a "pop %eip" or "leave" sort of thing. Unless EIP is popped from the stack frame, it will not point to the right instruction in the glibc cleanup code - it would still be pointing to the next instruction in current process's address space (which would be a "leave" from the main()). What I mean here is unless main()'s stack frame is destroyed in the "leave", the EIP value is not indicative of the actual next instruction to be executed.

If I'm not mistaken, this would be the case for epilogue of every function call.

I might be wrong, I need to check up.

[Klueless]

So you think the values before under EBP truely indicate where the next instruction (epilogue) is stored. Is that correct? So then how does that bogus value get pushed into EIP? Where does it come from? I don't see it in any of the bytes after main's EBP.

If this is true and if one cannot accurately trace where EIP truely is stored, then how do buffer overflows work if there are no functions called from within main? Without these functions, a malicious coder would never have the chance to overwrite the stack to point to shellcode. Heck, if you messed up main's stack, then you could apparently still return to libc no problem.