gdb 查看是否 栈溢出_[原理分析]Linux下的栈溢出案例分析-GDB调试操练[1]

摘要： 本文主要演示linux平台下的栈溢出，首先依据理论对演示样例代码进行溢出攻击；结果是溢出攻击成立，可是与设想的有区别。然后採用GDB调试工具对发生的意外。进行深入的分析。

測试的平台：1.  ubuntu 9;   gcc 4.4.1;   Gdb 7.0-ubuntu

2.  ubuntu系统安装在virtual box 3.2.8虚拟机上。

演示样例代码例如以下：

#include

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

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

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

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之，发