gcc -o addr_test addr_test.c -static

（此处使用静态链接，以便演示位置相关代码的特征）

我们运行这个程序3次，会发现所有的地址都是一个固定值。这是因为在没有开ASLR特性时，系统不会随机化分配程序的虚拟地址空间，程序所有的地址都是按照固定的规则来生成。

图3 - 固定segment地址分布

通过objdump命令反汇编后可以看到，对于全局变量和函数调用的访问，汇编指令跟的地址都是固定的，这样的代码我们就称它为位置相关的。

图4 - 位置相关代码汇编语句实例

这种代码，由于地址是写死的，只能加载到指定地址上运行，一旦加载地址有变化，由于代码里访问的变量、函数地址是固定的,加载地址变化后程序无法正常执行。

固定地址的方式虽然简单，但是无法实现一些高级特性比如动态库支持。动态库的代码会通过mmap()系统调用来映射到进程的虚拟地址空间，不同的进程中，同一个动态库映射的虚拟地址是不确定的。如果动态库的实现上使用位置相关的代码，则无法达到其任意地址运行的目的，这种情况下我们就需要引入位置无关代码PIC的概念了。

另外，我们可以看到，在没有开启地址随机化特性的系统上，由于程序各个segment的地址是固定的，黑客在攻击时会更加简单(感兴趣的同学可以搜索一下Ret2shellcode或Ret2libc攻击)，此时需要引入PIE的概念搭配ASLR一起来防护。

二、位置无关代码PIC和动态库的实现

PIC位置无关代码是指代码无论被加载到哪个地址上都可以正常执行。gcc选项中添加-fPIC会产生相关代码。

PIC用于生成位置无关的共享库，所谓位置无关，指的是共享库的代码断是只读的，存放在代码段，多个进程可同时公用这份代码段而不需要拷贝副本。库中的变量（全局变量和静态变量）通过GOT表访问，而库中的函数，通过PLT->GOT->函数位置进行访问。Linux下编译共享库时，必须加上-fPIC参数,否则在链接时会有错误提示(有资料说AMD64的机器才会出现这种错误,但我在Inter的机器上也出现了)。

关键点#1 - 代码段和数据段的偏移

代码段和数据段之间的偏移，在链接的时候由链接器给出，对于PIC来说非常重要。当链接器将各个目标文件的所有p组合到一起的时候，链接器完全知道每个p的大小和它们之间的相对位置。

图5 - 代码段和数据段偏移示例

如上图所示，示例中这里TEXT和DATA时紧紧挨着的，其实无论DATA和TEXT是否是相邻的，链接器都能知道这两个段的偏移。根据这个偏移，可以计算出在TEXT段内任意一条指令相对于DATA段起始地址的相对偏移量。如上图，无论TEXT段被放到了哪个虚拟地址上，假设一条mov指令在TEXT内部的0xe0偏移处，那么我们可以知道，DATA段的相对偏移位置就是:TEXT段的大小 - mov指令在TEXT内部的偏移 = 0xXXXXE000 - 0xXXXX00E0 = 0xDF20

关键点#2 - X86上指令相对偏移的计算

如果使用相对位置进行处理，可以看到代码能够做到位置无关。但在X86平台上mov指令对于数据的引用需要一个绝对地址，那应该怎么办呢？

从“关键点1”里的描述来看，我们如果知道了当前指令的地址，那么就可以计算出数据段的地址。X86平台上没有获取当前指令指针寄存器IP的值的指令（X64上可以直接访问RIP），但可以通过一个小技巧来获取。来看一段伪代码：

图6 - X86平台获取指令地址汇编

这段代码在实际运行时，会有以下的事情发生：

• 当cpu执行 call STUB的时候，会将下一条指令的地址保存到stack上，然后跳到标签STUB处执行。

• STUB处的指令是pop ebx,这样就将 "pop ebx"这条指令所在的地址从stack弹出放到了ebx寄存器中，这样就得到了IP寄存器的值。

1.全局偏移表GOT

在理解了前面的几点后，来看看在X86上是如何实现位置无关的数据引用的，此特性是通过全局偏移表global offset table（GOT）来实现的。

GOT是一张在data p中保存的一张表，里面记录了很多地址字段 (entry)。假设一条指令想要引用一个变量，并不是直接去用绝对地址，而是去引用GOT里的一个entry。GOT表在data p中的地址是明确的，GOT的entry包含了变量的绝对地址。

图7 - 代码地址和GOT表entry关系

如上图，根据"关键点1"和“关键点2”，我们可以先获取到当前IP的值，然后计算得到GOT表的绝对地址，由于变量的地址entry在GOT表中的偏移也是已知的，因此可以实现位置无关的数据访问。

以一条绝对地址的mov指令的伪代码为例（X86平台）：

图8 - 位置相关mov指令示例

如果要变成位置无关的代码，则要多几个步骤

图9 - 结合GOT实现位置无关的mov指令示例

通过上面的步骤，就可以实现代码访问变量的地址无关化。但是还有一个问题，这个GOT表里存储的VAR_ADDR值又是怎么变成实际的绝对地址的呢？

假设有一个libtest.so,有一个全局变量g_var,我们通过readelf -r libtest.so后，会看到如下的输出

图10 - rel.dyn段全局变量重定向描述字段

动态加载器会解析rel.dyn段，当它看到重定向类型为R_386_GLOB_DAT的时候，会做如下操作：将符号g_var实际的地址值替换到偏移0x1fe4处（也就是将Sym.Value的值替换为实际地址值）

2.函数调用的位置无关化实现

从理论上讲，函数的PIC实现也可以通过和数据引用GOT表相同的方式实现位置无关。不直接使用函数的地址，而是通过查GOT来找到实际的函数绝对地址。但实际上函数的PIC特性并不是这么做的，实际情况会复杂一些。为什么不按照和数据引用一样的方式，先来看一个概念：延迟绑定。

对于动态库的函数来说，在没有加载到程序的地址空间前，函数的实际地址都是未知的，动态加载器会处理这些问题，解析出实际地址的过程,这个过程称之为绑定。绑定的动作会消耗一些时间，因为加载器要通过特殊的查表、替换操作。

如果动态库有成百上千个函数接口，而实际的进程只用到了其中的几十个接口，如果全部都在加载的时候进行绑定操作，没有意义并且非常耗时。因此提出了延迟绑定的概念，程序只有在使用到对应接口时才实时地绑定接口地址。

因为有了延迟绑定的需求，所以函数的PIC实现和数据访问的PIC有所区别。为了实现延迟绑定，就额外增加了一个间接表PLT（过程链接表）。

PLT搭配GOT实现延迟绑定的过程如下：

第一次调用函数

图11 - 首次调用PIC函数时PLT,GOT关系

首先跳到PLT表对应函数地址PLT[n],然后取出GOT中对应的entry。GOT[n]里保存了实际要跳转的函数的地址，首次执行时此值为PLT[n]的prepare resolver的地址，这里准备了要解析的函数的相关参数，然后到PLT[0]处调用resolver进行解析。

resolver函数会做几件事情：

（1）解析出代码想要调用的func函数的实际地址A

（2）用实际地址A覆盖GOT[n]保存的plt_resolve_addr的值

（3）调用func函数

首次调用后，上图的链接关系会变成下图所示：

图12 - 首次调用PIC函数后PLT,GOT关系

随后的调用函数过程，就不需要再走resolver过程了

三、位置无关可执行程序PIE

PIE，全称Position Independent Executable。2000年早期及以前，PIC用于动态库。对于可执行程序来讲，仍然是使用绝对地址链接，它可以使用动态库，但程序本身的各个segment地址仍然是固定的。随着ASLR的出现，可执行程序运行时各个segment的虚拟地址能够随机分布，这样就让攻击者难以预测程序运行地址，让缓存溢出攻击变得更困难。OS在使能ASLR的时候，会检查可执行程序是否是PIE的可执行程序。gcc选项中添加-fPIE会产生相关代码。

四、Linux ASLR机制和PIE的关系

ASLR的全称为 Address Space Layout Randomization。在Linux 2.6.12 中被引入到 Linux 系统，它将进程的某些虚拟地址进行随机化，增大了入侵者预测目的地址的难度，降低应用程序被攻击成功的风险。

在Linux系统上，ASLR有三个级别

表2 - ASLR级别描述

ASLR的级别通过两种方式配置：

echo level > /proc/sys/kernel/randomize_va_space