Hook導(dǎo)入表 —— 實(shí)現(xiàn)掛鉤FreeLibaray和HOOK延遲加載模塊的API

　　最近在研究Windows Ring3上的API Hook，對HOOK導(dǎo)入表這種方法進(jìn)行了研究。HOOK導(dǎo)入表所用的C++類大同小異，不同的就是如何實(shí)現(xiàn)HOOK一個延遲加載的模塊中的函數(shù)，以及FreeLibaray某個函數(shù)之后再次LoadLibaray加載這個模塊所導(dǎo)致的模塊基地址不同的時候，這時該如何HOOK住這個模塊中的API。
　　顯然地，掛鉤LoadLibarayA/W、LoadLibarayExA/W、GetProcAddress這些函數(shù)還不夠，還需要掛鉤FreeLibrary函數(shù)。這里我參考了《Windows核心編程》（第五版）中的一個程序，封裝了一個C++類，能夠HOOK住FreeLibrary，同時也能解決延遲加載的問題。
　　以下是這個類的聲明：

 

　　想必其中某些函數(shù)不需要說了，需要說明的是FreeLibaray_Hook函數(shù)，這個函數(shù)是FreeLibaray的替換函數(shù)，通過sm_FreeLibrary對象進(jìn)行HOOK。
　　開始寫這個函數(shù)的時候，遇到了困難，理由是這樣的，因?yàn)槿绻@段代碼作為DLL注入到目標(biāo)進(jìn)程中去，如果通過鉤子的方法注入到目標(biāo)進(jìn)程中時，那么卸載鉤子時，會引發(fā)目標(biāo)進(jìn)程調(diào)用FreeLibaray來釋放這個DLL，此時會調(diào)用FreeLibaray_Hook函數(shù)，哪怕在這個函數(shù)的最后“return ::FreeLibaray(hLibModule)”，也會出現(xiàn)問題。因?yàn)檫@個函數(shù)會產(chǎn)生了C/C++運(yùn)行時的框架代碼，就會在返回之后調(diào)用一些框架代碼，比如調(diào)用C++類的析構(gòu)函數(shù)之類，而此時該模塊已經(jīng)從目標(biāo)進(jìn)程中卸載，這必然會導(dǎo)致內(nèi)存訪問違規(guī)。因此，必須如下定義該函數(shù)：

　　這樣，VC編譯器就不會對CApiHook::FreeLibaray_Hook函數(shù)產(chǎn)生一些框架代碼，就需要自己寫內(nèi)聯(lián)匯編來維持堆棧的平衡。這里給出這個函數(shù)的定義：

　　這里給出CApiHook類的完整定義：

 

 

　　如上就可以實(shí)現(xiàn)掛鉤FreeLibaray函數(shù)的功能了。

　　同時，這里在HOOK所有LoadLibaray*函數(shù)的時候，調(diào)用了FexupNewlyLoadedModule函數(shù)，該函數(shù)會遍歷所有CApiHook對象，查看是否存在某個對象的API原地址為NULL，如果是，就檢測模塊名是否一致，這樣就可以通過模塊得到這個API原始地址了，這樣就可以解決延遲加載的問題。

posted on 2009-08-14 13:36 小虎無憂 閱讀(1943) 評論(2)  編輯 收藏 引用 所屬分類: DLL