摘要：
本文主要演示linux平台下的栈溢出，首先依据理论对演示样例代码进行溢出攻击；结果是溢出攻击成立，可是与设想的有区别。然后採用GDB调试工具对发生的意外。进行深入的分析。
測试的平台：
1. ubuntu 9; gcc 4.4.1; Gdb 7.0-ubuntu
2. ubuntu系统安装在virtual box 3.2.8虚拟机上。
演示样例代码例如以下：
#include<string.h>
void overflow(char* arg)
{
char buf[12];
strcpy(buf, arg);
}
int main(int argc, char *argv[])
{
if(argc > 1)
overflow(argv[1]);
return 0;
}
假设依照一般的方式编译：
gcc –o stackoverflow stackoverflow.c
linux系统可以探測到程序中的stack overflow，从而终止程序，例如以下图所看到的：
那有没有办法让系统不探測到stack overflow。此处能够在编译时，禁用堆栈保护，详细命令例如以下：
gcc –fno-stack-protector –o stackoverflow stackoverflow.c
然后採用gdb调试stackoverflow，
这里的输出跟设想的存在非常大的区别，由于设想中的函数栈例如以下：
前面的12个字节填充buf，然后接下来的4个字节填充ebp，最后的4个字节填充RET地址。那么照理说，这里的eip应该是0x65656565，那为什么此处是0x61616161，刚好是aaaa的值呢？
依据单步调试的结果。发现eip变为0x61616161是在main函数退出后达到的，依照设想应该是在overflow退出时。eip变为0x65656565。
为什么overflow退出后还能回到main函数？可能的原因：输入的字符串没有覆盖掉ret地址，可是字符串却意外地将main的返回地址给覆盖掉了？
但就算是覆盖，为什么覆盖的值没有採用e的值，而是採用的a的值？要知道a是在字符串的起始处？这点的确让人奇怪。
1. 我们还是採用一步步调试的方式来观察问题所在。先看下gcc编译后的反汇编代码：
使用到的命令:
set disassembly-flavor intel //将汇编设定为intel风格；
disassemble main //反汇编main函数。
Main函数：
1. push ebp 2. mvo ebp, esp 3. and esp, 0xfffffff0 4. sub esp, 0x10 5. cmp DWORD PTR [ebp+0x8], 0x1 6. jle 0x804841d <main+31> 7. mov eax, DWORD PTR [ebp+0xc] 8. add eax, 0x4 9. mov eax, DWORD PTR [eax] 10. mov DWORD PTR [esp], eax 11. call 0x80483e4 <overflow> 12. mov eax, 0x0 13. leave 14. ret
然后再来看下。overflow的反汇编代码，命令：disassemble overflow
Overflow函数：
1. push ebp 2. mov ebp, esp 3. sub esp, 0x28 4. mov eax, DWORD PTR[ebp+0x8] 5. mov DWORD PTR[esp+0x4], eax 6. lea eax, [ebp-0x14] 7. mov DWORD PTR [esp], eax 8. call 0x804831c <strcpy@plt> 9. leave 10. ret
我们单步调试上述的指令，关注当中esp值的变化。
总图例如以下，后面是对当中每一步的分析：
在完毕main.1后，命令p $esp后，esp的值变为：Esp = 0xbffff438
Main.3后。esp的值变为0xbffff430，预计是用于对齐；
Main.4后，esp的值为0xbffff420；
Main.7-10，这里主要将argv[]的arg[1]字符串的首地址取出来。而且将其放置在esp中，此时esp的值为0xbffff420；
运行overflow.1后。esp的值变为：0xbffff41c，当中存放着main的下一条语句的地址。
通过命令：x $esp能够看到overflow返回的地址：
0xbffff41c 0x0804841d
Overflow.1运行后，esp的值变为0xbffff418，用于存放ebp的值；
Overflow.3运行后，esp的值变为0xbffff3f0，
Overflow.5-7运行后，将字符串的地址放置在3f0+0x4地址处，然后再将暂时字符串也即buf的首地址[ebp-0x14]放置在3f0地址处(当前的esp指向处)；
运行完overflow.8后，我们查看buf起始处后，发现的确完毕了内容的赋值，命令例如以下：
X 地址。
运行完leave指令后，发现esp的值变为：0xbffff41c。刚好指向的返回main的地址；然后再运行ret指令后。发现esp变为0xbffff420。然后，程序跳回到main函数；
然后再运行main函数中的leave指令，依照设想中leave指令运行后。esp的值应该变为43c，指向main的返回地址；可是实际我们运行后，esp的值变为0xbffff404，当中的内容刚好是0x61616161。也就是aaaa的值；这里我们測试时使用的參数的头四个字符刚好是aaaa；
到这里为止，就明确整个问题的症结：
Main函数中调用leave指令时。esp的值并没有调整到位。本来应该指向43c(前面的地址忽略)的，此处却指向的404？
那么为什么会产生这种状况？照理说这是编译器该干的事。为什么此处编译器没有尽责呢？
奇怪的是：
不发生栈溢出时，也即我们输入的字符串长度不超过12时，main中的leave指令运行后，程序能够正常的返回到43c的位置，顺利退出。
那这里的问题就非常奇怪了：栈溢出是发生在overflow中。程序能够从overflow中顺利返回到main中，然后main的leave指令就不正常了。假设overflow中没有栈溢出，程序也顺利返回到main函数，然后main的leave指令能够正常工作。
上述的问题的症结在于搞清楚leave指令本身；猜想其可能会依赖某些寄存器，或者依赖特定的存储单元来达到恢复目的。
首先看看能不能stepi进入leave；答案是leave是单条指令。不是一个处理函数；
所以我们试试能不能从寄存器上发现点什么。发现事实上对比vistual studio中的操作，
Leave指令应该等效为：
Mov esp, ebp
Pop ebp
之前关注的都是esp，那依照上面的等效的话，接下来应该关注ebp寄存器的变化。
所以，接下来要做的1. 首先验证上述的的等效成立，2. 要盯着ebp在运行过程中的变化。
对于问题1的验证，我们偷个懒，直接baidu之，发