• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

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

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

            CApiHook類聲明

             

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

            __declspec(naked) BOOL WINAPI CApiHook::FreeLibrary_Hook(HMODULE hLibModule)

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

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

             

            CApiHook類和一些輔助函數(shù)的定義

             

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

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

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

            評(píng)論

            # re: Hook導(dǎo)入表 —— 實(shí)現(xiàn)掛鉤FreeLibaray和HOOK延遲加載模塊的API 2009-08-14 16:21 萬(wàn)連文


            XTP的Skin模塊里面也有API的HOOK,做的也相當(dāng)不錯(cuò)  回復(fù)  更多評(píng)論   

            # re: Hook導(dǎo)入表 —— 實(shí)現(xiàn)掛鉤FreeLibaray和HOOK延遲加載模塊的API 2009-08-15 11:36 樂(lè)蜂網(wǎng)

            還不錯(cuò)啊~~  回復(fù)  更多評(píng)論   

            <2009年8月>
            2627282930311
            2345678
            9101112131415
            16171819202122
            23242526272829
            303112345

            導(dǎo)航

            統(tǒng)計(jì)

            常用鏈接

            留言簿

            隨筆分類

            隨筆檔案

            搜索

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            精品无码人妻久久久久久| 青青草原精品99久久精品66| 2021国内精品久久久久久影院| 亚洲AV无码一区东京热久久| 97久久精品人妻人人搡人人玩| 久久久久无码专区亚洲av| 精品久久久久久国产| 久久青青草原精品影院| 色老头网站久久网| 2022年国产精品久久久久| 开心久久婷婷综合中文字幕| 久久久久高潮毛片免费全部播放| 精品无码久久久久久久久久| 亚洲精品tv久久久久久久久| 国产精品成人无码久久久久久| 中文字幕久久精品无码| 国产精品狼人久久久久影院| 久久久久久久波多野结衣高潮| 亚洲国产成人久久综合一| A级毛片无码久久精品免费| 精品久久人人爽天天玩人人妻| 亚洲国产一成人久久精品| 久久强奷乱码老熟女| 久久亚洲国产中v天仙www| 亚洲中文精品久久久久久不卡| 久久嫩草影院免费看夜色| 9久久9久久精品| 一本久久a久久精品vr综合| 人妻精品久久久久中文字幕| 久久精品国产影库免费看| 亚洲AV无码久久精品蜜桃| 久久亚洲电影| 国产精品成人99久久久久 | 少妇久久久久久被弄到高潮| 国产成人精品久久免费动漫 | 天堂无码久久综合东京热| 中文字幕亚洲综合久久2| 国产精品一久久香蕉国产线看观看 | 香蕉久久夜色精品国产小说| 久久久久亚洲AV成人片| 久久久无码精品亚洲日韩蜜臀浪潮 |