"Turn" two articles about __security_cookie

___security_cookie mechanism to prevent stack overflow

The term "stack overflow" has been exposed many times since the bottom of the study and the compilation.

This time in the Exchange code to see an unknown ___security_cookie, checked the next, the original is the compiler's security check mechanism. Reprint an article:

First, the security cookie is not a protection mechanism that comes with Windows systems, and does not mean that there is an overflow vulnerability
program, in an environment with security cookie protection, it will not overflow properly.
So what exactly is a security cookie?
I think broadly speaking, it should be a protection stack mechanism, providing this protection, is the program itself, compiled into the program itself
The code provides, not a thread in the system that runs in a dark corner.
So, since the program itself is brought in, in order not to give the programmer an additional burden, the job is given to the compiler to complete.
Vc6.0 's cl.exe is not with this feature, only vc.net with the later version of Cl.exe only with this feature, the so-called/GS option.
When you use the vc.net CL compiler, the/GS option is turned on by default.
Now that we know the provider of this mechanism, what exactly is the mechanism?
The person familiar with the function call and the assembly instructions before and after the return is sure to be clear, on the Win32 platform, for function calls of the stdcall type,
When the call command finishes running, the current stack structure is basically this:

Office Change 2 ebp-8 low address
Office Change 1 Ebp-4
EBP EBP
Return address Ebp+4
Parameter 1 ebp+8
Parameter 2 ebp+c
Parameter 3 ebp+10
Parameter 4 ebp+14 High address

The first column is the contents of the DWORD stored in the stack, and the second column is the index of the stack address with EBP, which corresponds to the value that should be expressed in EBP,
To put it in the image, EBP holds an address to the stack (the stack is actually a piece of memory, and EBP just points to one of the internal comparisons of the current function
Important address, in fact, is very important), the rest of the stack is addressed by this ebp, that is, we give the function of the first parameter
Address, that is ebp+8, the second is ebp+c, we define the address of the local variable, the first local variable is ebp-4, the second local variable
The address is ebp-8, and so on. But this is not certain, the above is the ideal situation, if we set an array in the function,
such as Char Buf[8], and is the first local variable defined, then its address is certainly not ebp-4, or ebp-8. Therefore, the array
More special, the structure is also more special, the fundamental reason is that the stack is from the high address to the low address growth, and our array, structure,
But from the low-to-high address growth, the contradiction between the result is a subtle change in addressing.
Of course, for the convenience of explaining the problem, the variables defined by default, the parameters passed in, are four-byte aligned, and one variable
Double word. You can interpret the array as a 4-byte char, which is a double word.
In other words, when call is finished, the current stack structure is given, and if strcpy () is called in the function, it is entered in the local variable 1.
Things, the length is not detected, then ebp-4,ebp,ebp+4, and the following address, where the content will be overwritten. Over here
Overflow happened, we control the return address of RET, and then ...
Well, to prevent this, the new CL compiler's/GS option is added to the so-called "security cookie," How do I join? Where did you join?
It?
Let's take a look at the stack changes after the call command joins the "security cookie" after it runs.

Office Change 2 Ebp-c low address
Office Change 1 Ebp-8
XXXXX ebp-4
EBP EBP
Return address Ebp+4
Parameter 1 ebp+8
Parameter 2 ebp+c
Parameter 3 ebp+10
Parameter 4 ebp+14 High address

Change is obvious, in EBP above, the first local variable below, fill in a new value, this value is called "Security cookie"
The content of the ebp-4 is overwritten by the above-mentioned overflow process, i.e. the value of the security cookie is modified, and the function returns, that is, the RET is executed.
command, it will call another function, which is used to compare the value of ebp-4 and the value of the push to the stack is not the same, different
, then the process is terminated.
Well, you'll probably have the following questions:
1. How is this security cookie calculated?
The security cookie is a double word, or an int, which itself is stored in a global variable, which is created by the compiler
The stage is created and then written to the. Data section, which is the value stored in the PE.
But this value is changed again, after the Windows loader completes the necessary pre-preparation work (such as creating a process, allocating memory for the stack, waiting)
Setting the EIP to the code entry in PE, the first command executed is a call invocation, which is used to initialize the
Cookie value, of course, this code is also public, but it does not matter, this algorithm guarantees that the cookie value is random, Hacker also
is not to be guessed in a shellcode.
Specific algorithm I do not intend to explain here, interested readers can compile their own and then disassembly to see a bit.

2. When was it filled into the stack?
We know the calculation and initialization of this security cookie, so it must be written to ebp-4 when the function is called.
So, the past without this protection code, at the entrance of the function is generally like this:
Push EBP
MOV Ebp,esp
Sub ebp,n; This directive may be different, but in most cases it is the way to allocate space for local variables.
And then we start executing our code,
After this protection is added, a directive like this is added after sub ebp,n:
mov DWORD ptr [ebp-4],xxx
XXX is the value of the security cookie, this value is stored in the global variable, through the RVA+PE header address, can actually be said to be
The absolute address to refer to.
Here the value of the security cookie is written to the stack and then detected before the function returns.

When you get here, you're probably going to have a new problem.
Must a security cookie be written for each function call to protect it?
The answer is no, otherwise the execution efficiency of our program will be affected, and may not be small.
Then, there should be some rules, when to do this protection, when not needed.
The basis of course is also very simple, there is overflow possible, on the addition of such protection, no overflow possible, not added.
What is the possibility of overflow?
This is the compiler to judge, like a function defined in the char array, followed by a string manipulation function to do a certain operation, it is explained
There may be an overflow. The compiler adds security cookie protection when compiling this function.
There are, of course, some other very specific rules that are described in more detail on MSDN.

There are other issues that are not explained here and can be left to everyone.
1. Is there a way to deal with security cookie detection? (The answer is yes, but it seems to be not very beautiful)
2. Exception handling function for security exceptions
Changes of 3./safeseh to SEH processing

"Discussion" _security_cookie's question

#include <stdlib.h>voidstudy1 () {Charstr[4];//Mark agets (str); printf ("The content you entered is \n%s", str); }intMainintargcChar*argv[])  {study1 (); System ("PAUSE"); return 0;}

What is not clear is, in the above "mark one", if str length is less than or equal to 4,release why did not generate _security_cookie ah? If the length is greater than 4, the _security_cookie is generated, and I'm experimenting with VS 2005,
Ask to see the snow cow cow to answer ...

When the application starts, the cookie of the program (4 bytes (DWORD), unsigned integer) is computed (pseudo-random number) and saved in the. Data section of the load module, at the beginning of the function the cookie is copied to the stack, located directly in front of the EBP and return address (located in the return Back to the middle of the address and local variables). [Buffer] [Cookie] [SAVEDEBP] [Savedeip] At the end of the function, the program compares this cookie with the cookie stored in the. Data section. If they are not equal, the process stack is destroyed and the process must be terminated. To minimize the performance impact of additional lines of code, the compiler saves cookies on the stack only if a function contains a string buffer or uses the _ALLOCA function to allocate spaceon the stack. Also, when a buffer is at least 5 bytes

"Turn" two articles about __security_cookie