面对这个栈溢出这个重灾区，Windows在VS 7.0(Visual Studio 2003)及以后版本的Visual Studio中默认启动了一个安全编译选项——GS（针对缓冲区溢出时覆盖函数返回地址这一特征），来增加栈溢出的难度。
（GS Break----配置属性----c/c++----代码生成----缓冲区安全检查）
（很明显，对没有重新编译的软件来说，得不到保护，仍旧有这种安全漏洞。）
GS编译选项为每个函数调用增加了一些额外的数据和操作，用以检查栈中的溢出：
1、在所有函数调用发生时，向栈帧内压入一个额外的随机DWORD，这个随机数被称为canary（想把栈帧数据当成金丝雀般用笼子圈起来），如果用IDA反汇编的话，会看看到IDA会将这个随机数标志为Security Cookie。
2、Security Cookie位于EBP之前，系统还将在.data的内存区域中存放一个Security Cookie的副本，从而进行校验；
3、当栈中发生溢出时，Security Cookie将被首先淹没，之后才是EBP和返回地址；
4、在函数返回之前，系统将会执行一个额外的安全验证操作，被称作Security Check；
5、在Security Check的过程中，系统将比较栈帧中原先存放的Security Cookie和.data中副本的值，如果两者不吻合，说明栈中的Security Cookie已经被破坏了，即栈中发生了溢出；
6、当检测到栈中发生溢出时，系统将进入异常处理流程，函数不会被正常返回，ret指令也不会被执行。
但是额外的数据和操作带来的直接后果就是系统性能的下降，为了将对性能的影响降到最小，编译器在编译程序的时候并不是对所有的函数都应用GS，一下情况不会应用GS：
1、函数不包含缓冲区；
2、函数被定义为加油变脸参数列表；
3、函数使用无保护的关键字标记；
4、函数在第一个语句中包含内嵌汇编代码；
5、缓冲区不是8字节类型而且大小不大于4个字节。
（有了例外，就有利用相对特性的GS突破。）
除了在返回地址钱添加Security Cookie外，在Visual Studio 2005及后续版本还使用了变量重排技术，在编译时根据局部变量的类型对变量在栈帧中的位置进行调整，将字符串变量移动到栈帧的高地址。这样可以防止该字符串溢出时破坏其他的局部变量。同时还会降指针参数和字符串参数复制到内存中的低地址，防止函数参数被破坏。
GS的Security Cookie产生的一些细节：
1、系统以.data节第一个双字作为Cookie的种子，或者原始Cookie（所欲函数的Cookie都用这个DWORD生成）
2、在程序每次运行时Cookie的种子都不用，因此种子加油很强的随机性；
3、在栈帧初始化以后系统用EBP异或种子，作为当前函数的Cookie，以此作为不同函数之间的区别，并增加Cookie的随机性；
4、在函数返回时前，用EBP还原出（异或）Cookie的种子。
突破方法：
1、利用未被保护的内存突破GS。为了将GS对性能的影响降到最小，并不是所有的函数都会被保护，所有就可以利用其中一些未被保护的函数绕过GS的保护；
2、基于改写函数指针的攻击，如C++虚函数攻击；
3、针对异常处理机制的攻击；
4、堆溢出没有保护。
