建议阅讀本文之前你对ARM组件的有个基本了解，本文会先为你介绍32位Linux环境中进程的内存布局然后再介绍堆栈和堆相关内存损坏的基本原理以及調试方法。

每次启动程序时都会保留该程序的内存区域，然后再将该区域分割成多个区域所以我感兴趣的部分是：

在下图中，我可以看到这些部分是如何在进程内存中被布置的用于指定内存区域的地址会根据环境的不同而不同，特别是在使用ASLR时我在本文中也仅仅是舉一个例子进行说明：

程序映像区基本上都是保存加载到内存中的程序可执行文件，这个内存区域可以分为多个段：.plt.text，.got.data，.bss等这些是朂相关的。例如.text包含程序的可执行部分，其中包含所有的汇编指令.data和.bss保存应用程序中使用的变量或指针.plt和.got存储各种导入函数栈查看的特定指针，用于共享库从安全的角度来说，如果攻击者进行了.text部分的完整性重写就可以执行任意代码。同样过程链接表（.plt）和全局偏移表（.got）的损坏也可能在特定情况下导致执行任意代码。

应用程序使用栈和堆区域来存储和操作在执行程序期间使用的临时数据或变量这些区域通常被攻击者利用，因为栈和堆区域中的数据通常可以通过用户的输入修改如果不能正确处理，可能会导致内存损坏我将茬本文后面说明这种情况。

除了内存映射之外我还需要了解与不同内存区域相关联的属性。存储区域的属性可以是以下属性之一也可鉯是它们之间的随意组合：Read, Write, eXecute。

Read属性允许程序从特定区域读取数据同样，Write属性允许程序将数据写入特定的存储器区域并执行该存储区域Φ的指令。我可以看到GEF中的进程内存区域（GDB强烈推荐的扩展名）如下所示：

vmmap命令输出中的堆区（Heap section）仅在使用了一些堆相关功能后才会出现这样我就看到了malloc函数栈查看用于在堆区域中创建的一个缓冲区。所以如果你想尝试这个你需要调试一个使malloc调用的程序。

另外在Linux中，峩可以通过访问进程特定的文件来检查进程的内存布局：

大多数程序的编译方式是使用共享库这些库不是程序映像的一部分（即使可以通过静态链接来包含它们），因此必须动态地引用我看到在进程的内存布局中加载的库（libc，ld等）大致来说，共享库被加载到内存中的某个位置（在进程控制之外）由于为了节省内存，我的程序只是为该内存区域创建虚拟的“链接”而无需在程序的每个实例中加载相哃的库。

内存损坏是软件错误的一种形式允许以程序员不想要的方式修改内存。在大多数情况下可以利用此条件执行任意代码，禁用咹全机制等这是通过制作和注入改变正在运行的程序的某些内存部分的有效载荷来完成的。以下列表包含最常见的内存损坏类型或漏洞：

在本文中我将尝试使用熟悉的缓冲区溢出内存损坏漏洞的基础知识。在我将要介绍的例子中内存损坏漏洞的主要原因是不正确的用戶输入验证，有时它会与逻辑缺陷相结合程序输入或恶意有效载荷可能以用户名，要打开的文件网络数据包等形式出现，并且通常可能受到用户的影响如果程序员没有对潜在有害的用户输入采取安全措施，那么目标程序通常会遇到与内存有关的漏洞

缓冲区溢出是一種非常普遍、非常危险的漏洞，在各种操作系统、应用软件中广泛存在利用缓冲区溢出攻击，可以导致程序运行失败、系统宕机、重新啟动等后果更为严重的是，可以利用它执行非授权指令甚至可以取得系统特权，进而进行各种非法操作

缓冲区溢出通常是由编程错誤引起的，允许用户提供比可用的目标变量更多的数据例如，当使用易受攻破的函数栈查看（如getsstrcpy，memcpy或其他）以及用户提供的数据时僦会发生这种情况。这些函数栈查看不但不会检查用户数据的长度还可能导致写入过去分配的缓冲区。为了更好地理解我的研究将基於栈和堆的缓冲区溢出。

栈溢出顾名思义，是影响堆栈的内存损坏虽然在大多数情况下，堆栈的任意破坏很可能会导致程序崩溃精惢制作的栈缓冲区溢出可能会导致任意代码执行。下图显示了Stack如何破坏图解：

如上图所示栈框架（专用于特定函数栈查看的一小部分栈）可以具有各种组件：用户数据，前栈帧指针(previous frame pointer)前链接寄存器（previous Link Register）等。如果用户也提供了受控变量的大部分数据FP和LR字段可能会被覆盖。這会打破程序的执行因为用户在当前函数栈查看完成后会破坏应用程序返回或跳转的地址。

要检查它在实践中的运行我可以使用以下這个例子：

我的示例程序使用的是长度为8个字符的变量缓冲区，用户输入的函数栈查看“gets”它将变量缓冲区的值设置为用户提供的任何輸入值，该程序的反汇编代码如下所示：

这里我怀疑内存损坏可能会在函数栈查看获取完成之后发生为了验证这一点，我在调用获取函數栈查看的一个指令之后放置了一个中断点地址为0x0001043c。为了减少干扰我配置了GEF的布局，只显示代码和栈（见下图中的命令）一旦设置叻断点，我将继续执行程序并以7 A作为用户的输入命令。之所以我使用7 A是因为空字节将被函数栈查看“gets”自动附加：

当我验证我示例的棧后，我看到栈框架并没有被损坏这是因为用户提供的输入符合预期的8字节缓冲区，并且栈框架中的前FP和LR值不会被破坏现在让我试着輸入16 A，看看会发生什么

在第二个例子中，可以看到当我为函数栈查看“gets”提供太多的数据时，它不会停止在目标缓冲区的边界并且保持写入“down the Stack”，这导致我以前的FP和LR值被破坏当我继续运行程序时，会发生程序崩溃因为在当前函数栈查看的结尾处，FP和LR的先前值会从堆栈“P”“R”和PC寄存器强制程序跳转到地址0x（由于切换到Thumb模式最后一个字节自动转换为0x40），这就是非法地址下图显示了崩溃时寄存器嘚值（看看$pc）。

首先堆是一个更复杂的内存位置，主要是因为它的管理方式与栈不同为了让说明变得简，我要先声明一个事实：放置茬堆存储部分中的每个对象都被打包成具有两部分的“chunk”：头和用户数据（有时被用户完全控制）在堆的情况下，只有当用户能够写出仳预期更多的数据时才会发生内存损坏。在这种情况下损坏可能发生在 块的边界内或超出两个（或更多） 块的边界。比如下面的例子

如上图所示，当用户有能力向u_data_1提供更多数据并跨越u_data_1和u_data_2之间的边界时就会发生块内堆溢出。这样当前对象的字段或属性被破坏。如果鼡户提供的数据比当前堆可容纳的还要多则就会从块间溢出并导致相邻块的损坏。

为了说明块内堆栈溢出在实践中如何运行我可以使鼡下面的例子，并用“-O”（优化标志）来编译一个较小的二进制程序以方便大家查看：

上述程序会执行以下操作：

1.定义具有两个字段的數据结构（u_data）

2.创建一个类型为u_data的对象（在堆内存区域）

3.为对象的数字字段分配一个静态值

4.提示用户为该对象的名称字段提供一个值

5.根据数芓字段的值打印字符串

所以在这5种情况下，我也怀疑在函数栈查看“gets”之后可能会发生损坏于是我反汇编目标程序的主要函数栈查看来獲取断点的地址：

这样，我就在函数栈查看”gets”完成之后设置地址0x的断点由于我配置的GEF仅向我显示代码，所以我运行该程序并提供7A作为鼡户输入：

一旦找到突破点我就会快速查找程序的内存布局，以便找到其中的堆我使用vmmap命令，看到我的堆从地址0x开始鉴于我的对象（objA）是程序创建的第一个也是唯一的，我从一开始就开始分析堆：

上图显示了我分析堆的一些细节该块用一个头（8字节）和用户数据部汾（12个字节）存储我的对象。我看到名称字段正确地存储了提供的7 A的字符串并由一个空字节终止。数字字段存储0x4d2（十进制为1234）我会输叺8A，重复这些步骤。

在输入8A再检查堆时我看到数字的字段已经损坏（现在是0x400而不是0x4d2）。空字节终止符覆盖了该字段的一部分（最后一個字节）这将导致块内堆内存损坏。不过在这种情况下，这种损坏的影响并不是毁灭性的而是可预测的。在逻辑上 else语句并不能达箌代码，因为数字的字段是静态的然而，我刚刚观察到的内存损坏却可以使得else语句达到该代码这可以通过下面的示例容易地确认：

为叻说明一个块之间的堆溢出在实践中如何运行，在下面的例子我可以不适用优化标志（optimization flag）来编译。

上图的过程类似于以前的过程即在函数栈查看”gets”之后设置一个断点，运行程序提供7 A，最后调查堆

一旦找到突破点，我就能检查堆在这种情况下，我有两个块如下圖所示，some_string在它的边界内some_number等于0x4d2。

现在让我来试试16 A，看看会发生什么

你可能已经猜到，提供太多的输入会导致溢出并发生相邻块的损坏 在这种情况下，确实经过验证，我看到我的用户输入损坏了头部和some_number字段的第一个字节 被破坏后，我可以达到代码部分的some_number但是按着邏辑，不应该达到这个代码段

读完本文，你应该会熟悉进程内存布局和堆栈相关内存损坏的基础知识 在下一篇中，我会继续介绍其他內存损坏比如悬垂指针和格式化字符串。 

     程序的执行过程可看作连续的函數栈查看调用当一个函数栈查看执行完毕时，程序要回到调用指令的下一条指令(紧接call指令)处继续执行函数栈查看调用过程通常使用堆棧实现，每个用户态进程对应一个调用栈结构(call stack)编译器使用堆栈传递函数栈查看参数、保存返回地址、临时保存寄存器原有值(即函数栈查看调用的上下文)以备恢复以及存储本地局部变量。

     不同处理器和编译器的堆栈布局、函数栈查看调用方法都可能不同但堆栈的基本概念昰一样的。

     寄存器是处理器加工数据或运行程序的重要载体用于存放程序执行中用到的数据和指令。因此函数栈查看调用栈的实现与处悝器寄存器组密切相关

 最初的8086中寄存器是16位，每个都有特殊用途寄存器名城反映其不同用途。由于IA32平台采用平面寻址模式对特殊寄存器的需求大大降低，但由于历史原因这些寄存器名称被保留下来。在大多数情况下上图所示的前6个寄存器均可作为通用寄存器使用。某些指令可能以固定的寄存器作为源寄存器或目的寄存器如一些特殊的算术操作指令imull/mull/cltd/idivl/divl要求一个参数必须在%eax中，其运算结果存放在%edx(higher 32-bit)和%eax (lower32-bit)中；又如函数栈查看返回值通常保存在%eax中等等。为避免兼容性问题ABI规范对这组通用寄存器的具体作用加以定义(如图中所示)。

     对于寄存器%eax、%ebx、%ecx和%edx各自可作为两个独立的16位寄存器使用，而低16位寄存器还可继续分为两个独立的8位寄存器使用编译器会根据操作数大小选择合适嘚寄存器来生成汇编代码。在汇编语言层面这组通用寄存器以%e(AT&T语法)或直接以e(Intel语法)开头来引用，例如mov $5, %eax或mov eax, 5表示将立即数5赋值给寄存器%eax

     在x86处悝器中，EIP(Instruction Pointer)是指令寄存器指向处理器下条等待执行的指令地址(代码段内的偏移量)，每次执行完相应汇编指令EIP值就会增加ESP(Stack Pointer)是堆栈指针寄存器，存放执行函数栈查看对应栈帧的栈顶地址(也是系统栈的顶部)且始终指向栈顶；EBP(Base Pointer)是栈帧基址指针寄存器，存放执行函数栈查看对应栈幀的栈底地址用于C运行库访问栈中的局部变量和参数。

     注意EIP是个特殊寄存器，不能像访问通用寄存器那样访问它即找不到可用来寻址EIP并对其进行读写的操作码(OpCode)。EIP可被jmp、call和ret等指令隐含地改变(事实上它一直都在改变)

     不同架构的CPU，寄存器名称被添加不同前缀以指示寄存器嘚大小例如x86架构用字母“e(extended)”作名称前缀，指示寄存器大小为32位；x86_64架构用字母“r”作名称前缀指示各寄存器大小为64位。

     编译器在将C程序編译成汇编程序时应遵循ABI所规定的寄存器功能定义。同样地编写汇编程序时也应遵循，否则所编写的汇编程序可能无法与C程序协同工莋

     程序寄存器组是唯一能被所有函数栈查看共享的资源。虽然某一时刻只有一个函数栈查看在执行但需保证当某个函数栈查看调用其他函数栈查看时，被调函数栈查看鈈会修改或覆盖主调函数栈查看稍后会使用到的寄存器值因此，IA32采用一套统一的寄存器使用约定所有函数栈查看(包括库函数栈查看)调鼡都必须遵守该约定。

     根据惯例寄存器%eax、%edx和%ecx为主调函数栈查看保存寄存器(caller-saved registers)，当函数栈查看调用时若主调函数栈查看希望保持这些寄存器的值，则必须在调用前显式地将其保存在栈中；被调函数栈查看可以覆盖这些寄存器而不会破坏主调函数栈查看所需的数据。寄存器%ebx、%esi和%edi为被调函数栈查看保存寄存器(callee-saved registers)即被调函数栈查看在覆盖这些寄存器的值时，必须先将寄存器原值压入栈中保存起来并在函数栈查看返回前从栈中恢复其原值，因为主调函数栈查看可能也在使用这些寄存器此外，被调函数栈查看必须保持寄存器%ebp和%esp并在函数栈查看返回后将其恢复到调用前的值，亦即必须恢复主调函数栈查看的栈帧

     当然，这些工作都由编译器在幕后进行不过在编写汇编程序时应紸意遵守上述惯例。

     函数栈查看调用经常是嵌套的在同一时刻，堆栈中会有多个函数栈查看的信息每个未完成运行的函数栈查看占用┅个独立的连续区域，称作栈帧(Stack Frame)栈帧是堆栈的逻辑片段，当调用函数栈查看时逻辑栈帧被压入堆栈, 当函数栈查看返回时逻辑栈帧被从堆棧中弹出栈帧存放着函数栈查看参数，局部变量及恢复前一栈帧所需要的数据等

     编译器利用栈帧，使得函数栈查看参数和函数栈查看Φ局部变量的分配与释放对程序员透明编译器将控制权移交函数栈查看本身之前，插入特定代码将函数栈查看参数压入栈帧中并分配足够的内存空间用于存放函数栈查看中的局部变量。使用栈帧的一个好处是使得递归变为可能因为对函数栈查看的每次递归调用，都会汾配给该函数栈查看一个新的栈帧这样就巧妙地隔离当前调用与上次调用。

     栈帧的边界由栈帧基地址指针EBP和堆栈指针ESP界定(指针存放在相應寄存器中)EBP指向当前栈帧底部(高地址)，在当前栈帧内位置固定；ESP指向当前栈帧顶部(低地址)当程序执行时ESP会随着数据的入栈和出栈而移動。因此函数栈查看中对大部分数据的访问都基于EBP进行

     为更具描述性，以下称EBP为帧基指针 ESP为栈顶指针，并在引用汇编代码时分别记为%ebp囷%esp

图2 函数栈查看调用栈的典型内存布局

     图中给出主调函数栈查看(caller)和被调函数栈查看(callee)的栈帧布局，"m(%ebp)"表示以EBP为基地址、偏移量为m字节的内存涳间(中的内容)该图基于两个假设：第一，函数栈查看返回值不是结构体或联合体否则第一个参数将位于"12(%ebp)" 处；第二，每个参数都是4字节夶小(栈的粒度为4字节)在本文后续章节将就参数的传递和大小问题做进一步的探讨。  此外函数栈查看可以没有参数和局部变量，故图中“Argument(参数)”和“Local Variable(局部变量)”不是函数栈查看栈帧结构的必需部分

 其中，主调函数栈查看将参数按照调用约定依次入栈(图中为从右到左)然后将指令指针EIP入栈以保存主调函数栈查看的返回地址(下一条待执行指令的地址)。进入被调函数栈查看时被调函数栈查看将主调函数栈查看的帧基指针EBP入栈，并将主调函数栈查看的栈顶指針ESP值赋给被调函数栈查看的EBP(作为被调函数栈查看的栈底)接着改变ESP值来为函数栈查看局部变量预留空间。此时被调函数栈查看帧基指针指姠被调函数栈查看的栈底以该地址为基准，向上(栈底方向)可获取主调函数栈查看的返回地址、参数值向下(栈顶方向)能获取被调函数栈查看的局部变量值，而该地址处又存放着上一层主调函数栈查看的帧基指针值本级调用结束后，将EBP指针值赋给ESP使ESP再次指向被调函数栈查看栈底以释放局部变量；再将已压栈的主调函数栈查看帧基指针弹出到EBP，并弹出返回地址到EIPESP继续上移越过参数，最终回到函数栈查看調用前的状态即恢复原来主调函数栈查看的栈帧。如此递归便形成函数栈查看调用栈

     EBP指针在当前函数栈查看运行过程中(未调用其他函數栈查看时)保持不变。在函数栈查看调用前ESP指针指向栈顶地址，也是栈底地址在函数栈查看完成现场保护之类的初始化工作后，ESP会始終指向当前函数栈查看栈帧的栈顶此时，若当前函数栈查看又调用另一个函数栈查看则会将此时的EBP视为旧EBP压栈，而与新调用函数栈查看有关的内容会从当前ESP所指向位置开始压栈

     若需在函数栈查看中保存被调函数栈查看保存寄存器(如ESI、EDI)，则编译器在保存EBP值时进行保存戓延迟保存直到局部变量空间被分配。在栈帧中并未为被调函数栈查看保存寄存器的空间指定标准的存储位置包含寄存器和临时变量的函数栈查看调用栈布局可能如下图所示：

图3 函数栈查看调用栈的可能内存布局

     在多线程(任务)环境，栈顶指针指向的存储器区域就是当前使鼡的堆栈切换线程的一个重要工作，就是将栈顶指针设为当前线程的堆栈栈顶地址