评估后Vista时代系统内核模式安全性

Windows Vista与之前的MS Windows版本(包括WindowsXPSP2)相比增加了很多的安全性。Vista新安全性的特征可以包括以下几个方面：

驱动签名

路径保护

内核模式代码完整性检查

可选择支持使用TPM芯片的安全启动

限制用户模式访问\Device\PhysicalMemory

上述的这些功能使得Vista64位版本与Linux或MacOS相比更具备安全性。该文档的主要贡献在：通过拟向工程较全面的分析内核模式的安全组件以及评估可能存在的内核模式攻击。

该文档检查新的安全特性，通过这些安全特性来阻止恶意代码危及内核。由于这些特性都仅存在于64位的WindowsVista系统内，因此该文档的关注点在Vista64位版本。

该文档没有分析PatchGuard的执行，针对PatchGuard的分析在前期已经有Skape和Skywing[6]进行了较全面的分析，值得注意
的是PatchGuard发展到目前已经有所改变(在skape与skywing分析完后)。仅当下面章节对PatchGuard进行攻击评估时才会讨论
这些问题。针对Vista用户模式的安全性评估在前面已经有所讨论[7]。

由于无法访问WindowsVista的源代码，我们通过debugger(调试器)、disassembler(反编译)、hexeditor(16进
制编辑器，例如UE)学习了WindowsVista Community Technical
PrevIEw(CTP)Build5365版本。如果读者不熟悉X86体系架构和汇编语言的知识，推荐大家一本不错的关于X86汇编语言的在线图书
[8]。另外，在看该文档前你需要熟悉一些Windows系统架构的知识，推荐大家阅读[9]，该书讲解了Windows系统架构的知识，同时这本书的一
些知识同样可以应用到Vista系统上。在该文档公布时Vista系统还在测试阶段，但Vista在后来版本的安全性方面又做了一些改动。我们希望
Vista在最终的发布版本上有更多的改变，同时我们也计划继续对未来的Vista版本的内核改动进行研究。

Vista引导过程

WindowsVista支持从PC/ATBIOS和Intel新的EFI(可扩展固件接口)启动。我们的分析过程忽略了EFI部分。在本章节的最后部
分，引用了bootmgr入口点的开始指令(DllMail为EFI的入口点指令，offset0为PC/AT的入口点指令)这个过程从Vista启动管
理器开始，定位%SystemDrive%\bootmgr文件 (forPC/AT legacy
BIOS)或%SystemDrive%\Boot\EFI\bootmgr.efi (forEFIBIOS)。Vista
BootManager是启动Vista的必须环节，但也适用于启动WindowsVista之前的Windows版本。

Vista
BootManager首先调用InitializeLibrary，然后依次调用BlpArchInitialize(GDT, IDT,etc.),
BlMmInitialize (memory management),BlpFwInitialize(firmware=固件?),
BlpTpmInitialize (TPM),BlpIoInitialize (filesystems), BlpPltInitialize
(PCIconfiguration), BlBdInitialize(debugging),
BlDisplayInitialize,BlpResourceInitialize (finds itsown .rsrc section),
andBlNetInitialize。

在Vista系统内，Windows传统的boot.ini配置文件已经被启动配置数据文件(BCD)所代替，Vista下该文件位
于%SystemDrive%\Boot\BCD，该文件也是注册表的值(在Vista下被挂载在HKEY_LOCAL_MACHINE
\BCD00000000下)。可以使用bcdedit.exe来查看该文件的内容。

一个典型的Boot Manager的BCD配置文件如下：

Windows Boot Manager

Identifier: bootmgr

Type: 10100002

Device: partition=C:

Detion: Windows Boot Manager

Locale: en-US

Inherit options: globalsettings

Boot debugger: No

Pre-boot EMS Enabled: No

Default: current

Resume application: 3ced334e-a0a5-11da-8c2b-cbb6baaeea6d

Display order: current

Timeout: 30

如果只有一个启动入口在BCD文件内，启动管理器会直接从该入口启动。如果多于一个启动入口，BootManager会给用户一个可选择的列表，并提示用
户选择启动那个OS。如果启动阶段激活了日志记录，启动管理器会把状态信息写入%SystemDrive%\Boot\bootstat.dat文件内
(通过BmpInitializeBootStatusDataLog)。紧接着启动管理器会使用BlResourceFindHTML把
bootmgr.xsl定位在资源节点，而后把它传给BlXmiInitialize。bootmgr.xsl文件控制启动菜单和位于启动菜单的选项。

如果启动列表的某个条目被选择，跟随BmpTransferExecution之后，将使用BmpLaunchBootEntry对该条目进行加载。
BmpTransferExecution将重新找回启动选项(通过BlGetBootOptionString)并把他们交给
BlImgLoadBootApplication。如果FVE(FullVolumeEncryption)被激
活，BlFveSecureBootUnlockBootDevice和BlFveSecureBootCheckpointBootApp将被调用。由
于Windows分区被加密，必须在把控制权交给VistaOSLoader前对分区进行解密。

最后，Boot Manager调用BlImgStartBootApplication把控制权交给VistaOSLoader。

Windows Vista操作系统加载

bootmgr调用了位于%SystemRoot%\System32\WINLOAD.EXE下的VistaOSLoader。WINLOAD.EXE
替换了NTLDR(Windows NTOSLoader)，该小节的最后部分，会引用WINLOAD.EXE在开始入口点(OslMain)的指令。

一个典型的Vista OS载入的BCD入口配置文件如下：

Windows Boot Loader

IdentifIEr: current

Type: 10200003

Device: partition=C:

SYMANTEC ADVANCED THREAT RESEARCH 3

Path: \Windows\system32\WINLOAD.EXE

Detion: Microsoft Windows

Locale: en-US

Inherit options: bootloadersettings

Boot debugger: No

Pre-boot EMS Enabled: No

Advanced options: No

Options editor: No

Windows device: partition=C:

Windows root: \Windows

Resume application: 3ced334e-a0a5-11da-8c2b-cbb6baaeea6d

No Execute policy: OptIn

Detect HAL: No

No integrity checks: No

Disable boot display: No

Boot processor only: No

Firmware PCI settings: No

Log initialization: No

OS boot information: No

Kernel debugger: No

HAL breakpoint: No

EMS enabled in OS: No

执行从OslMain开始。它重用了与bootmgr阶段相同的代码，因此InitializeLibrary在bootmgr内的工作原理与在WINLOAD.EXE内的工作原理相似。在InitializeLibrary之后，控制权交给OslMain。

如果启动状态日志记录被激活，WINLOAD.EXE将会把结果写入%SystemDrive%\Boot\bootstat.dat(通过
OslpInitializeBootStatusDataLog和OslpSetBootStatusData)。接下来WINLOAD.EXE调用
OslDisplayInitialize，并使用BlResourceFindHTML定位osloader.xsl所在的资源节点。控制权转交给
BlXmiInitialize。在系统启动过程中osloader.xsl控制着高级启动选项。在操作完高级启动选项(使用
OslDisplayAdvancedOptionsProcess)，WINLOAD.EXE现在就准备开始启动。启动阶段首先会使用
BlDeviceOpen打开启动设备。根据设备类型，BlDeviceOpen会使用不同的设备函数集来打开设备。

全盘加密(_FvebDevicenTable) 如下：

dd 0 ; FVE has no EnumerateDeviceClass callback

dd offset _FvebOpen@8 ; FvebOpen(x,x)

dd offset _FvebClose@4 ; FvebClose(x)

dd offset _FvebRead@16 ; FvebRead(x,x,x,x)

dd offset _FvebWrite@16 ; FvebWrite(x,x,x,x)

dd offset _FvebGetInformation@8 ; FvebGetInformation(x,x)

dd offset _FvebSetInformation@8 ; FvebSetInformation(x,x)

dd offset _FvebReset@4 ; FvebReset(x)

For block I/O (_BlockIoDevicenTable) these are:

dd offset _BlockIoEnumerateDeviceClass@12;BlockIoEnumerateDeviceClass(x,x,x)

dd offset _BlockIoOpen@8 ; BlockIoOpen(x, x)

dd offset _BlockIoClose@4 ; BlockIoClose(x)

dd offset _BlockIoReadUsingCache@16;BlockIoReadUsingCache(x,x,x,x)

dd offset _BlockIoWrite@16 ; BlockIoWrite(x,x,x,x)

dd offset _BlockIoGetInformation@8 ;BlockIoGetInformation(x,x)

dd offset _BlockIoSetInformation@8 ;BlockIoSetInformation(x,x)

dd offset ?handleInputChar@OsxmlMeter@@UAEHG@Z;OsxmlMeter::handleInputChar(ushort)

dd offset _BlockIoCreate@12 ; BlockIoCreate(x,x,x)

For console (_ConsoleDevicenTable) these are:

dd offset _UdpEnumerateDeviceClass@12;UdpEnumerateDeviceClass(x,x,x)

dd offset _ConsoleOpen@8 ; ConsoleOpen(x,x)

dd offset _ConsoleClose@4 ; ConsoleClose(x)

dd offset _ConsoleRead@16 ; ConsoleRead(x,x,x,x)

dd offset _ConsoleWrite@16 ; ConsoleWrite(x,x,x,x)

dd offset _ConsoleGetInformation@8 ;ConsoleGetInformation(x,x)

dd offset _ConsoleSetInformation@8 ;ConsoleSetInformation(x,x)

dd offset _ConsoleReset@4 ; ConsoleReset(x)

For serial port (_SerialPortnTable) these are:

dd offset _UdpEnumerateDeviceClass@12;UdpEnumerateDeviceClass(x,x,x)

dd offset _SpClose@4 ; SpClose(x)

dd offset _SpRead@16 ; SpRead(x,x,x,x)

dd offset _SpWrite@16 ; SpWrite(x,x,x,x)

dd offset _SpGetInformation@8 ; SpGetInformation(x,x)

dd offset _SpSetInformation@8 ; SpSetInformation(x,x)

dd offset _SpReset@4 ; SpReset(x)

For PXE (_UdpnTable):

dd offset _UdpEnumerateDeviceClass@12;UdpEnumerateDeviceClass(x,x,x)

dd offset _UdpOpen@8 ; UdpOpen(x,x)

dd offset _SpClose@4 ; SpClose(x)

dd offset _UdpRead@16 ; UdpRead(x,x,x,x)

dd offset _UdpWrite@16 ; UdpWrite(x,x,x,x)

dd offset _UdpGetInformation@8 ; UdpGetInformation(x,x)

dd offset _UdpSetInformation@8 ; UdpSetInformation(x,x)

dd offset _UdpReset@4 ; UdpReset(x)

你可能注意到有些函数的返回在不同类别之间会存在共享(例如：serial port和PXE)。

接着LOADER_METER_BLOCK结构通过OslInitializeLoaderBlock进行初始化，LOADER_METER_BLOCK
包含了一些系统状态信息，如：启动设备、ACPI、SMBIOS表等。下面为LOADER_METER_BLOCK在Vista64位版本的结构：

+0x000 LoadOrderListHead : struct _LIST_ENTRY

+0x010 MemoryDetorListHead : struct _LIST_ENTRY

+0x020 BootDriverListHead : struct _LIST_ENTRY

+0x030 KernelStack : Uint8B

+0x038 Prcb : Uint8B

+0x040 Process : Uint8B

+0x048 Thread : Uint8B

+0x050 RegistryLength : Uint4B

+0x058 RegistryBase : Ptr64 to Void

+0x060 ConfigurationRoot : Ptr64 tostruct_CONFIGURATION_COMPONENT_DATA

+0x068 ArcBootDeviceName : Ptr64 to Char

+0x070 ArcHalDeviceName : Ptr64 to Char

+0x078 NtBootPathName : Ptr64 to Char

+0x080 NtHalPathName : Ptr64 to Char

+0x088 LoadOptions : Ptr64 to Char

+0x090 NlsData : Ptr64 to struct _NLS_DATA_BLOCK

+0x098 ArcDiskInformation : Ptr64 tostruct_ARC_DISK_INFORMATION

+0x0a0 OemFontFile : Ptr64 to Void

+0x0a8 SetupLoaderBlock : Ptr64 to struct_SETUP_LOADER_BLOCK

+0x0b0 Extension : Ptr64 to struct _LOADER_METER_EXTENSION

+0x000 Size : Uint4B

+0x004 Profile : struct _PROFILE_METER_BLOCK

+0x014 MajorVersion : Uint4B

+0x018 MinorVersion : Uint4B

+0x020 EmInfFileImage : Ptr64 to Void

+0x028 EmInfFileSize : Uint4B

+0x030 TriageDumpBlock : Ptr64 to Void

+0x038 LoaderPagesSpanned : Uint4B

+0x040 HeadlessLoaderBlock : Ptr64 tostruct_HEADLESS_LOADER_BLOCK

+0x048 SMBiosEPSHeader : Ptr64 to struct_SMBIOS_TABLE_HEADER

+0x050 DrvDBImage : Ptr64 to Void

+0x058 DrvDBSize : Uint4B

+0x060 NetworkLoaderBlock : Ptr64 to struct_NETWORK_LOADER_BLOCKbytes

+0x068 FirmwareDetorListHead : struct _LIST_ENTRY

+0x078 AcpiTable : Ptr64 to Void

+0x080 AcpiTableSize : Uint4B

+0x084 BootViaWinload : Bitfield Pos 0, 1 Bit

+0x084 BootViaEFI : Bitfield Pos 1, 1 Bit

+0x084 Reserved : Bitfield Pos 2, 30 Bits

+0x088 LoaderPerformanceData : Ptr64 tostruct_LOADER_PERFORMANCE_DATA

+0x090 BootApplicationPersistentData : struct _LIST_ENTRY

+0x0a0 WmdTestResult : Ptr64 to Void

+0x0a8 BootIdentifier : struct _GUID

+0x0b8 u : union

+0x000 I386 : struct _I386_LOADER_BLOCK

+0x000 CommonDataArea : Ptr64 to Void

+0x008 MachineType : Uint4B

+0x00c VirtualBias : Uint4B

下面会寻找系统磁盘(通过OslEnumerateDisks)和加载系统注册表项HKEY_LOCAL_MACHINE(通过
OslpLoadSystemHive)。当系统注册表项加载后，我们遇到了Vista在启动阶段的第一次代码完整性(通过
OslInitializeCodeIntegrity)。在该处首先会调用MincrypL_SelfTest，MincrypL_SelfTest验
证SHA1散列值，并使PKCS1的签名验证开始工作(usingapre-definedtestcase=通过预定义的测试样例?)。如果预先定义的
测试样例失败了，会返回错误代码到0xC0000428。然后，检查调试器是否开启(通过BlBdDebuggerEnabled)。如果在这里检测到调
试器在开启状态，会调用KnownAnswerTest。如果没有检测到调试器处在开启状态，会直接跳过该处。

接下来通过BlImgRegisterCodeIntegrityCatalogs从%SystemRoot%\System32\CatRoot
\F750E6C3-38EE-11D1-85E5-00C04FC295EE\nt5.cat加载OS的编目录(在内部调用了API函数
MinCrypL_AddCatalog)。

当OS编目录nt5.cat被加载后，WINLOAD.EXE通过SelfIntegrityCheck对其自身进行完整性检查，这里的检查做了两个事情：

1.计算PE映像(image)的SHA1哈希值，然后与PE证书表内的SHA1哈希值进行对比，这里的对比必须是匹配的，如果不匹配就会返回一个错误信息。

2.另外，他也调用ImgpValidateImageHash来验证映象(image)哈希值是否与nt5.cat内的相匹配。
ImgpValidateImageHash会调用API函数MinCrypL_CheckSignedFile来验证证书，调用
MinCrypL_CheckImageHash来寻找nt5.cat上的映象(image)匹配哈希值。在下面的章节III会讨论通过
MinCrypL_CheckSignedFile和MinCrypL_CheckImageHash进行驱动签名验证。

如果上述的签名过程不匹配，但是调试器在开启状态(BlBdDebuggerEnabledreturnsTRUE)，那么在这里会打印处如下的调试信息：

*** Windows is unable to verify the signature of the file%s.

It will be allowed to load because the boot debuggerisenabled.

Use g to continue!!

如果调试器是存在的，那么可以通过调用DbgBreakPoint来进行激活;另外，在这里通过调用ReportCodeIntegrityFailure替换了系统提示致命错误的错误形式。

当所有的完整性检查结束后(unless all integrity checks
havebeendisabled)，OslInitializeCodeIntegrity会返回成功状态，然后会继续从OslMain开始执行。接
着，OslpLoadAllModules被调用并开始加载系统模块。首先，会调用OslLoadImage来加载NTOSKRNL.EXE和
HAL.DLL，在这里仅仅是加载，此时没有解决Imports;第二，如果内核调试被开启，调试驱动会依靠启动调试选项的情况被加载
(kdcom.dllforserial port, kd1394.dll for IEEE1394, or
kdusb.dllforUSB)。第三，NTOSKRNL.EXE的Imports被加载和初始化(使用LoadImports和
BindImportRefences函数)。

OslLoadImage calls
GetImageValidationFlags to check thefilenameagainst a pre-defined list
of boot drivers inLoadBootImagesTable.If integrity checks are enabled,
then bootdrivers must be signed bya trusted root authority and all
theimage hashes must match thesigned catalog file unless a debuggeris
enabled. If a debugger isenabled, WINLOAD.EXE does not enforcethis
requirement. Instead itwill print an error message to thedebugger, but
will otherwiseignore the code integrity checkfailure. However, the
following bootdrivers (also listed inAppendix A) must pass the code
integritychecks even if a debuggeris enabled (otherwise WINLOAD.EXE
willrefuse to boot WindowsVista):

OslLoadImage调用GetImageValidationFlags来检查在LoadBootImagesTable中预先定义好的
bootdrivers文件名。如果启用了完整性检查，除非在这里调试器被开启，否则bootdrivers必须进行可信任的root签名，并且所有的映
象哈希值(imagehashes)要与编目录签名相匹配。如果调试器处于开启状态，WINLOAD.EXE不会强制这些要求。安全后
WINLOAD.EXE会打印一个错误信息给调试器，但是却忽略了代码完整性检查的失败。无论如何，接下来的bootdrivers必须通过代码完整性检
查，即使调试器在开启状态也必须检查。(如果没有进行检查，vista不会被启动起来)：

\Windows\system32\bootvid.dll

\Windows\system32\ci.dll

\Windows\system32\clfs.sys

\Windows\system32\hal.dll

\Windows\system32\kdcom.dll (or kd1394.sys or kdusb.dll,dependingon boot options)

\Windows\system32\ntoskrnl.exe

\Windows\system32\pshed.dll

\Windows\system32\WINLOAD.EXE

\Windows\system32\drivers\ksecdd.sys

\Windows\system32\drivers\spldr.sys

\Windows\system32\drivers\tpm.sys

加载映象和验证代码完整性都在BlImgLoadPEImageEx内，都使用了SelfIntegrityCheck(在前面章节有描述)函数。所有的
映象(image)都通过代码完整性校验后，NTOSKRNL.EXE和它所有的Imports此时会被加载。列表(版本:Build5363)如下：

\Windows\system32\NTOSKRNL.exe

\Windows\system32\HAL.dll

\Windows\system32\PSHED.dll

\Windows\system32\BOOTVID.dll

\Windows\system32\CLFS.SYS

\Windows\system32\CI.dll

接下来使用OslHiveFindDrivers查找所有的boot drivers，并且根据组(which
isorderedaccordingtoHKEY_LOCAL_MacHINE\CurrentControlSet\Control
\GroupOrderList)和标记(anintegerwhich determines each driver"s order within

itsrespectivegroup)对他们进行分类。这个分类好的bootdrivers列表通过OslLoadDrivers进行加载。
OslLoadDrivers为列表中的每个驱动调用LoadImageEx。LoadImageEx将会加载每个驱动及相关信息。

此时，剩余的boot drivers也被加载和初始化。列表如下(按照年月日排列,64位Vista)：

1. \Windows\system32\drivers\Wdf01000.sys

2. \Windows\system32\drivers\WDFLDR.SYS

3. \Windows\system32\drivers\acpi.sys

4. \Windows\system32\drivers\WMILIB.SYS

5. \Windows\system32\drivers\msisadrv.sys

6. \Windows\system32\drivers\pci.sys

7. \Windows\system32\drivers\volmgr.sys

8. \Windows\system32\drivers\isapnp.sys

9. \Windows\system32\drivers\mpio.sys

10. \Windows\system32\drivers\compbatt.sys

11. \Windows\system32\drivers\BATTC.SYS

12. \Windows\System32\drivers\mountmgr.sys

13. \Windows\system32\drivers\intelide.sys

14. \Windows\system32\drivers\PCIIDEX.SYS

15. \Windows\system32\drivers\pcmcia.sys

16. \Windows\system32\drivers\aliide.sys

17. \Windows\system32\drivers\amdide.sys

18. \Windows\system32\drivers\cmdide.sys

19. \Windows\system32\drivers\msdsm.sys

20. \Windows\system32\drivers\pciide.sys

21. \Windows\system32\drivers\viaide.sys

22. \Windows\System32\drivers\volmgrx.sys

23. \Windows\system32\drivers\atapi.sys

24. \Windows\system32\drivers\ataport.SYS

25. \Windows\system32\drivers\hpcisss.sys

26. \Windows\system32\drivers\storport.sys

27. \Windows\system32\drivers\adp94xx.sys

28. \Windows\system32\drivers\adpu160m.sys

29. \Windows\system32\drivers\SCSIPORT.SYS

30. \Windows\system32\drivers\adpu320.sys

31. \Windows\system32\drivers\djsvs.sys

32. \Windows\system32\drivers\arc.sys

33. \Windows\system32\drivers\arcsas.sys

34. \Windows\system32\drivers\elxstor.sys

35. \Windows\system32\drivers\i2omp.sys

36. \Windows\system32\drivers\iirsp.sys

37. \Windows\system32\drivers\iteraid.sys

38. \Windows\system32\drivers\lsi_fc.sys

39. \Windows\system32\drivers\lsi_sas.sys

40. \Windows\system32\drivers\lsi_scsi.sys

41. \Windows\system32\drivers\megasas.sys

42. \Windows\system32\drivers\mraid35x.sys

43. \Windows\system32\drivers\msahci.sys

44. \Windows\system32\drivers\nfrd960.sys

45. \Windows\system32\drivers\ql2300.sys

46. \Windows\system32\drivers\ql40xx.sys

47. \Windows\system32\drivers\sisraid2.sys

48. \Windows\system32\drivers\sisraid4.sys

49. \Windows\system32\drivers\symc8xx.sys

50. \Windows\system32\drivers\sym_hi.sys

51. \Windows\system32\drivers\sym_u3.sys

52. \Windows\system32\drivers\vsmraid.sys

53. \Windows\system32\drivers\fltmgr.sys

54. \Windows\system32\drivers\fileinfo.sys

55. \Windows\system32\drivers\ndis.sys

56. \Windows\system32\drivers\msrpc.sys

57. \Windows\system32\drivers\NETIO.SYS

58. \Windows\System32\Drivers\Ntfs.sys

此时，所有的bootdrivers被加载。接下来，调用OslpLoadNlsData从注册表项
HKEY_LOCAL_MACHINE\CurrentControlSet\Control\NLS加载操作系统的语言版本。最后调用
OslpLoadAllModules做了下面的几个事情：

1. 显示Vista启动过程中的进度条。

2. 加载%SystemRoot%\AppPatch\drvmain.sdb(theapplicationcompatability database)

3. 加载%SystemRoot%\System32\acpitabl.dat

4.加载HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Errata\InfName注册表项的INF文件。

在OslpLoadAllModules结束后，OslMain保存启动日志(OslpLogSaveInformation)，如果
FVE(FullVolumeEncryption)选项开启，结束FVE的加载
(BlFveSecureBootRestrictToOneandBlTpmShutdown)。最后，调用
OslArchTransferToKernel把控制权转交给NTOSKRNL.EXE。

Vista Windows系统内核

Vista使用了与先前版本一样的惯例。64位Vista会在%SystemRoot%\System32\ntoskrnl.exe查找
NTOSKRNL.EXE，在本章节的剩余部分，会引用ntoskrnl.exe在开始入口点的操作指令(KiSystemStartup)。

执行首先从KiSystemStartup开始。Vista下的NTOSKRNL.EXE内的一些重要部分与Windows2003SP1版相比，并没有
太多的改变，因此我们的重点为分析Vista下改变的特殊部分。在Vista下，NTOSKRNL.EXE添加了一个新函数
SepInitializeCodeIntegrity，但该函数仅仅是把CL.DLL内的CiInitialize(关于CiInitialize会在
后面的章节VI进行讨论)进行了另外的包装而已。如果代码完整性检查开启，SepInitializeCodeIntegrity会调用
CiInitialize，除此之外，它没有做任何其它的事情。

WINLOAD.EXE还负责检查bootdrivers签名的完整性。与WINLOAD.EXE相比，NTOSKRNL.EXE负责查证
systemdrivers(在bootdriver加载后)和运行时加载的drivers(即：当一个设备被插进系统)。当完整性检查开启，会使用
SeValidateImageHeader(在CI.DLL内CiValidateImageHeader函数的包装)和SeValidateImageData(在CI.DLL内
CiValidateImageData函数的包装)对加载的映象(image)进行代码完整性检查。只要一个执行映射进kernelmemeory都会
调用SeValidateImageHeader(通过MmCreateSection)。当一个内核模块加载时，都会调用
SeValidateImageData对kerneldrivers的代码段进行校验。运行时检查(例如：不断的检查kerneldrivers的代码
段是否被修改)由PatchGuard和CI.DLL进行处理。