Windows x64内核学习笔记(二)—— IA-32e模式
- IA-32e模式
- 模式检测
- 强制平坦段
- 任务切换
- 中断门描述符
- FS / GS
- 模式切换
- 32位程序进内核
- 64位程序进内核
- 实验:模式切换
- 第一步:编译以下代码
- 第二步:运行程序至第一次暂停处
- 第三步:使用WinDbg附加进程
- 第四步:在关键位置设置断点
- 第五步:让程序运行至断点位置
- 第六步:单步调试
- 参考资料
IA-32e模式
描述:IA-32e是IA-32模式的扩展,它是一种状态,其内核为64位,用户可以是32位,也可以是64位。
题外话:当在64位CPU中安装32位操作系统时,内核和用户都是32位的,这种状态叫做Legacy模式。
IA-32e模式的几个特性:
- 强制平坦段:段基址不可随意设置,即不再兼容16位模式了。
- 不支持任务切换:取消了TSS任务切换
- 取消了虚拟8086模式和实模式切换
模式检测
描述:如果IA32_EFER MSR(下标为0xC0000080)寄存器的值第八位为1,说明当前系统处于IA-32e模式。
强制平坦段
描述:在x64模式下,段描述符已经不再描述段的基址和界限(除了FS和GS),因此把这种机制叫做强制平坦段。
对于x64模式的gdt表来说,段描述符比x86系统少了很多,这是因为x64将侧重点放在了页保护而不是段保护。
关于64位段描述符的具体结构可以参考Intel开发手册卷3图5-2。
其中,L位为0表示兼容模式(x86模式),为1则表示x64模式。
可以通过Windbg的「dg offset」命令解析段描述符的具体属性。
任务切换
描述:
- 在IA-32e模式下,TSS段描述符扩展到128位,用于满足寻址要求(普通段寄存器不再需要基址和界限)。
- TSS段描述符不用来进行任务切换,而是主要保存一堆RSP的备用指针(当3环和0环发生任务切换时)。
查看TSS数据:
-
TSS段描述符的基址低四字节位于gdtr+40
直接读是什么也读不到的
-
TSS段基址的高四字节位于gdtr+48
-
凑在一起就能读出来具体的值了
x64模式中TSS的具体结构可以参考Intel开发手册卷3图7-11。
可以看到,它的前4个字节时保留的,因此在查看的时候需要跳过四个字节。
中断门描述符
描述:在x64模式中,中断门描述符也拓展到了128位,这样才能满足寻址要求。
具体的中断门描述符结构参考Intel开发手册卷3图6-8
其中,IST位表示当进入中断门时,使用TSS中的哪一项。
不难发现,大部分中断门描述符的IST位都是0,只有少数是有值的。
为0的时候,使用TSS中的RSP0,其他时候使用IST对应的下标。
对照中断函数列表看一下IST有值的项分别都对应什么函数。
可以看到,都是一些比较重要的中断处理程序,当执行这些函数时,需要切换到特定的堆栈。
FS / GS
描述:在x64系统中,当处于0环时,FS不再指向KPCR,而是由GS指向KPCR,在3环时GS指向TEB。
并且x64不再支持调用门、陷阱门、任务门,一律只支持中断门。
思考:为什么要这么做呢?
答案:因为如果通过其他门进去后再去关中断,那么执行关中断的指令时,如果产生了外部中断,由于此时FS寄存器和GS寄存器还没被正确设置,因此可能会产生错误,而调用中断门时,系统会自动将EFLAGS中的IF位清零,即关闭外部中断。
再思考:既然x64已经将段寄存器强制平坦了,FS和GS的基址该去哪里找呢?
答案:三个MSR寄存器。
- IA32_FS_BASE(下标0xC0000100)
- IA32_GS_BASE(下标0xC0000101)
- IA32_KERNEL_GS_BASE(下标0xC0000102)
模式切换
中断:只使用一张IDT表,内核可以根据栈上的CS判断先前模式。
系统调用:
- 只使用一张SSDT表
- 64位程序通过syscall进入内核
- 32位程序在ring3转入x64模式再进入内核
32位程序进内核
描述:32位程序在进入内核前,会先将环境转换成x64模式。
以32位notepad.exe为例,尝试使用x32dbg附加上去。
可以看到,如果在x64系统中运行32位程序,CS的段选择子默认为23。
看一下对应的段描述符。
其中,起关键性作用的是L位(Long),这里为0,说明程序目前在兼容模式下运行,即x86模式。
或者用dg命令看一下,NL表示「Not Long」,即该段为兼容模式。
然后,以NtOpenProcess函数为例,在其首地址设置断点,看一下32位程序是如何进入内核的。
尝试使用记事本打开文件,会触发该断点。
断下来之后,发现将中断号和一个地址放入调用了EDX并调用,这里跟入CALL。
发现里面是一条JMP指令,指向Wow64Transition,看函数名像是与64位模式转换相关,跳过去看看。
关键部分来了,这里有一条JMP FAR长调用指令,这条指令在跳转到0x77646009地址的同时将段选择子切换到了0x33。
先看一下0x77646009地址的指令,让ECX加了1,然后下方看上去似乎是一条跳转指令,而我们观察一下EDI的值,发现里面保存的根本是一个无效地址。
这是怎么回事呢?其实关键点出在段选择子的切换上,让我们看一下段选择子0x33指向的段描述符。
在这个新的段描述符中,L位为1,表示该段为x64模式。
也可以使用dg命令看一下,此时的Lo表示「Long」。
那么到这里就比较清楚了,原来经过了CALL FAR长调用之后,CS段选择子切换到了33,又因为段描述符中L位为1,即x64模式,所以之后的硬编码所对应的指令也都切换到了x64指令。
怎么看具体的指令是什么呢?可以尝试打开一个64位的程序(笔者选择64位的notepad.exe),使用x64dbg附加,然后随便找一条汇编指令,修改它的硬编码,看看之前那个地址77646009真正要执行的指令是什么。
可以看到,硬编码41 FF A7 F8 00 00 00
在32位模式下对应的指令有两条:
41 INC ECX
FF A7 F8 00 00 00 JMP DWORD PTR DS:[EDI+F8]
而在64位模式下对应的指令只有一条,也是32位程序进入内核时真正要执行的指令:
41:FFA7 F8 00 00 00 JMP QWORD PTR DS:[R15+0xF8]
这说明,在一个EXE程序中,能够既包含32位代码,又包含64位代码。
思考:如果在地址77646009设置执行断点,然后单步执行JMP FAR指令,能不能成功断下来进行调试呢?
答案:不能。
如果直接在3环调试器单步执行该CALL FAR指令的话,会直接跳到模式切换回来之后的地方 ,即NtOpenProcess返回的位置。
如果想要调试77646009部分的代码,只能使用WinDbg进行调试。
定位进程的时候,不知道为什么出现了两个notepad_x32.exe,实际只打开了一个,不管了,试试选择第二个进程。
用WinDbg附加上去。
在77646000设置一个断点。
kd> bp 77646000
kd> g //让虚拟机继续运行,等待触发NtOpenProcess,获得中断。
获得中断后,停在了77646000地址,就是长调用的位置,看一下当前所在地址的汇编指定。
因为这个时候长调用还没有执行,还没进入x64模式,因此汇编指令目前还是被解析成32位指令。
此时,CS段选择子为0x23:
现在单步执行(t)这条jmp far指令,进入x64模式,来到77646009,此时汇编指令发生了变化,变成了x64汇编指令。
此时,CS段选择子也切换到了0x33:
如果继续跟的话,会发现程序最终将走到64位系统模块中,通过64位模块进入内核。
使用64位CE查看32位进程的模块列表,能够发现进程环境中是有64位模块的。
64位程序进内核
描述:64位程序进内核的方式则要简单得多,直接调用syscall指令。
以64位notepad.exe为例,尝试使用x64dbg附加上去。
同样地,尝试在NtOpenProcess函数设置断点。
接着让程序跑起来,尝试用notepad打开一个文件,让程序中断下来。
可以看到,实际上断点设在了ZwOpenProcess函数,进入内核的方式也十分简单,就是直接调用syscall指令。
实验:模式切换
描述:既然程序可以在进入内核前,在ntdll.dll中进行模式切换,说明我们也可以在自己写的代码中进行模式切换。
第一步:编译以下代码
编译后的程序名为SwitchMode.exe
#include <stdio.h>
#include <windows.h>unsigned char jmp_far[11] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x23, 0x00 };void EditCode(LPVOID dest, LPVOID src)
{LPVOID lpAddress;DWORD dwOldProtect;__asm{mov eax, dword ptr [dest]mov dword ptr [lpAddress], eax}VirtualProtect((LPVOID)lpAddress, 4, PAGE_EXECUTE_READWRITE, &dwOldProtect);__asm{mov esi, dword ptr [src]mov edi, dword ptr [dest]mov dword ptr [edi], esi}
}int main()
{unsigned int* secret;/* 到第一个system("pause")为止,都是在动态修复代码偏移量 *///mov cwortd ptr [L4], jmp_far__asm{lea eax, jmp_farpush eaxpush L4call EditCodeadd esp, 8}//mov dword ptr [jmp_far+0], L5__asm{push offset L5lea eax, jmp_farpush eaxcall EditCodeadd esp, 8}//mov dword ptr [L3], secret__asm{lea eax, secretpush eaxpush offset L3call EditCodeadd esp, 8}//mov dword ptr [L1], L2__asm{push offset L2push offset L1call EditCodeadd esp, 8}system("pause"); //暂停一下//切换到x64模式__asm{__emit 0xEA
L1: //填充为L2的地址__emit 0x00__emit 0x00__emit 0x00__emit 0x00__emit 0x33__emit 0x00}L2://mov r12d, 0x12345678__asm{__emit 0x41__emit 0xBC__emit 0x78__emit 0x56__emit 0x34__emit 0x12}//mov dword ptr [secret], r12d__asm{__emit 0x44__emit 0x89__emit 0x24__emit 0x25
L3: //填充为secret的地址__emit 0x00__emit 0x00__emit 0x00__emit 0x00}//切换到32位模式__asm{//mov rax, jmp_far__emit 0x44__emit 0xB8
L4: //填充为数组jmp_far的地址__emit 0x00__emit 0x00__emit 0x00__emit 0x00//jmp far tword ptr ds:[rax]__emit 0x48__emit 0xFF__emit 0x28}L5:printf("%x\n", secret);system("pause");return 0;
}
第二步:运行程序至第一次暂停处
第三步:使用WinDbg附加进程
第四步:在关键位置设置断点
需要在地址4119FA设置断点,这条指令执行后,将切换到x64模式,程序暂停前,会将jmp far的目标地址改成411A01。
第五步:让程序运行至断点位置
目前411A01的指令被解析为32位指令。
第六步:单步调试
切换模式后,411A01的指令被重新解析成64位指令。
可以看到,32位程序一旦切换成x64模式,就可以使用本不应该出现的64位寄存器了。
这里通过r12寄存器向secret中写入数据,如果用普通的调试器,无法跟踪模式切换后的代码,是发现不了的。
设置好secret的值之后,紧接着便将模式切换回32位模式,这里需要使用jmp far tword指令(tword表示十个字节,前八个字节为目标地址,后两个字节指向段描述符偏移)。
切换回32位模式之后,便将secret的值打印出来,但如果使用普通的调试器,是无法发现secret的值是什么时候设置的。
参考资料
- bilibili周壑:x64内核研究系列教程
- 看雪论坛:浅谈32位程序是怎样在windows 64上运行的
- github项目:32位程序注入64位进程