缓冲区溢出实验最让人头疼的哈工缓冲地方，不是大计洞攻写exploit，而是算机实验搞明白那个该死的栈帧到底长什么样。哈工大CSAPP实验三给的系统target程序，表面上看就是器漏个普通的输入读取，但objdump反汇编之后，哈工缓冲你会发现getbuf函数的大计洞攻栈布局比课本上的示意图阴险得多。

先看核心代码。算机实验test函数调用getbuf，系统getbuf里声明了一个char数组，器漏大小是哈工缓冲32字节。按常理，大计洞攻输入超过32字节就会覆盖返回地址。算机实验但问题在于，系统编译器可能插入栈保护、器漏对齐填充，甚至把数组放到奇怪的位置。我第一遍做的时候，输入了44个字节才碰到返回地址，跟理论值差了8字节——那8字节是编译器用来对齐的padding。所以别信课本，信gdb。

实验分五个关卡，从简单到变态。Level 1要求调用一个现成的smoke函数，啥也不用干，把返回地址改成smoke的入口就行。听起来简单，但栈的字节序是小端，地址得倒着写。我第一次写的时候把0x08048e20写成了20 8e 04 08，结果跳到了非法地址，程序直接segfault。后来用gdb的x/20bx $esp看栈内容，才发现自己少写了一个字节。

Level 2开始上强度。要传参数给函数，还得让函数正常返回。这里得构造一段shellcode，把参数塞进寄存器，再跳转到目标函数。cookie值是个8字节的常数，得先想办法读到它。我当时的做法是用gdb在getbuf返回前打断点，直接print $eax，省了不少事。

Level 3最阴间。要绕过栈随机化，还得让程序跳到自己注入的代码里。ASLR开着的时候，每次栈地址都不一样，但实验环境里ASLR是关的，所以栈地址固定。即便如此，找到buf的起始地址还是得靠gdb。我在buf首地址处放shellcode，返回地址指向buf开头。注意shellcode不能有0x00字节，否则strcpy会截断。写汇编的时候得挑指令，比如用xor eax,eax代替mov eax,0。

Level 4要改全局变量。这关的坑在于，目标变量在.bss段，地址固定，但得让程序在返回前执行一段ROP链。我用了pop-ret gadget来设置寄存器，再调用目标函数。找gadget用ROPgadget工具，一条命令就能列出所有可用片段。但注意，有些gadget地址含0x0a或0x0d，会被scanf当成换行符吃掉，得避开。

Level 5是终极形态，栈不可执行，只能纯ROP。这时候得把整个攻击链拆成多个gadget，每个gadget做一小步，最后拼出完整逻辑。我花了整整一个下午调这关，最后发现是某个gadget的地址写错了——少了一个字节。用gdb单步跟的时候，看到eip跳到了奇怪的地方，才定位到问题。

整个实验做下来，最大的收获不是学会了写exploit，而是对栈帧的理解从二维图变成了三维直觉。以前看课本上的栈布局图，觉得清清楚楚；真到gdb里看内存，才发现编译器会塞各种东西进去，对齐、canary、临时变量，全挤在一起。有个细节我印象很深：getbuf的栈帧里，buf数组和返回地址之间其实还夹着8字节的saved ebp，但课本的简化图里经常省略这个。不省略的话，偏移量算错，exploit就废了。

实验环境是32位Linux，gcc默认开了栈保护。编译的时候得加-fno-stack-protector，否则canary会把栈写得乱七八糟，攻击根本没法做。还有，gdb里看栈的时候，x/40wx $esp比x/40bx $esp好用，因为地址是4字节对齐的，按字看更直观。

最后说个实用技巧：写exploit的时候，先用python生成payload，再重定向到target程序。别直接在终端里敲，二进制数据会乱码。python里用struct.pack(‘<I’, addr)来打包小端地址，比手动拼字节靠谱得多。我一开始手动拼，拼错了好几次，后来全改用struct，错误率直线下降。

(责任编辑：综合)