在PWN入门-LibC中，我们知道一个最简单的C程序对于LibC的依赖，由于LibC是C语言的基础库，其中包含了太多可以直接利用的东西，所以变成了天然的利用对象。在本文中，将会介绍另一个程序无法离开的东西，包括LibC也会大量使用它们，除了介绍之外，还会借助实例讲解如何对它进行利用，达到PWN的目的！

1. 系统调用解密

一段程序的运行，需要使用各种计算机资源，比如处理器核心、内存、输入/输出设备等等，假如任何程序都可以对这些物理资源进行随意的使用，那么计算机运行期的不可控性会大大增大。

为了避免资源的滥用，引入特权级别这一概念，它将计算机中的不同物种按照“种姓”划分，种姓越高可以操作的资源也就越多。特权级别一般由硬件厂商提供支持，对于操作系统而言，它显然没有必要在指令集提供权限管理支持的情况下，自己再定义一套权限管理机制。

在现代计算机中，操作系统会将计算机世界分成用户态和内核态两大空间，内核空间握有最高权限，可以完全掌控物理资源及核心数据，而用户空间权限则相对较低，它没有直接操作物理资源的资格。

当然用户空间想要访问高特权资源也不是不行，但需要提出申请，提出申请的操作用计算机专业术语描述的话就是系统调用，当用户空间发出系统调用后，内核就会进行相应，然后由内核完成指定的操作（系统调用是中断的一种，内核之所以能响应系统调用就是中断机制提供的帮助，关于中断在此不会有过多的描述）。

1.1 内核对系统调用的支持

用户空间会有各种各样的需求，内核会尽可能的提供支持，内核定义了一套协议，它要求系统调用的发起方提供一个系统调用号，对于内核自身而言，它会实现一个系统调用表sys_call_table，内核会以系统调用号作为索引值，对系统调用表进行检索，并执行检索到的功能。

1.2 系统调用号的查找

在Linux中，一般会将函数、数据及常量的声明相关的头文件放在/usr/include/目录下，该目录是系统自带的，初始内容是内核提供的，由于它是Linux默认的头文件查找路径，所以后续其他程序也可以向该目录添加头文件，常见的就要各类型的动态链接库开发包。

由于/usr/include/目录包含了内核信息，所以查找系统调用号时，可以根据该目录进行查找，系统调用号相关的定义一般放在*unistd*.h文件内，检索该文件就可以快速的获取系统调用号。

除此之外，也可以借助某些应用程序或某些应用程序源代码的帮助。在Linux部分发行版的仓库中有一个叫做ausyscall的程序，它包含在auditd包内，通过该程序可以将系统调用号打印出来。而某些应用程序源代码则是那些提供系统级辅助的程序，比如strace、glibc等等，它们的源代码中会包含系统调用表。

1.3 系统调用表的提交

从上面可以了解到，系统调用由中断机制机制支持，而中断是处理器提供硬件支持的机制，因此操作系统一定会将系统调用表提交给CPU。

Linux内核的启动时第一个运行的函数（不算汇编代码）start_kernel，它肩负起了一个很重要的任务就是初始化各种信息。

从软硬件的角度来看，中断可以分成硬件中断和软件中断（陷阱）两类，顾名思义，硬件中断是硬件向CPU发出的中断信号（APIC或与处理器相连的中断引脚），而陷阱则是软件向CPU发出的中断信号（指令集提供的中断指令）。

系统调用作为内核功能，显然属于陷阱。从start_kernel中可以快速的找到trap_init的身影，接下来让我们看看它都做了什么（这些代码都是于处理器相关的，不同处理器并不适用，所以内核代码中建立一个arch目录，里面存放着各种指令集架构的信息处理代码）。

1.3.1 与64位无关的IDT

trap_init内部与陷阱不强相关的内容暂且忽略，idt_setup_traps函数内部会初始化中断描述符表，要知道软件中断的类别非常之多，CPU如何根据指定中断信号执行对应的操作呢？答案当然还是查表，这个表就是idt_table中断描述符表，idt_setup_traps函数会根据def_idts数组的内容对IDT进行填充。

在def_idts中可以看到除法错误、非屏蔽中断等中断信号的身影，它们对应着不同的异常事件。

idt_table中的元素由gate_struct结构体进行描述，其中segment和offset_low组合形成中断向量号，offset_low、offset_middle、offset_high组合形成中断向量对应的处理函数，而bits用于中断向量的属性。

从def_idts内可以看到，64位系统下的系统调用不会交给IDT进行处理，只会处理32位程序的int80，那CPU从哪里知道系统调用的信息呢？

此处单独处理x64下的系统调用是为了实现快速系统调用，系统调用被大量且经常性的使用，如果系统调用速度较慢，那么这显然是一笔不小的开销，所以并没将x64下的系统调用交给IDT进行处理，而是给提供一个单独的寄存器进行保存。显然上学时住6人间集体宿舍与住单人单间的豪华宿舍相比知晓，是由显著差别的。

1.3.2 系统调用的初始化

在IDT完成设置后，紧接着会调用cpu_init函数，该函数的内部是真正初始化系统调用的地方，syscall_init就是关键函数。

在syscall_init函数的内部可以频繁的看到wrmsr的身影，即的全称是Write to Model Specific Register，即写模型特定寄存器，该寄存器是为了控制CPU运行及功能、调试、追踪程序执行、监测CPU性能等方面而存在的。

CONFIG_IA32_EMULATION是为了兼容32位而存在的，这里面的设置我们暂时忽略它。

不然知道MSR寄存器支持的功能非常之多，通过查阅英特尔芯片手册（MSR和软件设计卷2B）可以知道STAR、LSTAR、CSTAR及FMASK是与系统调用相关的寄存器。

其中LSTAR是专门给64位使用的。

MSR卷：

软件设计手册-2B卷：

从上面的代码中可以看到，system_init主要设置的寄存器就是STAR、LSTAR及FMASK。通过手册可以知道，FMASK用于指明系统调用的标志位属性，一般都是最后设置，STAR为CS代码段寄存器和SS栈寄存器提供内容，主要的作用是区分内核态与用户态的特权级别，LSTAR则直接执行64位系统下的系统调用处理函数的地址，64位下指定的处理函数为entry_SYSCALL_64。

假如在驱动中通过rdmsrl读取内容，就会可以发现LSTAR寄存器中保存的就是函数entry_SYSCALL_64的地址。

1.4 系统调用的自定义

首先我们已经知道了内核会根据系统调用号查找系统调用表，然后在运行时系统调用表会被加载到内存当中，此时只要获取系统调用表的起始地址，然后将表中某元素替换成我们自己定义处理函数，就可以实现系统调用的掉包了。

附件中给出了驱动的代码

1.4.1 系统调用表地址的确定

在Linux内核当中，经常可以看到某个函数或全局变量使用了EXPORT_SYMBOL宏及 EXPORT_SYMBOL_GPL宏的身影，它们的作用是将符号导出到符号命令空间中，使得被导出的符号可以被其余模块访问（比如动态加载的内核驱动）。

该宏首先会将类型为typeof(xxx)的符号声明为全局变量，随后会通过编译器的.section伪指令指定__ksymtab_strings节，接着存放__kstrtab_##sym[]和__kstrtabns_##sym[]两个数组的地址，数组内部分别存储符号名及命名空间名。

通过readelf和objdump工具可以方便的看到该节的信息。

在该宏的结尾处会通过宏__KSYMTAB_ENTRY将外部符号信息放入__ksymtab节内，节中信息包含外部符号的地址、存储外部符号名的数组地址以及存储命令空间名的数组地址。

借助__ksymtab节的帮助，内核外的模块就可以知道被导出符号的信息了。

想要获取系统调用表的地址，可以选择将sys_call_table导出，但是内核为了安全考虑一般不会将它导出，除非自己修改内核。

修改内核难免会有些麻烦，编译替换后还需要重启，并不是很方便，有没有什么办法在运行期就获取内核符号的地址呢？

当然是有的！首先在内核编译时，会产生一个System.map表，该表中会记录函数及全局变量的偏移值，如果你知道内核在运行期的基地址就可以确认它们在运行期的地址。

除了保存偏移值的符号表外，Linux内核提供kallsyms机制，它也保存着一张符号表，不过这个符号表是在运行期生成的，所以查看该表就可以直接获取对应符号在运行期的地址。它相较于System.map有两个好处，一是对运行期地址的直接获取，二是System.map是编译内核时产生的，只包含内核自身的符号信息，而kallsyms机制则提供运行期动态加载的内核模块信息。

kallsyms机制依赖编译选项CONFIG_KALLSYMS，只有该选项开启时该功能才会打开。

为了方便用户空间访问，kallsyms会在初始化时向proc注册kallsyms虚文件，可以通过访问该文件获取地址信息。

假如想要通过编译内核驱动的方式对符号地址进行获取，就需要借助kallsyms提供的接口，在kallsyms当中存在kallsyms_lookup_name函数，该函数的作用是根据指定符号名称查找地址。

但是实际使用kallsyms_lookup_name会遇到一个问题，那就是驱动无法使用未定义的符号kallsyms_lookup_name，显然这个符号并没有被导出，不能被外部模块使用。

通过查看内核源代码可以知道kallsyms内查找符号信息的相关接口均没有导出，进一步查阅资料后发现，只有Linux内核5.7.0之前的版本才会将它们导出。

为了直接通过编译驱动的方式获取系统调用表的地址，借助kallsyms_lookup_name接口的帮助已经是相当方便且通用的方法了，有没有什么办法可以获取未导出符号呢？

这当然也有！要知道在Linux内核当中，默认的调试机制就是依赖printk进行打印，这种静态的调试机制有一种坏处，就是每次新添加调试信息，都需要重新编译内核或内核模块。

但现如今，随着Linux内核的更新，Linux内核支持一种类似于调试器的调试机制，调试器的核心特定就是可以随时查看系统状态，调试器想要观察某函数的执行过程时或变量状态时，首先要做的就是设置断点或观察点。Linux内核支持的新调试机制也与之类似，它支持动态的向被调试目标插入探测点，当被调试目标执行时，会调用调试者自定义的函数对信息进行收集，实现该机制的技术被称作是kprobes。

既然该机制如此强大，那相比获取一个符号的地址也是轻而易举吧！通过查看kprobes的注册函数register_kprobe，可以知道在注册函数的起始位置，它就会根据指定的符号名获取符号地址，这正是我们想要的结果。

借助kprobes技术，我们不止可以获取kallsyms_lookup_name函数的地址，也可以获取sys_call_table数组的地址，从实用性的角度上考虑，获取kallsyms_lookup_name函数是更加好的方案，因为这里我们只需要地址，并不需要使用kprobes技术提供的其他功能。

1.4.2 kallsyms的辅助调试介绍 - 以调试内核驱动加载过程为例

前面介绍kallsyms时讲过，它是一张运行期实时更新的符号表，包含了内核自身及内核模块的符号信息，它对调试起到了非常大的帮助作用，比如printk中根据地址打印符号%pS就是从kallsyms内匹配到的符号。

除此之外，在调试过程中我们经常都需要k（WinDBG的查看栈回溯命令）一下或bt（GDB的查看栈回溯命令）一下，函数的执行流程可以非常有效的帮助我们了解事情发生的经过如何。在Linux内核当中，也存在着这样的功能，它通过dump_stack函数实现，该函数是直接导出的。

dump_stack函数是Linux内核中常用的调试手段，Linux内核让人闻风丧胆的Panic，就会借助它打印栈回溯信息，有些时候不方便编译但有注入错误的机会时，就可以通过Panic机制将栈回溯等信息打印处理。

下面展示了在内核模块初始化函数内，添加dump_stack函数后，内核消息dmesg中出现的内容。

从下面的信息中，可以看到，目前3号CPU正在执行insmod加载驱动命令，其进程号是10350，紧接着的就是栈回溯信息，以及最后的寄存器信息。

从栈回溯信息上看，起始位置是entry_SYSCALL_64_after_hwframe，它位于
entry_SYSCALL_64函数内部（这也是MSR LSTAR寄存器指向的地方），作为全局符号存在，是entry_SYSCALL_64函数开始执行代码的标号。

在此之后会进行一系列的安全检查，这些AMD处理器新添加的安全机制。完成安全检查后，entry_SYSCALL_64就会正式开始调用do_syscall_64函数，这也标志着系统调用的正式开始。

1.4.2.1 无效的系统调用表？

do_syscall_64函数最终会调用x64_sys_call函数，该函数的内部会根据系统调用号匹配对应的处理函数。不过这里一看，switch用的也不是系统调用表啊！难道系统调用表已经被弃用了？

可是所有的文章都说用的系统调用表啊！难道它们都错了，那就让我们看看接下来掉包系统调用表会发生什么吧！

由于目前使用的是insmod命令加载驱动，所以根据系统调用号__NR_finit_module匹配到了__x64_sys_finit_module，该函数的作用是根据驱动文件的文件描述符加载驱动。

由于目前使用使用的内核版本是6.10，所以会先通过idempotent_init_module函数校验Cookie，如果可以匹配到Cookie，那么才会通过init_module_from_file函数读取驱动文件后进行加载，加载驱动的函数就是load_module了。

在版本小于6.8的内核中，finit_module会直接调用load_module对驱动进行加载，Cookie校验机制是6.8内核后新添加的安全机制。

在完成do_init_module函数的任务后，就会正式通过do_one_initcall调用驱动的初始化函数，我们知道Linux当中驱动的初始化函数都具有统一的入口即module_init(xx)，而module_init最终会返回xx的函数指针，就是下面的fn()，do_one_initcall会通过函数指针对初始化函数进行调用。

此时驱动就已经完成了加载。

1.4.3 系统调用表的掉包

经过上面的分析，我们已经可以知道如果获取内核符号的地址以及系统调用的处理流程，那么此时我们就可以先获取系统调用表的地址，在根据指定的系统调用号，对表中的处理函数进行掉包，进而完成系统调用的自定义。

1.4.3.1 崩溃了？！！！

下面是驱动调用系统调用表，dmesg打印如下的内容。

上面的打印信息中显示出3号CPU正在运行1604号进程tee，这是因为驱动响应了echo "syscal hack | sudo tee -a /proc/lde_proc"，进而调用lde_syscall_hack函数。继续查看调用栈信息，从调用栈中可以看到页错误的信息，asm_exc_page_fault函数标志着处理页错误的开始。

代码里面有哪里写地址上的数据了吗？哦，原来是替换系统调用表的时候，不难确认获取的系统调用表的地址是正确的，也可以根据表中元素的地址匹配到符号名（%pS），掉包的地址是自己模块内定义的函数，既然写地址的位置和内容都没有错，那么难道是这个地址不能被写？

在打印信息中还可以看到下面的语句，它说进行写操作时权限违规了。

CPU需要识别地址是否可写，那么信息就一定需要位置保存，对于CPU而言，保存信息的地方当然就是寄存器了。从打印信息中也可也看到，除了栈信息以外，还存在各种寄存器的信息，不难将通用寄存器（用户态软件可以使用的）排除掉，那么就是剩下CR0-CR4寄存器。

通过查阅资料可以知道，CRO用于保存CPU和系统的信息，CR1是保留寄存器，暂时不用，CR2保存页故障对应的虚拟地址（可以看到CR2保存的数值与UG: unable to handle page fault for address的数值一致），CR3则CR2中线性地址对应的物理地址，CR4则标明扩展功能的属性。

由于CR0保存着CPU和系统的信息，所以我们继续看一下CR0寄存器的信息，其中第16位是WP写保护位，根据数值0x80050033可以确定，当前的WP位值是1，只有将WP设置成0就可以写数据了！

接下来通过上面的代码先将WP位设置成0，然后再去该系统调用表，应该就可以了。

1.4.3.2 失效的系统调用表

消除写保护后再次对系统调用进行掉包，然后通过用户程序触发系统调用，但是会发现虽然系统调用表被成功篡改了，但是系统没有执行被篡改的系统调用。

在前面分析驱动的加载流程时，看到过6.10内核中系统调用已经不借助系统调用表进行查找了，尽管系统调用表内还会保存一份处理系统调用信息，但它也只具备帮助作用了。

这一改动在2024年4月8日由Thomas Gleixner提交，在下方给出了对应的提交ID。

1.4.3.3 成功完成系统调用的自定义

尽管已经不在根据系统调用表查找处理函数了，但是我们还可以从中获取到一个重要的信息，就是系统调用处理函数的所在地址，并且我们手中还握着生杀大权 - 写保护的开关权限。有了它们我们就可以直接改写对应地址的指令，让它跳转到我们自定义的函数内部。

上方的代码，就是用于改写指令的，此处使用的跳转方式为mov rax,[目的地址]; jmp rax，其中mov rax对应的原始字节为0x48 0xB8，jmp rax对应的字节是0xff 0xe0。

当前机器使用小端字节序，因此我们需要保障高位数据位于低位地址，低位数据位于高位地址，因此可以构造出下面的字节序列。

将构造好的跳转指令插入到系统调用处理函数的起始位置后，再次执行用户空间程序触发系统调用，此时可以发现系统调用的执行流程已经进入到我们自定义的函数内部了！

1.4.4 IDT表的扩展说明

在前面有提到过IDT表，x64下为了快速的系统调用并没有使用它，但是考虑它的重要性，下面会做一个小演示，其作用是解析IDT表的内容。

从上面代码中可以看到，代码首先会获取IDT表的所在地址，然后会处理段和标志位信息，然后拼接地址，匹配对应的符号。

从下面的打印信息中可以看到，第一列对应IDT表项的序列号，第二列是段和偏移新信息，第三列是比特位信息，第四列是处理中断的函数地址，第五列是函数地址对应的符号信息。

从上方打印的信息中，可以看到IDT表中0号表项用于处理除法错误，254号表项用于处理中断异常，255号表项用于处理APIC的中断异常。

2. 利用思路

在最原始的栈溢出利用当中，需要向栈内注入一段Shellcode并覆盖函数的返回地址，其中被劫持的返回地址需要指向Shellcode的所在位置，当函数返回时自然就会前往执行Shellcode，后面为了缓解该问题，栈所在的内存页会直接被设置为不可执行的状态，此时栈上的Shellcode就无法执行了。

对于用户态程序来讲内存页的可执行状态不是它可以操作的，需要权限更高的内核进行操作，显然用户态程序无法直接完成内存页可执行状态的篡改。

2.1 ROP

想要执行Shellcode有两个条件，一是Shellcode位于可执行的区域，二是有办法前往Shellcode的所在区域。

位于可执行区域的Shellcode并不难找，比如程序自身以及依赖动态链接链接库中的代码，不管借用整个函数还是部分指令都不是问题。此处需要了解的是被利用元素的偏移值及模块的基地址，用于提供位置信息。

既然Shellcode有了，那么应该如何跳转呢？是jxx还是call这样的指令呢，如果是它们，此时就又会要求栈所在内存页是可执行状态的了，它们是不可取的。除此之外还有什么跳转方式呢？call指令用于函数调用，而函数的返回则是ret指令。

ret指令有一个好处，就是它会从栈上取返回地址，对需要向栈上注入数据的我们是刚需的。此时向栈上注入的数据就不再是Shellcode，而是Shellcode对应的地址，每使用一次ret指令都会根据地址执行一段代码，代码结尾如果还是ret指令，那么就会继续取出地址并前往执行。这种利用ret指令进行编程的方式被称作是面向返回的编程ROP(Return-Oriented Programming)。

因此使用ROP时，只需要拥有栈上数据的读取权限，而不需要栈的执行权限，给栈上数据和Shellcode直接搭建执行的桥梁。

2.2 系统调用的利用

比起动态链接库，系统调用才是用户态程序最离不开的存在，借助系统调用可以实现非常丰富的功能，在众多的系统调用中，存在一个我们非常关心且有用的系统调用，它就是__NR_execve，它接收3个参数，第一个参数是可执行程序的路径，第二个参数是命令行参数argv，第三个参数是环境变量参数envp，最后根据这三个参数执行程序。

对于当前机器来讲，保存前六个参数会使用rdi、rsi、rdx、rcx、r8、r9寄存器。

从entry_SYSCALL_64的汇编代码中可以看到，系统调用号位于rax寄存器内（do_syscall_64第二参数是系统调用号，根据调用协议会占用rsi寄存器，entry_SYSCALL_64中将eax的数值放入到rsi后，调用do_syscall_64函数）。

通用寄存器是用户态和内核态都可以访问的，上面复制数据到rdi和rsi时，用户态程序传递参数不就被覆盖了吗？

这个秘密其实就在entry_64.S文件中起始部分包含的calling.h头文件内，该头文件中会提前将寄存器信息压入栈内，按照struct pt_args的格式保存，pt_args会通过movq %rsp, %rdi作为第一个参数传递给do_syscall_64函数，这时do_syscall_64就可以通过pt_args使用用户态程序传递的参数。

到此我们可以知道，为了借助系统调用完成PWN，需要进行以下的操作：

1. 将系统调用号压入rax寄存器内
2. 将参数压入对应寄存器内
3. 压入寄存器的数据需要在栈上构造
4. 构造ROP将它们串联起来，使之可以顺利执行

3. 示例讲解

本次使用的示例程序与PWN入门-LibC取物中的程序一致，反汇编内容在PWN入门-LibC取物中已经进行了详细的解析，下面会直接给出源代码。

程序只开启了NX、PIE保护。

首先，我们的目标是调用Shell，需要__NR_execve系统调用，它的系统调用号是59，放入rax寄存器内。

之后根据内核中execve的要求，我们需要提交第一个参数为Shell程序的路径，而命令行参数和环境变量参数在这里没有需求，从程序的返回变结果来看，不管是main函数还是simple_overflow函数都是没有接收参数的，因此rsi和rdx寄存器中保存的都是libc传递过来的参数，其中rsi和rdx分别对应主程序的命令行参数和环境变量参数。

此时调用shell时并不需要命令行参数rsi，我们需要直接运行Shell，而不是借助Shell运行某某东西，因此rsi可以清空，环境变量在此没有设置的必要，所以rdx也需要清空。

Linux下一般通过/bin/sh运行Shell，因此这里需要根据该字符串对文件进行检索获取相对位置。

该字符串会根据调用协议放入rdi寄存器内。

接下来要做的准备就是构造ROP。

函数的结尾处，有一个天然的ret指令（对应十六进制数据为0xc3），我们需要它带我们前面向寄存器存入参数的指令所在地。其中pop rax指令的十六进制数据为0x58，pop rdi指令的十六进制数据为0x5f，pop rsi指令的十六进制数据为为0x5e，pop rdx指令的十六进制数据为为0x5a。

如此构造有两种方式，一是pop rax ; pop rdi ; xxx ; ret，而是pop rax ; ret ; pop rdi ; ret ; xxx（交换顺序也可）。

通过ROPgadget和hexdump工具检索会发现找不到与方式一匹配的指令。

检索方式二中的格式时，会发现可以检索到数据，其中rax、rdi、rsi分别对应偏移值0xd0887、0xfd8c4及0xfec6b，而rdx则无法检查到数据。

3.1 为什么只有rdx无法检索？

这时因为rax是返回值使用的寄存器，函数中的返回值很多时候都通过局部变量赋值，而局部变量又在栈上，所以从栈上弹出值到rax再返回，很合情合理吧。

至于rsi和rdi，它们是幸运的一方，在x64架构中新添加了r8-r158个寄存器，它们二进制的表示形式中，会借用pop rax等其余七个寄存器的编码，比如pop rsi对应0x5e，pop r14对应0x41 0x5e。还有更加重要的一点，就是r12-r15寄存器是被调用方保存的，如果调用者要使用这些寄存器，就需要先将寄存器的数值压入栈内，返回时再恢复，那么此时r12-r15寄存器就会在返回前进行pop操作，pop rsi和pop rdi与pop r14和pop r15二进制编码部分重合，因此有了部分提取的可能。

剩下最惨的就是rdx寄存器了，非亲非故，找不到一个返回前使用的理由。

考虑到，这里我们需要将rdx寄存器设置成0，而函数返回时返回0或空指针是一种常见的操作，因此在函数返回时对应的汇编代码中，时长可以看到下面的操作（清零edx，然后edx赋值给rax后返回）。

借助上面的汇编代码，我们一页可以实现rdx的清零操作。

3.2 指令的可执行确认

通过readelf工具观察libc.so.6的段头信息，会发现上面找到的偏移值均位于可执行段内，它们是可以进行利用的。

设置好参数后，下一步要做的就是调用系统调用指令syscall，

3.3 构造出来的exploit

3.4 成功PWN

[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课