缓冲区溢出与注入分析
虽然程序加载以及动态符号链接都已经很理解了，但是这会儿却被进程的内存映像给”纠缠"住。看着看着就一发不可收拾——很有趣。
下面一起来探究“缓冲区溢出和注入”问题（主要是关心程序的内存映像）。
永远的
Hello World，太熟悉了吧，#include <stdio.h>
int main(void)
{
printf("Hello World\n");
return 0;
}
如果要用内联汇编（
inline assembly）来写呢？ 1 /* shellcode.c */
2 void main()
3 {
4 __asm__ __volatile__("jmp forward;"
5 "backward:"
6 "popl %esi;"
7 "movl $4, %eax;"
8 "movl $2, %ebx;"
9 "movl %esi, %ecx;"
10 "movl $12, %edx;"
11 "int $0x80;" /* system call 1 */
12 "movl $1, %eax;"
13 "movl $0, %ebx;"
14 "int $0x80;" /* system call 2 */
15 "forward:"
16 "call backward;"
17 ".string \"Hello World\\n\";");
18 }
看起来很复杂，实际上就做了一个事情，往终端上写了个
Hello World 。不过这个非常有意思。先简单分析一下流程：- 第 4 行指令的作用是跳转到第 15 行（即
forward标记处），接着执行第 16 行。 - 第 16 行调用
backward，跳转到第 5 行，接着执行 6 到 14 行。 - 第 6 行到第 11 行负责在终端打印出
Hello World字符串（等一下详细介绍）。 - 第 12 行到第 14 行退出程序（等一下详细介绍）。
为了更好的理解上面的代码和后续的分析，先来介绍几个比较重要的内容。
X86 处理器平台有三个常用寄存器：程序指令指针、程序堆栈指针与程序基指针：寄存器 | 名称 | 注释 |
EIP | 程序指令指针 | 通常指向下一条指令的位置 |
ESP | 程序堆栈指针 | 通常指向当前堆栈的当前位置 |
EBP | 程序基指针 | 通常指向函数使用的堆栈顶端 |
当然，上面都是扩展的寄存器，用于 32 位系统，对应的 16 系统为
ip，sp，bp 。call指令跳转到某个位置，并在之前把下一条指令的地址（EIP）入栈（为了方便”程序“返回以后能够接着执行）。这样的话就有：call backward ==> push eipjmp backwardret指令通常call指令和ret是配合使用的，前者压入跳转前的下一条指令地址，后者弹出call指令压入的那条指令，从而可以在函数调用结束以后接着执行后面的指令。ret ==> pop eip
通常在函数调用后，还需要恢复
esp 和 ebp，恢复 esp 即恢复当前栈指针，以便释放调用函数时为存储函数的局部变量而自动分配的空间；恢复 ebp 是从栈中弹出一个数据项（通常函数调用过后的第一条语句就是 push ebp），从而恢复当前的函数指针为函数调用者本身。这两个动作可以通过一条 leave 指令完成。这三个指令对我们后续的解释会很有帮助。更多关于 Intel 的指令集，请参考：Intel 386 Manual, x86 Assembly Language FAQ：part1, part2, part3.
系统调用是用户和内核之间的接口，用户如果想写程序，很多时候直接调用了 C 库，并没有关心系统调用，而实际上 C 库也是基于系统调用的。这样应用程序和内核之间就可以通过系统调用联系起来。它们分别处于操作系统的用户空间和内核空间（主要是内存地址空间的隔离）。
用户空间 应用程序(Applications)
| |
| C库（如glibc）
| |
系统调用(System Calls，如sys_read, sys_write, sys_exit)
|
内核空间 内核(Kernel)
系统调用实际上也是一些函数，它们被定义在
arch/i386/kernel/sys_i386.c （老的在 arch/i386/kernel/sys.c）文件中，并且通过一张系统调用表组织，该表在内核启动时就已经加载了，这个表的入口在内核源代码的 arch/i386/kernel/syscall_table.S 里头（老的在 arch/i386/kernel/entry.S）。这样，如果想添加一个新 的系统调用，修改上面两个内核中的文件，并重新编译内核就可以。当然，如果要在应用程序中使用它们，还得把它写到 include/asm/unistd.h 中。如果要在 C 语言中使用某个系统调用，需要包含头文件
/usr/include/asm/unistd.h，里头有各个系统调用的声明以及系统调用号（对应于调用表的入口，即在调用表中的索引，为方便查找调用表而设立的）。如果是自己定义的新系统调用，可能还要在开头用宏 _syscall(type, name, type1, name1...)来声明好参数。如果要在汇编语言中使用，需要用到
int 0x80 调用，这个是系统调用的中断入口。涉及到传送参数的寄存器有这么几个，eax 是系统调用号（可以到 /usr/include/asm-i386/unistd.h 或者直接到 arch/i386/kernel/syscall_table.S 查到），其他寄存器如 ebx，ecx，edx，esi，edi 一次存放系统调用的参数。而系统调用的返回值存放在 eax 寄存器中。下面我们就很容易解释前面的
Shellcode.c 程序流程的 2，3 两部分了。因为都用了 int 0x80 中断，所以都用到了系统调用。第 3 部分很简单，用到的系统调用号是 1，通过查表（查
/usr/include/asm-i386/unistd.h 或 arch/i386/kernel/syscall_table.S）可以发现这里是 sys_exit 调用，再从 /usr/include/unistd.h 文件看这个系统调用的声明，发现参数 ebx 是程序退出状态。第 2 部分比较有趣，而且复杂一点。我们依次来看各个寄存器，首先根据
eax 为 4 确定（同样查表）系统调用为 sys_write，而查看它的声明（从 /usr/include/unistd.h），我们找到了参数依次为文件描述符、字符串指针和字符串长度。- 第一个参数是
ebx，正好是 2，即标准错误输出，默认为终端。 - 第二个参数是
ecx，而ecx的内容来自esi，esi来自刚弹出栈的值（见第 6 行popl %esi;），而之前刚好有call指令引起了最近一次压栈操作，入栈的内容刚好是call指令的下一条指令的地址，即.string所在行的地址，这样ecx刚好引用了Hello World\\n字符串的地址。 - 第三个参数是
edx，刚好是 12，即Hello World\\n字符串的长度（包括一个空字符）。这样，Shellcode.c的执行流程就很清楚了，第 4，5，15，16 行指令的巧妙之处也就容易理解了（把.string存放在call指令之后，并用popl指令把eip弹出当作字符串的入口）。
这里的 ELF 不是“精灵”，而是 Executable and Linking Format 文件，是 Linux 下用来做目标文件、可执行文件和共享库的一种文件格式，它有专门的标准，例如：X86 ELF format and ABI，中文版。
下面简单描述
ELF 的格式。ELF 文件主要有三种，分别是：- 可重定位的目标文件，在编译时用
gcc的-c参数时产生。 - 可执行文件，这类文件就是我们后面要讨论的可以执行的文件。
- 共享库，这里主要是动态共享库，而静态共享库则是可重定位的目标文件通过
ar命令组织的。
ELF 文件的大体结构：ELF Header #程序头，有该文件的Magic number(参考man magic)，类型等
Program Header Table #对可执行文件和共享库有效，它描述下面各个节(section)组成的段
Section1
Section2
Section3
.....
Program Section Table #仅对可重定位目标文件和静态库有效，用于描述各个Section的重定位信息等。
对于可执行文件，文件最后的
Program Section Table （节区表）和一些非重定位的 Section，比如 .comment，.note.XXX.debug 等信息都可以删除掉，不过如果用 strip，objcopy 等工具删除掉以后，就不可恢复了。因为这些信息对程序的运行一般没有任何用处。ELF 文件的主要节区（section）有 .data，.text，.bss，.interp 等，而主要段（segment）有 LOAD，INTERP 等。它们之间（节区和段）的主要对应关系如下：Section | 解释 | 实例 |
.data | 初始化的数据 | 比如 int a=10 |
.bss | 未初始化的数据 | 比如 char sum[100]; 这个在程序执行之前，内核将初始化为 0 |
.text | 程序代码正文 | 即可执行指令集 |
.interp | 描述程序需要的解释器（动态连接和装载程序） | 存有解释器的全路径，如 /lib/ld-linux.so |
而程序在执行以后，
.data，.bss，.text 等一些节区会被 Program header table 映射到 LOAD 段，.interp 则被映射到了 INTERP 段。对于
ELF 文件的分析，建议使用 file，size，readelf，objdump，strip，objcopy，gdb，nm 等工具。这里简单地演示这几个工具：
$ gcc -g -o shellcode shellcode.c #如果要用gdb调试，编译时加上-g是必须的
shellcode.c: In function ‘main’:
shellcode.c:3: warning: return type of ‘main’ is not ‘int’
f$ file shellcode #file命令查看文件类型，想了解工作原理，可man magic,man file
shellcode: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV),
dynamically linked (uses shared libs), not stripped
$ readelf -l shellcode #列出ELF文件前面的program head table，后面是它描
#述了各个段(segment)和节区(section)的关系,即各个段包含哪些节区。
Elf file type is EXEC (Executable file)
Entry point 0x8048280
There are 7 program headers, starting at offset 52
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x08048034 0x08048034 0x000e0 0x000e0 R E 0x4
INTERP 0x000114 0x08048114 0x08048114 0x00013 0x00013 R 0x1
[Requesting program interpreter: /lib/ld-linux.so.2]
LOAD 0x000000 0x08048000 0x08048000 0x0044c 0x0044c R E 0x1000
LOAD 0x00044c 0x0804944c 0x0804944c 0x00100 0x00104 RW 0x1000
DYNAMIC 0x000460 0x08049460 0x08049460 0x000c8 0x000c8 RW 0x4
NOTE 0x000128 0x08048128 0x08048128 0x00020 0x00020 R 0x4
GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4
Section to Segment mapping:
Segment Sections...
00
01 .interp
02 .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version .gnu.version_r
.rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame
03 .ctors .dtors .jcr .dynamic .got .got.plt .data .bss
04 .dynamic
05 .note.ABI-tag
06
$ size shellcode #可用size命令查看各个段（对应后面将分析的进程内存映像）的大小
text data bss dec hex filename
815 256 4 1075 433 shellcode
$ strip -R .note.ABI-tag shellcode #可用strip来给可执行文件“减肥”，删除无用信息
$ size shellcode #“减肥”后效果“明显”，对于嵌入式系统应该有很大的作用
text data bss dec hex filename
783 256 4 1043 413 shellcode
$ objdump -s -j .interp shellcode #这个主要工作是反编译，不过用来查看各个节区也很厉害
shellcode: file format elf32-i386
Contents of section .interp:
8048114 2f6c6962 2f6c642d 6c696e75 782e736f /lib/ld-linux.so
8048124 2e3200 .2.
补充：如果要删除可执行文件的
Program Section Table，可以用 A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux 一文的作者写的 elf kicker 工具链中的 sstrip 工具。在命令行下，敲入程序的名字或者是全路径，然后按下回车就可以启动程序，这个具体是怎么工作的呢？
首先要再认识一下我们的命令行，命令行是内核和用户之间的接口，它本身也是一个程序。在 Linux 系统启动以后会为每个终端用户建立一个进程执行一个 Shell 解释程序，这个程序解释并执行用户输入的命令，以实现用户和内核之间的接口。这类解释程序有哪些呢？目前 Linux 下比较常用的有
/bin/bash 。那么该程序接收并执行命令的过程是怎么样的呢？先简单描述一下这个过程：
- 读取用户由键盘输入的命令行。
- 分析命令，以命令名作为文件名，并将其它参数改为系统调用
execve内部处理所要求的形式。 - 终端进程调用
fork建立一个子进程。 - 终端进程本身用系统调用
wait4来等待子进程完成（如果是后台命令，则不等待）。当子进程运行时调用execve，子进程根据文件名（即命令名）到目录中查找有关文件（这是命令解释程序构成的文件），将它调入内存，执行这个程序（解释这条命令）。 - 如果命令末尾有
&号（后台命令符号），则终端进程不用系统调用wait4等待，立即发提示符，让用户输入下一个命令，转 1）。如果命令末尾没有&号，则终端进程要一直等待，当子进程（即运行命令的进程）完成处理后终止，向父进程（终端进程）报告，此时终端进程醒来，在做必要的判别等工作后，终端进程发提示符，让用户输入新的命令，重复上述处理过程。
现在用
strace 来跟踪一下程序执行过程中用到的系统调用。$ strace -f -o strace.out test
$ cat strace.out | grep \(.*\) | sed -e "s#[0-9]* \([a-zA-Z0-9_]*\)(.*).*#\1#g"
execve
brk
access
open
fstat64
mmap2
close
open
read
fstat64
mmap2
mmap2
mmap2
mmap2
close
mmap2
set_thread_area
mprotect
munmap
brk
brk
open
fstat64
mmap2
close
close
close
exit_group
相关的系统调用基本体现了上面的执行过程，需要注意的是，里头还涉及到内存映射（
mmap2）等。下面再罗嗦一些比较有意思的内容，参考《深入理解 Linux 内核》的程序的执行（P681）。
Linux 支持很多不同的可执行文件格式，这些不同的格式是如何解释的呢？平时我们在命令行下敲入一个命令就完了，也没有去管这些细节。实际上 Linux 下有一个
struct linux_binfmt 结构来管理不同的可执行文件类型，这个结构 中有对应的可执行文件的处理函数。大概的过程如下：- 在用户态执行了
execve后，引发int 0x80中断，进入内核态，执行内核态的相应函数do_sys_execve，该函数又调用do_execve函数。do_execve函数读入可执行文件，检查权限，如果没问题，继续读入可执行文件需要的相关信息（struct linux_binprm描述的）。 - 接着执行
search_binary_handler，根据可执行文件的类型（由上一步的最后确定），在linux_binfmt结构链表（formats，这个链表可以通过register_binfmt和unregister_binfmt注册和删除某些可执行文件的信息，因此注册新的可执行文件成为可能，后面再介绍）上查找，找到相应的结构，然后执行相应的load_binary函数开始加载可执行文件。在该链表的最后一个元素总是对解释脚本（interpreted script）的可执行文件格式进行描述的一个对象。这种格式只定义了load_binary方法，其相应的load_script函数检查这种可执行文件是否以两个#!字符开始，如果是，这个函数就以另一个可执行文件的路径名作为参数解释第一行的其余部分，并把脚本文件名作为参数传递以执行这个脚本（实际上脚本程序把自身的内容当作一个参数传递给了解释程序（如/bin/bash），而这个解释程序通常在脚本文件的开头用#!标记，如果没有标记，那么默认解释程序为当前SHELL）。 - 对于
ELF类型文件，其处理函数是load_elf_binary，它先读入ELF文件的头部，根据头部信息读入各种数据，再次扫描程序段描述表（Program Header Table），找到类型为PT_LOAD的段（即.text，.data，.bss等节区），将其映射（elf_map）到内存的固定地址上，如果没有动态连接器的描述段，把返回的入口地址设置成应用程序入口。完成这个功能的是start_thread，它不启动一个线程，而只是用来修改了pt_regs中保存的PC等寄存器的值，使其指向加载的应用程序的入口。当内核操作结束，返回用户态时接着就执行应用程序本身了。 - 如果应用程序使用了动态连接库，内核除了加载指定的可执行文件外，还要把控制权交给动态连接器（
ld-linux.so）以便处理动态连接的程序。内核搜寻段表（Program Header Table），找到标记为PT_INTERP段中所对应的动态连接器的名称，并使用load_elf_interp加载其映像，并把返回的入口地址设置成load_elf_interp的返回值，即动态链接器的入口。当execve系统调用退出时，动态连接器接着运行，它检查应用程序对共享链接库的依赖性，并在需要时对其加载，对程序的外部引用进行重定位（具体过程见《进程和进程的基本操作》）。然后把控制权交给应用程序，从ELF文件头部中定义 的程序进入点（用readelf -h可以出看到，Entry point address即是）开始执行。（不过对于非LIB_BIND_NOW的共享库装载是在有外部引用请求时才执行的）。
对于内核态的函数调用过程，没有办法通过
strace（它只能跟踪到系统调用层）来做的，因此要想跟踪内核中各个系统调用的执行细节，需要用其他工具。比如可以通过 Ftrace 来跟踪内核具体调用了哪些函数。当然，也可以通过 ctags/cscope/LXR 等工具分析内核的源代码。Linux 允许自己注册我们自己定义的可执行格式，主要接口是
/procy/sys/fs/binfmt_misc/register，可以往里头写入特定格式的字符串来实现。该字符串格式如 下： :name:type:offset:string:mask:interpreter:name新格式的标示符type识别类型（M表示魔数，E表示扩展）offset魔数（magic number，请参考man magic和man file）在文件中的启始偏移量string以魔数或者以扩展名匹配的字节序列mask用来屏蔽掉string的一些位interpreter程序解释器的完整路径名
Linux 下是如何给进程分配内存（这里仅讨论虚拟内存的分配）的呢？可以从
/proc/<pid>/maps 文件中看到个大概。这里的 pid 是进程号。/proc 下有一个文件比较特殊，是 self，它链接到当前进程的进程号，例如：$ ls /proc/self -l
lrwxrwxrwx 1 root root 64 2000-01-10 18:26 /proc/self -> 11291/
$ ls /proc/self -l
lrwxrwxrwx 1 root root 64 2000-01-10 18:26 /proc/self -> 11292/
看到没？每次都不一样，这样我们通过
cat /proc/self/maps 就可以看到 cat 程序执行时的内存映像了。$ cat -n /proc/self/maps
1 08048000-0804c000 r-xp 00000000 03:01 273716 /bin/cat
2 0804c000-0804d000 rw-p 00003000 03:01 273716 /bin/cat
3 0804d000-0806e000 rw-p 0804d000 00:00 0 [heap]
4 b7b90000-b7d90000 r--p 00000000 03:01 87528 /usr/lib/locale/locale-archive
5 b7d90000-b7d91000 rw-p b7d90000 00:00 0
6 b7d91000-b7ecd000 r-xp 00000000 03:01 466875 /lib/libc-2.5.so
7 b7ecd000-b7ece000 r--p 0013c000 03:01 466875 /lib/libc-2.5.so
8 b7ece000-b7ed0000 rw-p 0013d000 03:01 466875 /lib/libc-2.5.so
9 b7ed0000-b7ed4000 rw-p b7ed0000 00:00 0
10 b7eeb000-b7f06000 r-xp 00000000 03:01 402817 /lib/ld-2.5.so
11 b7f06000-b7f08000 rw-p 0001b000 03:01 402817 /lib/ld-2.5.so
12 bfbe3000-bfbf8000 rw-p bfbe3000 00:00 0 [stack]
13 ffffe000-fffff000 r-xp 00000000 00:00 0 [vdso]
编号是原文件里头没有的，为了说明方便，用
-n 参数加上去的。我们从中可以得到如下信息：- 第 1，2 行对应的内存区是我们的程序（包括指令，数据等）
- 第 3 到 12 行对应的内存区是堆栈段，里头也映像了程序引用的动态连接库
- 第 13 行是内核空间
总结一下：
- 前两部分是用户空间，可以从
0x00000000到0xbfffffff（在测试的2.6.21.5-smp上只到bfbf8000），而内核空间从0xC0000000到0xffffffff，分别是3G和1G，所以对于每一个进程来说，共占用4G的虚拟内存空间 - 从程序本身占用的内存，到堆栈段（动态获取内存或者是函数运行过程中用来存储局部变量、参数的空间，前者是
heap，后者是stack），再到内核空间，地址是从低到高的 - 栈顶并非
0xC0000000下的一个固定数值
结合相关资料，可以得到这么一个比较详细的进程内存映像表（以
Linux 2.6.21.5-smp 为例）：地址 | 内核空间 | 描述 |
0xC0000000 | | |
| (program flie) 程序名 | execve 的第一个参数 |
| (environment) 环境变量 | execve 的第三个参数，main 的第三个参数 |
| (arguments) 参数 | execve 的第二个参数，main 的形参 |
| (stack) 栈 | 自动变量以及每次函数调用时所需保存的信息都 |
| | 存放在此，包括函数返回地址、调用者的 |
| | 环境信息等，函数的参数，局部变量都存放在此 |
| (shared memory) 共享内存 | 共享内存的大概位置 |
| ... | |
| ... | |
| (heap) 堆 | 主要在这里进行动态存储分配，比如 malloc，new 等。 |
| ... | |
| .bss (uninitilized data) | 没有初始化的数据（全局变量哦） |
| .data (initilized global data) | 已经初始化的全局数据（全局变量） |
| .text (Executable Instructions) | 通常是可执行指令 |
0x08048000 | | |
0x00000000 | | ... |
光看没有任何概念，我们用
gdb 来看看刚才那个简单的程序。$ gcc -g -o shellcode shellcode.c #要用gdb调试，在编译时需要加-g参数
$ gdb -q ./shellcode
(gdb) set args arg1 arg2 arg3 arg4 #为了测试，设置几个参数
(gdb) l #浏览代码
1 /* shellcode.c */
2 void main()
3 {
4 __asm__ __volatile__("jmp forward;"
5 "backward:"
6 "popl %esi;"
7 "movl $4, %eax;"
8 "movl $2, %ebx;"
9 "movl %esi, %ecx;"
10 "movl $12, %edx;"
(gdb) break 4 #在汇编入口设置一个断点，让程序运行后停到这里
Breakpoint 1 at 0x8048332: file shellcode.c, line 4.
(gdb) r #运行程序
Starting program: /mnt/hda8/Temp/c/program/shellcode arg1 arg2 arg3 arg4
Breakpoint 1, main () at shellcode.c:4
4 __asm__ __volatile__("jmp forward;"
(gdb) print $esp #打印当前堆栈指针值，用于查找整个栈的栈顶
$1 = (void *) 0xbffe1584
(gdb) x/100s $esp+4000 #改变后面的4000，不断往更大的空间找
(gdb) x/1s 0xbffe1fd9 #在 0xbffe1fd9 找到了程序名，这里是该次运行时的栈顶
0xbffe1fd9: "/mnt/hda8/Temp/c/program/shellcode"
(gdb) x/10s 0xbffe17b7 #其他环境变量信息
0xbffe17b7: "CPLUS_INCLUDE_PATH=/usr/lib/qt/include"
0xbffe17de: "MANPATH=/usr/local/man:/usr/man:/usr/X11R6/man:/usr/lib/java/man:/usr/share/texmf/man"
0xbffe1834: "HOSTNAME=falcon.lzu.edu.cn"
0xbffe184f: "TERM=xterm"
0xbffe185a: "SSH_CLIENT=219.246.50.235 3099 22"
0xbffe187c: "QTDIR=/usr/lib/qt"
0xbffe188e: "SSH_TTY=/dev/pts/0"
0xbffe18a1: "USER=falcon"
...
(gdb) x/5s 0xbffe1780 #一些传递给main函数的参数，包括文件名和其他参数
0xbffe1780: "/mnt/hda8/Temp/c/program/shellcode"
0xbffe17a3: "arg1"
0xbffe17a8: "arg2"
0xbffe17ad: "arg3"
0xbffe17b2: "arg4"
(gdb) print init #打印init函数的地址，这个是/usr/lib/crti.o里头的函数，做一些初始化操作
$2 = {<text variable, no debug info>} 0xb7e73d00 <init>
(gdb) print fini #也在/usr/lib/crti.o中定义，在程序结束时做一些处理工作
$3 = {<text variable, no debug info>} 0xb7f4a380 <fini>
(gdb) print _start #在/usr/lib/crt1.o，这个才是程序的入口，必须的，ld会检查这个
$4 = {<text variable, no debug info>} 0x8048280 <[email protected]+20>
(gdb) print main #这里是我们的main函数
$5 = {void ()} 0x8048324 <main>
补充：在进程的内存映像中可能看到诸如
init，fini，_start 等函数（或者是入口），这些东西并不是我们自己写的啊？为什么会跑到我们的代码里头呢？实际上这些东西是链接的时候 gcc 默认给连接进去的，主要用来做一些进程的初始化和终止的动作。更多相关的细节可以参考资料如何获取当前进程之静态影像文件和"The Linux Kernel Primer"， P234， Figure 4.11，如果想了解链接（ld）的具体过程，可以看看本节参考《Unix环境高级编程编程》第7章 "UnIx进程的环境"， P127和P13，ELF: From The Programmer's Perspective，GNU-ld 连接脚本 Linker Scripts。上面的操作对堆栈的操作比较少，下面我们用一个例子来演示栈在内存中的情况。
这一节主要介绍一个函数被调用时，参数是如何传递的，局部变量是如何存储的，它们对应的栈的位置和变化情况，从而加深对栈的理解。在操作时发现和参考资料的结果不太一样（参考资料中没有
edi 和 esi 相关信息，再第二部分的一个小程序里头也没有），可能是 gcc 版本的问题或者是它对不同源代码的处理不同。我的版本是 4.1.2 （可以通过 gcc --version 查看）。先来一段简单的程序，这个程序除了做一个加法操作外，还复制了一些字符串。
/* testshellcode.c */
#include <stdio.h> /* printf */
#include <string.h> /* memset, memcpy */
#define BUF_SIZE 8
#ifndef STR_SRC
# define STR_SRC "AAAAAAA"
#endif
int func(int a, int b, int c)
{
int sum = 0;
char buffer[BUF_SIZE];
sum = a + b + c;
memset(buffer, '\0', BUF_SIZE);
memcpy(buffer, STR_SRC, sizeof(STR_SRC)-1);
return sum;
}
int main()
{
int sum;
sum = func(1, 2, 3);
printf("sum = %d\n", sum);
return 0;
}
上面这个代码没有什么问题，编译执行一下：
$ make testshellcode
cc testshellcode.c -o testshellcode
$ ./testshellcode
sum = 6
下面调试一下，看看在调用
func 后的栈的内容。$ gcc -g -o testshellcode testshellcode.c #为了调试，需要在编译时加-g选项
$ gdb -q ./testshellcode #启动gdb调试
...
(gdb) set logging on #如果要记录调试过程中的信息，可以把日志记录功能打开
Copying output to gdb.txt.
(gdb) l main #列出源代码
20
21 return sum;
22 }
23
24 int main()
25 {
26 int sum;
27
28 sum = func(1, 2, 3);
29
(gdb) break 28 #在调用func函数之前让程序停一下，以便记录当时的ebp(基指针)
Breakpoint 1 at 0x80483ac: file testshellcode.c, line 28.
(gdb) break func #设置断点在函数入口，以便逐步记录栈信息
Breakpoint 2 at 0x804835c: file testshellcode.c, line 13.
(gdb) disassemble main #反编译main函数，以便记录调用func后的下一条指令地址
Dump of assembler code for function main:
0x0804839b <main+0>: lea 0x4(%esp),%ecx
0x0804839f <main+4>: and $0xfffffff0,%esp
0x080483a2 <main+7>: pushl 0xfffffffc(%ecx)
0x080483a5 <main+10>: push %ebp
0x080483a6 <main+11>: mov %esp,%ebp
0x080483a8 <main+13>: push %ecx
0x080483a9 <main+14>: sub $0x14,%esp
0x080483ac <main+17>: push $0x3
0x080483ae <main+19>: push $0x2
0x080483b0 <main+21>: push $0x1
0x080483b2 <main+23>: call 0x8048354 <func>
0x080483b7 <main+28>: add $0xc,%esp
0x080483ba <main+31>: mov %eax,0xfffffff8(%ebp)
0x080483bd <main+34>: sub $0x8,%esp
0x080483c0 <main+37>: pushl 0xfffffff8(%ebp)
0x080483c3 <main+40>: push $0x80484c0
0x080483c8 <main+45>: call 0x80482a0 <[email protected]>
0x080483cd <main+50>: add $0x10,%esp
0x080483d0 <main+53>: mov $0x0,%eax
0x080483d5 <main+58>: mov 0xfffffffc(%ebp),%ecx
0x080483d8 <main+61>: leave
0x080483d9 <main+62>: lea 0xfffffffc(%ecx),%esp
0x080483dc <main+65>: ret
End of assembler dump.
(gdb) r #运行程序
Starting program: /mnt/hda8/Temp/c/program/testshellcode
Breakpoint 1, main () at testshellcode.c:28
28 sum = func(1, 2, 3);
(gdb) print $ebp #打印调用func函数之前的基地址，即Previous frame pointer。
$1 = (void *) 0xbf84fdd8
(gdb) n #执行call指令并跳转到func函数的入口
Breakpoint 2, func (a=1, b=2, c=3) at testshellcode.c:13
13 int sum = 0;
(gdb) n
16 sum = a + b + c;
(gdb) x/11x $esp #打印当前栈的内容，可以看出，地址从低到高，注意标记有蓝色和红色的值
#它们分别是前一个栈基地址(ebp)和call调用之后的下一条指令的指针(eip)
0xbf84fd94: 0x00000000 0x00000000 0x080482e0 0x00000000
0xbf84fda4: 0xb7f2bce0 0x00000000 0xbf84fdd8 0x080483b7
0xbf84fdb4: 0x00000001 0x00000002 0x00000003
(gdb) n #执行sum = a + b + c，后，比较栈内容第一行，第4列，由0变为6
18 memset(buffer, '\0', BUF_SIZE);
(gdb) x/11x $esp
0xbf84fd94: 0x00000000 0x00000000 0x080482e0 0x00000006
0xbf84fda4: 0xb7f2bce0 0x00000000 0xbf84fdd8 0x080483b7
0xbf84fdb4: 0x00000001 0x00000002 0x00000003
(gdb) n
19 memcpy(buffer, STR_SRC, sizeof(STR_SRC)-1);
(gdb) x/11x $esp #缓冲区初始化以后变成了0
0xbf84fd94: 0x00000000 0x00000000 0x00000000 0x00000006
0xbf84fda4: 0xb7f2bce0 0x00000000 0xbf84fdd8 0x080483b7
0xbf84fdb4: 0x00000001 0x00000002 0x00000003
(gdb) n
21 return sum;
(gdb) x/11x $esp #进行copy以后，这两列的值变了，大小刚好是7个字节，最后一个字节为'\0'
0xbf84fd94: 0x00000000 0x41414141 0x00414141 0x00000006
0xbf84fda4: 0xb7f2bce0 0x00000000 0xbf84fdd8 0x080483b7
0xbf84fdb4: 0x00000001 0x00000002 0x00000003
(gdb) c
Continuing.
sum = 6
Program exited normally.
(gdb) quit
从上面的操作过程，我们可以得出大概的栈分布(
func 函数结束之前)如下：地址 | 值(hex) | 符号或者寄存器 | 注释 |
低地址 | | | 栈顶方向 |
0xbf84fd98 | 0x41414141 | buf[0] | 可以看出little endian(小端，重要的数据在前面) |
0xbf84fd9c | 0x00414141 | buf[1] | |
0xbf84fda0 | 0x00000006 | sum | 可见这上面都是func函数里头的局部变量 |
0xbf84fda4 | 0xb7f2bce0 | esi | 源索引指针，可以通过产生中间代码查看，貌似没什么作用 |
0xbf84fda8 | 0x00000000 | edi | 目的索引指针 |
0xbf84fdac | 0xbf84fdd8 | ebp | 调用func之前的栈的基地址，以便调用函数结束之后恢复 |
0xbf84fdb0 | 0x080483b7 | eip | 调用func之前的指令指针，以便调用函数结束之后继续执行 |
0xbf84fdb4 | 0x00000001 | a | 第一个参数 |
0xbf84fdb8 | 0x00000002 | b | 第二个参数 |
0xbf84fdbc | 0x00000003 | c | 第三个参数，可见参数是从最后一个开始压栈的 |
高地址 | | | 栈底方向 |
先说明一下
edi 和 esi 的由来（在上面的调试过程中我们并没有看到），是通过产生中间汇编代码分析得出的。$ gcc -S testshellcode.c
在产生的
testShellcode.s 代码里头的 func 部分看到 push ebp 之后就 push 了 edi 和 esi 。但是搜索了一下代码，发现就这个函数里头引用了这两个寄存器，所以保存它们没什么用，删除以后编译产生目标代码后证明是没用的。$ cat testshellcode.s
...
func:
pushl %ebp
movl %esp, %ebp
pushl %edi
pushl %esi
...
popl %esi
popl %edi
popl %ebp
...
下面就不管这两部分（
edi 和 esi）了，主要来分析和函数相关的这几部分在栈内的分布：- 函数局部变量，在靠近栈顶一端
- 调用函数之前的栈的基地址（
ebp，Previous Frame Pointer），在中间靠近栈顶方向 - 调用函数指令的下一条指令地址
` （eip`），在中间靠近栈底的方向 - 函数参数，在靠近栈底的一端，最后一个参数最 先入栈
到这里，函数调用时的相关内容在栈内的分布就比较清楚了，在具体分析缓冲区溢出问题之前，我们再来看一个和函数关系很大的问题，即函数返回值的存储问题：函数的返回值存放在寄存器
eax 中。先来看这段代码：
/**
* test_return.c -- the return of a function is stored in register eax
*/
#include <stdio.h>
int func()
{
__asm__ ("movl $1, %eax");
}
int main()
{
printf("the return of func: %d\n", func());
return 0;
}
编译运行后，可以看到返回值为 1，刚好是我们在
func 函数中 mov 到 eax 中的“立即数” 1，因此很容易理解返回值存储在 eax 中的事实，如果还有疑虑，可以再看看汇编代码。在函数返回之后，eax 中的值当作了 printf 的参数压入了栈中，而在源代码中我们正是把 func 的结果作为 printf 的第二个参数的。$ make test_return
cc test_return.c -o test_return
$ ./test_return
the return of func: 1
$ gcc -S test_return.c
$ cat test_return.s
...
call func
subl $8, %esp
pushl %eax #printf的第二个参数，把func的返回值压入了栈底
pushl $.LC0 #printf的第一个参数the return of func: %d\n
call printf
...
对于系统调用，返回值也存储在
eax 寄存器中。先来看一段简短的代码。
/* testshellcode.c */
#include <stdio.h> /* printf */
#include <string.h> /* memset, memcpy */
#define BUF_SIZE 8
#ifdef STR1
# define STR_SRC "AAAAAAA\0\1\0\0\0"
#endif
#ifndef STR_SRC
# define STR_SRC "AAAAAAA"
#endif
int func(int a, int b, int c)
{
int sum = 0;
char buffer[BUF_SIZE];
sum = a + b + c;
memset(buffer, '\0', BUF_SIZE);
memcpy(buffer, STR_SRC, sizeof(STR_SRC)-1);
return sum;
}
int main()
{
int sum;
sum = func(1, 2, 3);
printf("sum = %d\n", sum);
return 0;
}
编译一下看看结果：
$ gcc -DSTR1 -o testshellcode testshellcode.c #通过-D定义宏STR1，从而采用第一个STR_SRC的值
$ ./testshellcode
sum = 1
不知道你有没有发现异常呢？上面用红色标记的地方，本来
sum 为 1+2+3 即 6，但是实际返回的竟然是 1 。到底是什么原因呢？大家应该有所了解了，因为我们在复制字符串 AAAAAAA\\0\\1\\0\\0\\0 到 buf 的时候超出 buf 本来的大小。 buf 本来的大小是 BUF_SIZE，8 个字节，而我们要复制的内容是 12 个字节，所以超出了四个字节。根据第一小节的分析，我们用栈的变化情况来表示一下这个复制过程（即执行 memcpy 的过程）。memcpy(buffer, STR_SRC, sizeof(STR_SRC)-1);
（低地址）
复制之前 ====> 复制之后
0x00000000 0x41414141 #char buf[8]
0x00000000 0x00414141
0x00000006 0x00000001 #int sum
（高地址）
下面通过
gdb 调试来确认一下(只摘录了一些片断)。$ gcc -DSTR1 -g -o testshellcode testshellcode.c
$ gdb -q ./testshellcode
...
(gdb) l
21
22 memset(buffer, '\0', BUF_SIZE);
23 memcpy(buffer, STR_SRC, sizeof(STR_SRC)-1);
24
25 return sum;
...
(gdb) break 23
Breakpoint 1 at 0x804837f: file testshellcode.c, line 23.
(gdb) break 25
Breakpoint 2 at 0x8048393: file testshellcode.c, line 25.
(gdb) r
Starting program: /mnt/hda8/Temp/c/program/testshellcode
Breakpoint 1, func (a=1, b=2, c=3) at testshellcode.c:23
23 memcpy(buffer, STR_SRC, sizeof(STR_SRC)-1);
(gdb) x/3x $esp+4
0xbfec6bd8: 0x00000000 0x00000000 0x00000006
(gdb) n
Breakpoint 2, func (a=1, b=2, c=3) at testshellcode.c:25
25 return sum;
(gdb) x/3x $esp+4
0xbfec6bd8: 0x41414141 0x00414141 0x00000001
可以看出，因为 C 语言没有对数组的边界进行限制。我们可以往数组中存入预定义长度的字符串，从而导致缓冲区溢出。
溢出之后的问题是导致覆盖栈的其他内容，从而可能改变程序原来的行为。
如果这类问题被“黑客”利用那将产生非常可怕的后果，小则让非法用户获取了系统权限，把你的服务器当成“僵尸”，用来对其他机器进行攻击，严重的则可能被人删除数据（所以备份很重要）。即使不被黑客利用，这类问题如果放在医疗领域，那将非常危险，可能那个被覆盖的数字刚好是用来控制治疗癌症的辐射量的，一旦出错，那可能导致置人死地，当然，如果在航天领域，那可能就是好多个 0 的
money 甚至航天员的损失，呵呵，“缓冲区溢出，后果很严重！”那这个怎么办呢？貌似Linux下缓冲区溢出攻击的原理及对策提到有一个
libsafe 库，可以至少用来检测程序中出现的类似超出数组边界的问题。对于上面那个具体问题，为了保护 sum 不被修改，有一个 小技巧，可以让求和操作在字符串复制操作之后来做，以便求和操作把溢出的部分给重写。这个呆伙在下面一块看效果吧。继续看看缓冲区的溢出吧。先来看看这个代码，还是
testShellcode.c 的改进。/* testshellcode.c */
#include <stdio.h> /* printf */
#include <string.h> /* memset, memcpy */
#define BUF_SIZE 8
#ifdef STR1
# define STR_SRC "AAAAAAAa\1\0\0\0"
#endif
#ifdef STR2
# define STR_SRC "AAAAAAAa\1\0\0\0BBBBBBBB"
#endif
#ifdef STR3
# define STR_SRC "AAAAAAAa\1\0\0\0BBBBBBBBCCCC"
#endif
#ifdef STR4
# define STR_SRC "AAAAAAAa\1\0\0\0BBBBBBBBCCCCDDDD"
#endif
#ifndef STR_SRC
# define STR_SRC "AAAAAAA"
#endif
int func(int a, int b, int c)
{
int sum = 0;
char buffer[BUF_SIZE] = "";
memset(buffer, '\0', BUF_SIZE);
memcpy(buffer, STR_SRC, sizeof(STR_SRC)-1);
sum = a + b + c; //把求和操作放在复制操作之后可以在一定情况下“保护”求和结果
return sum;
}
int main()
{
int sum;
sum = func(1, 2, 3);
printf("sum = %d\n", sum);
return 0;
}
看看运行情况：
$ gcc -D STR2 -o testshellcode testshellcode.c #再多复制8个字节，结果和STR1时一样
#原因是edi,esi这两个没什么用的，覆盖了也没关系
$ ./testshellcode #看到没？这种情况下，让整数操作在字符串复制之后做可以“保护‘整数结果
sum = 6
$ gcc -D STR3 -o testshellcode testshellcode.c #再多复制4个字节，现在就会把ebp给覆盖
#了，这样当main函数再要用ebp访问数据
#时就会出现访问非法内存而导致段错误。
$ ./testshellcode
Segmentation fault
如果感兴趣，自己还可以用gdb类似之前一样来查看复制字符串以后栈的变化情况。
下面来做一个比较有趣的事情：如何设法保护我们的
ebp 不被修改。首先要明确
ebp 这个寄存器的作用和“行为”，它是栈基地址，并且发现在调用任何一个函数时，这个 ebp 总是在第一条指令被压入栈中，并在最后一条指令（ret）之前被弹出。类似这样：func: #函数
pushl %ebp #第一条指令
...
popl %ebp #倒数第二条指令
ret
还记得之前（第一部分）提到的函数的返回值是存储在
eax 寄存器中的么？如果我们在一个函数中仅仅做放这两条指令：popl %eax
pushl %eax
那不就刚好有：
func: #函数
pushl %ebp #第一条指令
popl %eax #把刚压入栈中的ebp弹出存放到eax中
pushl %eax #又把ebp压入栈
popl %ebp #倒数第二条指令
ret
这样我们没有改变栈 的状态，却获得了
ebp 的值，如果在调用任何一个函数之前，获取这个 ebp，并且在任何一条字符串复制语句（可能导致缓冲区溢出的语句）之后重新设置一下 ebp 的值，那么就可以保护 ebp 啦。具体怎么实现呢？看这个代码。/* testshellcode.c */
#include <stdio.h> /* printf */
#include <string.h> /* memset, memcpy */
#define BUF_SIZE 8
#ifdef STR1
# define STR_SRC "AAAAAAAa\1\0\0\0"
#endif
#ifdef STR2
# define STR_SRC "AAAAAAAa\1\0\0\0BBBBBBBB"
#endif
#ifdef STR3
# define STR_SRC "AAAAAAAa\1\0\0\0BBBBBBBBCCCC"
#endif
#ifdef STR4
# define STR_SRC "AAAAAAAa\1\0\0\0BBBBBBBBCCCCDDDD"
#endif
#ifndef STR_SRC
# define STR_SRC "AAAAAAA"
#endif
unsigned long get_ebp()
{
__asm__ ("popl %eax;"
"pushl %eax;");
}
int func(int a, int b, int c, unsigned long ebp)
{
int sum = 0;
char buffer[BUF_SIZE] = "";
sum = a + b + c;
memset(buffer, '\0', BUF_SIZE);
memcpy(buffer, STR_SRC, sizeof(STR_SRC)-1);
*(unsigned long *)(buffer+20) = ebp;
return sum;
}
int main()
{
int sum, ebp;
ebp = get_ebp();
sum = func(1, 2, 3, ebp);
printf("sum = %d\n", sum);
return 0;
}
这段代码和之前的代码的不同有：
- 给
func函数增加了一个参数ebp，（其实可以用全局变量替代的） - 利用了刚介绍的原理定义了一个函数
get_ebp以便获取老的ebp - 在
main函数中调用func之前调用了get_ebp，并把它作为func的最后一个参数 - 在
func函数中调用memcpy函数（可能发生缓冲区溢出的地方）之后添加了一条恢复设置ebp的语句，这条语句先把buffer+20这个地址（存放ebp的地址，你可以类似第一部分提到的用gdb来查看）强制转换为指向一个unsigned long型的整数（4 个字节），然后把它指向的内容修改为老的ebp。
看看效果：
$ gcc -D STR3 -o testshellcode testshellcode.c
$ ./testshellcode #现在没有段错误了吧，因为ebp得到了“保护”
sum = 6
如果我们复制更多的字节过去了，比如再多复制四个字节进去，那么
eip 就被覆盖了。$ gcc -D STR4 -o testshellcode testshellcode.c
$ ./testshellcode
Segmentation fault
同样会出现段错误，因为下一条指令的位置都被改写了，
func 返回后都不知道要访问哪个”非法“地址啦。呵呵，如果是一个合法地址呢？如果在缓冲区溢出时，
eip 被覆盖了，并且被修改为了一条合法地址，那么问题就非常”有趣“了。如果这个地址刚好是调用func的那个地址，那么整个程序就成了死循环，如果这个地址指向的位置刚好有一段关机代码，那么系统正在运行的所有服务都将被关掉，如果那个地方是一段更恶意的代码，那就？你可以尽情想像哦。如果是黑客故意利用这个，那么那些代码貌似就叫做shellcode了。有没有保护
eip 的办法呢？呵呵，应该是有的吧。不知道 gas 有没有类似 masm 汇编器中 offset 的伪操作指令（查找了一下，貌似没有），如果有的话在函数调用之前设置一个标号，在后面某个位置获取，再加上一个可能的偏移（包括 call 指令的长度和一些 push 指令等），应该可以算出来，不过貌似比较麻烦（或许你灵感大作，找到好办法了！），这里直接通过 gdb 反汇编求得它相对 main 的偏移算出来得了。求出来以后用它来”保护“栈中的值。看看这个代码：
/* testshellcode.c */
#include <stdio.h> /* printf */
#include <string.h> /* memset, memcpy */
#define BUF_SIZE 8
#ifdef STR1
# define STR_SRC "AAAAAAAa\1\0\0\0"
#endif
#ifdef STR2
# define STR_SRC "AAAAAAAa\1\0\0\0BBBBBBBB"
#endif
#ifdef STR3
# define STR_SRC "AAAAAAAa\1\0\0\0BBBBBBBBCCCC"
#endif
#ifdef STR4
# define STR_SRC "AAAAAAAa\1\0\0\0BBBBBBBBCCCCDDDD"
#endif
#ifndef STR_SRC
# define STR_SRC "AAAAAAA"
#endif
int main();
#define OFFSET 40
unsigned long get_ebp()
{
__asm__ ("popl %eax;"
"pushl %eax;");
}
int func(int a, int b, int c, unsigned long ebp)
{
int sum = 0;
char buffer[BUF_SIZE] = "";
memset(buffer, '\0', BUF_SIZE);
memcpy(buffer, STR_SRC, sizeof(STR_SRC)-1);
sum = a + b + c;
*(unsigned long *)(buffer+20) = ebp;
*(unsigned long *)(buffer+24) = (unsigned long)main+OFFSET;
return sum;
}
int main()
{
int sum, ebp;
ebp = get_ebp();
sum = func(1, 2, 3, ebp);
printf("sum = %d\n", sum);
return 0;
}