环境及配置：

虚拟机：win10 X64 1903，VS2015+WDK10驱动开发环境

主机OS： Win10 1809

WIndbg：Windbg10.0.18362.1，VKD-Redux

虚拟机：VMware 15.5.5

win10 1903是微软于2019年新推出的操作系统版本，它涵盖了微软所有最新的安全保护机制，如SMEP，SMAP，KPTI，CFG，patch guard以及一系列和硬件漏洞有关的缓解机制等。他是19年度功能性更新的版本，1909版本年1903版本的稳定版，所以区别应该是不大。

我的虚拟机版本是VMware 15.5.5，15.5.5较15的早期版本稳定且快速。它修复了很多bug，比如早期版本无法从主机复制文件到虚拟机的bug。我没采用最新的15.5.6版本，整体感觉不如15.5.5好用(该版本创建虚拟机时优先采用nvme虚拟磁盘，但实测区别不大，甚至感觉慢于SCSI)。？

因为内核代码只要稍有错误就会产生致命的崩溃，所以无论是驱动开发还是内核安全研究，都不可避免的会蓝屏。所以为了少花时间在重复的崩溃+重启+连接调试器+修改内存数据上，我的建议是给虚拟机拍摄运行时快照，一旦崩溃直接恢复到上一个运行时状态，如果您的电脑配置一般，可以尝试将虚拟机内存减小，减少了文件读写的总量从而提高了恢复速度。快照还能间接绕过KALSR

多啰嗦一句，请大家在调试漏洞/研究内核前一定要把网断掉，因为联网后Windows的自动更新会偷偷修改内存布局，可能导致实验出错。我之前在做9-9-9-9-12分页实验时，经常才解析到第一/二级页表就发现后面的页表内存全都失效了，我排查很久才发现是因为没有断网。。。。我的断网设置如下

windbg是我配置VS2015+WDK10驱动开发环境时，WDK里自带的windbg，版本是Windbg10.0.18362.1，但我感觉不同windbg的版本区别不会很大，硬要说的话，特别老的版本无法执行类似 dq gdtr 指令,只能先r gdtr，然后dq addrgdt,很不方便。而且老的windbg可能将win10识别成win7，因为它出生那会还没win10呢。但即使这样其实影响也不大，原因是windbg并没有深度的侵入系统，他只是一个将内核信息做格式化后展示出来的printer而已。前段时间论坛很多兄弟都在发HEVD教程，大家翻一翻就知道怎么配了。

最后，很多同学都使用Virtual KD进行内核调试，VKD确实方便，但建议既要配置传统的管道调试环境又要配置VKD环境，原因是，VKD每次都只能在启动时用调试器连接操作系统，相当于每一次OS都以boot debug选项启动，这个给我们将来调试和研究patch guard 带来了很大的困难，因为如果在PG初始化之前就附加了调试器，那么PG是不会初始化的，导致PG被“绕过”，就无法研究他的原理了，想研究PG我觉得最好别用VKD-redux，用管道调试合适。

顺便一提，有的人说只要附加调试器就能绕过PG，我觉得这种说法不太准确，应该是在PG初始化前附加调试器可以自动绕过，就是那个windows图标刚出现，马上附加调试器是可以的，VKD-redux是可以在初始化前附加上去的。如果用管道调试，太考验人的手速的人品了，几乎做不到，

预备知识

阅读本文需要熟练掌握32位操作系统下段保护模式和页保护模式的知识，还需要有X64汇编基础。

对比总结32位和64位下,IDT,GDT,DS,CS,TSS,FS,GS的异同

1.IA32e

首先这块其实自己也不太懂，可能理解也不太准，我就是分享给大家我是怎么理解的。IA-32e 是扩展IA32指令集，e代表extention。XP下CPU不是有好几种工作模式嘛，保护模式，实模式，虚拟8086模式，64位下新加了一种IA32e模式，IA32e又分成两种工作模式，第一种是内核是64位的，用户程序可以是64位或32位的。还有一种叫Legacy模式：是内核是32位，用户程序也是32位的运行模式。我既可以安装64位的操作系统也能安装32位的，就得益于此IA-32e。

到64位就不再兼容很早以前的模式比如虚拟8086这些过时的东西，但Legasy模式就能很好兼容之前的模式（不是说64位就用不到之前的模式了，比如64位操作系统启动时还是实模式，然后逐渐进入ia-32e模式，但系统稳定后就永远稳定在ia32e模式）。

2.如何查看是否处于IA-32e模式

C0000080，该常量既不是一个虚拟地址，也不是一个物理地址。他是MSR寄存器有关的一个宏，可能是一个偏移，用rdmsr C0000080 指令查看MSR寄存器在那个偏移的值。

查看得到msr[c0000080] = 00000000 00000d01 00000000 00000000 00000000 00000000 00000000 00000000 00001101 00000001

该字节数组下标索引是8的位置1就说明出于ia32e模式，注意，是下标索引是8的位置，是从0开始数的，也就是第9位被置一，表明是ia32e模式，另外考虑字节序，是从后往前数的。

3.32/64位下的CS和DS

DS，ES，SS在64位模式下已不再使用。

IA32e下，代码段CS，数据段DS仍和32位一样使用64位，即8字节的描述符，但仅仅是DS和CS段描述符一样，不意味着64位所有GDT表项和32位的都完全相同。用Windbg dq gdtr的结果如下

如果出现连续4个8字节全是0表明GDT已经结束。可以看到，这里甚至没有用l参数指定长度GDT就全显示出来了，可见64位的GDT表确实比32位OS下的GDT表要短的多。64位下变短的原因我觉得主要有两方面，一是因为IA-32e用不到为了兼容虚拟8086模式、实模式而存在的GDT表项，所以微软把他删了。其实XP系统中也没怎么用到，系统进入保护模式后，这些项就完全没用了，就那么空在那，甚至还有从系统启动到结束就没用过的表项。不但占地方还给了黑客可趁之机，很多大神看上了这一大片有可读写可执行属性的内存，把Shellcode或者全局数据区布置在这了，这操作也是非常的骚气。二是由于到了64位微软对段保护机制严重弱化，甚至已经基本废掉了段保护机制，DS，ES，SS在64位模式下已不再使用。自然GDT表项就少了。目前64位主要依靠页保护机制，SMEP，SMAP，KPTI等保护机制的核心也是页保护而不是段保护。

Windbg有个dg指令可以快速判断代码段/数据段描述符，用法是dg+相对于GDT表首地址的偏移，就以第三项00209b00 00000000的为例，它距离GDT表首16个字节，就是两个GDT表长度为10h，所以dg 10 后如下所示

简单解释一下：Code表示是给CS段描述符用的，P1是0表示DPL是0，是给零环用的。基址base和界限limit都是0，是由于强制平坦导致的，所谓强制平坦就是基址为0，界限是0，这么做是为兼容性考虑。再对比白皮书中段选择子，发现L位被置一，说明是64位代码段。

再以第四项为例解析一下 dg 18

显然是给零环用的代码段，但是L位已经不代表64/32位，只有代码段才生效。

同理可知，dg 20 是三环代码段，dg 28 是三环数据段。

4.32/64位下的TSS

GDT表第9项是TSS任务段,用dg 40查看如下

40偏移的确是TSS任务段的起始没错，但这里解析出的TSS段，它的段基址和偏移都是不对的。如果用用dq查看这个基址，会发现这里根本没有内存。这是因为，64位下的TSS段已经不再是32位下的8字节了，而是扩展到了16字节，但dg指令默认取8字节，所以解析出来一定是错的。

我们手工解析这个16字节的TSS：fffff80545a5dff0 : 45008ba5 c0000067 00000000 fffff805,段基址应该是：fffff805+45+a5+c000 = fffff80545a5c000。这是TSS真正的起始地址。这里需要大家自己把相应位置的数据找出来，记住顺序。

虽然英特尔设计TSS的初衷是给OS厂商做任务切换的（一定要注意！任务切换不等于线程切换！），但32位时代无论是微软还是Linux都没有采用英特尔的设计，因为跟MSR不一样，TSS不是一个寄存器而是块内存区域，真要用这个来切换，会导致频繁的内存读写，内存读写十分耗时会降低系统的速度。有多耗时呢？只要做过5级页表映射实验的同学应该都深有体会，所以微软和Linux都用MSR寄存器来切，英特尔也意识到了这点，所以64位时代英特尔干脆把TSS段的任务切换作用彻底废了，再也不保存之前那些通用寄存器了。

32位TSS长这样

64位的TSS变成这样

64位的TSS主要用于存放内核切换时用到的栈指针，上图中IST是一些特殊的栈指针，和中断有关。RSP0,1,2,3就是零环，1环，2环，三环的默认栈指针。我们已经知道TSS的基址是fffff80545a5c000，但TSS开头的四个字节是Reserved，所以要想正确解析出RSP还得再加上4变成fffff80545a5c004

可以看到，RSP0是fffff805 45a5f200，还记得三环进零环时切换成内核栈的过程嘛，这个内核栈指针就是RSP0了，每次切换到零环默认用这个栈指针。RSP1，RSP2都是0，操作系统没用到1环和2环。RSP3没有的，因为每次三环进零环RSP3是随机的。我们可以查看一下RSP0内核栈，发现全是0

5.32/64位下的IDT表

大部分情况下，零环代码就用RSP0这个内核栈了。但是少部分情况，有一些特殊的中断比如不可屏蔽中断和双重错误会使用特殊的栈。TSS里那一堆IST其实也是RSP指针，这里保存着特殊的栈指针。光这么说肯定听不懂，我们具体看看64位下的IDT表，

64位下的IDT表项已经全部从之前的64位变成128位。总结一下，64位下CS和DS仍然是8字节没变，而TSS和IDT变成了128位也就是16字节。由于最新的windows基本废弃了段保护机制，数据段和代码段的基址和偏移已经没有意义了，没必要把8字节的段描述符扩展到16字节，数据/代码段寄存器可以被强制平坦。但TSS和IDT的基址和界限还是有实际意义的，他们不能被强制平坦的，必须扩展到128位基址和偏移才有地方放，才能寻址到全部的地址空间，不然只有8字节肯定放不下那么大的偏移和界限，所以IDT项要16个字节

以0号中断为例手工解析一下。

fffff805 45a5b000 ： 43168e00-00107100 00000000-fffff805

不能用之前解析TSS的方法解析它。按照之前的方法他的基址应该等于00000000 fffff805+43+00+ 0010=fffff80543000010，但IDT的结构和TSS不同，应该是00000000 fffff805+4316+7100=fffff80543167100，我们可以对照一下下图64位的中断门描述符的结构，发现offset的确应该是63..32+31..16+15..0

可以对比一下32位的中断门描述符结构：

(注释：1.64位取消了任务门 2.64位合并了中断门和陷阱门描述符 3.32/64位中断门的差别只有IST和偏移地址)

我们再用!idt来验证一下0号中断处理函数的地址是不是刚刚解析出来的那个值

发现0号中断指定的处理函数基址的确是fffff80543167100，

64位的中断门描述符里有个IST项，他叫IST索引号，这就和我们之前的特殊栈指针联系起来了，如果不指定索引号默认填写0，使用的就是RSP0，但是如果你不喜欢默认的栈，想使用系统分配的特殊的栈，就需要指定了IST，就把那个特殊IST的编号写到这里。

下图是之前查看过的TSS。以第0个IDT项43168e00-00107100 00000000-fffff805为例： 里面8e00里的00 就是IST，如果这个位置的数字是0，就用默认的RSP0，栈指针就是下图中fffff80545a5f200。如果这个数是1，内核栈就用IST1，IST1就是下图中的fffff80545a5f3d0，

是2内核栈就用IST2，对应fffff80545a5f5d0。因为大部分IDT项用不到特殊的栈指针，所以大部分IDT表项这里都是0，对应fffff80545a5f200

从下图可以看到，01,02,08中断的中断处理函数的栈比较特殊，windbg给我们特殊标了出来，对应idtr项的IST分别是04,03和01，没标出来的IST都是0，即都是用的默认的内核栈。

01号是硬件断点的中断，02号中断是系统突然掉电的中断，而8号中断是处理双重错误，就是处理一个异常时又出现异常的处理函数，系统会蓝屏，这些函数都挺特殊，都不用默认的内核栈指针了。

6.32/64位下的FS和GS

32位系统FS三环时指向TEB，零环时用KPCR，而64位系统三环时用GS指向TEB，零环时GS指向KPCR（之前32位windows下根本没用过GS），也就是说，在64位下不再用FS指向KPCR和TEB，64位下用GS取代了FS，FS则继续留给32位程序继续用

和32位的一样，64位IDT表里仍然大量使用中断门描述符，但任务门已经没了，而且调用门和陷阱门windows仍然没有用，虽然windows不使用不代表不能人为构造，但是它这么做的原因是什么呢，这就不得不提到一个中断门独有的优势。

中断门有个天然属性，就是执行中断处理函数时，默认是屏蔽掉可屏蔽中断的，比如时钟中断。即相当于在中断处理函数最开始的位置插入了一行汇编指令cli，该指令修改RFLAG寄存器的IF标志位，设置当前函数为不可中断。

如果没有设置中断不可屏蔽行不行，答案是不行的，我们知道一旦进入零环后，32位系统的FS寄存器/64位系统下的GS寄存器，必须要设置指向内核结构体KPCR之后，才能将中断打开，这样线程才能正常调度。

以KiBreakpointTrapShadow为例，它是int3的中断处理函数，如果是三环执行到int3，就进入执行该函数（零环执行int3则是直接进入KiBreakpointTrap），设想有如下情景：假如在刚进KiBreakpointTrapShadow没有关闭中断，如果执行到第一行 test [rsp+arg_0], 1 时突然时钟中断来了，并且导致线程切换，切换时一定用到KPCR结构体，但是此时swapgs还没执行到，从IDA可以看出，swapgs指令还在第三行，GS并没有来得及指向正确的KPCR，如果此时切换线程，结果必然是线程切换失败，系统直接崩溃蓝屏。

如果微软大量使用陷阱门或调用门，进入中断处理例程后这俩默认是开中断的，虽然GS很快能被修正，但理论上还是能被外部中断打断，所以不太稳定。然而中断门会自动屏蔽rflag标志位的IF中断标志位，这是他的优点，所以操作系统只使用中断门而不使用陷阱门和调用门。

既然FS/GS还是需要指向KPCR的，就从侧面说明FS和GS不能被强制平坦，因为如果他俩也被强制平坦，KPCR的基址就没地方保存了。

事实也正是如此，但问题是，既然FS和GS没被强制平坦，又没有像TSS一样扩展到128位，那该怎么指向正确的地址空间呢，微软的解决方案是，他给出了三个寄存器，

IA32_FS_BASE C0000100，IA32_GS_BASE C0000101，IA32_KERNEL_GS_BASE C0000102

并没把基址保存在FS/GS里而是MSR寄存器里，用这三个寄存器配合rdmsr指令就能读到MSR里FS和GS寄存器的值，换言之FS/GS的偏移被保存到MSR里了。

下图中，用rdmsr C0000100来读取内核FS，但在零环里读到不到内核的FS，读出来全是0，只能在用户进程下才能读到。rdmsr C0000101零环下能读到内核GS，也就是KPCR的首地址。我们可以将rdmsr C0000101的返回值解析成kpcr结构体。

总结一下，64位下FS/GS寄存器不保存KPCR的基址和偏移，他们被保存在MSR里，当一个零环线程调度到三环线程时，系统会把MSR寄存器复制到FS寄存器，然后在三环中再用rdmsr C0000100就能读到0环FS寄存器的值。

而32位下KPCR的地址是该段选择子对应段描述符的偏移地址,32位下段描述符在GDT表里，但是64位下FS/GS虽然没有被强制平坦但和GDT表没任何关系了。这里纠正一个可能的误区，我们之前一直说段寄存器是8字节的，指的并不是段寄存器总长度，而是段描述符的长度。段寄存器在32/64位下应该都是96位 （这里我自己理解的也不一定对，欢迎吐槽，欢迎指正,热烈欢迎）

另外之前XP系统三环进零环是通过push 30 然后 pop fs 来设置FS的，64位下设置FS是通过swapgs，该指令本质上是把MSR中IA32_GS_BASE里的值和MSR里IA32_KERNEL_GS_BASE的值交换了一下。

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