Windows漏洞利用技術總結

標籤：c   style   class   blog   code   java   

Windows漏洞利用技術總結

1. 前言

　　本文是我對漏洞利用技術的學習總結，也是自己踐行QAD (Questions、Answer、Discussions)的一次實踐。本文通過閱讀幾位大牛的文章、演講報告、exploit編寫教程等技術文檔不斷總結修改而成，列舉了當前Windows下常見攻擊緩解技術的基本原理及繞過方法，具體技術細節則不詳細描述，大家可以通過參考文獻或其他文章進一步學習。由於本人能力有限，文中可能還存在不少錯誤，我會不斷回顧並完善。

 

2. Windows攻擊緩解技術簡介

　　自從Windows 成為主流作業系統以後，針對Windows平台的漏洞利用技術不斷髮展，而微軟也不斷運用新的攻擊緩解技術來封堵漏洞利用技術。根據被引入Windows的時間順序，先後引入的攻擊緩解技術有：GS（Control Stack Checking Calls）、SafeSEH（Safe Structured Exception Handler）、Heap Protection、DEP（Data Execution Prevention）、ASLR（Address Space Layout Randomization）等。

　　下面用一個例子對這幾種保護機制及其繞過方法做進一步說明

int main(int argc, char **argv){    Char buf[64];    __try    {        memcpy(buf, argv[1], atol(argv[2]));    }    __except(EXCEPTION_CONTINUE_SEARCH)    {    }    return 0;}

　　這個例子的漏洞顯而易見，下面讓我們在開啟不同保護機制的情況下解釋如何利用這個例子的堆疊溢位漏洞。

 

•  無攻擊緩解措施

　　如果在編譯連結時不開啟任何保護機制，我們只需要溢出buf，改寫返回地址，使其指向可預測的shellcode地址。這裡我使用jmp esp指令（記憶體中任何一條jmp esp指令，在當前進程自己的dll中尋找最佳）的地址覆蓋main函數的返回地址，並用shellcode進一步覆蓋隨後的堆棧空間。

　　當main函數返回時，會從棧中彈出返回地址（此時已經是jmp esp的地址）並跳轉至其處繼續執行。當jmp esp指令被執行後，eip指向了當前堆棧，此時程式執行流程被轉到了已經溢出的堆棧中，shellcode便得到了執行。

 

•  GS

　　GS（Control Stack Checking Calls）是一種針對堆疊溢位的攻擊緩解技術，它主要通過Stack Cookies和Variable Reordering兩種技術對堆棧進行保護。

　　Stack Cookies是由編譯器提供的一種運行時堆疊溢位檢測技術，開啟/GS選項的編譯器通過在函數頭部與尾部增加代碼塊的方式來檢測堆疊溢位。當函數執行時，這段代碼會在堆棧本地變數與函數返回地址之間儲存一個隨機值（即stack cookies）。函數返回時會檢查堆棧中存放的隨機值是否被修改，如果被修改則意味著發生了堆疊溢位，從而終止程式運行，阻止惡意代碼執行。

　　Variable reordering是一種在編譯階段通過重新排列變數順序來最大限度降低堆疊溢位破壞的技術。它重新排列本地變數，將string buffer類型的變數放置在比其他類型變數更高的堆棧地址空間上，防止攻擊者通過溢出string buffer改寫其他本地變數，在stack cookies被檢測前擷取控制權。同時，Variable reordering還將函數參數中的指標、string buffer複製到本地變數上方額外分配的堆棧地址空間上，函數內部不再使用原先位於返回地址後方的參數。

　　下面的是被GS保護的函數堆棧布局

 

 Figure 2?1

 

　　針對開啟GS保護的程式，可以通過溢出buf，改寫堆棧上的SHE record，因為GS並沒有對堆棧上的SHE record進行保護。同時攻擊者在stack cookie被檢查前觸發一個異常，即可通過改寫的SHE record擷取控制權。

　　這裡，我們確保修改後的SHE record --> Handler為指向pop pop ret指令串的地址（注意，需要確保此指令串位於沒有SafeSEH保護的模組中，否則異常分發函數將對其進行驗證），而將SHE record --> nextSEH改寫成jumpcode（short jmp X）。

　　當函數發生異常（可以通過buf溢出大量的資料，使得strcpy訪問到堆棧的底端）從而索引SEH異常處理函數時，將執行pop pop ret，這串指令從堆棧中彈出nextSEH的地址（此時nextSEH處為跳轉指令jumpcode）給EIP，執行jumpcode後將跳轉到shellcode，使其擷取執行許可權。

 

Figure 2?2

 

•  GS & SafeSEH

　　SafeSEH（Safe Structured Exception Handler）是一種針對SHE異常處理的攻擊緩解技術，用於阻止攻擊者通過改寫堆棧上的Exception Handler Record來擷取控制權。它包括針對SEH異常處理函數的驗證（SHE Handler validation）和針對SEH鏈完整性的驗證（SEH chain validation）兩部分。

　　SHE Handler validation：使用(/SAFESEH)連結選項產生的可執行檔，會在頭部包含一個記錄所有有效異常處理函數的SafeSEH table，當異常發生時ntdll.dll中的異常分發處理函數會驗證堆棧上的Exception Handler Record指向SafeSEH table中一個有效異常處理函數。如果異常分發處理函數檢測出Exception Handler Record被攻擊者改寫並指向了其它地方，則會終止程式的運行。

　　SEH chain validation是針對SEH鏈完整性的驗證保護技術，通常這種技術被稱為SEHOP（Structured Exception Handler Overwrite Protection），它是在Windows Server 2008被引入的一項保護機制。如果系統開啟了SEHOP保護機制，會將ntdll.dll中的FinalExceptionHandler作為最後一個異常處理函數設定到每個SHE鏈的尾部。當異常發生時，異常分發處理函數會遍曆整個異常處理鏈，確保最後一個Exception Handler Record的nextSEH指標為0xFFFFFFFF，Handler始終指向FinalExceptionHandler，否則將終止程式的運行。

　　針對開啟SafeSEH保護的程式，可以在改寫Exception Handler Record時，進一步偽造整個SEH鏈，從而繞過檢測。具體細節不在這裡闡述，請參考其他技術文檔。

 

•   GS & DEP

　　DEP（Data Execution Prevention）試圖從根本上阻止shellcode的執行。在開啟DEP的系統中，代碼只能在被標記為execution的頁面上執行，因此可以阻止攻擊者執行位於堆棧、堆或者資料區段中的shellcode。當EIP指向non-execution屬性的頁面時，系統將直接終止程式執行。可以通過連結選項(/NXCOMPAT)使產生的可執行檔開啟DEP保護。

　　目前，常見的繞過DEP的技術主要分兩類，第一類是借用第三方應用程式及組件，利用這些程式可以申請同時支援readable、writeable、executable屬性記憶體頁的特點，結合Heap Spray技術實現shellcode的布局與執行。JIT Spray就屬於這類技術；第二類是採用代碼重用的方法實現對DEP的繞過，包括利用系統API改寫記憶體頁屬性、調用執行系統命令或載入可執行檔（EXE、DLL等）引入外部代碼、改寫安全配置（IE瀏覽器的SafeMode標誌位等）。其中利用系統API改寫記憶體頁屬性是最為常見的利用方法。

　　針對這個例子，我們利用漏洞改寫Exception Handler Record，此時修改SHE record --> Handler指向pop/pop/pop esp ret指令串的地址。並用可以改寫頁面屬性的系統API地址（VirtualProtect、ZwProtectVirtualMemory等）來改寫nextSEH。當發生異常時，pop/pop/pop esp ret將被執行，其中pop esp將改變堆棧指標，使esp其指向nextSEH。因此ret指令執行後，將跳轉到用於改寫頁面屬性的系統API處。通過系統API將頁面改寫為execution屬性，最後跳轉到shellcode處繼續執行。

 

•  GS & DEP & SafeSEH

　　針對同時開啟GS、DEP、SafeSEH的應用程式，實現漏洞利用的原理與上面類似，不同的是還需要偽造SEH鏈，這裡不再詳細敘述。

 

• GS & DEP & SafeSEH & ASLR

　　ASLR（Address Space Layout Randomization）是從Vista和Windows Server 2008起引入的一項重要的攻擊緩解技術。系統在載入支援ASLR技術的可執行程式、動態連結程式庫等映像檔案時，會對其載入位置進行隨機化處理，使得重啟後每次載入進記憶體的基址不同。因此利用程式編寫者就無法找到穩定可靠的jmp esp、pop pop ret、xchg eax,esp等指令地址，更無法定位系統API的位置，特別是在DEP、ASLR同時開啟的情況下，會大大增加漏洞利用的難度。

　　ASLR會對載入的PE檔案、堆、堆棧、PEB、TEB等的位置進行隨機化處理。可以通過連結選項(/DYNAMICBASE)使產生的可執行檔開啟ASLR保護。

　　面對ASLR和DEP，許多攻擊者需要解決兩個關鍵問題，首先是如何通過漏洞擷取到模組（目標進程、系統或其他DLL）基址，由此才有可能利用系統API進行代碼重用；其次是定位攻擊者布局在堆棧、堆上的shellcode地址（通常由stack pivot、ROP chain、payload等組成）。

　　目前，常見的擷取模組基址的方法有兩種，第一種是查看系統或應用程式運行時是否載入了non-ASLR的模組，是否有其他外部的non-ASLR模組可以被引入當前進程空間，比如Java 6運行環境JRE1.6的msvcr71.dll、Office 2010/2007的hxds.dll（當在URL中使用ms-help://時引入）等。這些non-ASLR模組每次載入到進程記憶體空間時的基址都是固定不變的，因此可以在他們匯入表中索引系統DLL的基址，在其代碼空間中搜尋可執行指令小配件（gadget）等；第二種是通過記憶體資訊泄露漏洞擷取有關記憶體布局、目標進程相關的狀態資訊等。例如可以通過靜態變數的指標、虛函數表指標等暴露出目標進程、系統或其他DLL的基址，從而進一步擷取相關API地址及有用的gadget等。（後文會對bypass ASLR的相關技術進一步討論）

　　為了定位攻擊者布局在堆棧、堆上的shellcode地址，最常見的方法是Heap spray技術，通過連續大量的記憶體申請，將shellcode布局在指定的記憶體位址上。這種方法存在穩定性不高、消耗時間和資源多、容易被檢測的缺點；因此，最好的方法還是使用漏洞讀取出shellcode地址，其限制條件為漏洞類型，需要一個具有任意地址讀寫的漏洞來配合利用。

　　針對這個例子的漏洞情境，攻擊者的可控程度較低，無法在GS & DEP & SafeSEH & ASLR攻擊緩解技術都開啟的情況下實現利用。但是，當類似這樣的一個漏洞情境發生在瀏覽器、Adobe Flash、Adobe Reader、Office等應用軟體中時，結合資訊泄露類漏洞，攻擊者則會實現完美利用。因為攻擊者可以使用JavaScript、ActionScript、VBScript等指令碼語言進行記憶體操作（記憶體申請與釋放、建立特殊對象等）從而使得利用變得可行。

 

　　由上面的簡介我們知道，即便Windows已經逐步引入了新的攻擊緩解技術來阻止惡意代碼運行，但這些攻擊緩解技術只是提高了編寫漏洞利用程式的難度，並不能完全阻止惡意代碼的運行。通過研究，仍然可以通過已知或未知的方法對其進行利用。

　　當前，IE瀏覽器、Adobe Flash、Adobe Reader、Microsoft Office等是人們日常辦公、娛樂生活中經常使用的應用軟體。因此，惡意代碼編寫者常常針對它們，利用挖掘到的漏洞進行攻擊，使得惡意代碼傳播面廣、影響範圍大。業內安全廠商、研究人員也都集中精力針對這些軟體的漏洞挖掘、利用技術進行分析與研究，下面主要針對IE瀏覽器，具體講解ASLR & DEP繞過技術的原理。

 

3. 繞過ASLR

　　FireEye在其部落格上曾發表一篇文章——《ASLR Bypass Apocalypse in Recent Zero-Day Exploits》，通過舉例說明了最近0day漏洞利用中所使用的三類繞過ASLR的技術：Using non-ASLR modules、Modifying the BSTR length/null terminator、Modifying the Array object。從本質上來講第二類和第三類技術一樣，都是通過一系列的記憶體破壞（Memory Corruption），最終泄露出關鍵模組的記憶體基址，並擷取控制權。下面參考FireEye的文章分別對三類技術的原理進行介紹。

 

3.1. 利用non-ASLR模組

　　這是一種最簡單也最常見的對抗ASLR保護的技術，因為現在仍然有許多應用程式及其模組在編譯時間沒有開啟ASLR保護（/DYNAMICBASE連結選項）。系統每次都會在固定的記憶體基址上載入它們，惡意代碼編寫者便可以從這些non-ASLR模組中挑選指令（gadget）、索引系統函數，實現關閉DEP、擷取控制權等。

　　常見的未開啟ASLR保護的模組有Java 6運行環境JRE1.6的msvcr71.dll， office 2007/2010的HXDS.DLL。HXDS.DLL會在瀏覽器載入一個帶有“ms-help://”的URL時被載入進記憶體，但是微軟已經通過補丁修補了這個問題，現在的HSDS.DLL已經開啟了ASLR保護。而Java 7運行環境JRE 1.7也已經全部開啟了ASLR保護。

　　隨著越來越多的應用程式及其模組使用ASLR保護，今後使用這種利用方法通用性將越來越低。

 

3.2. 修改BSTR的長度或終止符3.2.1. BSTR

　　BSTR是一種字串資料型別，一種Pascal-Style字串（明確標示字串長度）和C-Style字串（以\0結尾）的混合物，主要應用於COM、互動功能等。它是一種複合的資料類型，由一個長度首碼，資料字串和一個終止符組成，如所示：

 

Figure 3?1

　　其中資料字串string為UNICODE編碼，但是也可以儲存其他非\x00\x00的字串。

3.2.2. 利用方法

　　這種利用方法首次出現是在Pwn2own 2010上，它只適用於那些可以重寫記憶體的特殊類型的漏洞，例如緩衝區溢位、任意地址寫、增加或減少記憶體指標處的內容。

　　1. 修改BSTR的長度

　　當某個記憶體破壞漏洞可以滿足修改任意4位元組記憶體的最終效果時，便可以利用它來修改指定位置處的BSTR的長度首碼，從而使得此BSTR可以訪問它原始界限以外的記憶體。由此最終可以擷取適合構造ROP鏈的連結庫的精確位置，從而實現了繞過ASLR。當通過此方法繞過ASLR後，便可通過同樣的記憶體破壞漏洞改變執行流程擷取控制權。

　　例如下面的一個情形，首先在記憶體中連續建立一定數量且大小相同的BSTR，它們在記憶體中的布局如Figure 3?2所示。

 

Figure 3?2

 

 　　釋放其中的一個BSTR，然後立刻申請相同大小的一個object，相同大小是指object最終在記憶體中所佔用的大小與BSTR在記憶體中佔用的大小一致。由於前端堆Low Fragmentation Heap的作用，申請的object很可能會被分配到剛剛釋放的BSTR記憶體空間上。因此此時的記憶體布局。

 

Figure 3?3

 

　　此時修改Object前面BSTR的長度，就可以通過越界讀，讀取到object對象的虛函數表指標，最終計算出相關模組的記憶體基址。

　　2. 修改BSTR的終止符

　　很多時候記憶體破壞類漏洞可控程度並不高，不足以修改4位元組（不能用來修改BSTR的長度），只能對記憶體指標處的1、2位元組進行修改。在這種情況下我們可以通過修改BSTR的終止符，從而將string與後面的object串連起來。隨後訪問修改後的BSTR，object也會作為BSTR的一部分被訪問到，攻擊者便可以計算出相關模組的基址。

 

3.3. 修改Array對象長度3.3.1. 利用方法

　　這種修改Array對象長度的利用方法與修改BSTR長度的利用方法類似，同樣需要那些可以重寫記憶體的記憶體破壞類型的漏洞。但是從攻擊者的角度來看，可以通過這種利用方法實現繞過ASLR的漏洞更具方便使用性，因為一旦Array對象的長度被修改，攻擊者就可以通過數組擷取任意記憶體讀寫的能力，同時更容易控製程序的執行流程，實現代碼執行。下面通過VUPEN在Pwn2Own2013上利用的CVE-2013-2551漏洞為例，描述此方法的利用原理。

　　這個漏洞是由於負責VML解析的模組VGX.DLL，在處理<v:stroke>標籤的dashstyle.array.length屬性時，沒有對傳入的參數進行完備驗證而導致的整數溢出漏洞。攻擊者利用這個漏洞能夠對任意地址進行讀寫操作——通過讀取敏感記憶體資訊、改寫對象虛表，就能夠完美繞過重重記憶體防護機制實現任意代碼執行。

　　首先說明一下，VML中使用JS語句對dashstyle屬性賦值時，例如：stroke.dashstyle = "1 2 3 4"，函數vgx!ParseDashStyle會被調用，將控制流程轉向_MsoFCreateArray函數來建立一個ORG數組。在_MsoFCreateArray中調用_MsoFInitPx函數根據數群組成員個數來、進行記憶體配置，每個數群組成員佔四位元組記憶體，所以ORG數組的緩衝區大小為數群組成員個數×4(byte)。在對dashstyle.array.length屬性賦值時，數群組成員的個數會改變，在其內部調用的vgx!COALineDashStyleArray::put_length函數中會根據新設定的值來重新為ORG數組成會根據新設定的值來重新為ORG數組成分配記憶體。然而在put_length中存在一個整數溢出漏洞，使得可以不通過新的記憶體配置而將dashstyle的Array對象長度設定為0xffff。此漏洞的利用原理如下。

　　在堆上分配連續的 COARuntimeStyle對象，每個對象佔用0xB0位元組，並在中間通過設定dashstyle穿插進一個ORG數組。控制數組的大小，使其也為0xB0位元組。此時記憶體布局。

 

Figure 3?4

 

　　利用漏洞修改dashstyle的長度，使得可以通過ORG數組越界訪問隨後的資料。 ORG數組的長度被修改後，迴圈給每個 COARuntimeStyle的marginLeft屬性賦值，在迴圈中同時利用已經溢出的ORG 數組去讀取指定位移處的值（即讀取ORG 數組隨後 COARuntimeStyle對象儲存marginLeft屬性的地址），如果其值大於0，說明此時索引到ORG 數組之後的那個 COARuntimeStyle對象。此時利用ORG 數組越界寫 COARuntimeStyle對象中儲存marginLeft屬性的地址的值，修改其為0x7ffe0300。越界寫完成後，通過 COARuntimeStyle對象的get_marginLeft來讀取marginLeft屬性。於是 COARuntimeStyle就會將0x7ffe0300處的值讀取出來，而0x7ffe0300處正好儲存著系統調用入口函數ntdll!KiFastSystemCall的地址，通過計算便可得到ntdll的記憶體基址，由此便繞過了ASLR。

　　此處也可以通過ORG數組越界讀隨後COARuntimeStyle對象的前4位元組（虛函數表指標），最終減去相應位移即可得到當前vgx.dll的記憶體基址。

　　（註：Win7+IE8/IE10下的CVE-2013-2551漏洞利用原理及代碼請關注ISCC2014結束後我發表的博文。）

 

4. 繞過DEP

　　DEP技術在XP SP3被引入，但僅依靠GS & DEP & SafeSEH技術仍不足以阻止所有的惡意代碼。第2節中已經簡要介紹了常見的兩類Bypass DEP技術。目前0day漏洞利用中常採用代碼重用的方法實現對DEP的繞過，包括利用系統API改寫記憶體頁屬性、調用執行系統命令或載入可執行檔（EXE、DLL等）從進程空間外引入代碼、改寫安全配置（例如IE瀏覽器的SafeMode標誌位[5]等）。

　　其中，利用系統API改寫記憶體頁屬性和載入可執行檔（EXE、DLL等）從進程空間外引入代碼是最為常見的利用方法，其核心是ROP技術。它將堆棧切換到攻擊者偽造的堆棧上，利用精巧構造的堆棧實現DEP的繞過。下面將主要說明ROP的技術原理。（註：TK提出的LdrHotPatchRoutine技術等方法不需要使用ROP）

 

4.1. ROP技術

　　ROP的全稱為Return Oriented Programming，它是目前最常用的繞過DEP的技術。它利用了攻擊者可以控製程序執行時的資料這樣一個事實，攻擊者向進程記憶體空間中注入一個偽造的呼叫堆疊，然後執行一個stack pivot（堆棧反轉）指令，使得堆棧指標轉換到偽造的呼叫堆疊上，偽造的堆棧可以被認為是記錄著因果關係鏈結（ROP chain，由一個個ROP Gadget組成，下文具體解釋）。

　　在正常情況下，當一個函數返回時，正常的堆棧中儲存著函數的返回地址，即父函數調用子函數時的下一條指令的地址。然而當堆棧指標轉換到偽造的呼叫堆疊後，當函數返回時將從偽造堆棧中擷取返回地址，此時的返回地址是指向進程空間中的一個ROP Gadget。

　　ROP Gadget代表進程空間中任何有用的可執行指令串（位於可執行頁面上），並且這些可執行指令串都以 ret指令結尾，從而使得指令串執行完畢後仍然從偽造的堆棧中擷取返回地址（下一個ROP Gadget的地址）。 要保證目標程式每次運行時，偽造堆棧中ROP Gadgets的地址都是可預期且可靠的，攻擊者必須先繞過ASLR，擷取相關模組的記憶體基址，然後根據指令位移（寫入程式碼，每個模組中的指令位移固定不變）得到確定的ROP Gadget地址，或者通過動態搜尋的方法在記憶體空間中搜尋ROP Gadget構建ROP chain。

　　在偽造堆棧上構造一系列ROP Gadget的目的就是針對要利用的漏洞布置“有用”的環境（例如調整堆棧指標、設定寄存器值等），因為最後一個ROP Gadget將指向VirtualAlloc、VirtualProtect、WriteProcessMemory、ShellExecueEx、LoadLibrary等函數的地址，它們將用於修改指定記憶體頁為可執行或者從進程空間外引入代碼並執行。最終使得堆棧、堆上的資料變成可執行或直接載入運行可執行檔，從而繞過DEP的保護。

　　ROP利用方法之所以能夠工作是因為攻擊者欺騙系統使用攻擊者可控的資料，而這些資料也並不需要得到執行許可權，攻擊者只需要控制EIP接下來執行的地址從而執行需要的指令和函數。當偽造的堆棧被注入進程空間後（通過Heap spray[4]在指定地址處布局shellcode、通過漏洞擷取shellcode的地址），ROP方法的執行流程簡單總結如下：

　　1)  執行“stack pivot”指令（例如xchg eax, esp; ret等），將堆棧指標轉換到偽造堆棧上。

　　2)  從偽造堆棧的頂部開始執行ROP Gadget

　　　　a) 執行一些“有用”的指令串（push/pop/add/sub…）

　　　　b) 執行ret指令（如果偽造堆棧上的返回地址處仍然是一個ROP Gadget，則繼續跳轉至執行；如果返回地址是一個函數地址如VirtualProtect等，則利用偽造堆棧上布置　　　　　　　　　　　　好的參數執行函數。執行完畢後即可跳轉至偽造堆棧上設定好的返回地址，運行payload）

 

5. 通用繞過方法

　　已經有研究者公布出了更具通用性的繞過ASLR、DEP的方法，例如Dion Blazakis提出的JIT spray（Just In Time Compilation），於暘（tombkeeper）發現的LdrHotPatchRoutine等。但是研究者也發現，在自然環境下，從來沒有0day攻擊使用這些方法對抗ASLR，原因是這些方法公開以後，就很快會被修補掉。下面簡單介紹一下其實現原理，技術細節請參考其他技術文檔。

5.1. JIT spray技術

　　JIT Spray 是一種利用“及時編譯”的特性來繞過ASLR、DEP的利用方法。一個“及時編譯器”根據定義產生代碼作為它的資料。因此它的目的就是產生可執行資料。JIT編譯器是一種不能運行在“no-executable-data”環境下的程式，因此，JIT編譯器會免除DEP。而JIT Spray攻擊就是用JIT編譯器“產生的程式碼(利用代碼)”來進行堆噴射的一種攻擊方式。

5.2. LdrHotPatchRoutine 技術

　　從Windows NT 4到Windows 8，SharedUserData的位置一直固定在地址0x7ffe0000，並且在x86下0x7ffe0300處也一直儲存這KiFastSystemCall的地址。

而x64下7ffe0350則儲存著LdrHotPatchRoutine的地址，在它內部會索引LdrLoadDll來載入外部的DLL，從而可以實現任意代碼的執行。

5.3. DEV技術

　　DEV技術最早由yuange提出，其基本思想是利用指令碼語言的先天優勢，即指令碼語言是解釋執行的，代碼、shellcode都是資料。通過漏洞修改關鍵資料結構，最終實現作為指令碼的shellcode的執行。關於DEV的技術細節請參見參考文獻[6]。

5.4. Undocuments

　　相信還有其他未公開的通用方法，能夠像LdrHotPatchRoutine技術、JIT spray技術、DEV技術一樣不需要通過精心的記憶體布局，從而實現繞過ASLR、DEP。這些未公開的技術具有更高的價值。

 

6. 參考文獻

[1] Bypassing Browser Memory Protections-Setting back browser security by 10 years [EB/OL]. Alexander Sotirov, Mark Dowd. 2008.

[2] The info leak era on software exploitation [EB/OL]. Fermin J. Serna. 2012.

[3] ASLR Bypass Apocalypse in Recent Zero-Day Exploits [EB/OL]. Xiaobo Chen. 2013.

[4] Heap Feng Shui in JavaScript. [EB/OL]. 2007

[5] Subverting without EIP. [EB/OL]. MALLOCAT. 2014

[6] APT 進階漏洞利用技術. [EB/OL]. yuange. 2014