(来自windows核心编程)API Hook的试验记录

女爷i 2021-12-22 02:55 218阅读 0赞

直接pudn找到windows viac 的源码（第五版？）

找到22-LastMsgBoxInfo工程

开始试验发现挂在了CAPIHook::GetProcAddress 错误是stack overflow

然后去掉

CAPIHook CAPIHook::sm\_GetProcAddress("Kernel32.dll", "GetProcAddress",  
(PROC) CAPIHook::GetProcAddress, TRUE);

结果发现不报错，顺利得到结果；

但是，最后退出的时候挂在CAPIHook::LoadLibraryW 错误也是stack overflow

于是更新sdk，当前是Microsoft Platform SDK for Windows Server 2003 R2

结果，乱搞一通，路径，debugging tool 等，还是不行，主程序（原来是对话框）改成控制台也不行。

重启电脑后，控制台可以了，但对话框的还是不行。

但可以肯定，是自己的系统问题，因为我之前用vs03的时候是完全可以正常运行的。

所以，用vc6来运行pudn上下载的 windows via 程序源码会问题多多。

实现的核心是ReplaceIATEntryInOneMod这个函数，然而呈现在我们面前的是CAPIHook这个类。

留意到了

CAPIHook CAPIHook::sm\_LoadLibraryA ("Kernel32.dll", "LoadLibraryA",  
(PROC) CAPIHook::LoadLibraryA, TRUE);

CAPIHook CAPIHook::sm\_LoadLibraryW ("Kernel32.dll", "LoadLibraryW",  
(PROC) CAPIHook::LoadLibraryW, TRUE);

CAPIHook CAPIHook::sm\_LoadLibraryExA("Kernel32.dll", "LoadLibraryExA",  
(PROC) CAPIHook::LoadLibraryExA, TRUE);

CAPIHook CAPIHook::sm\_LoadLibraryExW("Kernel32.dll", "LoadLibraryExW",  
(PROC) CAPIHook::LoadLibraryExW, TRUE);

CAPIHook CAPIHook::sm\_GetProcAddress("Kernel32.dll", "GetProcAddress",  
(PROC) CAPIHook::GetProcAddress, TRUE);

这几行。其实就是作者提到的要另外（附加）挂接的函数，其实去掉也不会影响这个程序的基础目的（挂接api）。

但是我不太理解的是：作者的挂接都写在dll里边，而且是隐式调用dll，导致我这种菜鸟不好理解。

1.于是我尝试先把dll变为显式调用：

ok，一切顺利。

2.把挂接函数放到外边

由于CAPIHook::sm\_GetProcAddress依然会导致不稳定，试验中暂时去掉

ok。

3.挂了dll之后改为动态挂接api(原来的钩子是随着dll的加载而加载的)

首先，作者为了标准和规范。在挂接函数体中时这样写的

// This is the MessageBoxW replacement function  
int WINAPI Hook\_MessageBoxW(HWND hWnd, PCWSTR pszText, LPCWSTR pszCaption,  
UINT uType) \{

// Call the original MessageBoxW function  
int nResult = ((PFNMESSAGEBOXW)(PROC) g\_MessageBoxW)  
(hWnd, pszText, pszCaption, uType);

// Send the information to the main dialog box  
SendLastMsgBoxInfo(TRUE, (PVOID) pszCaption, (PVOID) pszText, nResult);

// Return the result back to the caller  
return(nResult);  
\}

注意类中的 operator PROC() \{ return(m\_pfnOrig); \}

其实，这个可以改为

int nResult = MessageBoxW  
(hWnd, pszText, pszCaption, uType);

因为dll自身的api并没有被挂接

所以我先改为以上方式

然后我屏蔽掉

//extern CAPIHook g\_MessageBoxA;  
//extern CAPIHook g\_MessageBoxW;

不是，犯了了个错误

应该是屏蔽

// CAPIHook g\_MessageBoxA("User32.dll", "MessageBoxA",  
// (PROC) Hook\_MessageBoxA, TRUE);  
//  
// CAPIHook g\_MessageBoxW("User32.dll", "MessageBoxW",  
// (PROC) Hook\_MessageBoxW, TRUE);

结果后来发现得出了上面的试验只说明了自己对dll的了解太少了

原来

CAPIHook g\_MessageBoxA("User32.dll", "MessageBoxA",  
(PROC) Hook\_MessageBoxA, TRUE);  
  
CAPIHook g\_MessageBoxW("User32.dll", "MessageBoxW",  
(PROC) Hook\_MessageBoxW, TRUE);

这两个变量在dll中时貌似是一个普通的全局变量。但是在dll加载的时候，每个加载这个dll的进程线程都会建立一个各自的副本。

也就是说，每次dll被加载都调用了构造函数，反之，释放的时候也调用了解析函数。

为了验证这一点，我特意做了个试验：

CAPIHook *g_pMessageBoxA;
    CAPIHook *g_pMessageBoxW;
    
    BOOL APIENTRY DllMain( HANDLE hModule, 
                          DWORD  ul_reason_for_call, 
                          LPVOID lpReserved
                          )
    {
        switch (ul_reason_for_call)
        {
        case DLL_PROCESS_ATTACH:
            g_pMessageBoxA = new CAPIHook("User32.dll", "MessageBoxA", 
                (PROC) Hook_MessageBoxA, TRUE);
            g_pMessageBoxW = new CAPIHook("User32.dll", "MessageBoxW", 
                (PROC) Hook_MessageBoxW, TRUE);
            break;
        case DLL_THREAD_ATTACH:
            g_pMessageBoxA = new CAPIHook("User32.dll", "MessageBoxA", 
                (PROC) Hook_MessageBoxA, TRUE);
            g_pMessageBoxW = new CAPIHook("User32.dll", "MessageBoxW", 
                (PROC) Hook_MessageBoxW, TRUE);
            break;
        case DLL_THREAD_DETACH:
            delete g_pMessageBoxW;
            delete g_pMessageBoxA;
            break;
        case DLL_PROCESS_DETACH:
            delete g_pMessageBoxW;
            delete g_pMessageBoxA;
            break;
        }
        return TRUE;
    }

结果页同样可以实现api的hook。

这个试验只说明了自己所知甚少。之前我觉得搞windows底层没前途，现在觉得很可笑，因为我只懂皮毛，当然觉得没前途。

转载于:https://www.cnblogs.com/d20062303732/archive/2012/05/26/2519503.html