缓冲区溢出与注入分析

缓冲区溢出与注入分析

前言

虽然程序加载以及动态符号链接都已经很理解了，但是这伙却被进程的内存映像给”纠缠"住。看着看着就一发不可收拾——很有趣。

下面一起来探究“缓冲区溢出和注入”问题（主要是关心程序的内存映像）。

进程的内存映像

永远的 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，ret 指令的作用分析

• call 指令

  跳转到某个位置，并在之前把下一条指令的地址（EIP）入栈（为了方便”程序“返回以后能够接着执行）。这样的话就有：

  call backward   ==>   push eip
                        jmp backward

• ret 指令

  通常 call 指令和 ret 是配合使用的，前者压入跳转前的下一条指令地址，后者弹出 call 指令压入的那条指令，从而可以在函数调用结束以后接着执行后面的指令。

  ret                    ==>   pop eip

通常在函数调用后，还需要恢复 esp 和 ebp，恢复 esp 即恢复当前栈指针，以便释放调用函数时为存储函数的局部变量而自动分配的空间；恢复 ebp 是从栈中弹出一个数据项（通常函数调用过后的第一条语句就是 push ebp），从而恢复当前的函数指针为函数调用者本身。这两个动作可以通过一条 leave 指令完成。

这三个指令对我们后续的解释会很有帮助。更多关于 Intel 的指令集，请参考：Intel 386 Manual, x86 Assembly Language FAQ：part1, part2, part3.

什么是系统调用（以 Linux 2.6.21 版本和 x86 平台为例）

系统调用是用户和内核之间的接口，用户如果想写程序，很多时候直接调用了 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 文件

这里的 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 下程序的内存映像

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 <__libc_start_main@plt+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 <printf@plt>
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 调