前言:本文主要討論現在網傳很廣的單線程函數hook 類CULHook 掛鉤代碼的致命漏洞以及設計缺陷,并給出我的解決方案.

   知識前提:您應該有windows 程序設計和C++的基本知識,以及對操作系統(tǒng)原理稍微了解.

     -----------人因相互學習而進步,若您發(fā)現文中有錯誤,請不吝賜教,能夠告訴我,感恩您.

    once, I saw a cpp class that realized the API hook by inline assembly  in user mode. Maybe some of you have known this class that named "CULHook" too.
However, there are some problems existed by now. One problem is that  hook method doesn't work well on multiple threads condition. And another  problem
seems not to be clear but fatal !

  This is the original code of the class CULHook:             代碼來自 <windows 程序設計> -王艷平         注： 注解見下面，可參考我的CSTAPIHook類的代碼

#include <windows.h>

class CULHook
{
public:
    CULHook(LPSTR pszModName, LPSTR pszFuncName, PROC pfnHook);
    ~CULHook();
    void Unhook();
    void Rehook();
protected:
    PROC m_pfnOrig;        
    BYTE m_btNewBytes[8];
    BYTE m_btOldBytes[8];   
    HMODULE m_hModule;
};

CULHook::CULHook(LPSTR pszModName, LPSTR pszFuncName, PROC pfnHook)
{
    // jmp eax == 0xFF, 0xE0
    BYTE btNewBytes[8] = { 0xB8, 0x00, 0x00, 0x40, 0x00, 0xFF, 0xE0, 0x00 };
    memcpy(m_btNewBytes, btNewBytes, 8);
    *(DWORD *)(m_btNewBytes + 1) = (DWORD)pfnHook;
    m_hModule = ::LoadLibrary(pszModName);

    if(m_hModule == NULL)
    {
        m_pfnOrig = NULL;
        return;
    }
    m_pfnOrig = ::GetProcAddress(m_hModule, pszFuncName);
    if(m_pfnOrig != NULL)
    {
        DWORD dwOldProtect;
        MEMORY_BASIC_INFORMATION    mbi;                                         //1
        ::VirtualQuery( m_pfnOrig, &mbi, sizeof(mbi) );
        ::VirtualProtect(m_pfnOrig, 8, PAGE_READWRITE, &dwOldProtect);   //2
        memcpy(m_btOldBytes, m_pfnOrig, 8);
        ::WriteProcessMemory(::GetCurrentProcess(), (void *)m_pfnOrig, m_btNewBytes, sizeof(DWORD)*2, NULL);
        ::VirtualProtect(m_pfnOrig, 8, mbi.Protect, 0);
    }
}

CULHook::~CULHook()
{
    Unhook();
    if(m_hModule != NULL)
        ::FreeLibrary(m_hModule);
}

void CULHook::Unhook()
{
    if(m_pfnOrig != NULL)
    {
        DWORD dwOldProtect;
        MEMORY_BASIC_INFORMATION    mbi;
        ::VirtualQuery(m_pfnOrig, &mbi, sizeof(mbi));                               //1
        ::VirtualProtect(m_pfnOrig, 8, PAGE_READWRITE, &dwOldProtect);  //2

        ::WriteProcessMemory(::GetCurrentProcess(), (void *)m_pfnOrig,
            m_btOldBytes, sizeof(DWORD)*2, NULL);

        ::VirtualProtect(m_pfnOrig, 8, mbi.Protect, 0);
    }
}

void CULHook::Rehook()
{
    if(m_pfnOrig != NULL)
    {
        DWORD dwOldProtect;                                        
        MEMORY_BASIC_INFORMATION    mbi;                                         //1                       
        ::VirtualQuery( m_pfnOrig, &mbi, sizeof(mbi) );                               
        ::VirtualProtect(m_pfnOrig, 8, PAGE_READWRITE, &dwOldProtect);    //2
        ::WriteProcessMemory(::GetCurrentProcess(), (void *)m_pfnOrig, m_btNewBytes, sizeof(DWORD)*2, NULL);
        ::VirtualProtect(m_pfnOrig, 8, mbi.Protect, 0);
    }
}

  一個事實:我用這個類掛鉤TerminateProcess和Process32NextW函數時,目標進程崩潰(下面你將會看到在什么情況下會失敗)
   凡是我標1的地方都有設計問題，凡是我標2的地方都有嚴重安全隱患。

   1, 首先我們先看一下這個類，有著很明顯的設計問題，我們可以看看構造函數和ReHook成員函數，有著明顯的代碼重復，一種解決方案是，把掛鉤功能放在一個成員函數中，在構造函數中調用即可。
   2, 凡是我標1 的地方完全沒有必要，我們知道VirtualProtect 的最后一個參數可以返回原來的權限，寫完內存后直接把 dwOldProtect再傳給 VirtualProtect 以恢復頁面權限屬性，而無需
      再大費周章的得到 mbi 結構.
  3, 最不容易被發(fā)現的一點,也就是我標2的地方,也就是我們應該獲取何種訪問權限,代碼中是PAGE_READWRITE, 這有問題嗎?我們不能給教科書挑錯吧,畢竟原書示例程序的卻是用這個類   攔截了Ws2_32.dll中的winsock2的 一些函數. 但是,這句有問題,要弄清楚這個問題就必須清楚這個類的原理.

  原理: 通過修把要掛鉤函數的前8個字節(jié)數據改為跳轉到我們函數的機器指令(原來的8字節(jié)保存起來),然后在我們的鉤子函數中執(zhí)行我們的操作,我們要干預的動作全部結束后,再把原來       的8字節(jié)數據寫回去,再調用原函數,為了再次攔截目標函數,原函數調用完后, 要再次把原函數前8個字節(jié)寫成跳轉到我們函數的機器指令,至于為什么是8字節(jié)? 我們來看看實現這個跳轉的匯   編指令吧:

                mov eax,our_Hookfunction         //把我們函數地址裝入到eax寄存器的指令占1字節(jié) ,我們的函數地址占4字節(jié),  即:0xB8, 0x00, 0x00, 0x00, 0x00 
                jmp eax                                  //jmp 指令碼1字節(jié), eax 寄存器號1字節(jié) 即: 0xFF, 0xE0, 

好了 1+4+2=7 , 按照對齊原則,最后一字節(jié)我們以0填充.
問題在哪里,我說過這個類是掛鉤單線程函數的,怎么理解, 試想這種情況:當我們修改目標函數前8個字節(jié)時,在32位系統(tǒng)中,,要寫完8字節(jié)(64位)得用兩個存儲周期，假如第一次寫了32位數據后，系統(tǒng)發(fā)生線程換，如果新線程也要調用我們要掛鉤的函數，因為這個函數我們只寫了前4個字節(jié)，后4字節(jié)還沒寫，天知道會發(fā)生什么事。假如只有一個線程會調用我們的目標函數，則萬事大吉。當然這個類本身就是掛鉤單線程函數的，我在這里說明是因為有人人問過我這個問題。

好了既然搞清楚了原理，我們就言歸正傳，分析下面這種情況：假設我們要掛鉤的目標進程中有D和W兩個線程分別只會調用fun1,fun2兩個函數,而fun1和fun2又都是dw.dll的導出函數,且在同一個頁面中,現在我們用上面的類掛鉤函數fun1,顯然fun1是單線程(D)調用的,符合單線程安全,按理說應該會成功. 難道真相就是能成功掛鉤嗎,如果是,我這篇博客就沒必要寫了.根據上面類的代碼我們來分析運行過程:首先我們把跳轉到我們函數的機器指令寫到fun1的前8個字節(jié),首先代碼中獲取了PAGE_READWRITE權限,然后有了權限后開始寫,若只寫完前4個字節(jié)后,系統(tǒng)切換到線程W,假設W線程在這個時間片里沒有調用fun2,而線程W不會調用fun1,等線程切回來之后我們寫完剩下的4字節(jié),如果是這樣則掛鉤成功,但是如果在寫了前4字節(jié)切換到W時,W調用了fun2,會發(fā)生什么,這就是我本篇博文主要的焦點了,因為fun1和fun2是在同一個頁面中,而VirtualProtect給該頁面獲取了PAGE_READWRITE權限,也許有人會認為只給fun1獲取了PAGE_READWRITE 權限,而fun2權限沒變,這是錯誤的,因為系統(tǒng)權限管理是以頁為單位的,VirtualProtect 會給fun1所在的所有頁都會獲取PAGE_READWRITE 權限(如果fun1的代碼橫跨兩個頁面,則這兩個頁面都會被改為PAGE_READWRITE 權限),也就是說此時fun2的權限是PAGE_READWRITE 即只能讀或寫,而不能執(zhí)行,那么fun2調用將會失敗,產生非法操作,這時您的目標進程就被您成功的搞崩潰了.這也就解釋了我們用這個類掛鉤其他某些函數時,一掛鉤,目標進程就崩潰. 還有一個問題就是如果目標進程是單線程的,那么掛鉤還有沒有可能會失敗, 請讀者思考,我把答案直接告訴你,有可能!如果您實在想不到為什么可以向我反饋,我在這里說出原因主要是想讓您能夠獨立思考,授人以魚不如授人以漁.

解決方案:在VirtualProtect指定要獲取的操作權限時把PAGE_EXECUTE_WRITECOPY 或PAGE_EXECUTE_READWRITE,也就是加上EXECUTE可執(zhí)行權限,就行了,到此我們的主要問題就解決了,但是別忘了你現在瀏覽的是Duwen的C++博客,所以我設計了CSTAPIHook類 意思就是 CPP Single Thread API Hook 的意思:


/************************************************************************