GS保護檢測棧溢出，在函數調用時向棧幀中壓入一個額外的隨機DWORD,就是常見的逆向代碼中的Security Cookie.
Security Cookie 位於EBP之前，系統還將在.data的內存區域中存放一個Security Cookie的副本。
系統比較棧幀中原先存放的Security Cookie和.data中的副本的值是否一致。來判定棧是否被破壞。
當檢測到棧中發生溢出時，系統將進入異常處理流程。函數不會被正常返回。ret指令也不會被執行。系統以.data節的第一個雙字節作爲原始Cookie，所用的函數Cookie都是通過此DWORD生成，程序每次運行時原始Cookie都不同，在棧幀初始化後系統用EBP異或原始Cookie，作爲當前函數的COokie.增加不同的函數Cookie隨機性。函數返回前在異或回去。
若統一將函數都GS保護，GS操作將大大影響系統性能，因此在設計時部分情況不會用GS,因此對繞過GS就有了可乘之機。
下面幾種情況編譯器不會應用GS.
1.函數不包含緩衝區。
2.函數被定義爲具有變量參數列表。
3.函數使用無保護的關鍵字標記。
4.函數第一個語句中包含內嵌彙編代碼。
5.緩衝區不是8字節類型且大小不大於4個字節。
Visual Studio 2005後加入變量重排技術。編譯時將局部變量類型對變量在棧幀中毒的位置進行調整。將字符串變量移動到棧幀的高地址。防止在字符串溢出對其他局部變量的破環。同時將指針參數和字符串參數複製到內存中低地址。防止函數參數被破壞。
程序員可對特殊的不符合GS保護條件的函數添加GS保護。通過#pragram strict_gs_check(on)添加Security Cookie.
#pragram strict_gs_check(on)//爲此函數強制啓用GS
int sometingFunc(char * str)
{
char arry[4]; //緩衝區太小。
strcpy(arry,str);
return 1;
}
vs2017中的啓用編譯器啓用GS保護。
