---

1，安全Cookie(Security Cookie）

安全Cookie功能打开之后，编译器在编译程序的时候，会在栈上放置一个安全Cookie值，如下图所示，同时在程序的.data段里保存这个cookie的副本。一旦在栈上发生溢出，覆盖EIP返回地址之前，必然会同时覆盖这个cookie值。因此，只要将栈上的cookie值和对应的副本进行比较，就可以判断是否发生了栈溢出。

2，SafeSEH

SafeSEH安全选项，需要操作系统和编译器双重支持。编译器启用该链接选项之后，编译器在编译程序的时候将把所有的异常处理函数地址提取出来，编入一张安全的S.E.H表，并将这张表放到程序的映像里。当程序调用异常处理函数的时候会将函数地址与S.E.H表进行匹配，检查调用的异常处理函数是否位于安全S.E.H表中

dumpbin  /loadconfig 文件名 可显示S.E.H表

操作系统：RtlDispatchException()-->RtlIsValidHandler()来对异常处理函数的有效性进行验证的。

 

3，DEP-Data Execution Prevention

DEP的基本原理是将数据所在内存页标识为不可执行，当程序溢出成功转入shellcode时，程序会尝试在数据页面上执行指令，此时CPU就会抛出异常，而不是去执行恶意指令。

软件DEP，检测代码在可执行页上

硬件DEP，需要CPU支持。AMD叫No-Execute Page-Protection(NX),Intel为Execute Disable Bit(XD)

4，ASLR-Address Space Layout Randomnization

Address Space Layout Randomization

需编译器和操作系统双重支持

/dynamicbase

映像随机化，堆栈随机化，PEB，TEB随机化，重启系统之后，各种地址会随机改变，因此像栈溢出中经常使用的JMP ESP这种跳板指令的地址以及各种API地址就不好确定了

5，SEHOP-Structured Exception Handling Overwrite Protection

SEHOP的核心任务就是检查这条S.E.H链的完整性，在程序转入异常处理前SEHOP会检查S.E.H链上最后一个异常处理函数是否为系统固定的终极异常处理函数。如果是，则说明这条S.E.H链没有被破坏，程序可以去执行当前的异常处理函数；如果检测到最后一个异常处理函数不是终极BOSS，则说明S.E.H链被破坏，可能发生了S.E.H覆盖攻击，程序将不会去执行当前的异常处理函数

6，堆保护

PEB random，PEB基址：0x7ffdf000，xp sp2后，随机化。避免了DWORD shoot修改PEB中的函数指针

7，SafeUnlink

一个更安全的内存分配中的双向链表节点摘除函数如下：safe_remove()，首先判断该节点的前向结点的后面结点以及后向结点的前面结点是否仍为本结点。如果是，那么就表明没有出现溢出覆盖，否则就已经发生了溢出覆盖。

/*不安全的结点移除算法*/

int remove(ListNode *node)

{

    node->blink->flink = node->flink;

    node->flink->blink = node->blink;

    return 0;

}

/*增加了溢出判断的安全的结点移除算法*/

int safe_remove(ListNode *node)

{

    if((node->blink->flink==node)&&(node->flink->blink==node))

    {

        node->blink->flink = node->flink;

        node->flink->blink = node->blink;

        return 1;  

    }

    return 0;

}

8，Heap cookie

 

Heap cookie的原理与栈上的Security cookie原理类似，都是增加一个cookie，并保存一个副本。一旦发生堆溢出的时候，这个cookie必然会被改变，因此只要检测其和副本是否一致，就可以判断是否发生了堆溢出，从而防止堆上的溢出攻击。