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

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

　　NtCreateSection:

              ............无关部分........
        　　//取当前线程上个模式
        　　if (KeGetPreviousMode() != KernelMode)
        　　{
        　　//如果是用户模式，如果Attributes有0x2000000或0x10000的话，则返回无效参数
        　　v13 = 0;
        　　if ( !(Attributes & 0x2100000) )
        　　{
        　　.....无关处理....
        　　}
        　　return STATUS_INVALID_PARAMETER_6;
        　　}

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

　　接着系统会调用SeValidateImageHeader函数，这个函数只是简单地为_g_CiCallbacks中存放的函数准备函数，便调用_g_CiCallbacks存放的函数。_g_CiCallbacks这个全局变量中存放着系统初始化时(SeInitSystem->SepInitializationPhase1->SepInitializeCodeIntegrity)存入的 ci.dll的CiValidateImageHeader函数。

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

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

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

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

        kd> kc
        　　nt!MmAccessFault
        　9 7 3 1 2 4 8 :

本文来源：blog 作者：佚名