最近要看各種paper 但是看的斷斷續續的，后面看前面的就忘光了（主要就是太忙……各種私人以及學習的是，不過還好申請弄完了 閑下來可以看看書了 哈哈），所以開個帖子把讀過的paper總結下，寫個心得吧。標紅的是我的問題~哈哈
原文：HookFinder: Identifying and Understanding Malware Hooking Behaviors
source2download：點這里
引言：
這篇文章講述的內容小有趣的說，主要介紹了一個系統，把樣本的惡意程序放進去能夠自動分析出它的hook操作，包括hook了哪里，如何hook的。它結合一個特定的“虛擬機”（這么說不算太貼切 它文章里面用的是system-emulator這個詞，文章里面說這個和虛擬機不用，我估計是原理相同用途不同而已吧，后面就虛擬機這么叫吧），在物理層面它能夠獲取到程序執行時的所有寄存器狀態，在系統層面它能夠獲得系統信息，比如進程模塊地址之類的東西，就跟windbg類似。然后通過跟蹤寄存器讀寫操作以及結合系統信息來檢測出程序的hook行為，它里面測試的樣例可都是kernel級別的rootkit喲，還是相當強大的一個東東。
下面就開始吧，通過監測寄存器（system-emulator提供的接口），那么我們便可以掌握內存的讀寫情況，更犀利的是我們如此便可以監控所有對內存讀寫的操作。然后通過一個叫Semantics Extrator（SE）的模塊來提取出操作系統層次的信息，打個比方，我捕獲到0x743292BC這個要被寫入東西，那么通過SE模塊我可以查出這個地址是系統內核函數ObReferencebyPointors的函數空間，然而我又可以通過SE模塊知道我現在運行的代碼段是在X驅動模塊中的，那么顯然X驅動就有可能是在修改系統代碼，正在進行Data Hook。
聽起來很犀利哇？不過深入分析下去，還是有很多問題要解決的。多個模塊代碼都進行了同樣的hook你又如何記錄存儲這些HOOK信息咧？如何實現自動檢測HOOK？
那么文章中提出了設計了3個模塊（其實不止3個 我把工作相似的模塊合并了）：Impact Engine，SE，Hook Detector
Impact Engine
何為impact在文中的意思就是改動，整體翻譯就是改動檢測引擎（個人YY過來的）。這個引擎用來監控標記程序運行時，對系統內存讀寫的動作，以便下一步的分析。
這個引擎分2部分，Impact Marker和Impact Tracker
Impact Marker
監控惡意代碼中的內存讀寫分幾種情況，一種是在代碼中直接進行內存讀寫，另一種就是惡意代碼通過調用外部函數比如memcpy之類的來進行內存操作，文中主要討論了記錄外部調用的內存操作的策略。
首先監控內存讀寫以及寄存器讀寫，但這2個操作是分開來處理的。對于外部函數調用讀寫內存，我們只監控外部變量的讀寫，至于外部變量如何判斷很簡單，查看寫入地址如否在線程堆棧的范圍內，若在則是局部變量，若不在，嘿嘿~外部變量。
那么對于寄存器讀寫的操作就顯得容易多了，因為在windows系統下，返回值是通過eax傳遞的，文中說的是在函數開始時記錄eax的值，然后等函數結束后在比對eax的值是否與原來的一樣，如果不一樣，那么函數包含返回值則標記之，如果不一樣，那么函數返回值是無效的。
當然這里涉及到一個問題就是惡意代碼會動態產生可執行代碼丫，但是由于我們標記了它內存分配情況，那么只要在執行時判斷下執行的指令是否取自標記的內存段，若是，就認為是惡意代碼自產生的可執行代碼，然后對于這段代碼也采取同樣的監控標記方式來跟蹤它的輸入輸出。
Impact Tracker（IT）
這個模塊主要用來關聯這些標記的內存操作和內存改動的。如果在Impact Marker的標記中，操作數的地址或數據是被標記了的，則標記上目的操作數的地址或數據。并且IT模塊對目的操作數每個標記分配一個ID號，并記錄每個ID號之間的關聯，如此一來我們便可以捕獲惡意代碼對系統生成的改動，比如惡意代碼是如何改動重要數據結構的，當然這些監控對惡意代碼的磁盤讀寫，設備掛載，系統例程注冊同樣有效。因為這些操作的最終原理也不過是生成或改動數據結構而已。
Semantics Extractor
該模塊很簡單，就是從虛擬的系統中提取出需要的信息，比如說進程的所有信息，線程的所有信息，驅動模塊的所有信息等等，然后獲得這些需要的信息一般有2種方式，其一就是通過解析一些重要的數據結構來獲得，比如EPROCESS，另一種方式就是向虛擬系統中插入一個模塊，在系統運行時動態收集系統信息，主要通過設置回調函數的方式工作。比如收集進程信息，在進程創建銷毀的時候調用該模塊的處理例程等等。
此外SE模塊還負責解析函數符號名，確定是否是惡意代碼進行的外部函數調用。主要是通過解析PE頭文件來實現，這個就不累述了，一來我只是略懂，二來看雪上關于PE的資料我覺得已經很透徹了~
HOOK Detector
這個模塊的判斷依據還比較簡單，判斷EIP寄存器載入的數據是否是被標記了的，如果EIP載入了被標記的數據（也就是說程序當時運行在非惡意代碼模塊的上下文，若不考慮這個，則惡意代碼代碼執行的內部調用也會被誤判為HOOK）并且立即跳轉到了惡意代碼的模塊空間或者是惡意代碼分配的內存空間內，則將其定義為一個HOOK。當然這個辦法僅僅能用于數據HOOK，代碼HOOK的話還需另加討論，我們定義說如果在非惡意代碼上下文是運行了被標記為惡意代碼模塊的篡改數據，并且EIP載入數據也被標記并且跳轉到了惡意代碼空間，那么這就是一個代碼HOOK，然而這里又有一個問題，代碼HOOK和惡意代碼自產生的代碼性質是一樣的，那么如何判斷這些被標記的代碼是自產生代碼還是HOOK的數據咧？很簡單，自產生代碼存在的空間要么是惡意代碼模塊分配的，要么是占用了不屬于任何模塊的數據空間，而HOOK的數據肯定是覆蓋了系統調用的空間的，所以簡單的通過SE模塊查一下這段代碼是否在系統調用空間就OK了，如果是，則判斷為HOOK數據，如果不是，在驗證下是否滿足自產生代碼的條件。
類別：Host Security 查看評論文章來源:
http://hi.baidu.com/uestc%5Fay/blog/item/f9bae97af15009e60ad187f9.html