By Toby Opferman IntroductionWelcome to the second installment of these debugging tutorials. In this article, I will investigate the stack and how it plays an integral part in debugging. Anytime you ask the question 'What do you do when your program traps?', the most common answer is 'Get a stack trace'. This is definitely true, it's probably the very first thing you should do anytime you investigate a crash dump.
Sorry if this tutorial is too general and beginner-ish! I should probably set the level as beginner instead of intermediate. I only set it as intermediate since the article is requiring assembly knowledge.
What is the Stack?This is the first and most obvious question. Unfortunately, I did not cover or really answer this in the first tutorial as I was taking for granted that everyone was familiar with it. In order to explain what the stack is, let me start from where we begin, what a process is.
What is a Process?A process is basically an instance of an application in memory. The executable and supported libraries are mapped into this address space. A process does not execute, but just rather defines the memory boundaries, resources, and the like which are accessible from anyone operating within that process.
What is a Thread?A thread is an instance of execution that operates within the boundaries of a process. A process is not scheduled to execute, the threads within a process are. There may be many threads executing in the context of one process. Although a thread may have 'thread specific storage', generally all memory and resources created in the context of the process can be used by any executing thread.
Global and Local ResourcesNot to be confusing here, but there are exceptions. There are resources that are created globally rather than locally. That means these resources may be used outside the context of the process in which they were created. One such example is a window handle. These resources have their own boundaries outside of a process. Some resources may be system wide, others desktop or session wide. There are also 'shared' resources where processes can negotiate sharing of a resource through other means and mechanisms.
What is Virtual Memory?In general, 'Virtual Memory' is generally thought of as fooling the system into thinking there's more physical memory than there really is. This is true and false at the same time. It depends on who 'the system' is and there's really more to it than that.
The system is not being fooled into thinking there's more memory than there really is. The hardware already knows there's less memory and is actually the one who implements the necessary mechanisms to support 'Virtual Memory'. The Operating System is the one which utilizes these capabilities to perform 'Virtual Memory', so it is also not being fooled. So, who is being fooled? If anyone is being fooled, it's the processes running on the system.
I don't believe that to be the case either. The application programmer generally knows the system he is programming for already. That means, he knows the Operating System uses 'Virtual Memory' or not such as DOS and he programs for that platform. In general, it doesn't mean anything. A simple application really doesn't care as long as it gets to execute. The only time you really run into trouble would be a 'cooperative multitasking' system verses a 'preemptive multitasking' system. But, then again, the programmer knows his target platform and programs appropriately. The differences with those two types of Operating Systems is beyond the scope of this article and does not apply.
So, back to answering this question. The first thing that 'Virtual Memory' does is that it abstracts the physical address space of the machine. This means the application programs do not see or know about the physical address. They know a 'Virtual' address. The CPU is then capable of converting a 'Virtual' address to a 'Physical' address based on certain characteristics setup by the Operating System. The details of that mechanism is beyond the scope of this document. Just understand that the application receives a 'Virtual' address and the processor maps it to a physical address.
The next part of the equation is that the 'Virtual' address does not need to point to a 'Physical' address. The Operating System can use a swap file to keep memory on disk, that way, the entire program does not have to be in physical memory at the same time. This allows many programs to be in memory and execute. If a program attempts to access a memory location that is not in physical memory, the CPU knows this. The CPU will page fault and know that the memory that is being accessed is out on disk. The Operating System will then get told and will pull that memory from disk to Physical memory. Once this is complete, the program is given back execution and will continue where it left off.
There are many algorithms to decide how to pull memory in from disk. Unless you plan to grow the footprint of a process in Physical memory, you usually swap a page out to swap one in. There are many algorithms that the OS can use to grow the process physical foot print and swap pages in and out. A simple one is basically, the least frequently used page in memory. You generally want to avoid writing programs that keep crossing page boundaries frequently, this will eliminate 'thrashing' which is swapping in and out pages from memory to disk often. These topics are outside the scope of this tutorial.
The next advantage of 'Virtual Memory' is protection. A process cannot directly access another process's memory. That means that at anyone time, the CPU has only the Virtual address mappings for that process. That means, it can't resolve a virtual address in another process. This makes sense because since they are separate mappings, the processes could and will have the same memory address pointed to different locations!
That doesn't mean it's impossible to read another process' memory. If the Operating System has built-in support, such as Windows does, you can access another process' memory. You could also do this if you could gain access to memory locations, and manipulate the CPU registers as they relate to Virtual Memory mapping. Luckily, you can't, as the CPU can check your privilege level before you attempt to execute sensitive assembly instructions, and 'Virtual Memory' will keep you away from being a usermode process and manipulating page or descriptor tables (Although, there is a method in Windows 9x to get the LDT in usermode).
What is the stack?Now that I've described the basics of the system, I can get back to 'What is a stack?'. In general, a stack is a general-purpose data structure that allows items to be pushed onto it and popped off. Think of it as a stack of plates. You can put items on the top and you can only take items off the top (without cheating). If you followed that strict rule, you have a stack. A stack is generally referred to as 'LIFO' or 'Last In First Off'.
Programs generally use the stack as a means of temporary storage. This is generally unknown to the non-assembly programmer as the language hides these details. However, the generated code produced by your program will use a stack and the CPU has built-in stack support!
On Intel, the assembly instructions to put something on the stack and take something off are PULL, but in the Intel world, we use
Getting back on track, every 'thread' executing in a process has its own stack. This is because we can't have multiple threads attempting to use the same temporary storage location as we will see in a moment.
How is a function call made?The function call depends on the 'calling convention'. The 'calling convention' is a basic method that the caller (the function making the call) and callee (the function being called) have agreed on in order to pass parameters to the function and clean up the parameters afterwards. In Windows, we generally support three different calling conventions. These are 'this call', 'standard call' and 'CDECL or C Calling convention'.
This CallThis is a C++ calling convention. If you're familiar with C++ internals, member functions of an object require the
Standard Call'Standard Call' is when the parameters are pushed backwards on to the stack and the callee cleans up the stack.
CDECL or C Calling Convention'C Calling' convention basically means that the parameters are pushed backwards onto the stack and the caller cleans up the stack.
Pascal Calling ConventionIf you've seen old programs, you will see 'PASCAL' as their calling convention. In WIN32, you actually are not allowed to use __pascal anymore. The PASCAL macro has actually been redefined as 'Standard Call'. However, Pascal calling convention parameters are pushed forward onto the stack. The callee cleans up the stack.
Cleans up the stack?The difference in who cleans up the stack is a big deal. The first is saving bytes. If the callee cleans up the stack, that means there doesn't have to be extra instructions generated at every function call to clean up the stack. The disadvantage to this is that you cannot use variable arguments. Variable arguments are used by functions like printf. The actual callee does not REALLY know how many arguments are pushed onto the stack. It can only GUESS by the information provided to it, in say, its format string. If you tell printf , it will attempt to use 3 more values on the stack to fill those, whether or not you pushed them or not! This may or may not trap. If you push more parameters than you tell printf, there's no problem since the caller is cleaning up the stack anyway. They're just there for no reason, but printf does not know they're there. Remember that, variable argument functions do not magically know how many parameters are there, they must implement some method for the caller to tell them through their parameter list. Printf's just happen to be the format string, you could even pass a number down if you want, but the compiler isn't going to do it for you.
Also, although it is possible to then clean up the stack, it's not entirely feasible. Since the function does not know at compile time how many parameters are sent to it, it means it has to manipulate the stack and move around the return value in order to clean up. It's easier to just let the caller clean up the stack in this case.
Intel supports an instruction to clean up the stack by the callee. It's <Byte Count> where Byte Count is the size in bytes of the parameters on the stack. A 2 byte instruction.
So, what is the stack?A stack is a location for temporary storage. Parameters are pushed onto the stack, then the return address is pushed onto the stack. The flow of execution must know where to return to. The CPU is stupid, it just executes one instruction after the other. You have to tell it where to go. In order to tell it how to get back, we need to save the return address, the location after the function call. There is an assembly instruction that does this for us:
The layout of the stack would be the following:
[Parameter n ]...[Parameter 2 ][Parameter 1 ][Return Address ][Previous Base Pointer][Local Variables ]
Before returning, the stack is cleaned up to the return address and then a 'return' is issued. If the stack is not kept in proper order, we may get out of sync and return to the wrong address! This can cause a trap, obviously!
What is the 'base pointer'?The 'base pointer' in Intel is generally EBP. What happens is since ESP is dynamic and always changing, you save the old EBP from the previous function, then set EBP to the current stack location. You can now reference variables directly on the stack from a standard offset. This means that the first parameter will always be EBP + xx, etc. If you do not save ESP and always reference ESP, you're going to have to keep track of how much data is on the stack. If you put more and more data on the stack, the offset to the first parameter changes. The assembler does generate functions when appropriate to not set EBP, so it's not always the case that EBP is the base pointer but rather the function could be using ESP directly.
Generally, it's EBP + Value to get to function parameters and EBP - Value to get to local variables.
Putting it all togetherSo, you can now see the reason each thread has its own stack. If they shared the same stack, they would overwrite each other's return values and data! Or, could eventually, if they ran out of stack space. That's the next problem we will discuss.
Stack OverflowA Stack Overflow is when you reached the end of your stack. Windows generally gives the program a fixed amount of user mode stack space. The kernel has its own stack. It generally occurs when you run out of stack space! Recursion is a good way to run out of stack space. If you keep recursively calling a function you may eventually run out of stack and trap.
Windows generally does not allocate all of the stack at once, but instead grows the stack as you need it. This is an optimization obviously.
We can write a small program to perform a stack overflow and then find out how much stack Windows gave us.
(TEB at 7ffde000 ExceptionList: 0012ffb0 StackBase: Evaluate expression:
Stack UnderflowIn general, a Stack Underflow is the opposite of an overflow. You've somehow thought you put more on the stack than you really have and you've popped off too much. You've reached the beginning of the stack and it's empty, but you thought there was more data and kept attempting to pop data off.
Overflows and UnderflowsOverflows and Underflows can also be said to occur when your program gets out of sync and crashes thinking the stack is in a different position. The stack could underflow if you clean up too much in a function and then attempt to return. Your stack is out of sync and you return to the wrong address. The reason your stack is out of sync is you thought you had more data on it than you did. You could consider that an underflow.
The opposite can also occur. You've cleaned up too little because you didn't think you had that much data on the stack and you return. You trap when you return because you went to the wrong address. You 'could' consider this an overflow as you are out of sync, thinking you have less data on the stack than you really do.
How does the debugger get a stack trace?This brings me to my next topic, how does a debugger get a stack trace? The first answer is simply by using 'Symbols'. The symbols can tell the debugger how many parameters are on the stack, how many local variables, etc., so the debugger can then use the symbols to determine how to walk the stack and display the information.
If there are no symbols, it uses the base pointer. Each base pointer points to the previous base pointer. The Base Pointer + 4 also points to the return address. This is how it then walks the stack. If everyone uses EBP, the stack trace could be a perfect world. Although the debugger does not know how many parameters there are, it just dumps the location where the parameters WOULD be, it's up to you to interpret what the correct parameters are.
Here is a simple table of some function calls. I am going to use the stack trace from the first tutorial.
0:000> kbChildEBP RetAddr Args to Child0012fef4 77c3e68d 77c5aca0 00000000 0012ff44 MSVCRT!_output+0x180012ff38 00401044 00000000 77f944a8 00000007 MSVCRT!printf+0x350012ff4c 00401147 00000001 00323d70 00322ca8 temp!main+0x440012ffc0 77e814c7 77f944a8 00000007 7ffdf000 temp!mainCRTStartup+0xe30012fff0 00000000 00401064 00000000 78746341 kernel32!BaseProcessStart+0x23
Since ESP will point to local variables, etc., we will dump EBP. I will use the 'DDS' command which means 'Dump Dwords with Symbols'. The debugger will attempt to match the value on the stack with the closest symbol.
Our current EBP value is 0012fef4. This is a pointer on the stack, remember? This value points to the previous EBP. Remember, EBP + 4 == return value, EBP + 8 == Parameters. The bold walks the stack to each EBP value.
[Stack Address | Value | Description]0012fef4 0012ff380012fef8 77c3e68d MSVCRT!printf+0x350012fefc 77c5aca0 MSVCRT!_iob+0x200012ff00 000000000012ff04 0012ff440012ff08 77c5aca0 MSVCRT!_iob+0x200012ff0c 000000000012ff10 000007e80012ff14 7ffdf0000012ff18 0012ffb00012ff1c 000000010012ff20 0012ff0c0012ff24 0012f8c80012ff28 0012ffb00012ff2c 77c33eb0 MSVCRT!_except_handler30012ff30 77c146e0 MSVCRT!`string'+0x16c0012ff34 000000000012ff38 0012ffc00012ff3c 00401044 temp!main+0x440012ff40 000000000012ff44 77f944a8 ntdll!RtlpAllocateFromHeapLookaside+0x420012ff48 000000070012ff4c 000000000012ff50 00401147 temp!mainCRTStartup+0xe30012ff54 000000010012ff58 00323d700012ff5c 00322ca80012ff60 00403000 temp!__xc_a0012ff64 00403004 temp!__xc_z0012ff68 0012ffa40012ff6c 0012ff940012ff70 0012ffa00012ff74 000000000012ff78 0012ff980012ff7c 00403008 temp!__xi_a0012ff80 0040300c temp!__xi_z0012ff84 77f944a8 ntdll!RtlpAllocateFromHeapLookaside+0x420012ff88 000000070012ff8c 7ffdf0000012ff90 c00000050012ff94 00323d700012ff98 000000000012ff9c 8053476f0012ffa0 00322ca80012ffa4 000000010012ffa8 0012ff840012ffac 0012f8c80012ffb0 0012ffe00012ffb4 00401210 temp!except_handler30012ffb8 004020d0 temp!?MSVCRT_NULL_THUNK_DATA+0x800012ffbc 000000000012ffc0 0012fff00012ffc4 77e814c7 kernel32!BaseProcessStart+0x230012ffc8 77f944a8 ntdll!RtlpAllocateFromHeapLookaside+0x420012ffcc 000000070012ffd0 7ffdf0000012ffd4 c00000050012ffd8 0012ffc80012ffdc 0012f8c80012ffe0 ffffffff0012ffe4 77e94809 kernel32!_except_handler30012ffe8 77e91210 kernel32!`string'+0x980012ffec 000000000012fff0 000000000012fff4 000000000012fff8 00401064 temp!mainCRTStartup
So, EBP points to (0012fef4) which points to the previous EBP of 0012ff38. EIP == 77c3f10b, which is MSVCRT!_output+0x18. We can then dump EBP + 8 as the parameters. The debugger with 'KB' generally dumps the first 3 values of the stack. It doesn't know if those are correct parameters or not, it's just a preview. If you want to know the rest, you simply find the location on the stack and dump.
0012fefc 77c5aca0 MSVCRT!_iob+0x200012ff00 000000000012ff04 0012ff44
So, we can assemble the first function:
MSVCRT!_output+0x18(77c5aca0, 00000000, 0012ff44);
The second function is EBP + 4, the return address. Remember, it doesn't know where the functions start. So, the best it can do is match the return address specifying this as the function.
This is the calling function:
0012fef8 77c3e68d MSVCRT!printf+0x35
It then goes to the previous EBP, 0012ff38, and adds 8 to get the parameters.
0012ff40 000000000012ff44 77f944a8 ntdll!RtlpAllocateFromHeapLookaside+0x420012ff48 00000007
This is the calling function with its parameters.
MSVCRT!printf+0x35(00000000, 77f944a8, 00000007);
As you can see, if anything is off, this information is wrong. That is why you must use your judgment when interpreting these values.
The next EBP was :0012ffc0. It's the memory location at 0012ff38. The previous return value is:
0012ff3c 00401044 temp!main+0x44
The previous parameters were at 0012ffc0 + 8. Remember, this also assumes that EBP was the first value pushed onto the stack. If the debugger is smart enough, it could attempt to just walk the stack until it gets the first recognizable symbol and use that as the return value! That's in case something was pushed onto the stack before EBP was saved and set.
These are the parameters:
0012ffc8 77f944a8 ntdll!RtlpAllocateFromHeapLookaside+0x420012ffcc 000000070012ffd0 7ffdf000temp!main+0x44(77f944a8, 00000007, 7ffdf000)
Our next EBP was 0012ffc0, so + 4 is the return value. That's our function now.
0012ffc4 77e814c7 kernel32!BaseProcessStart+0x23
So, EBP = 0012ffc0, points to previous EBP 0012fff0 and we know that previous EBP + 8 == parameters.
0:000> dds 0012fff00012fff0 000000000012fff4 00000000 <-- Previous return value is NULL so stop here.0012fff8 00401064 temp!mainCRTStartup <-- + 80012fffc 0000000000130000 78746341kernel32!BaseProcessStart+0x23(00401064, 00000000, 78746341)
This should be good enough since our previous return value is NULL. So, this is our manual generation of the stack:
MSVCRT!_output+0x18 (77c5aca0, 00000000, 0012ff44);MSVCRT!printf+0x35 (00000000, 77f944a8, 00000007);temp!main+0x44 (77f944a8, 00000007, 7ffdf000);kernel32!BaseProcessStart+0x23 (00401064, 00000000, 78746341);
This was our stack trace from the debugger:
ChildEBP RetAddr Args to Child0012fef4 77c3e68d 77c5aca0 00000000 0012ff44 MSVCRT!_output+0x180012ff38 00401044 00000000 77f944a8 00000007 MSVCRT!printf+0x350012ff4c 00401147 00000001 00323d70 00322ca8 temp!main+0x440012ffc0 77e814c7 77f944a8 00000007 7ffdf000 temp!mainCRTStartup+0xe30012fff0 00000000 00401064 00000000 78746341 kernel32!BaseProcessStart+0x23
What's different and why? Well, we followed a simple rule to walk the stack. EBP points to the previous EBP. Secondly, we didn't use symbol information to walk the stack. If I delete the symbols for temp.exe, I get the following stack trace:
0:000> kbChildEBP RetAddr Args to Child0012fef4 77c3e68d 77c5aca0 00000000 0012ff44 MSVCRT!_output+0x180012ff38 00401044 00000000 77f944a8 00000007 MSVCRT!printf+0x35WARNING: Stack unwind information not available. Following frames may be wrong.0012ffc0 77e814c7 77f944a8 00000007 7ffdf000 temp+0x10440012fff0 00000000 00401064 00000000 78746341 kernel32!BaseProcessStart+0x230:000>
The same as ours! So, the debugger used symbolic information to walk the stack and display a more accurate picture. However, without symbolic information, there's function calls missing. That means, we cannot always trust the stack trace if symbols are wrong, missing or not complete. If we do not have symbol information for all modules, then we have a problem!
If I continue with these tutorials, one of the next ones will attempt to explain symbols and validating them. However, I will attempt to show you one trick to validating function calls in this tutorial.
As we can see, we notice we are missing a function call. How do you validate function calls? By verifying they were made.
Verifying Function CallsI ran the program again and got a new stack trace.
0:000> kbChildEBP RetAddr Args to Child0012fef4 77c3e68d 77c5aca0 00000000 0012ff44 MSVCRT!_output+0x180012ff38 00401044 00000000 00000000 00000000 MSVCRT!printf+0x35WARNING: Stack unwind information not available. Following frames may be wrong.0012ffc0 77e814c7 00000000 00000000 7ffdf000 temp+0x10440012fff0 00000000 00401064 00000000 78746341 kernel32!BaseProcessStart+0x230:000>
Some of the values on the stack are different, but that's what happens when you run programs again. You're not guaranteed the same run every time!
This is your first return value: 77c3e68d
If you un-assemble it, you will get this:
MSVCRT!printf+
<77c3e691 ff75e4
This is the return value. What is a return value? It's the next instruction after a call is made. Thus, if we keep subtracting from this value, we will eventually un-assemble the call instruction. The trick is to un-assemble enough to make out the call function. Be warned though, Intel opcodes are variable. That means that they are not a fixed size and un-assembling in the middle of an instruction can generate a completely different instruction and even different instruction list! So, we have to guess. Usually if we go back enough, the instructions eventually get back on track and are unassembled correctly.
MSVCRT!printf+MSVCRT!printf+_output! So, that is a correct function call. Want to try another?
The next return address listed in the stack trace is 00401044. Let's try the same:
temp+temp+
Use 'DD' to get the value at the address.
0:000> dd 0040201000402010 77c3e658
We will now un-assemble this address since we know it's a function call.
MSVCRT!printf:77c3e658 6a10 printf here.
The next return value is 77e814c7. Let's see if we're calling temp.
kernel32!BaseProcessStart+kernel32!BaseProcessStart+77e814c4 ff5508
0012fff0 temp+temp. Unfortunately, we can't be certain it's the same function. In order to find that out, we need to un-assemble this function and walk through it. Remember, the call to printf is at:
0040103e ff1510204000
If we do DDS on EBP, we find this:
0:000> dds ebp0012fef4 0012ff380012fef8 77c3e68d MSVCRT!printf+0x350012fefc 77c5aca0 MSVCRT!_iob+0x200012ff00 000000000012ff04 0012ff440012ff08 77c5aca0 MSVCRT!_iob+0x200012ff0c 000000000012ff10 000007e80012ff14 7ffdf0000012ff18 0012ffb00012ff1c 000000010012ff20 0012ff0c0012ff24 ffffffff0012ff28 0012ffb00012ff2c 77c33eb0 MSVCRT!_except_handler30012ff30 77c146e0 MSVCRT!`string'+0x16c0012ff34 000000000012ff38 0012ffc00012ff3c 00401044 temp+0x10440012ff40 000000000012ff44 000000000012ff48 000000000012ff4c 000000000012ff50 00401147 temp+0x11470012ff54 000000010012ff58 003224700012ff5c 00322cf80012ff60 00403000 temp+0x30000012ff64 00403004 temp+0x30040012ff68 0012ffa40012ff6c 0012ff940012ff70 0012ffa00:000> dds0012ff74 000000000012ff78 0012ff980012ff7c 00403008 temp+0x30080012ff80 0040300c temp+0x300c0012ff84 000000000012ff88 000000000012ff8c 7ffdf0000012ff90 000000010012ff94 003224700012ff98 000000000012ff9c 8053476f0012ffa0 00322cf80012ffa4 000000010012ffa8 0012ff840012ffac e3ce0b300012ffb0 0012ffe00012ffb4 00401210 temp+0x12100012ffb8 004020d0 temp+0x20d00012ffbc 000000000012ffc0 0012fff00012ffc4 77e814c7 kernel32!BaseProcessStart+0x23
There are a lot of unknown TEMP + xxx values on the stack! The one in bold is the one we know is the return value for the printf(). 00401064, we know is the start address of the function called from BaseProcessStart(). What values are close to this one?
This is where guess work comes in. If you think that function does not jump backwards, you could attempt to only look at values that are > than this one. You could attempt to un-assemble every single reference, but you have to start somewhere. I would say, look at the symbols closest to this one first. Here is one:
0012ff50 temp+temp+not a
Let's un-assemble this one:
temp+temp+temp+printf. So, we could then disassemble the original function call until we reached this call, to see if it called it, or if there's yet another function call in between.
temp+temp+EBP, thus we could not get an accurate stack trace. When that happens, we need to verify our trace. As we can see, the previous function did not call printf, but another one did that it called.
00401147 is the missing return value. If we find it on the stack, we can update the correct parameters:
0000000000401147 temp+0x1147000000010032247000322cf8
So, here's the one generated from KB:
0:000> kbChildEBP RetAddr Args to Child0012fef4 77c3e68d 77c5aca0 00000000 0012ff44 MSVCRT!_output+0x180012ff38 00401044 00000000 00000000 00000000 MSVCRT!printf+0x35WARNING: Stack unwind information not available. Following frames may be wrong.0012ffc0 77e814c7 00000000 00000000 7ffdf000 temp+0x10440012fff0 00000000 00401064 00000000 78746341 kernel32!BaseProcessStart+0x230:000>
Here's our modified one:
ChildEBP RetAddr Args to Child0012fef4 77c3e68d 77c5aca0 00000000 0012ff44 MSVCRT!_output+0x180012ff38 00401044 00000000 00000000 00000000 MSVCRT!printf+0x35WARNING: Stack unwind information not available. Following frames may be wrong.xxxxxxxx 0401147 00000001 00322470 00322cf8 temp+0x10440012ffc0 77e814c7 00000000 00000000 7ffdf000 temp+0x11470012fff0 00000000 00401064 00000000 78746341 kernel32!BaseProcessStart+0x230:000>
We know that the temp that calls printf() is main(). So, argc = 1, *argv[] = 322470.
*argv[] is a pointer to an array of pointers which are ANSI strings.
0:000> dd 32247000322470 00322478 00000000 706d6574 ababab0000322480 abababab feeefeab 00000000 0000000000322490 000500c5 feee0400 00325028 00320178003224a0 feeefeee feeefeee feeefeee feeefeee003224b0 feeefeee feeefeee feeefeee feeefeee003224c0 feeefeee feeefeee feeefeee feeefeee003224d0 feeefeee feeefeee feeefeee feeefeee003224e0 feeefeee feeefeee feeefeee feeefeee0:000> da 0032247800322478 'temp'
Dumping the array, which only contains 1 string as per argc, we can then use the 'da' command to view that string as shown above.
Multiple Return Addresses On The Stack?Why are there multiple return addresses on the stack? The stack may generally be initialized to zero, but as it's being used, it becomes dirty. You know that local variables aren't always initialized, so if you make a function call, those values aren't reset to zero when the stack moves up. If you pop a value off the stack, the stack may decrement, but the values stay unless they are physically cleaned up. Sometimes, the stack optimizes things and doesn't clean up variables as well. So, seeing 'ghost' values on the stack is very common.
This is not always desirable to leave values on the stack. For example, if your function puts the password on the stack and traps sometime later. A stack dump may still show the password on the stack! So, sometimes when you have sensitive information, you may want to clean up the values on the stack before you return. One way to do this is with the SecureZeroMemory() API. This can be used to clear memory securely as calling other APIs may be 'optimized' out of the code, for example, if you call them before you return. The compiler knows you're not going to use the variable anymore and may not perform the clearing.
Buffer OverflowsBuffer overflows are a common occurrence on the stack. The stack grows down in memory, but arrays grow up in memory. This is because you usually 'increment' a pointer or array when using it to get to the next index, rather than decrementing it. Thus let's say this was your C function:
{ DWORD MyArray[
That would evaluate to a stack like this:
424 [Return Address ]420 [ Previous Base Pointer ]416 [ Local Array Variable Index 3]412 [ Local Array Variable Index 2]408 [ Local Array Variable Index 1]404 [ Local Array Variable Index 0]400 [ Local Integer Value ]
As you can see, if you index your array to MyArray[MyArray[
Windows 2003Windows 2003 has a new method to attempt to prevent buffer overflows. This can be compiled in VS.NET using the GS flags. A random value is generated as a cookie on startup of the application. The cookie is then XOR'd with the return address of the function and placed on the stack after the base pointer. This is a simple example:
[Return Address ][Previous Base Pointer ][Cookie XOR Return Address ]
Upon return, the cookie is checked against the return value. If they're unchanged, then the return occurs, if not, then we have a problem. The reason for this security is not to prevent code from trapping without proper handling, but rather to protect code from executing injected code. A security risk is when someone finds out how to overflow a buffer with actual code and an address to that code. This will cause the program to return to and execute that code.
This URL provides the full details of this:
MSDN ConclusionI have confused beginners and probably bored advanced programmers, however, it's hard to portray advanced concepts in a simple manner. I am trying my best though. If you like or dislike these tutorials, leave me a comment. If you want these to end, let me know too!
I've probably started off too simple then got too advanced too fast. I can't help it though, programmers should study this information and supplement it with other sources to gain full knowledge on the subject. Do not take what you read or posted on message boards as concrete fact. Everyone is human, everyone errors and not one person knows everything. These sites let just about anyone post information, so always be skeptical. Let me know if you found an error. Thanks.
About Toby Opferman
