还有一点，如果这时候漏洞触发成功，间接调用的寄存器值已经被攻击者修改了，这时候从bitmap中取值的时候可能造成内存访问无效。请看LdrpValidateUserCallTargetBitMapCheck符
号处的这条指令：mov edx,dword ptr [edx+eax*4] edx是bitmap地址,eax是索引，但如果eax不可信了，这个很有可能，则会导致内存访问异常，并且这个函数并没有异常处理。这是因为微软为了效率考虑（毕竟这个校验函数的调用十分频繁，一个开启CFG的模块可能会有上万个调用处），微软在ntdll! RtlDispatchException中对该地址发生的异常做了一个处理:
如果异常发生的地址命中LdrpValidateUserCallTargetBitMapCheck，则进行一个单独处理，RtlpHandleInvalidUserCallTarget会校验当前进程的DEP状态和要间接调用的地址(ecx)的内存属性，如果当前进程关闭了DEP并且要间接调用的地址有可执行属性，则触发CFG异常，否则通过修改pContext把EIP修正到ret返回处，并且表明异常已被处理。
最后再说下这个原始的bitmap，在系统初始化的时候，内存管理器初始化中会创建一个Section(MiCfgBitMapSection32)，这个Section在Win8.1上的大小是通过MmSystemRangeStart(32位下是0x80000000)计算的，前面提到过bitmap里面1位代表8字节，计算完后正好是32MB
而在Win10上MiCfgBitMapSection32的大小有了变化，直接写死成了0x3000000(48MB)
Section创建完成后在每个进程启动的时候会映射进去
(NtCreateUserProcess-> PspAllocateProcess-> MmInitializeProcessAddressSpace-> MiMapProcessExecutable-> MiCfgInitializeProcess)
映射的时候作为shared view，除非某一个进程修改了这片内存。
在一个CFG模块映射进来的时候，重定位过程中会重新解析PE文件LOADCONFIG中的Guard Function Table以重新计算该模块对应的bitmap（MiParseImageCfgBits），最后更新到MiCfgBitMapSection32中去（MiUpdateCfgSystemWideBitmap）。
