API（应用程序编程接口）是微软为开发者提供的一套函数接口，可以用于与系统进行交互、实现一些复杂的功能等。

我们日常在3环写的API如：ReadMemory、CloseHandle、OpenProcess等。其真正的功能实现全部在驱动层，3环中我们使用的只是一个门票，用于通知驱动层我们要实现的功能。而这些API函数从3环的校验代码进入到0环的功能代码的步骤，就称为系统调用。

一些常见的动态链接库如下：

于防来说，了解系统调用可以更好的了解程序流程。对于一些恶意样本，攻击者会将API调用改为直接进入0环的方式，这样对于一些3环的监控工具则无法监控该样本的行为，一些3环的APIHOOK也将失效。同样的，IDA一类的反汇编工具也无法直接查看样本使用了哪些API函数。

于攻来说，了解系统调用可以让你真正知道API函数执行的本质，无论是自实现系统调用、驱动层HOOK或是以服务号调用API，都可以让你的攻击手段很难被安全从业者察觉、分析。而HOOK住驱动层的功能函数，也可以达到另类的驱动通信效果。

由于现在的系统带有PG保护，使得系统调用这个技术点无法被直接利用，现已作为基础知识慢慢的与其他技术相融合。

在MSDN上搜索该函数，发现其所属模块为kernel32.dll，但是当你去追kernel32里的流程，你会发现最终都是执行了一个return 0。这是历史遗留问题，所以不能盲目相信MSDN。

在WIN7镜像中，随便找个程序拖到OD里，Ctrl+G定位至ReadProcessMemory函数。发现该函数已经隶属于KernelBase模块了。且其内部没有什么有用的代码，只调用了ntdll的NtReadVirtualMemory函数。该函数是KernelBase的导入函数。

使用IDA打开ntdll，在导出函数选项卡中搜索NtReadVirtualMemory。

跟过去看一下该函数的实现。发现函数内部仅调用了[7FFE0300]处的函数，同时为eax赋值。

至此，3环绝大部分告一段落。可以发现ReadProcessMemory函数的3环执行流程就是跳来跳去，然后执行一个call [7FFE0300]。接下来我们需要探求7FFE0300里面存的是什么。

在继续分析之前，我们需要补充一个知识点：_KUSER_SHARED_DATA。这是一个3环与0环共享的结构体。

在3环，它的地址为7ffe0000，具备只读权限。在0环，它的地址为ffdf0000，具备读写权限。这两个地址指向同一个物理页，只是访问权限不同。该结构会在操作系统启动时由操作系统自己填充。

结构体信息如下：

其中偏移0x300处的成员为SystemCall，该成员指明了当发生系统调用时，3环进入0环走哪个函数，该成员就存储对应函数的地址。

由于现在的处理器均支持快速调用（sysenter指令），而旧处理器不支持，所以此处存储的函数地址有两种情况。后文仅演示快速调用。（中断门（0x2E）进0环已经在历史的长河中被替代了，有兴趣的可以了解下。）

为了查看7FFE0300的值，我们需要借助windbg动态调试。

在windbg中输入 !process 0 0遍历所有进程，随便附加其中一个即可。

输入 dt _KUSER_SHARED_DATA 7FFE0000查看该结构体的成员信息。可以发现偏移0x300处存储的值为0x77a470b0。

使用命令 u 77a470b0 查看该地址的函数。可以看到windbg帮我们识别出来是ntdll模块中的KiFastSystemCall函数。回到IDA中，定位至该函数，观察函数执行流程。

可以发现该函数只有两行代码：mov edx,esp sysenter。 sysenter将会进入0环。

在保护模式章节中，我们知道3环进0环必备的几个条件：

在旧CPU中，使用中断门（0x2E）进行系统调用，需要查询TSS来获取这几个寄存器的值。内存查询是很慢的。

而sysenter指令将会直接从MSR寄存器中读取并写入至CS、SS、EIP、ESP中，速度很快，因此称为快速调用。

MSR寄存器很大，存了很多的数据。

在偏移0x174处，存储着系统调用时0环的CS。

在偏移0x175处，存储着系统调用时0环的ESP。

在偏移0x176处，存储着系统调用时0环的EIP。

SS的值通过CS+8得到（具体原因参考保护模式章节，CS与SS的段描述符是相邻的）。

通过指令RDMSR/WRMSR可以对MSR寄存器进行读写。

在windbg中查看CS ESP EIP的值：

在windbg中输入命令 u 83e420c0查看这个函数

可以得知当我们在3环调用sysenter指令时，将会执行内核模块（ntoskrnl、ntkrnlpa）中的KiFastCallEntry函数

当发生系统调用时，若CPU支持快速调用，则走KiFastSystemCall函数，内部执行sysenter指令。并在0环执行KiFastCallEntry函数。同时携带了edx（3环堆栈）、eax（系统调用号）

以下结构体均在内核空间，3环无法直接访问

在进入0环时，该结构体用于保存3环寄存器。由windows进行维护。

结构体成员：

在3环时，FS指向TEB结构。在0环时，FS指向KPCR结构。该结构体用于描述对应的CPU的状态。（一核对应一个KPCR）

windbg中输入 dd KeNumberProcessor 查看核数

windbg中输入 dd KiProcessorBlock LXXX 查看每个核的KPCR结构地址。

结构体成员：

结构体成员：

线程结构体，每一个线程都有一个线程结构体，用于描述对应线程的各种属性。

结构体成员：

Ethread的子结构体，里面的成员相对于Ethread更重要。

结构体成员：

分析该函数需要时刻对照上文的几个结构体，否则无法理解函数在做什么。

函数内部首先填充DS ES FS寄存器，并切换堆栈。（由于MSR寄存器所有核共享一个，为了防止互相影响，又从各自的TSS中拿了单独的ESP0 ）

然后填充TrapFrame结构，该结构存储在0环堆栈中，通过push依次进行成员的填充。

起始位置为HardwareSegSs，V86那四个寄存器是虚拟8086模式用的，所以直接省略了。

继续填充TrapFrame结构体的其余成员。

填充好后将TrapFrame结构的首地址赋值给Kthread中的TrapFrame成员。

在上文3环分析部分，可以看到ReadPrcMem函数仅调用了sysenter，并没有直接调用内核的某个对应函数。其真正调用的功能函数的地址，将通过查找系统服务表的方式得到。而3环传入的eax则是这个系统服务表的索引，也叫系统调用号。

系统服务表的宏观架构（系统服务表地址存储在Kthread+E0处）：

3环在调用sysenter之前往eax中存的值决定了要调用哪个函数。

系统调用号仅低13位起作用，结构如下：

下标为12的位（第13位）如果为0，则查第一张系统服务表，为1则查第二张。

低12位（0~11）就是函数地址表和函数参数表的索引。

首先拆分系统调用号，找到系统服务表地址，取出索引。

获取函数地址、函数参数个数，复制参数至0环堆栈，并做第一次权限判断（3环堆栈地址判断）。

再次判断3环cs权限，通过后调用最终的功能函数。

上文通过Kthread+BC去得到了系统服务表地址。Windows中提供了一个导出的全局变量SystemServicesDescriptorTable。也叫SSDT。这个全局变量存储了系统服务表的地址，但仅存储了第一张表的地址。

在windbg中输入命令 dd KeServiceDescriptorTable查看该全局变量。可以发现只有一张表（16个字节）。第二张表全部为空。

内核中还有一个全局变量称为SSDT Shadow，该变量未导出，但可以查看所有的系统服务表。

在windbg中输入命令 dd KeServiceDescriptorTableShadow查看该全局变量。可以看到所有的系统服务表。

接近上文call ebx后，首先检查IRQL及线程挂靠相关信息。

然后检查ETW日志是否需要记录。并为Kthread->TrapFrame成员赋值。可用于恢复旧TrapFrame或蓝屏时进行堆栈回溯。

随后判断是否虚拟8086模式和之前的特权级。并相应的执行性能统计。

如果有APC需要处理则处理APC。（仅先前模式为用户模式时才会处理，APC知识后续章节学习。）

恢复异常链表及调试寄存器（如果为调试模式的话）。

进行一万个感觉没卵用的判断

最后恢复各种寄存器，并以iret方式返回3环。

返回的代码真正有用的就是恢复寄存器的几行，其余全是在做先前模式相关的判断。其中穿插了一个处理APC的逻辑。

当有APC需要处理时，会以另一套流程返回3环，由于目前不具备APC知识，暂不做分析。

整体分析流程皆以 先前模式为用户级别 为前提去分析，可以看到判断还是很多的，甚至考虑了其他非正常cs的情况。

SSDT HOOK代码不算难，个人觉得比Inline HOOK简单的多。

还挺好玩的，简单的保护了DbgView进程。

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！