Windows内核-系统调用

如果你写过一个读写进程内存的小工具，在用户态调用 OpenProcess、ReadProcessMemory，一切正常；可一旦想绕过某个保护机制，或者想让自己的调用不被调试器拦下来，就会发现知识断在了半路——从 ntdll 到内核那一步，看不见也摸不着。这门课要补的就是这个缺口。

先确认你到底缺哪一块

下面这些情况，中一条以上，说明这门课对你不是"锦上添花"而是"必须补"：

• 知道用户态 API 最终会走到 ntdll 里的 Nt* 函数，但说不清 sysenter 执行的那一刻寄存器里装了什么；
• 调试时被断点拦住，只会换工具，不知道断点为什么偏偏设在那里；
• 听过 SSDT 这个词，也能说出它是"系统服务描述符表"，但没实际改过其中一项；
• 写驱动时调用内核函数顺手就来，却从没回头看过这些函数是怎么被用户态请求触达的。

如果这些你都能顺畅讲清楚，那这门课对你价值有限，不必浪费时间。它面向的是知道"结果"但没走过"过程"的人。

这门课真正要讲清的一条链

核心就是一条执行链：三环的 API 调用如何一步步落到零环，执行完又如何返回三环。课程会把中间每一段都拆开看，包括 sysenter 进入零环时的现场、系统服务表如何根据服务号定位到具体内核函数、零环处理完之后的返回路径。另一条路是 int 0x2E，它和 sysenter 做的是同一件事，但走的是中断门，对比着看更容易理解为什么现代系统选了前者。

把这条链走通之后再回头看调试器的行为，很多之前"莫名其妙的拦截"会变得有迹可循——因为你知道调用在哪个环节被观察、在哪个环节可以被改写。

两个动手点：不是看懂，是能改

自写三环 API

不用 ntdll 提供的入口，自己拼出一次完整的系统调用。目的很直接：当调用路径不经过常规位置时，按常规位置下断点的调试器就失去了着力点。这里必须真正理解服务号怎么来、参数怎么传、栈怎么切，否则拼出来的调用只会崩。

SSDT HOOK

修改系统服务表里的目标项，让指定的调用在进入真正内核函数之前先落到你自己的处理逻辑上。这一节的落点是：让调试器无法打开进程。听起来是一句话，做起来涉及表项定位、原函数地址保存、调用约定对齐、以及改完之后如何不把系统搞蓝屏。

这两件事的共同点是：它们都建立在对调用链的准确理解上，抄代码抄不出来。

建议的练法

• 先纯看：跟一遍从三环到零环再回来的完整流程，把每一步的寄存器和栈画出来；
• 再验证：在虚拟机里对着自己的理解下断点，看实际执行位置和你推断的是否一致；
• 然后动手：先写通三环自调用，确认能正常返回，再去碰 SSDT；
• 最后加约束：所有实验都在快照过的虚拟机里做，内核层的改动一旦出错，恢复成本远高于重装。

课件不提供配套资料下载，所有代码需要自己敲。这其实是好事——这段内容的坑都在细节里，复制粘贴会把坑一起复制过去，而你并不知道它为什么能跑。

看完应该能回答的问题

• 一次用户态 API 调用，从进入 ntdll 到内核函数开始执行，中间发生了哪几件事？
• 服务号是在哪一步被用来定位内核函数的？定位依据是什么？
• sysenter 和 int 0x2E 进入零环的差别在哪，为什么会有这种差别？
• 调试器的断点通常设在调用链的哪个位置，绕过它的思路有哪几种？
• SSDT 表项被改之后，原来的内核函数还能被调用到吗？通过什么方式？

这些问题答不上来的部分，就是你需要重点看的部分。别从头到尾平均用力。