在VISTA以后操作系统系统使用MmLoadImage加载驱动的前会MmCheckImage来检查镜像正确性在VISTA及以后操作系统中MmCheckImage发生了个有意思变化.

　　原本MmCheckImage(vista以前系统上)会使用SEC_IMAGE作为AllocationAttributes来ZwCreateSection为驱动文件创建Section但是VISTA以后系统上该参数被换成了个未公开值: 0x100000(注意,SEC_IMAGE是0x10000006个0)

　　在ZwCreateSection 中系统会检查如果线程上个模式不是KernelMode,则不允许使用这个未公开AllocationAttributes:

　　NtCreateSection:

　　 ............无关部分........

　　 　　//取当前线程上个模式

　　 　　 (KeGetPreviousMode != KernelMode)

　　 　　{

　　 　　//如果是用户模式如果Attributes有0x2000000或0x10000话则返回无效参数

　　 　　v13 = 0;

　　 　　 ( !(Attributes & 0x2100000) )

　　 　　{

　　 　　.....无关处理....

　　 　　}

　　 　　 STATUS_INVALID_PARAMETER_6;

　　 　　}

　　然后在NtCreateSection->MmCreateSection(这个在VISTA开始发生了巨大变化)中进行些判断后(包括这个特殊Attributes)系统会MiValidateImageHeader进行镜像检查此时系统会将这个镜像通过MiMapImageInCachemap到系统缓存Cache中然后将按镜像页数 * PAGE_SIZE大小分配分页内存并将PE数据COPY到内存中

　　接着系统会SeValidateImageHeader这个只是简单地为_g_CiCallbacks中存放准备便_g_CiCallbacks存放_g_CiCallbacks这个全局变量中存放着系统化时(SeInit->SepInitializationPhase1->SepInitializeCodeIntegrity)存入 ci.dllCiValidateImageHeader

　　CiValidateImageHeader首先会对镜像进行些检查工作然后开始CipValidateFileHashCipValidateFileHash对文件做些解析工作后开始CipImageGetImageHash此会分析PE每个节并对其节内数据SHA签名算法A_SHAUpdate

　　注意前面加粗文字由于是按整页数来分配和COPY数据因此如果某个节数据长度(SizeOfRawData)超出了页对齐范围(MiMapImageInCache似乎并不将这个数据算成个新节)那么A_SHAUpdate中数据COPY将触及到未分配内存从而引发BSOD

　　这里提供个简单例子(下载到:http://www.debugman.com/read.php?tid=3217帖子中附件或http://mj0011.ys168.com 漏洞演示目录下bsodxx.rar)

　　这个PE文件最后个节SizeOfRawData是0x1004使用任意个加载工具加载此文件系统将立即BSODBSOD时Stack类似:

　　 kd> kc

　　 　　nt!MmAccessFault

　　 　　nt!KiTrap0E

　　 　　nt!memcpy

　　 　　CI!A_SHAUpdate

　　 　　CI!CipImageGetImageHash

　　 　　CI!CipValidateFileHash

　　 　　CI!CiValidateImageHeader

　　 　　nt!SeValidateImageHeader

　　 　　nt!MiValidateImageHeader

　　 　　nt!MmCreateSection

　　 　　nt!NtCreateSection

　　 　　nt!KiFastCallEntry

　　 　　nt!ZwCreateSection

　　 　　nt!MmCheckImage

　　 　　nt!MiCreateSectionForDriver

　　 　　nt!MiObtainSectionForDriver

　　 　　nt!MmLoadImage

　　 　　nt!IopLoadDriver

　　 　　nt!IopLoadUnloadDriver

　　因此说解析PE很危险啊很危险