Win10安全特性之執(zhí)行流保護(hù)

以win10 preview 9926中IE11的Spartan html解析模塊為例，看一下CFG的具體情況：

這里就是被編譯器插入的CFG校驗(yàn)函數(shù)

但是靜態(tài)情況下默認(rèn)的檢測函數(shù)是一個(gè)直接return的空函數(shù)，是微軟在和我們開玩笑嗎？

通過動(dòng)態(tài)調(diào)試看一下

從上圖我們可以看出，實(shí)際運(yùn)行時(shí)的地址和我們通過IDA靜態(tài)看到的地址是不一樣的，這里就涉及到CFG和操作系統(tǒng)相關(guān)的那部分。支持CFG版本的操作系統(tǒng)加載器在加載支持CFG的模塊時(shí)，會把這個(gè)地址替換成ntdll中的一個(gè)函數(shù)地址。不支持CFG版本的操作系統(tǒng)不用理會這個(gè)檢測，程序執(zhí)行時(shí)直接retn。

這是ntdll中的檢測函數(shù)

原理是在進(jìn)入檢測函數(shù)之前，把即將call的寄存器值（或者是帶偏移的寄存器間接尋址）賦值給ecx，在檢測函數(shù)中通過編譯期間記錄的數(shù)據(jù)，來校驗(yàn)這個(gè)值是否有效。

檢測過程如下:

首先從LdrSystemDllInitBlock+0x60處讀取一個(gè)位圖(bitmap)，這個(gè)位圖表明了哪些函數(shù)地址是有效的，通過間接調(diào)用的函數(shù)地址的高3個(gè)字節(jié)作為一個(gè)索引，獲取該函數(shù)地址所在的位圖的一個(gè)DWORD值，一共32位，證明1位代表了8個(gè)字節(jié)，但一般來說間接調(diào)用的函數(shù)地址都是0x10對齊的，因此一般奇數(shù)位是不使用的。

通過函數(shù)地址的高3個(gè)字節(jié)作為索引拿到了一個(gè)所在的位圖的DWORD值，然后檢查低1字節(jié)的0-3位是否為0，如果為0，證明函數(shù)是0x10對齊的，則用3-7bit共5個(gè)bit就作為這個(gè)DWORD值的索引，這樣通過一個(gè)函數(shù)地址就能找到位圖中所對應(yīng)的位了。如果置位了，表明函數(shù)地址有效，反之則會觸發(fā)異常。

這里有個(gè)有趣的東西，雖然使用test cl,0Fh檢測是否0x10對齊，如果對齊的話實(shí)際上用3-7位作為索引，也就是說第3位一定是0。但如果函數(shù)地址不是0x10對齊的話，則會對3-7位 or 1，然后再作為索引。這樣就有一個(gè)弊端，如果一個(gè)有效的間接調(diào)用的函數(shù)地址是8字節(jié)對齊的，那么其實(shí)是允許一個(gè)8字節(jié)的一個(gè)錯(cuò)位調(diào)用的，這樣可能導(dǎo)致的結(jié)果就是可能造成雖然通過了校驗(yàn)，但是實(shí)際調(diào)用的地址并不是原始記錄的函數(shù)地址。