以下部分为CSAPP第七章中的内容。
由于库函数是经常更新的，且像print这种函数会被调用很多次，如果使用静态库会被复制很多次，浪费空间。所以出现了共享库，所有程序在运行或加载时通过动态链接器动态链接共享同一段内存里的代码。在 Linux 系统中通常用 .so 后缀来表示可共享库，微软中用DLL表示。

c
-fpic 选项指示编译器生成与位置无关的代码（下一节将详细讨论这个问题）。-shared 选项指示链接器创建一个共享的目标文件。一旦创建了这个库，随后就要将它链接到图 7-7 的示例程序中：

1.当加载器加载和运行可执行文件 prog2l 时，它利用 7.9 节中讨论过的技术，加载部分链接的可执行文件 prog2l。
2.接着，它发现 prog2l 包含一个 .interp 节，这一节包含动态链接器的路径名，动态链接器本身就是一个共享目标（如在 Linux 系统上的 ld-linux.so）.加载器不会像它通常所做地那样将控制传递给应用程序，而是加载和运行这个动态链接器。
3.然后，动态链接器通过执行下面的重定位完成链接任务：

重定位 libc.so 的文本和数据到某个内存段。

重定位 libvector.so 的文本和数据到另一个内存段。

重定位 prog2l 中所有对由 libc.so 和 libvector.so 定义的符号的引用。

最后，动态链接器将控制传递给应用程序。从这个时刻开始，共享库的位置就固定了，并且在程序执行的过程中都不会改变。

动态链接是一项强大有用的技术。下面是一些现实世界中的例子：
分发软件。微软 Wmdows 应用的开发者常常利用共享库来分发软件更新。他们生成一个共库的新版本，然后用户可以下载，并用它替代当前的版本。下一次他们运行应用程序时，应用将自动链接和加载新的共享库。
构建高性能 Web 服务器。许多 Web 服务器生成动态内容，比如个性化的 Web 页面、账户余额和广告标语 s 早期的 Web 服务器通过使用 fork 和 execve 创建一个子进程，并在该子进程的上下文中运行 CGI 程序来生成动态内容。然而，现代高性能的 Web 服务器可以使用基于动态链接的更有效和完善的方法来生成动态内容。

应用程序还可能在它运行时要求动态链接器加载和链接某个共享库，而无需在编译时将那些库链接到应用中。

JAVA定义了Java Native Interface去调用本地C和C++函数：通过把C函数变成.so共享库，然后使用类似dlopen的接口进行读取调用。

共享库的主要目的是给多个程序使用。
那么，多个进程是如何共享程序的一个副本的呢？
一种方式是给每个共享库分配一个事先预备的专用的地址空间片，然后如果要使用这个共享库，加载器就访问这个地址。但是提前分配会导致内存浪费，内存分配不准确等问题。

可以使用位置无关代码（position independent code PIC），在x8664系统中，如果是对同一个程序的符号的引用不需要把其变成PIC，可以使用PC相对寻址来编译这些引用。如果是外部共享库的引用，则使用PIC。

如何实现PIC?
定义一个全局偏移表GOT，这个表会存储一个引用的实际地址，如果检测到还没存储到实际的运行地址，会先调用动态链接器来返回一个实际的运行地址。
GOT放在数据段的开头。

这样代码如果需要调用外部引用的话，调用地址填写GOT的内容即可（通过 GOT 进行间接访问），由于GOT和调用处的相对地址是不变的，所以通过PC相对寻址就可以访问到外部引用。

在编译时先生成重定位记录在.rel中，然后动态链接器在程序加载的时候再解析它。不过，这种方法并不是 PIC，因为它需要链接器修改调用模块的代码段，GNU 编译系统使用了一种很有趣的技术来解决这个问题，称为延迟绑定（lazy binding），将过程地址的绑定推迟到第一次调用该过程时。这样不需要在调用模块的代码段增加引用的模块，而是通过访问内存中的某一个地址访问被引用模块。

过程链接表（PLT）。PLT 是一个数组，其中每个条目是 16 字节代码。PLT[0] 是一个特殊条目，它跳转到动态链接器中。每个被可执行程序调用的库函数都有它自己的 PLT 条目。每个条目都负责调用一个具体的函数。PLT[1]（图中未显示）调用系统启动函数（__libc_start_main），它初始化执行环境，调用 main 函数并处理其返回值从 PLT[2] 开始的条目调用用户代码调用的函数。在我们的例子中，PLT[2] 调用 addvec，PLT[3]（图中未显示）调用 printf。
全局偏移量表（GOT）。正如我们看到的，GOT 是一个数组，其中每个条目是 8 字节地址。和 PLT 联合使用时，GOTfO] 和 GOT[1] 包含动态链接器在解析函数地址时会使用的信息。GOT[2] 是动态链接器在 ld-linux.so 模块中的入口点。其余的每个条目对应于一个被调用的函数，其地址需要在运行时被解析。每个条目都有一个相匹配的 PLT 条目。例如，GOT[4] 和 PLT[2] 对应于 addvec。初始时，每个 GOT 条目都指向对应 PLT 条目的第二条指令。

图 7-19a 展示了 GOT 和 PLT 如何协同工作，在 addvec 被第一次调用时，延迟解析它的运行时地址：
第 1 步。不直接调用 addvec，程序调用进入 PLT[2]，这是 addvec 的 PLT 条目。
第 2 步。第一条 PLT 指令通过 GOT[4] 进行间接跳转。因为每个 GOT 条目初始时都指向它对应的 PLT 条目的第二条指令，这个间接跳转只是简单地把控制传送回 PLT[2] 中的下一条指令。
第 3 步。在把 addvec 的 ID（0x1）压入栈中之后，PLT[2] 跳转到 PLT[0]。
第 4 步。PLT[0] 通过 GOT[1] 间接地把动态链接器的一个参数压入栈中，然后通过 GOT[2] 间接跳转进动态链接器中。动态链接器使用两个栈条目来确定 addvec 的运行时位置，用这个地址重写 GOT[4]，再把控制传递给 addvec。
图 7-19b 给出的是后续再调用 addvec 时的控制流：
第 1 步。和前面一样，控制传递到 PLT[2]。
第 2 步。不过这次通过 GOT[4] 的间接跳转会将控制直接转移到 addvec。
Linux的ASLR共有3个级别0、1、2
0: 关闭ASLR,没有随机化,堆栈基地址每次都相同,libc加载地址也相同
1: 普通ASLR mmap、栈基地址、libc加载随机化,但是堆没有随机化
2.增强ASLR,增加堆随机化

比如我们想获取system函数的运行地址，我们可以先利用格式化字符串漏洞先获取到printf函数的实际运行地址。由于printf函数和system函数都在libc库，所以其在libc库中的地址距离和实际载入后的运行地址偏移距离是一致的，所以我们可以获取他们再获取Libc中的相对偏移，再加上printf的实际运行地址，既可以得到system函数的运行地址。
可以表示为：
system实际地址=printf实际地址+两函数在libc库中的相对距离

参考程序为《CTF竞赛权威指南PWN篇》第175页

可以看到程序存在格式化字符串漏洞
首先分析程序

看到这个0804a010是printf的GOT地址， 0x8048360

看到先跳转到plt表

查看一下printf函数和system函数的运行地址

发现printf函数的运行地址还是plt表项的地址，说明还没解析，而system函数也没有内容。

设断点在这里，准备跳转到plt表

si进去

看到跳转到GOT表的printf项的存内容所指向的地址（0x804a010 上面打印GOT表的时会出现过）

由于现在GOT表的printf项的存的是PLT表项的第二条指令的地址。
所以会直接向下执行。

此时再次si进入，跳转到plt[0]

plt[0]把GOT[1]的重定位表项GOT[1]的地址压栈然后跳转到动态链接器的地址GOT[2]。
执行ni，最终会跳回到printf的代码。

可以看到printf函数的代码开始地址为0xf7e2b430
此后，printf的PLT表项会直接跳转到GOT表项中存有的printf函数的运行地址，即以下跳转会直接跳转到0xf7e2b430

可以看到 printf和system两个函数的地址已经可以被打印出来
但system函数是什么时候链接进来的？？？我也还不清楚。

漏洞利用代码如下：

执行代码

可以看到输出的system函数地址0xf7e172e0与gdb打印的内容一致。
我们打印一下gdb里面printf实际运行地址的十进制表示

可以看到4158829616就是printf地址的十进制表示

这是在libc中的地址

[招生]系统0day安全班，企业级设备固件漏洞挖掘，Linux平台漏洞挖掘！