實驗要求：調研 VC .net 或 GCC 4.*中的 Canary 技術實現， 弄懂原理並設計相應的實驗例程進行測試，編制相應 報告。
實驗環境：
Windows 10， 編譯器配置爲 TDM-GCC 4.8.1 64-BIT Debug
實驗主題：
調研 GCC 4.*中的 Canary 技術：
原理：
1、 在所有函數調用發生時，向棧幀內壓入一個額外的隨機 DWORD，這個隨機數被稱作
“canary”，用 IDA 反彙編時，又被稱作“Security Cookie”。
2、 canary 位於 EBP 之前，系統還會在.data 的內存區域中存放一個 canary 的副本。
3、 當棧中發生溢出時，canary 將被首先淹沒，之後纔是 EBP 和返回地址。
4、 在函數返回之前，系統將執行一個額外的安全驗證操作，稱作 Security Check。 5、在 Security Check 過程中，系統將比較棧幀中原先存放的 canary 和.data 中副本的值，若兩者不同，則說明棧中發生了溢出，系統將進入異常處理流程，函數不會正常返回。
如圖所示，（圖自 Dynamic Canary Randomization for Improved Software Security 論文）
GCC 4. 中的堆棧保護實現：*
Stack Guard 是第一個使用 Canaries 探測的堆棧保護實現，它於 1997 年作爲 GCC 的一個擴展發佈。最初版本的 Stack Guard 使用 0x00000000 作爲 canary word。儘管很多人建議把 Stack Guard 納入 GCC，作爲 GCC 的一部分來提供堆棧保護。但實際上，GCC 3.x 沒有實現任何的堆棧保護。直到 GCC 4.1 堆棧保護才被加入，並且 GCC4.1 所採用的堆棧保護實現並非 Stack Guard，而是 Stack-smashing Protection（SSP，又稱 ProPolice）。 SSP 在 Stack Guard 的基礎上進行了改進和提高。它是由 IBM 的工程師 Hiroaki Rtoh 開發並維護的。與 Stack Guard 相比，SSP 保護函數返回地址的同時還保護了棧中的 EBP 等信息。此外，SSP 還有意將局部變量中的數組放在函數棧的高地址，而將其他變量放在低地址。這樣就使得通過溢出一個數組來修改其他變量（比如一個函數指針）變得更爲困難。
個人思考：
- 可以看出，canary code 作爲 stack 的一個有效的保護機制，可以有效地防止通過緩衝區溢出覆蓋函數返回地址，只犧牲程序的一小部分性能的代價。
- 通過隨機不同函數返回地址前的 canary code 在程序每次運行時 Cookie 的種子都不相同，增強的隨機性，增加破解 canary code 的難度。
- 侷限性： a）根據原理看出 canary code 不能防止函數返回地址前的緩衝區溢出。 b）可利用未保護內存繞過 canary 機制，由於緩衝區不是 8 字節類型且大小不大於 4 個字節可通過緩衝區不大於 4 字節的棧溢出直接繞過，此部分不經過 canary 保護 c) 可能根據不同機器棧地址的增長機制或不同分配影響 canary code 的保護功能。
檢驗實驗：編寫緩存區溢出，覆蓋函數返回地址的攻擊代碼：
打開 gcc canary 棧保護編譯選項：-fstack-protector-all 運行結果，成功檢測：
關閉 canary 棧保護選項後運行：發現不能成功檢測，程序運行數秒後崩潰