___security_cookie机制，防止栈溢出
从研究底层和汇编以来，已经多次接触到“栈溢出”这个名词了。
这次在汇编码中看到了个不明就里的 ___security_cookie ，查了下，原来是编译器的安全检查机制。转载一篇文章：
首先，security cookie并不是windows系统自带的保护机制，并不是说一个确实存在溢出漏洞的
程序，放到带security cookie保护的环境中，就不能正常溢出了。
那么，到底是什么是security cookie呢？
我觉得从广义上讲，它应该是一种保护栈的机制，提供这种保护的，是程序本身，编译进程序本身的
代码提供的，而不是系统中某个运行在黑暗角落中的线程。
所以，既然是程序自身就带上的，为了不给程序员带来额外的负担，这份工作就交给编译器来完成了。
vc6.0的cl.exe是不带这个功能的，只有vc.net以后面版本的cl.exe才带这个功能，就所谓的/GS选项。
即用vc.net的cl编译器时，/GS选项默认就打开了。
现在，我们知道了这个机制的提供方，那么，这个机制到底是怎么一回事呢？
熟悉函数调用及返回前后的汇编指令的人肯定很清楚，在win32平台，对于stdcall类型的函数调用，
当call指令运行完毕，当前的堆栈结构基本上是这样的：
局变2 ebp-8 低地址
局变1 ebp- 4
ebp ebp
返回地址 ebp+4
参数1 ebp+8
参数2 ebp+c
参数3 ebp+10
参数4 ebp+14 高地址
第一列是堆栈中存放的dword的内容，第二列是用ebp作为栈地址的索引时，它对应的应该用ebp表示的值，
说得形象一点，ebp中存放着栈的一个地址(栈其实也是一片内存，ebp只是指向其中一个对当前函数内部比较
重要的地址，其实是相当重要)，栈的其它位置都是通过这个ebp来寻址的，即我们给函数的第一个形参的
地址，就是ebp+8,第二个就是ebp+c,我们定义的局部变量的地址，第一个局部变量是ebp-4,第二局部变量的
地址就是ebp-8，依此类推。但这也不是一定的，上面说的是理想情况，如果我们在函数里定了一个数组，
如 char buf[8];并且是定义的第一个局部变量，那么它的地址肯定就不是ebp-4,还是ebp-8。所以，数组
比较特殊，结构体也比较特殊，其根本原因是栈是从高地址向低地址生长的，而我们的数组，结构体，
却是从低向高地址生长的，两者矛盾的结果就是寻址上的微妙变化。
当然，这里为了方便说明问题，都默认定义的变量，传入的参数，都是四字节对齐的，并且一个变量一个
双字。你可以把数组理解一个4字节的char,也就是一个双字了。
话说回来，当call运行完毕，当前的堆栈结构已经给出，如果在函数里调用strcpy()往局部变量1 里考入
东西，对长度没有进行检测，那么ebp-4,ebp,ebp+4,还有后面的地址，其所在的内容都会被覆盖掉。这里
溢出就发生了，我们控制住了ret的返回地址，然后...
嗯，为了防止这一切，新的cl编译器的/GS选项加上入所谓的"security cookie"，如何加入的？在哪加入的
呢？
先看看加入"security cookie"后的call指令运行完以后，堆栈的变化。
局变2 ebp-c 低地址
局变1 ebp-8
XXXXX ebp-4
ebp ebp
返回地址 ebp+4
参数1 ebp+8
参数2 ebp+c
参数3 ebp+10
参数4 ebp+14 高地址
变化很明显，在ebp上面，第一个局部变量的下面，填入的一个新的值，这个值就是所谓的"security cookie"
.按照前面说的溢出过程，ebp- 4的内容被覆盖掉，即security cookie的值被修改，在函数返回，即执行ret
指令前，会call另一个函数，这个函数就是用来对比 ebp-4的值和当时push到栈中的值是不是一样，不一样的
话，就说明溢出了，然后进程被终止。
那么，你大概会产生以下几个问题：
1. 这个security cookie是如何计算出来的？
security cookie是一个双字，也可以说是一个int,其本身是保存在全局变量里的，其创建是编译器在编译
阶段就创建的，然后写入到.data段里，即在PE里就保存了这个值。
但这个值又是变化的，windows装载器完成必要的前期准备工作后(如创建进程，为栈分配内存，等待)
把 EIP设置为PE里的代码入口处，第一个执行的指令就是一个call调用，这个call调用就是用来初始化这个
cookie值的，当然，这段代码也是公开的，但没有关系，这个算法保证这个cookie值是随机的，hacker也
是不能在一个shellcode中可以猜出来的。
具体算法我不打算在此说明，感兴趣的读者可以自己编译一下再反汇编一下看看。
2.是什么时候填入到栈里面的？
我们知道了这个 security cookie的计算和初始化过程，那么，它必须在函数调用时写入到ebp-4里面才有用。
所以，过去的不带这种保护的代码，在函数入口处一般是这样的：
push ebp
mov ebp,esp
sub ebp,n ;这条指令可能不同，不过多数情况下都是这样来为局部变量分配空间的
然后，后面就开始执行我们的代码了，
加入这种保护后，会在sub ebp,n后面，加入一条像这样的指令：
mov dword ptr [ebp-4],XXX
XXX就是security cookie的值，这个值保存在全局变量里，通过RVA＋PE头地址，实际上也可以说成是
绝对地址来引用了。
到这里security cookie的值就写入栈了，然后在函数返回前检测一下就行了。
到了这里，你大概又会产生一个新的问题，
必须为每一个函数调用都写入security cookie进行保护吗？
答案是否定的，要不然我们的程序的执行效率会受到一定的影响，并且可能还不小。
那么，就应该存在一定的规则，什么时候进行这种保护，什么时候不需要。
其依据当然也很简单，有溢出可能的，就加入这种保护，没有溢出可能的，就不加。
那怎么样才算是有溢出可能呢？
这个是编译器进行判断的，像函数里定义了char数组，后面又用字符串操作函数进行了一定的操作，就说明
可能存在溢出。编译器在编译这个函数里的时候就加上security cookie的保护。
当然，这里还有一些其它的很具体的规则，在msdn里有更详细的描述。
还有其它一些问题没有在这里说明，可以把这些问题留给大家
1.有对付security cookie的检测的方法吗？(答案是有的，但好像都不是很优美)
2.有关security异常的异常处理函数
3./safeSEH对 SEH处理的变化
【讨论】_security_cookie的问题
#include <stdlib.h> void study1() { char str[4]; //标记一 gets(str); printf("你输入的内容是 %s",str); } int main(int argc, char* argv[]) { study1(); system("PAUSE"); return 0; }
不明白的是，在上述"标记一"处，如果str的长度小于等于4，release下为什么没有生成_security_cookie啊？如果长度大于4就会生成_security_cookie,我是在vs 2005下试验的，
求看雪牛牛给解答……
当应用程序启动时，程序的cookie（4字节（dword），无符号整型）被计算出来（伪随机数）并保存在
加载模块的.data节中,在函数的开头这个cookie被拷贝到栈中，位于EBP和返回地址的正前方（位于返
回地址和局部变量的中间）。
[buffer][cookie][savedEBP][savedEIP]
在函数的结尾处，程序会把这个cookie和保存在.data节中的cookie进行比较。
如果不相等，就说明进程栈被破坏，进程必须被终止。
为了尽量减少额外的代码行对性能带来的影响，只有当一个函数中包含字符串缓冲区或使用_alloca函数
在栈上分配空间的时候编译器才在栈中保存cookie。另外，当缓冲区至少于5个字节时，在栈中也不保
存cookie。
在典型的缓冲区溢出中，栈上的返回地址会被数据所覆盖，但在返回地址被覆盖之前，cookie早已经被
覆盖了，因此就导致了exploit的失效（但仍然可以导致拒绝服务），因为在函数的结尾程序会发现cookie
已经被破坏，接着应用程序会被结束。