found a good example to demostrate the memory layout and its stack info of a user-mode process, only that this example is for Linux. But it is still worth taking a look at it.
C source file is quite simple:
- void func(int x, int y)
- {
- int a;
- int b[3];
- /* no other auto variable */
- …
- }
- void main()
- {
- …
- func(72,73);
- …
- }
Memory layout is as below. I will talk about the stack in the next session.
The diagram below shows the memory layout of a typical C’s process. The process load segments (corresponding to ” text ” and ” data ” in the diagram) at the process’s base address. The main stack is located just below and grows downwards. Any additional threads that are created will have their own stacks, located below the main stack. Each of the stack frames is separated by a guard page to detect stack overflows among stacks frame. The heap is located above the process and grows upwards.
In the middle of the process’s address space, there is a region is reserved for shared objects. When a new process is created, the process manager first maps the two segments from the executable into memory. It then decodes the program’s ELF header. If the program header indicates that the executable was linked against a shared library, the process manager will extract the name of the dynamic interpreter from the program header. The dynamic interpreter points to a shared library that contains the runtime linker code. The process manager will load this shared library in memory and will then pass control to the runtime linker code in this library.
Ref:
http://www.cs.uleth.ca/~holzmann/C/system/memorylayout.pdf
http://www.tenouk.com/Bufferoverflowc/Bufferoverflow1c.html
Stack Frame
Stack is one important segment of the process’s memory layout. It is a dynamic memory buffer portion used to store data implicitly normally during the run time.
The stack segment is where local (automatic) variables are allocated. In C program, local variables are all variables declared inside the opening left curly brace of a function body including the main() or other left curly brace that aren’t defined as static. The data is popped up or pushed into the stack following the Last In First Out (LIFO) rule. The stack holds local variables, temporary information/data, function parameters, return address and the like. When a function is called, a stack frame (or a procedure activation record) is created and PUSHed onto the top of the stack. This stack frame contains information such as the address from which the function was called and where to jump back to when the function is finished (return address), parameters, local variables, and any other information needed by the invoked function. The order of the information may vary by system and compiler. When a function returns, the stack frame is POPped from the stack. Typically the stack grows downward, meaning that items deeper in the call chain are at numerically lower addresses and toward the heap.
Stack frame constructed during the function call for memory allocation implicitly.
A typical layout of a stack frame is shown below although it may be organized differently in different operating systems:
*Function parameters.
*Function’s return address.
*Frame pointer.
*Exception Handler frame.
*Locally declared variables.
*Buffer
*Callee save registers
As an example in Windows/Intel, typically, when the function call takes place, data elements are stored on the stack in the following way:
1. The function parameters are pushed on the stack before the function is called. The parameters are pushed from right to left.
2. The function return address is placed on the stack by the x86 CALL instruction, which stores the current value of the EIP register.
3. Then, the frame pointer that is the previous value of the EBP register is placed on the stack.
4. If a function includes try/catch or any other exception handling construct such as SEH (Structured Exception Handling – Microsoft implementation), the compiler will include exception handling information on the stack.
5. Next, the locally declared variables.
6. Then the buffers are allocated for temporary data storage.
7. Finally, the callee save registers such as ESI, EDI, and EBX are stored if they are used at any point during the functions execution. For Linux/Intel, this step comes after step no. 4.
There are two CPU registers that are important for the functioning of the stack which hold information that is necessary when calling data residing in the memory. Their names areESP and EBP in 32 bits system.
The ESP (Extended Stack Pointer) holds the top stack address. TheEBP (Extended Base Pointer) points to the bottom of the current stack frame.
ESP points to the top of the stack (lower numerical address); it is often convenient to have a stack frame pointer (FP) which holds an address that point to a fixed location within a frame. Looking at the stack frame, local variables could be referenced by giving their offsets from ESP. However , as data are pushed onto the stack and popped off the stack, these offsets change, so the reference of the local variables is not consistent. Consequently, many compilers use another register, generally called Frame Pointer (FP), for referencing both local variables and parameters because their distances from FP do not change with PUSHes and POPs. On Intel CPUs,EBP (Extended Base Pointer) is used for this purpose.
Because the way stack grows, actual parameters have positive offsets and local variables have negative offsets from FP as shown below. Let examine the following simple C program.
- #include <stdio.h>
- int MyFunc(int parameter1, char parameter2)
- {
- int local1 = 9;
- char local2 = ’Z';
- return 0;
- }
- int main(int argc, char *argv[])
- {
- MyFunc(7, ’8′);
- return 0;
- }
And the memory layout will look something like this:
Each time a new function is called, the old value of EBP is the first to be pushed onto the stack and then the new value of ESP is moved to EBP. This new value of ESP held by EBP becomes the reference base to local variables that are needed to retrieve the stack section allocated for the new function call. As mentioned before, a stack grows downward to lower memory address. The stack pointer (ESP) points to the last address on the stack not the next free available address after the top of the stack.
The first thing a function must do when called is to save the previous EBP (so it can be restored by copying into the EIP at function exit later). Then it copies ESP into EBP to create the new stack frame pointer, and advances ESP to reserve space for the local variables. This code is called the procedure prolog . Upon function exit, the stack must be cleaned up again, something called theprocedure epilog .
Using a very simple C program skeleton, the following tries to figure out function calls and stack frames construction/destruction.
- #include <stdio.h>
- int a();
- int b();
- int c();
- int a()
- {
- b();
- c();
- return 0;
- }
- int b()
- {
- return 0;
- }
- int c()
- {
- return 0;
- }
- int main()
- {
- a();
- return 0;
- }
By taking the stack area only, the following is what happen when the above program is run.
By referring the previous program example and above figure, when a program begins execution in the function main(), stack frame is created, space is allocated on the stack for all variables declared within main(). Then, when main() calls a function, a(), new stack frame is created for the variables in a() at the top of the main() stack. Any parameters passed by main() to a() are stored on the stack. If a() were to call any additional functions such as b() and c(), new stack frames would be allocated at the new top of the stack. Notice that the order of the execution happened in the sequence. When c(), b() and a() return, storage for their local variables are de-allocated, the stack frames are destroyed and the top of the stack returns to the previous condition. The order of the execution is in the reverse. As can be seen, the memory allocated in the stack area is used and reused during program execution. It should be clear that memory allocated in this area will contain garbage values left over from previous usage.
Ref:
http://www.tenouk.com/Bufferoverflowc/Bufferoverflow1c.html
http://www.tenouk.com/Bufferoverflowc/Bufferoverflow2.html