stack cookie的两种讲法
- windows平台上叫 /GS:cookie
- linux上叫Stack Canary
它的原理就是在ebp-4的地方插入一个随机数（4字节还是8字节看计算机位数了），然后在函数返回（return）的时候会调用另一个函数去检查这个值是否被修改，如果被修改了的话就终止程序，这就使得经典栈溢出的手法难以奏效
- 首先在windows平台上，在vs编译的时候有那个安全选项可以加上，然后在调试的时候就直接看函数，我们会发现在以前的经典的push ebp mov ebp esp , sub esp , 88h这些之后呢，还会有一个mov eax , dword prt [stack_overflow_gs!_security_cookie(00416000)] xor eax,ebp 这样类似的东西，这个其实就是添加一个随机数进去，然后在程序的结束部分还有一个对应的操作 mov ecx,doword prt [ebp-4] xor ecx,ebp call stack_overflow_gs!ILT_25(_security_check_cookie)(00416000)这类操作（具体代码可能不一样但是都是这个意思）
- 下面详细说一下：
调试可以发现那个cookie的初始值0041600其实就是.data段的起始地方，在程序运行得时候这里面是个随机数字，但是你在原始文件的PE里面可以看，.data段的值不是全部一样的，为啥呢？其实是在start函数后的有一个_mainCRTStartup的一个库启动的时候有一个函数调用__security_init_cookie 下面是ida里面的情况
我们可以看出cookie的值有一套自己的计算逻辑，基本上是以系统时间，进程id,性能计数器等作为可变元
stack_overflow_gs!ILT_25(_security_check_cookie)这个函数做了什么？ 其实里面就是一个cmp 的比较不相等的话跳到函数里面的另一个函数里（这个函数就是终止程序啦，反馈信息了，这么一些个操作），OK windows上差不多就这些。
下面这个讲linux上的cookie，这个是当前时期的重点：
首先它跟windows第一点的不同就是代码顺序
它这个其实是在栈开辟完成后进行的一盘操作而且我们也看到了，这个canary的位置是在ebp - 0xc的位置，然后要知道的一点就是cookie的初始化是在glibc里面进行的，但是不要认为cookie是glibc生成的，其实是内核给的glibc
- 然后还是最后有个检查嘛
下面最最重要的当然是破解手法了：
- 其一肯定是暴力破解cookie值，但是这个应用场景有限，你要是没啥前提条件单纯的跑程序的话，cookie的值每次都会变，估计你就呵呵呵了，那么，这个前提条件就是子进程存在栈溢出漏洞（linux上子进程跟父进程之间关系严格）这个意思就是子进程无限的fork，因为在这个时候它的哪个cookie事实上是继承的父进程的cookie，那么父进程fork的时候给子进程的cookie都是哪一个，那么你就暴力破解吧。
- leak info(OOB read，file log) 意思就是程序还存在其他漏洞，想越界读取啊 ， 格式化字符串啊， 其他的一些输出函数啊 ，那么我们调整一些参数，利用这些漏洞可以得到Cookie的值啊。
- 迂回绕过，这意思就是我们可以避开cookie的检查（例如我们可以不修改你的ebp , ret_addr，我们就简单的修改你的局部变量来改变程序流程）
- 这个就是我们既然得不到cookie, 那么意思就是__stack_chk_fial@plt这个函数非要执行不可了，那我们可以把这个函数给got劫持了，把它里面.got.plt那个地址改成我们shellcode的地址。
