x64 番外篇——保护模式相关
写在前面
此系列是本人一个字一个字码出来的，包括示例和实验截图。由于系统内核的复杂性，故可能有错误或者不全面的地方，如有错误，欢迎批评指正，本教程将会长期更新。 如有好的建议，欢迎反馈。码字不易，如果本篇文章有帮助你的，如有闲钱，可以打赏支持我的创作。如想转载，请把我的转载信息附在文章后面，并声明我的个人信息和本人博客地址即可，但必须事先通知我。
你如果是从中间插过来看的，请仔细阅读 羽夏看Win系统内核——简述 ，方便学习本教程。
看此教程之前，问几个问题，基础知识储备好了吗？保护模式篇学会了吗？练习做完了吗？没有的话就不要继续了。
🔒 华丽的分割线 🔒
概述
在64位下，有两种CPU模式，一种是IA-32e模式，是IA-32模式的扩展，另一个是Legacy模式。IA-32e模式是指内核64位，用户64或32位均可，它强制平坦段，不支持任务切换；而Legacy模式指内核32位，用户32位支持非平坦段、任务切换、虚拟8086、实模式等。
在IA-32e模式下，代码段和数据段仍使用64位描述符，强制平坦（FS，GS除外）；TSS段描述符扩展到128位，TSS段不用来任务切换，主要保存一堆rsp备用指针；中断门描述符扩展到128位。
有些寄存器我们需要知道的，如下所示：
| MSR 寄存器名 | 索引数值 |
|---|---|
| IA32_EFER_MSR | C0000080H |
| IA32_FS_BASE | C0000100H |
| IA32_GS_BASE | C0000101H |
| IA32_KERNEL_GS_BASE | C0000102H |
IA32_EFER_MSR
该MSR结构如下所示：
索引0位表示SYSCALL/SYSRET这类指令是否启用，索引8位表示IA-32e模式是否启用，索引10位表示IA-32e模式是否处于处于活动状态，索引11位知识是否启用PAE分页的XD位是否有效。如果到这里有不会的地方，请回去复习。
下面我们在虚拟机中读取该寄存器的值：
kd> rdmsr C0000080
msr[c0000080] = 00000000`00000d01
kd> .formats 00000000`00000d01
Evaluate expression:
Hex: 00000000`00000d01
Decimal: 3329
Octal: 0000000000000000006401
Binary: 00000000 00000000 00000000 00000000 00000000 00000000 00001101 00000001
Chars: ........
Time: Thu Jan 1 08:55:29 1970
Float: low 4.66492e-042 high 0
Double: 1.64474e-320
从上面的值我们可以看出寄存器里面的所有的功能处于启用状态。
IA32_FS_BASE
这个MSR寄存器保存的是fs的基址，由于是64位内核，直接读取的话该值是0，我们可以读取一下：
kd> rdmsr C0000100
msr[c0000100] = 00000000`00000000
IA32_GS_BASE
这个MSR寄存器保存的是gs的基址，内核指向KPCR结构体（和32位的fs一样的作用），我们可以尝试以下：
kd> rdmsr C0000101
msr[c0000101] = fffff805`5e089000
kd> dt _KPCR fffff805`5e089000
nt!_KPCR
+0x000 NtTib : _NT_TIB
+0x000 GdtBase : 0xfffff805`65690fb0 _KGDTENTRY64
+0x008 TssBase : 0xfffff805`6568f000 _KTSS64
+0x010 UserRsp : 0
+0x018 Self : 0xfffff805`5e089000 _KPCR
+0x020 CurrentPrcb : 0xfffff805`5e089180 _KPRCB
+0x028 LockArray : 0xfffff805`5e089870 _KSPIN_LOCK_QUEUE
+0x030 Used_Self : 0x00000079`22c2a000 Void
+0x038 IdtBase : 0xfffff805`6568e000 _KIDTENTRY64
+0x040 Unused : [2] 0
+0x050 Irql : 0 ''
+0x051 SecondLevelCacheAssociativity : 0xc ''
+0x052 ObsoleteNumber : 0 ''
+0x053 Fill0 : 0 ''
+0x054 Unused0 : [3] 0
+0x060 MajorVersion : 1
+0x062 MinorVersion : 1
+0x064 StallScaleFactor : 0xb58
+0x068 Unused1 : [3] (null)
+0x080 KernelReserved : [15] 0
+0x0bc SecondLevelCacheSize : 0x900000
+0x0c0 HalReserved : [16] 0xad178600
+0x100 Unused2 : 0
+0x108 KdVersionBlock : (null)
+0x110 Unused3 : (null)
+0x118 PcrAlign1 : [24] 0
+0x180 Prcb : _KPRCB
IA32_KERNEL_GS_BASE
这个MSR的作用是作为GS基址的交换目标。说人话的话就是一个缓存，交换比较方便。我们从3环到0环。从0环到3环，GS内核指向KPCR，3环指向TEB，是如何做到呢？这个就是一个非常重要的寄存器.进0环的时候，把3环的交给它；出0环的时候，把0环的交给它。
我们来读一下：
kd> rdmsr C0000102
msr[c0000102] = 00000079`22c2a000
按照上述说法，这个就是TEB了，但由于这个是3环的地址，我们无法读取里面的结构体内容。
由于现在64位CPU一般安装的系统都是IA-32e模式下的，即内核64位的，故后续所有介绍都会以IA-32e模式为主。
段与段描述符
在64位系统下，段的保护被进一步弱化。绝大多数的段被强制平坦。何为强制平坦，就是段的首地址和界限的值不再起作用，被保留置0。首地址默认是0，界限默认十六进制全是F。但也有例外，比如GS和FS，因为它们指向一些结构体，这些结构体的首地址肯定不是0。
64位的段和32位的段大体上就上述变化，但有一个段比较特别，那就是代码段，我们来看一下它的结构：
代码段比32位的多了个位L，它的作用是来指示是32位的还是64位的，如果是0表示兼容模式（x86模式），为1则表示x64模式。
里面还有一个D位，它的作用是指示默认大小的。如果L == 0，如果该位是0，默认的数据和地址大小为16位；反之为32位。如果L == 1，D位必须为0，否则会触发通用保护异常。
最后要介绍的段就是TSS段，被扩展为128位，用于满足寻址要求，如下结构所示：
TSS和32位的操作系统一样，只是用来保存一堆寄存器的，并不用于任务切换。
页
在64位下分页不再是PAE分页，而是被Intel称之为4级分页（4-LEVEL PAGING）的东西。当CR0.PG == 1 && CR4.PAE == 1 && IA32_EFER.LME == 1时会启用该分页模式。4级分页将48位线性地址转换为52位物理地址。虽然52位对应于4 PBytes，但线性地址仅限于48位，最多可以访问256 TBytes的线性地址空间。也就是说剩余的16位是被保留的。
4级分页使用分页结构的层次结构来生成线性地址的转换。CR3用于定位第一个分页结构，即PML4表。将CR3与4级分页一起使用取决于是否已通过设置CR4.PCIDE启用进程上下文标识符。
这个CR3也是结构的，并不直接是物理地址的，如果CR4.PCIDE为0，则它的结构如下：
如果CR4.PCIDE为1，则它的结构如下：
其中M是MAXPHYADDR的缩写，最大是52，这个值通过CPUID.80000008H:EAX[7:0]进行查询，在我的虚拟机操作系统这个值为十进制的39。
kd> r cr4
cr4=0000000000070678
kd> .formats 0000000000070678
Evaluate expression:
Hex: 00000000`00070678
Decimal: 460408
Octal: 0000000000000001603170
Binary: 00000000 00000000 00000000 00000000 00000000 00000111 00000110 01111000
Chars: .......x
Time: Tue Jan 6 15:53:28 1970
Float: low 6.45169e-040 high 0
Double: 2.27472e-318
首先我们得确认这个CR4.PCIDE是在哪个位上，发现是在索引17位：
这个位被置1了，说明是第二种形式。有关这部分细节，对于我们不写操作系统的人来说似乎没啥用处，就不追究了。
下面我们来看看4级分页线性地址的结构，如下是线性地址如何翻译成物理地址的：
按照之前的说法套路，给一个非正式的名字9-9-9-9-12分页。又了之前的底子，我就不赘述内部的详细结构，直接用一张图进行总结（在Intel白皮书的第2832页）：
细心的你可能会发现protection key这个东西，这是啥呢？这个就是4级分页的一个新的机制，提供更完全的保护，当CR4.PKE == 1时有效，不幸的是，在我的虚拟机的操作系统并不使用该位，所以无效，如果对这块技术感兴趣请仔细阅读Intel白皮书的第2835页。
当然上述分页还有大页的情形，如下所示：
下面我们就用x86下的实验方式来学习分页，首先你得有新版的CheatEngine，下面开始：
如上图所示，我打开了一个CheatEngine和一个Notepad，并且在记事本里面写上hello,world!。然后我们开始老套路搜索内存：
把,改为%，定位到指定的地址，如下图所示：
我们先用vtop执行偷懒看看结果：
kd> !process 0 0 notepad.exe
PROCESS ffff8f0fec1be080
SessionId: 1 Cid: 091c Peb: 4e42d08000 ParentCid: 0b70
DirBase: 9bd65002 ObjectTable: ffffdd8291064c40 HandleCount: 356.
Image: notepad.exe
kd> !vtop 9bd65000 1DEFB0044B0
Amd64VtoP: Virt 000001defb0044b0, pagedir 000000009bd65000
Amd64VtoP: PML4E 000000009bd65018
Amd64VtoP: PDPE 000000009d581bd8
Amd64VtoP: PDE 00000000a3882ec0
Amd64VtoP: PTE 00000000827ae020
Amd64VtoP: Mapped phys 0000000027fca4b0
Virtual address 1defb0044b0 translates to physical address 27fca4b0.
kd> !db 27fca4b0
#27fca4b0 68 00 65 00 6c 00 6c 00-6f 00 25 00 77 00 6f 00 h.e.l.l.o.%.w.o.
#27fca4c0 72 00 6c 00 64 00 21 00-0d 00 0a 00 00 00 00 00 r.l.d.!.........
#27fca4d0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
#27fca4e0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
#27fca4f0 00 00 00 00 00 00 00 00-08 00 79 fe de 01 00 00 ..........y.....
#27fca500 00 00 00 00 00 00 00 00-2a f8 73 48 50 71 00 10 ........*.sHPq..
#27fca510 30 48 00 fb de 01 00 00-00 42 00 fb de 01 00 00 0H.......B......
#27fca520 40 48 00 fb de 01 00 00-10 42 00 fb de 01 00 00 @H.......B......
为什么我在遍历进程的后面加上notepad.exe呢？是因为在Win10上，就算你原装最低配置，也有一大串的进程，带来很大的烦恼。我明确是记事本的进程叫这个名字，我就在后面限定它。
你或许还有一个疑问，为什么命名目录表基址的值为9bd65002，但为什么vtop的时候后面的2没了呢？那么我们再回过头来看看上图的Cr3结构你就会明白为什么。
在做这个实验的时候，发现了一个十分有意思的现象，当你恢复虚拟机执行其他操作的时候，再次中断回到Windbg，注意我没有退出记事本，回来发现它的DirBase发生了变化。
好，我们继续我们的实验：
kd> !process 0 0 notepad.exe
PROCESS ffff8f0fec1be080
SessionId: 1 Cid: 091c Peb: 4e42d08000 ParentCid: 0b70
DirBase: 9c065002 ObjectTable: ffffdd8291064c40 HandleCount: 359.
Image: notepad.exe
kd> !vtop 9c065000 1DEFB0044B0
Amd64VtoP: Virt 000001defb0044b0, pagedir 000000009c065000
Amd64VtoP: PML4E 000000009c065018
Amd64VtoP: PDPE 0000000036881bd8
Amd64VtoP: PDE 00000000a3982ec0
Amd64VtoP: PTE 00000000828ae020
Amd64VtoP: Mapped phys 0000000027fca4b0
好我们手动拆分虚拟地址并用访问物理地址的方式进行该实验。首先拆分以下我们的虚拟地址：
000000011 = 0x3
101111011 = 0x17B
111011000 = 0x1D8
000000100 = 0x4
010010110000 = 0x4B0
拆解完毕后，我们来开始进行测试：
kd> !dq 9c065000
#9c065000 8a000000`13a79867 00000000`00000000
#9c065010 00000000`00000000 8a000000`36881867
#9c065020 00000000`00000000 00000000`00000000
#9c065030 00000000`00000000 00000000`00000000
#9c065040 00000000`00000000 00000000`00000000
#9c065050 00000000`00000000 00000000`00000000
#9c065060 00000000`00000000 00000000`00000000
#9c065070 00000000`00000000 00000000`00000000
kd> !dq 36881000+17b*8
#36881bd8 0a000000`a3982867 00000000`00000000
#36881be8 00000000`00000000 00000000`00000000
#36881bf8 00000000`00000000 00000000`00000000
#36881c08 00000000`00000000 00000000`00000000
#36881c18 00000000`00000000 00000000`00000000
#36881c28 00000000`00000000 00000000`00000000
#36881c38 00000000`00000000 00000000`00000000
#36881c48 00000000`00000000 00000000`00000000
kd> !dq A3982000+1D8*8
#a3982ec0 0a000000`828ae867 0a000000`27aa6867
#a3982ed0 0a000000`1222f867 00000000`00000000
#a3982ee0 00000000`00000000 00000000`00000000
#a3982ef0 00000000`00000000 00000000`00000000
#a3982f00 00000000`00000000 00000000`00000000
#a3982f10 00000000`00000000 00000000`00000000
#a3982f20 0a000000`99493867 0a000000`91a7b867
#a3982f30 00000000`00000000 00000000`00000000
kd> !dq 828ae000+4*8
#828ae020 81000000`27fca867 81000000`10be0867
#828ae030 81000000`892f5867 81000000`980f7847
#828ae040 81000000`2aef6867 81000000`93dfe867
#828ae050 81000000`12f06867 81000000`5210f867
#828ae060 81000000`98211867 81000000`a4310847
#828ae070 81000000`b011f867 81000000`2b920867
#828ae080 81000000`95d23847 81000000`6da22847
#828ae090 81000000`0e728847 81000000`88827867
kd> !db 27fca000+4b0
#27fca4b0 68 00 65 00 6c 00 6c 00-6f 00 25 00 77 00 6f 00 h.e.l.l.o.%.w.o.
#27fca4c0 72 00 6c 00 64 00 21 00-0d 00 0a 00 00 00 00 00 r.l.d.!.........
#27fca4d0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
#27fca4e0 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
#27fca4f0 00 00 00 00 00 00 00 00-08 00 79 fe de 01 00 00 ..........y.....
#27fca500 00 00 00 00 00 00 00 00-2a f8 73 48 50 71 00 10 ........*.sHPq..
#27fca510 30 48 00 fb de 01 00 00-00 42 00 fb de 01 00 00 0H.......B......
#27fca520 40 48 00 fb de 01 00 00-10 42 00 fb de 01 00 00 @H.......B......
当然上述我们有不严谨的地方，我们并没有判断是否是大页的情况，但对于一般变量来说，大页的情况还是比较少的。
学过我之前写的教程都知道，操作系统可是不能这么直接访问物理内存的，它依旧通过线性地址进行访问内容，必然在某个地址放着这几张表。按照之前的学习路线，我们必然得需要逆向MmIsAddressValid，下面我们开始继续：
; BOOLEAN __stdcall MmIsAddressValid(PVOID VirtualAddress)
public MmIsAddressValid
MmIsAddressValid proc near ; CODE XREF: KiMarkBugCheckRegions+B3↑p
; KiMarkBugCheckRegions+1E8↑p ...
sub rsp, 28h
call MmIsAddressValidEx
add rsp, 28h
retn
MmIsAddressValid endp
可以看出，这个啥也没做，只是调用了MmIsAddressValidEx这个函数，我们点进去看看：
; BOOLEAN __fastcall MmIsAddressValidEx(PVOID VirtualAddress)
MmIsAddressValidEx proc near ; CODE XREF: MiIncreaseUsedPtesCount+64↑p
; MiCommitExistingVad+65D↓p ...
PXE = qword ptr -28h
PPE = qword ptr -20h
PDE = qword ptr -18h
PTE = qword ptr -10h
VirtualAddress = qword ptr 8
; FUNCTION CHUNK AT .text:00000001402234DC SIZE 00000056 BYTES
mov [rsp+VirtualAddress], rbx
push rdi
sub rsp, 20h
mov rax, rcx ; VirtualAddress
mov r10, rcx
sar rax, 47 ; 实现的虚拟地址是48位的，如果是内核地址，则最后是-1，用户地址是0
inc rax ; 自增1
cmp rax, 1 ; 如果大于1，有问题
ja InvalidAddr
mov rdx, rcx ; VirtualAddress
mov rdi, 0FFFFF68000000000h ; PML4 表基址
shr rdx, 9
mov rcx, 7FFFFFFFF8h
and rdx, rcx
mov rax, rdi
add rdx, rax
mov [rsp+28h+PXE], rdx ; 获取 PXE
shr rdx, 9
and rdx, rcx
mov rax, rdi
add rdx, rax
mov [rsp+28h+PPE], rdx ; 获取 PPE
shr rdx, 9
and rdx, rcx
mov rax, rdi
add rdx, rax
mov [rsp+28h+PDE], rdx ; 获取 PDE
shr rdx, 9
and rdx, rcx
mov rax, rdi
add rdx, rax
mov r11, 0FFFFF6FB7DBED000h
mov [rsp+28h+PTE], rdx ; 获取 PTE
mov edx, 4
mov rbx, 0FFFFF6FB7DBED7F8h
loc_1400AB248: ; CODE XREF: MmIsAddressValidEx+BF↓j
mov r9, [rsp+rdx*8-8] ; 初始值 rdx = 4
dec rdx
mov rcx, [r9]
mov rax, r11
cmp r9, rax
jb short loc_1400AB263
mov rax, rbx
cmp r9, rax
jbe short loc_1400AB27E
loc_1400AB263: ; CODE XREF: MmIsAddressValidEx+A9↑j
; MmIsAddressValidEx+D9↓j ...
test cl, 1
jz short InvalidAddr
test cl, cl
js short loc_1400AB2BD
test rdx, rdx
jnz short loc_1400AB248
loc_1400AB271: ; CODE XREF: MmIsAddressValidEx+113↓j
; MmIsAddressValidEx+122↓j
mov al, 1
loc_1400AB273: ; CODE XREF: MmIsAddressValidEx+126↓j
mov rbx, [rsp+28h+VirtualAddress]
add rsp, 20h
pop rdi
retn
; ---------------------------------------------------------------------------
loc_1400AB27E: ; CODE XREF: MmIsAddressValidEx+B1↑j
mov eax, cs:MiFlags
test eax, 0C00000h
jz short loc_1400AB263
mov rax, gs:_KPCR.Prcb.CurrentThread
mov r8, [rax+_KTHREAD.___u25.ApcState.Process]
cmp [r8+_EPROCESS.Pcb.AddressPolicy], 1
jz short loc_1400AB263
test cl, 1
jz short InvalidAddr
test cl, 20h
jz loc_1402234DC
test cl, 42h
jnz short loc_1400AB263
jmp loc_1402234DC
; ---------------------------------------------------------------------------
loc_1400AB2BD: ; CODE XREF: MmIsAddressValidEx+BA↑j
mov rax, rdi
cmp r10, rax
jb short loc_1400AB271
mov rax, 0FFFFF6FFFFFFFFFFh
cmp r10, rax
ja short loc_1400AB271
InvalidAddr: ; CODE XREF: MmIsAddressValidEx+1B↑j
; MmIsAddressValidEx+B6↑j ...
xor al, al
jmp short loc_1400AB273
MmIsAddressValidEx endp
但不幸的是，我根本无法弄懂这块代码的所有细节，完全弄懂的部分均用注释标注，主要是如下代码看起来十分奇怪：
loc_1400AB248: ; CODE XREF: MmIsAddressValidEx+BF↓j
mov r9, [rsp+rdx*8-8] ; 初始值 rdx = 4
dec rdx
mov rcx, [r9]
mov rax, r11
cmp r9, rax
jb short loc_1400AB263
mov rax, rbx
cmp r9, rax
jbe short loc_1400AB27E
根据堆栈图，它是在该函数直接提栈的局部变量区，而我未发现任何初始化该区域数据的汇编代码。该代码里面还有ShadowMapping这个东西，从名字上来看是影子映射相关的，但我同样弄不出来相关细节。网络上有关x64的资料少之又少，我无法解决，所以有关页的相关内容，只能在此告一段落。
门
门在x86上是十分重要的东西，尤其是中断门在Win系统扮演了十分重要的角色。鉴于之前在基础篇保护模式介绍的内容基础，这里就只讲调用门和中断门。
注意：我不太建议做和学WinXP一样的内核实验，因为PG有可能会被触发导致蓝屏，搞懂原理即可。
调用门
在x64下，调用门的结构如下：
可以看出，调用门被扩展为128位，基本内容并没有发生任何变化。我们看看GDT表里面的内容：
kd> dq gdtr
fffff803`86c90fb0 00000000`00000000 00000000`00000000
fffff803`86c90fc0 00209b00`00000000 00409300`00000000
fffff803`86c90fd0 00cffb00`0000ffff 00cff300`0000ffff
fffff803`86c90fe0 0020fb00`00000000 00000000`00000000
fffff803`86c90ff0 86008bc8`f0000067 00000000`fffff803
fffff803`86c91000 0040f300`00003c00 00000000`00000000
fffff803`86c91010 00000000`00000000 00000000`00000000
fffff803`86c91020 00000000`00000000 00000000`00000000
里面的内容少了不少，相比于XP系统来说。有关调用门细节就介绍这些。
中断门
中断门也被同样的扩展为128位，其余的功能并没有发生任何变化。
然后我们再看一下IDT表：
kd> dq idtr
fffff803`86c8e000 81158e00`00101100 00000000`fffff803
fffff803`86c8e010 81158e04`00101180 00000000`fffff803
fffff803`86c8e020 81158e03`00101200 00000000`fffff803
fffff803`86c8e030 8115ee00`00101280 00000000`fffff803
fffff803`86c8e040 8115ee00`00101300 00000000`fffff803
fffff803`86c8e050 81158e00`00101380 00000000`fffff803
fffff803`86c8e060 81158e00`00101400 00000000`fffff803
fffff803`86c8e070 81158e00`00101480 00000000`fffff803
我们可以用!idt获取每一个索引对应的函数，如下为部分展示，后面有stack的说明该函数有自己独占的栈。
kd> !idt
Dumping IDT: fffff80386c8e000
00: fffff80381151100 nt!KiDivideErrorFaultShadow
01: ffff80381151180 nt!KiDebugTrapOrFaultShadow Stack = 0xFFFFF80386C929D0
02: fffff80381151200 nt!KiNmiInterruptShadow Stack = 0xFFFFF80386C927D0
03: fffff80381151280 nt!KiBreakpointTrapShadow
04: fffff80381151300 nt!KiOverflowTrapShadow
05: fffff80381151380 nt!KiBoundFaultShadow
06: fffff80381151400 nt!KiInvalidOpcodeFaultShadow
07: fffff80381151480 nt!KiNpxNotAvailableFaultShadow
08: fffff80381151500 nt!KiDoubleFaultAbortShadow Stack = 0xFFFFF80386C923D0
……
有关中断门相关内容，暂时就这么多。
SMEP 与 SMAP
x64的CPU又增加了一些标识来增加安全性：SMEP与SMAP。这两个标识在CR4中，我们再拿来看看：
SMEP英文全称是supervisor-mode execution prevention，看意思就是限制执行代码的。SMAP英文全称为supervisor-mode access prevention，看意思就是限制访问内存的。这些限制是限制谁的，限制内核的。在WinXP下，只要是内核就具有至高无上的权限，我想读哪块内存就读，想执行啥代码就执行。
说这两个标志位的功能倒是挺容易的，为什么要说这个东西呢？之前的实验应用层程序通过调用门提权并执行代码就会出现问题，我们需要对这两个标志位进行清0操作，否则就会出错。
有一个特殊的汇编指令CLAC，它的作用是清除EFLAGS寄存器中的AC标志位。这将禁用用户模式数据访问的任何对齐检查。如果在CR4寄存器中设置了SMAP位，这个位就不会起作用；STAC可以恢复使用SMAP。有关这两个位介绍就这么多。
下一篇
x64 番外篇—— WOW64
本文来自博客园，作者：寂静的羽夏 ，一个热爱计算机技术的菜鸟
转载请注明原文链接：https://www.cnblogs.com/wingsummer/p/16092862.html
