Question

If I run a program, just like

#include <stdio.h>
int main(int argc, char *argv[], char *env[]) {
  printf("My references are at %p, %p, %p\n", &argc, &argv, &env);
}

We can see that those regions are actually in the stack.
But what else is there? If we ran a loop through all the values in Linux 3.5.3 (for example, until segfault) we can see some weird numbers, and kind of two regions, separated by a bunch of zeros, maybe to try to prevent overwriting the environment variables accidentally.

Anyway, in the first region there must be a lot of numbers, such as all the frames for each function call.

How could we distinguish the end of each frame, where the parameters are, where the canary if the compiler added one, return address, CPU status and such?

Answer 1

The contents of the stack are basically:

• Whatever the OS passes to the program.
• Call frames (also called stack frames, activation areas, …)

What does the OS pass to the program? A typical *nix will pass the environment, arguments to the program, possibly some auxiliary information, and pointers to them to be passed to main().

In Linux, you’ll see:

• a NULL
• the filename for the program.
• environment strings
• argument strings (including argv[0])
• padding full of zeros
• the auxv array, used to pass information from the kernel to the program
• pointers to environment strings, ended by a NULL pointer
• pointers to argument strings, ended by a NULL pointer
• argc

Then, below that are stack frames, which contain:

• arguments
• the return address
• possibly the old value of the frame pointer
• possibly a canary
• local variables
• some padding, for alignment purposes

How do you know which is which in each stack frame? The compiler knows, so it just treats its location in the stack frame appropriately. Debuggers can use annotations for each function in the form of debug info, if available. Otherwise, if there is a frame pointer, you can identify things relative to it: local variables are below the frame pointer, arguments are above the stack pointer. Otherwise, you must use heuristics, things that look like code addresses are probably code addresses, but sometimes this results in incorrect and annoying stack traces.