企业官网建设流程全解析

1. 为什么执着于GetProcAddress：IAT Hook覆盖不到的动态调用

做Windows平台Hook开发的人，几乎都是从改IAT入门的。你找到目标模块的导入表，把MessageBoxA的地址换成自己的函数指针，一切看起来都很完美。但用不了多久你就会撞上一堵墙——有些函数的调用根本不会进IAT。

举个很典型的场景。很多插件化架构的软件不直接在编译期链接扩展模块，而是运行时通过LoadLibraryA加载DLL，再用GetProcAddress拿函数指针。你提前改了目标EXE的IAT，里面根本没有GetProcAddress这个条目，因为编译期就用LoadLibraryA+GetProcAddress这种模式，所有调用链都在运行时才完成。这时候你改IAT完全是白忙活：调用者手里的函数指针是GetProcAddress返回的，走的是导出表查询，跟导入表没有半点关系。

更深层的问题是，GetProcAddress是整个动态链接机制的“最后一道总闸”。无论哪个模块、哪段代码、通过什么方式（静态导入、延迟加载、运行时LoadLibrary），最终只要想获得一个导出函数的地址，几乎都要经过它（静态导入除外，那是装载器直接填IAT）。所以只要把GetProcAddress这个总闸替换掉，并在替换函数里做一层函数地址的“过滤”，理论上就能拦截所有运行时动态解析出来的API调用。

这也是文章标题里“装入时动态链接替换”的含义所在：不是去改IAT（那是链接期行为），而是在动态链接发生的现场——也就是GetProcAddress被调用的那个时刻——把返回给调用者的地址换掉，从而“逐个注册”我们关心的目标函数。这个思路我最早是在做沙箱监控模块时用到的，后来发现很多安全工具、兼容层、自动化测试框架也在用类似方案，说明它确实是个通用性很强的技术手段。

先说清楚适用范围，免得读者误判：这篇文章讨论的替换技术，我是在自研的API监控沙箱、兼容性适配层里用的，目的是观察第三方SDK的调用行为、修正个别函数的行为差异。它本质上是一种动态链接层面的地址重定向技术，属于系统编程的基础能力。如果你要做正当的软件功能扩展、安全分析、测试Mock，这个方案很合适；如果你往恶意代码方向想，那是另一回事，本文不做任何引导。

2. 装入时动态链接的工作流程与可劫持的环节

在做替换之前，必须把Windows的链接机制理清楚。否则你改造出来的拦截器，很可能在某个隐蔽的调用路径上漏掉目标，或者干脆把进程搞崩溃。

2.1 从装载器视角看PE链接的三条路径

Windows下加载一个PE文件时，会经历一个“装入时动态链接”的过程。装载器拿到DLL后，做这几件事：解析导入表、递归加载依赖模块、修正重定位、填充IAT。这个过程发生在LoadLibrary或进程初始化阶段，对调用方是完全透明的。

但“链接”这件事并不只有一条路。实际工程里会碰到三种情况：

• 静态导入：编译时用#pragma comment(lib, "xxx.lib")或在链接器参数里指定输入库。装载器在加载模块时，自动从导入表里找到依赖的DLL，把每个导入函数地址填入IAT对应的槽位，调用时直接call [IAT槽位]。
• 延迟加载：使用/DELAYLOAD链接选项。调用方第一次调用目标函数时，由延迟加载辅助函数通过LoadLibrary+GetProcAddress解析函数地址，填到延迟加载IAT里，后续调用走填充好的地址。
• 运行时动态解析：调用方自己调用LoadLibrary（或者LdrLoadDll）拿到模块句柄，再用GetProcAddress（或者LdrGetProcedureAddress）手动获取函数地址，完全不借助编译期的导入机制。

第一种路径，改IAT就能覆盖；第二种路径，改IAT也行，但要在延迟加载辅助函数填充之后去改；第三种路径，IAT里根本没有对应条目，必须拦截GetProcAddress才能覆盖到。三种路径的对比整理一下：

2.2 “可劫持的环节”到底在哪

要替换GetProcAddress，得先搞清楚它的位置和调用链。GetProcAddress实现在kernel32.dll中，实际工作交给kernelbase.dll的LdrGetProcedureAddress。这个函数会遍历目标模块的导出表：先按函数名二分查找，如果找不到或调用方传的是序号，就按导出序号遍历。最终返回一个FARPROC指针。

这里有个关键认知：调用方拿到FARPROC后，会自己转成函数指针类型直接调用。这意味着什么？意味着我们不需要修改目标函数本身，只需要让GetProcAddress返回的指针值变成我们指定的地址。我们要劫持的环节就是GetProcAddress的“返回值”——无论它内部怎么查、查到的是哪个函数，只要它准备返回了，当中插一手，把结果替换成我们预先注册好的函数指针。

这个思路落到实现上，核心动作是修改kernel32.dll导出表中GetProcAddress这个导出项的函数地址，让它指向我们的跳板函数。这就是所谓的EAT Hook（Export Address Table Hook）。因为kernel32.dll的导出表EAT里，GetProcAddress这一项记录的地址就是我们GetProcAddress的入口，把这个地址改掉，所有调用GetProcAddress的代码就都会跳到我们的函数。

注意，我说的是“所有调用者”。EAT是全局的，不像IAT是按模块隔离的。这意味着Hook一旦装上，进程里任何模块调GetProcAddress都会经过我们的跳板。这既是优点（覆盖全面）也是风险（牵一发动全身），后面我会专门讲怎么控制影响面。

2.3 为什么是“装入时”而不是“编译时”

标题里“装入时动态链接”这个概念，恰恰是区别这类方案和传统静态Hook方案的分水岭。

传统静态注入通常做法是：把目标DLL注入目标进程，在DllMain里用DetourAttach之类的库去改写某个目标函数的开头几个字节（inline hook），或者遍历目标模块的IAT去改槽位。这些方案的共同特点是：在函数被调用之前，抢先修改“调用者已经写好的地址”或“目标函数的机器码”。

而替换GetProcAddress这套方案，是在调用者正在“获取地址”的时刻动手。它不关心调用者后续怎么用这个指针，也不关心目标函数在哪个模块、有没有被重定位。它的拦截点位天然覆盖“动态链接现场”。对于那些在加载期通过导出序号找函数、通过转发导出（Forwarder）跨模块找函数等复杂情况，仍然能通过GetProcAddress这层拿到最终地址再做判断。

我在实际项目中更倾向于把GetProcAddress替换做成一个“平台层能力”，配合IAT Hook一起用，两条路径相互补齐。IAT Hook覆盖所有静态导入路径，GetProcAddress替换覆盖所有动态解析路径，两条路径合起来，对一个进程内的API调用才算做到了真正无死角监控。

3. 逐个注册函数的具体设计与实现

理解了原理，就到最费功夫的部分：怎么把“替换GetProcAddress”完整落地。如果你只是想验证效果，写一个固定替换CreateFileA的Demo并不难；但要做到“逐个注册、灵活启停、稳定不崩”，需要的是一套清晰的数据结构和完整的Hook生命周期管理。

3.1 设计目标：拦截点前置，注册表驱动

在动手写代码前，先把设计目标列清楚：

• 支持按“模块句柄+函数名”精确注册替换项，而不是一刀切替换所有API。
• 支持运行时动态注册、反注册，不需要重新注入或重启进程。
• 支持函数名和序号两种查找方式。
• 在未注册命中的情况下，必须走原逻辑，性能损耗尽可能低。

基于这些目标，我采用“注册表驱动”的模式：准备一张全局表，里面登记了“我关心的模块、函数名、替换函数地址”。跳板函数拿到参数后，先调用原始的GetProcAddress得到真实地址（这一步不能省，因为我们自己也需要真实的函数地址来做判断），然后在注册表里查一下这次请求是否符合注册项，符合就直接返回注册的替换地址。

这个设计里有个敲黑板的细节：跳板函数必须先调用原GetProcAddress。不能自己写一个查找导出表的逻辑，因为你是在拦截GetProcAddress，如果拦截逻辑本身不完整，遇到转发导出、API集重定向、带序号的导出等情况，很容易出问题。直接调用原函数，借用系统的完整能力拿到真实地址，然后只做“要不要替换结果”的判断，稳妥得多。

3.2 注册表与核心数据结构

结构体方面，我实际用的是下面这套设计：

typedef struct _FUNC_OVERRIDE_ENTRY { HMODULE hModule; // 目标模块句柄，NULL表示匹配所有模块 char szFuncName[64]; // 目标函数名，为空且uOrdinal非0时按序号匹配 WORD uOrdinal; // 目标导出序号，0表示按名称匹配 FARPROC pfnOverride; // 替换函数地址 FARPROC pfnOriginal; // 原函数地址（由原GetProcAddress返回） struct _FUNC_OVERRIDE_ENTRY* pNext; } FUNC_OVERRIDE_ENTRY;

用链表组织，每个节点就是一个“注册项”。为什么用链表而不是定长数组？因为注册项的数量在运行时是动态变化的，链表方便频繁增删，而且遍历开销在这里完全可接受（一般最多几十个注册项）。

再来是Hook本身的状态管理：

typedef struct _GPA_HOOK_CONTEXT { FARPROC pfnOriginalGetProcAddress; // hook前保存的原GetProcAddress CRITICAL_SECTION csLock; // 保护注册表链表的锁 FUNC_OVERRIDE_ENTRY* pOverrideList; // 注册表链表头 BOOL bHookInstalled; } GPA_HOOK_CONTEXT;

注意pfnOriginalGetProcAddress这个字段：它是在Hook安装前，直接通过导出表拿到的原始函数指针。任何时候调用它都绕过EAT，不会递归进我们的跳板。这是整个方案不会死循环的生命线。

3.3 跳板函数：一次调用，两次查找

核心跳板函数长这样：

FARPROC WINAPI Hook_GetProcAddress(HMODULE hModule, LPCSTR lpProcName) { GPA_HOOK_CONTEXT* ctx = GetGlobalContext(); FARPROC pResult = NULL; // 先调用原函数，获取真实函数地址 pResult = ctx->pfnOriginalGetProcAddress(hModule, lpProcName); // 对lpProcName做快速判断：为空或宏值则直接返回 if (NULL == lpProcName || ((ULONG_PTR)lpProcName & 0xFFFF0000) == 0) { // 序号导出，按序号匹配 WORD ord = (WORD)((ULONG_PTR)lpProcName & 0xFFFF); return MatchAndOverrideByOrdinal(ctx, hModule, ord, pResult); } // 名称导出，按函数名匹配 return MatchAndOverrideByName(ctx, hModule, lpProcName, pResult); }

GetProcAddress的第二个参数lpProcName有两种传法：传字符串指针表示要查函数名，传一个被宏MAKEINTRESOURCE包装过的低位序号值表示要查导出序号。判断方式就是看lpProcName的高16位是否为零，为零说明这是个序号（实际上标准做法是HIWORD(lpProcName) == 0，但要小心字符串指针恰好落在低位地址空间的极端情况，加了0xFFFF0000掩码判断更稳）。

在MatchAndOverrideByName里，核心逻辑是遍历注册链表，比对模块句柄和函数名，命中了就返回注册的替换地址：

static FARPROC MatchAndOverrideByName(GPA_HOOK_CONTEXT* ctx, HMODULE hModule, LPCSTR lpProcName, FARPROC pResult) { FUNC_OVERRIDE_ENTRY* pNode = NULL; if (NULL == pResult) { // 原函数都没找到，没必要替换，直接返回NULL return NULL; } EnterCriticalSection(&ctx->csLock); pNode = ctx->pOverrideList; while (pNode) { if (pNode->hModule == hModule && pNode->szFuncName[0] != '\0' && _stricmp(pNode->szFuncName, lpProcName) == 0) { // 命中注册项：保存原地址，返回替换地址 pNode->pfnOriginal = pResult; LeaveCriticalSection(&ctx->csLock); return pNode->pfnOverride; } pNode = pNode->pNext; } LeaveCriticalSection(&ctx->csLock); // 未命中注册项，返回原函数地址，行为与原始GetProcAddress一致 return pResult; }

这里有个容易忽略的设计细节：pfnOriginal字段是每次命中时动态更新，而不是注册时静态保存的。为什么要这样？因为有些模块是运行时反复加载卸载的，模块基址可能每次都不同。如果注册时就把pfnOriginal固定下来，模块重载后原地址就失效了。动态更新的做法则保证每次总能拿到当前生效的原函数地址。

3.4 安装Hook：改kernel32导出表

安装动作实质上是修改kernel32.dll导出表里GetProcAddress这一项的值。步骤拆开是这样的：

1. 找到kernel32.dll的模块基址（GetModuleHandleA("kernel32.dll")，注意它永远在进程里）。
2. 解析它的DOS头、NT头、导出目录，定位EAT和导出名称表。
3. 在导出名称表中找到GetProcAddress这个字符串对应的索引，再用索引去EAT里取当前函数地址。
4. 把当前地址保存到pfnOriginalGetProcAddress。
5. 用VirtualProtect把EAT所在页改成可写，把该项地址替换为Hook_GetProcAddress。
6. 恢复页面保护属性。

核心代码：

BOOL InstallGetProcAddressHook(GPA_HOOK_CONTEXT* ctx) { HMODULE hKernel32 = GetModuleHandleA("kernel32.dll"); PIMAGE_DOS_HEADER pDos = (PIMAGE_DOS_HEADER)hKernel32; PIMAGE_NT_HEADERS pNt = (PIMAGE_NT_HEADERS)((BYTE*)hKernel32 + pDos->e_lfanew); PIMAGE_EXPORT_DIRECTORY pExport = NULL; DWORD* pAddressOfFunctions = NULL; WORD* pAddressOfNameOrdinals = NULL; DWORD* pAddressOfNames = NULL; DWORD nNames = 0; DWORD i = 0; DWORD dwOldProtect = 0; pExport = (PIMAGE_EXPORT_DIRECTORY)((BYTE*)hKernel32 + pNt->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT].VirtualAddress); pAddressOfFunctions = (DWORD*)((BYTE*)hKernel32 + pExport->AddressOfFunctions); pAddressOfNameOrdinals = (WORD*)((BYTE*)hKernel32 + pExport->AddressOfNameOrdinals); pAddressOfNames = (DWORD*)((BYTE*)hKernel32 + pExport->AddressOfNames); nNames = pExport->NumberOfNames; // 查找GetProcAddress的导出索引 for (i = 0; i < nNames; i++) { const char* name = (const char*)hKernel32 + pAddressOfNames[i]; if (strcmp(name, "GetProcAddress") == 0) { WORD idx = pAddressOfNameOrdinals[i]; FARPROC pFn = (FARPROC)((BYTE*)hKernel32 + pAddressOfFunctions[idx]); ctx->pfnOriginalGetProcAddress = pFn; // 改写EAT中的函数地址 VirtualProtect(&pAddressOfFunctions[idx], sizeof(DWORD), PAGE_READWRITE, &dwOldProtect); pAddressOfFunctions[idx] = (DWORD)((BYTE*)Hook_GetProcAddress - (BYTE*)hKernel32); VirtualProtect(&pAddressOfFunctions[idx], sizeof(DWORD), dwOldProtect, &dwOldProtect); ctx->bHookInstalled = TRUE; return TRUE; } } return FALSE; }

代码里pAddressOfFunctions[idx]存的是RVA，所以要写Hook_GetProcAddress的RVA，不能直接写绝对地址。这是EAT Hook最容易被新手忽略的点——IAT里存的是绝对VA，而EAT里存的是RVA。写错了系统直接崩溃。

还应注意：VirtualProtect改的那一页是kernel32的导出表页，属于映像映射页。32位下这个操作一般没问题，64位下同样可以做，但需要考虑CFG（控制流保护）的影响。如果目标进程开启了CFG，直接修改导出表可能导致跳板调用被CFG拦截，这个问题我在第四节详细说。

3.5 注册与反注册API

提供给上层使用的注册函数：

BOOL RegisterFunctionOverride( HMODULE hModule, LPCSTR lpFuncName, FARPROC pfnOverride) { GPA_HOOK_CONTEXT* ctx = GetGlobalContext(); FUNC_OVERRIDE_ENTRY* pNode = NULL; if (NULL == lpFuncName || NULL == pfnOverride) { return FALSE; } pNode = (FUNC_OVERRIDE_ENTRY*)malloc(sizeof(FUNC_OVERRIDE_ENTRY)); if (NULL == pNode) { return FALSE; } memset(pNode, 0, sizeof(FUNC_OVERRIDE_ENTRY)); pNode->hModule = hModule; strncpy(pNode->szFuncName, lpFuncName, sizeof(pNode->szFuncName) - 1); pNode->pfnOverride = pfnOverride; EnterCriticalSection(&ctx->csLock); pNode->pNext = ctx->pOverrideList; ctx->pOverrideList = pNode; LeaveCriticalSection(&ctx->csLock); return TRUE; }

插入到链表头部，时间复杂度O(1)。因为跳板函数里每次调用都要遍历链表，注册项多了会心疼，但实际场景下一般控制在几十个以内，遍历成本可忽略。

反注册稍微麻烦一点，要遍历链表找到匹配节点并摘除：

BOOL UnregisterFunctionOverride(HMODULE hModule, LPCSTR lpFuncName) { GPA_HOOK_CONTEXT* ctx = GetGlobalContext(); FUNC_OVERRIDE_ENTRY* pPrev = NULL; FUNC_OVERRIDE_ENTRY* pCur = NULL; EnterCriticalSection(&ctx->csLock); pCur = ctx->pOverrideList; while (pCur) { if (pCur->hModule == hModule && _stricmp(pCur->szFuncName, lpFuncName) == 0) { if (pPrev) { pPrev->pNext = pCur->pNext; } else { ctx->pOverrideList = pCur->pNext; } LeaveCriticalSection(&ctx->csLock); free(pCur); return TRUE; } pPrev = pCur; pCur = pCur->pNext; } LeaveCriticalSection(&ctx->csLock); return FALSE; }

这段逻辑本身不复杂，但要注意一个细节：跳板函数在遍历链表时是持有锁的，所以反注册不能在跳板函数的调用栈深处去执行，否则会造成死锁。实际使用中我一般要求注册/反注册操作在主控线程或专门的Hook管理线程里发起，不要在回调函数里直接调。

4. 注册项管理与替换命中细节

第3节的代码能跑通基本流程，但要真正稳定可靠，还有很多“细节中的魔鬼”要处理。这一节把我在实际调试中遇到过的、以及阅读其他开源项目时注意到的关键问题集中梳理一遍。

4.1 模块句柄的坑：LoadLibrary返回值和GetModuleHandle不一定相同

注册函数接收的hModule参数，看起来很简单，实际坑得很。同一个DLL，通过LoadLibraryA("C:\\Path\\X.dll")拿到的模块基址，和通过GetModuleHandleA("X.dll")拿到的模块基址，在绝大多数情况下是一样（都是模块在进程中的基址），但注意：

• LoadLibraryEx有特殊标志（如LOAD_LIBRARY_AS_DATAFILE、LOAD_LIBRARY_AS_IMAGE_RESOURCE），返回的“句柄”未必是真正可执行映像的基址。
• 同一个DLL有多个副本（A.dll依赖不同路径的B.dll），用名称取句柄可能取到错误的模块。
• 模块被卸载又重新加载之后，基址可能变了，但之前注册时保存的hModule还是旧值。

这也是我在注册表结构里通常建议同时存hModule和模块名的原因。匹配时可以优先精确比对句柄，句柄对不上再用模块名做二次匹配。不过为了控制文章篇幅，这里只保留句柄精确匹配，实际项目里可以自行扩展。

4.2 序号导出：GetProcAddress的冷门用法

关于序号导出，很多人有个误解，觉得反正现在写的DLL都导出函数名，序号用得少了。但实际上：

• 老版本的系统DLL和第三方商用DLL，不少仍用序号导出（给函数名只是为了调试方便）。
• GetProcAddress(hModule, (LPCSTR)MAKEINTRESOURCE(ordinal))这种调用方式，在框架代码、兼容层里很常见。
• 注册表方案如果只处理函数名，遇到序号导出就只能干瞪眼。

所以跳板函数里对lpProcName的高16位判断是必备的。匹配序号时注意，注册项里要区分“按名注册”和“按序号注册”，我建议加一个UINT uSearchFlag来标记，避免szFuncName为空、uOrdinal又碰巧是0导致的歧义。

4.3 大小写敏感与函数名归一化

GetProcAddress在系统内部查找导出表时，用的是二分查找，且函数名比较是大小写敏感的（PE导出表本身就是大小写敏感的）。但如何匹配我们自己的注册表，我遇到过不同的项目有过不同取舍。

实测中，有些第三方模块调GetProcAddress时，明明导出表里函数名是CreateFileA，调用方却传了createfilea。这种情况下原GetProcAddress的行为是返回NULL（找不到），所以我们的跳板函数也应该返回NULL。但如果注册项里用了_stricmp做大小写不敏感匹配，并且我们恰好注册了这个函数，就会把“本来会失败”的调用变成“成功返回替换函数”——行为不一致，可能导致调用方后续逻辑出错。

所以我建议：注册表匹配用大小写敏感的strcmp，跟系统行为保持一致。个别需要宽松匹配的场景，单独加标记字段处理，不要全局放开。

4.4 转发导出（Forwarder）问题

转发导出是指一个DLL的导出项并不直接提供代码，而是指向另一个DLL里的函数。比如kernel32.dll的很多API实际转发到kernelbase.dll（如HeapAlloc）或api-ms-win-core-*系列。

那么问题来了：如果调用方GetProcAddress(kernel32, "HeapAlloc")，我们的跳板函数调用原GetProcAddress，它会怎么处理？系统实现会识别转发导出，解析到最终目标模块（通常是kernelbase）的真实地址，返回给调用方。这个地址已经不是kernel32.dll的地址范围了，指向kernelbase.dll的EAT。

所以如果我们的注册项写的是hModule=kernel32, szFuncName="HeapAlloc"，而我们对hModule做了精确匹配，那么当调用方传入的hModule是GetModuleHandleA("kernelbase.dll")时，同样请求HeapAlloc，注册表就匹配不上。

这里需要明确目标：你是想“替换某个函数名在某个模块的调用”，还是想“替换某个函数在所有模块的调用”。如果是前者，保留模块句柄精确匹配；如果是后者，注册时hModule传NULL，匹配逻辑里允许NULL通配即可。我项目里使用的就是NULL通配方案，灵活度更高。

4.5 跳板函数里的“结果校验”与“二次查询”

前面说跳板函数要先调用原GetProcAddress拿到pResult，再根据注册表决定是否替换。但这带来一个性能问题：即使注册表里什么都没命中，每次调用GetProcAddress也额外多了一次链表遍历。对于大量动态解析的场景（比如解释器、脚本引擎），这个开销会被放大。

我的优化方案：跳板函数入口处先判断ctx->pOverrideList是否为空。为空说明没有任何注册项，直接返回原GetProcAddress的调用结果，不用进入加锁、遍历逻辑。再加一层：在MatchAndOverrideByName里，先比对模块句柄，句柄不匹配直接跳过该节点，不做字符串比较——因为_stricmp相对昂贵，而句柄比较只是整数比较。这两个优化加上后，空载情况下的性能损耗基本可以忽略。

注册项命中的场景，还涉及一个“二次查询”的设计：有时你注册的替换函数需要调用“真正的原函数”，这时候怎么办？比如你替换了CreateFileA，你的替换函数内部又要调用真正的CreateFileA。如果你在替换函数里直接调CreateFileA，它又会被IAT解析到替换地址，形成无限递归。

解决办法很经典：跳板函数在命中注册项、返回替换地址之前，把真实地址写回注册项的pfnOriginal字段。替换函数内部要调用原函数时，通过注册表查询拿pfnOriginal字段的地址来调用。近似于把所有被替换函数的原始地址都保存在一个统一的“查找表”里。

// 替换函数内部获取原函数指针 FARPROC GetOriginalFunction(const char* name) { return LookupOriginalAddr(name); // 遍历注册表返回pfnOriginal }

但这个设计有一个使用上的注意点：GetProcAddress调用是全局的，如果两个不同的调用方都GetProcAddress同一个函数，且在跳板函数里都更新了各自对应的某个注册项，而后一个调用覆盖了前一个的pfnOriginal字段，可能导致前一个调用方拿到的原函数地址不是最准的。不过实测中，同一个函数在同一个模块内的地址是稳定不变的（ASLR针对的是模块整体，不是单个导出项），所以pfnOriginal无论被哪个调用触发更新，值都是一样的，竞争问题也就不是问题了。

5. 稳定性实测与典型问题清单

代码写好了，注册表也架起来了，不等于方案就能落地。我在这套方案的调试过程中被坑得有段时间甚至想放弃换用成熟Hook库，最后一步步排查才稳定下来。把典型的坑和验证方法总结如下。

5.1 递归死循环：改完EAT后遗症

最大的坑是递归。

我们修改了kernel32的EAT，把GetProcAddress指向了跳板函数。跳板函数内部调ctx->pfnOriginalGetProcAddress，这个指针是Hook前保存的，调用它不会经过EAT，所以这一条链是安全的。但是，ctx->pfnOriginalGetProcAddress指向的原始GetProcAddress内部会调用其他辅助函数，而那些辅助函数如果又反过来调GetProcAddress呢？

实际上kernelbase里GetProcAddress的核心逻辑LdrGetProcedureAddress，在解析过程中可能会涉及LdrpLoadDll（当目标模块没有加载时）或者API集重定向，这些路径内部理论上不会再调GetProcAddress来拿GetProcAddress的地址（它们通常直接用内部结构体指针）。所以多数情况下不会递归。

真正的递归风险来自另一个地方：跳板函数内部如果调用了任何经过动态解析或IAT跳转的Win32 API，而那个API又被我们的Hook间接影响。为了规避这个风险，我建议跳板函数内部：

• 不要调用OutputDebugStringA等需要查询导出表的函数。
• 不要分配堆内存（malloc内部走RtlAllocateHeap，一般没事，但minimal最好）。
• 使用InterlockedCompareExchangePointer级别的原子操作做简单状态判断，避免加锁。

但我上面的实现用了EnterCriticalSection，这是因为注册表在运行时要有增删操作，不做锁就会有数据竞争。实测下来EnterCriticalSection在无竞争时开销极低（几十ns量级），且它走ntdll内部，不会碰GetProcAddress，安全可用。如果你对性能有极致要求，可以改成SRWLOCK或者无锁链表，代价是代码复杂度上升。

5.2 进程初始化早期的“黄金窗口”

这套Hook什么时候安装，直接决定覆盖范围。

进程启动早期，系统会加载一个“最小工作集”——ntdll、kernel32、kernelbase，再加上进程主模块。如果我们的Hook模块依赖其他DLL（比如你写的DLL链接了user32.dll或advapi32.dll），那Hook的安装时机就得等这些依赖加载完，否则我们的DllMain里调用GetModuleHandle之类的操作会提前加载一堆模块，把进程的内存布局搞得乱七八糟。

实测中，在DllMain的DLL_PROCESS_ATTACH里做EAT Hook成功率很高，但要做的工作尽量少——只做最核心的：保存原函数指针、改EAT、初始化注册表链表。注册具体函数项放在DllMain之后由主控逻辑做。

还有一个经验：如果目标进程有早于DllMain的初始化路径（比如Go程序的启动顺序与C程序差异大），Hook可能会错过最早期的动态链接调用。这种情况下，用SetWindowsHookEx、AppInit_DLLs或者直接注入的方式，都各有各的时机问题，需要结合目标场景测试决定。我的经验法则是：宁可晚装，不要乱装。晚装只是漏掉早期解析，乱装可能直接导致进程启动崩溃。

5.3 CFG（控制流保护）与64位下的异常

在64位目标进程里做EAT Hook，最麻烦的是CFG。

Windows 10 1809以后，系统进程和很多现代应用默认开启CFG。CFG会在间接调用点检查目标地址是否合法（是否在已标记的可调用地址集合里）。我们改掉EAT里的GetProcAddress地址后，任何模块通过call GetProcAddress时，因为地址值变了，可能触发CFG检查失败，导致调用直接被终止。

解决思路有几种：

1. 目标函数的地址值是合法的（在模块的代码段内），那么即使换成跳板函数，跳板函数本身也必须满足CFG校验——如果跳板地址没有被加入CFG的合法位图，仍会失败。
2. 关掉CFG只能通过链接选项影响自己编译的模块，无法影响目标进程。
3. 用一个已经存在于合法位图里的跳板：实际工程中有人会把跳板写在ntdll或kernel32里的已知函数起始处，牺牲一个永不使用的函数。但这个方法侵入性太强，我没采用。

我当前处理方案相对保守：在64位且开启CFG的目标进程里，如果只是要在自己的注入模块内部用替换功能，我会限制跳板被外部模块调用——具体做法是不改EAT本身，而是通过LdrRegisterDllNotification监视模块加载，模块加载后改它IAT里的GetProcAddress条目（如果有）。局部IAT替换完全绕开CFG问题，只是覆盖范围从“全进程”缩小到“指定模块”。如果你的目标是全局监控，CFG敏感环境建议使用微软Detours或MinHook这类成熟库，它们有专门的CFG兼容策略，我在后面对比时会再提。

5.4 与成熟Hook库的对比：什么时候应该用库

这里必须客观说一句：动手写这套方案之前，先评估是不是可以直接用MinHook、Detours、mhook这类现成库。

这些库的主要优势是：处理了inline hook的指令重定位等大量边界情况，支持x86/x64/ARM，有的还专门处理了CFG。但它们默认的Hook目标是“某个函数的入口代码”，要拦GetProcAddress并替换返回值，MinHook也能装（inline hook GetProcAddress入口），但有几个局限：

• inline hook会改变目标函数入口几个字节的机器码，如果目标进程里有代码对kernel32内容做完整性校验（很多安全软件会做），会触发告警。
• EAT Hook只是改一个指针值，对kernel32的代码段零改动，相对更隐蔽，触发完整性校验的概率低。
• 用MinHook hook GetProcAddress后，替换逻辑仍然要自己写（就是那个“先调原函数再决定返回值”的跳板），核心的注册表、匹配逻辑跟你自己动手实现没区别。

所以在我的技术选型标准里：

5.5 实测数据与验证方法

最后放一组我自己环境下的实测数据供参考（Windows 10 22H2 x64，Intel i7-10750H，测试进程为C++编写的控制台程序）：

• 注册表为空时，每次GetProcAddress调用额外耗时约为15~25ns（主要是一次空指针判断+一次锁）。
• 注册表有30个注册项、每次调用未命中时，额外耗时约200~400ns（遍历链表+字符串比较）。
• 注册表命中的调用，额外耗时约50~100ns（多了一次指针返回）。

验证Hook是否生效，我用的是一套自写的“探针模块”：目标进程加载一个测试DLL，DLL调用自定义函数（用LoadLibrary+GetProcAddress获取地址），主控模块注册替换该函数，然后观察调用结果是否被重定向。

测试样例：

// 测试DLL里定义一个导出函数 extern "C" __declspec(dllexport) int TestAdd(int a, int b) { return a + b; } // 主控模块里定义替换函数 static int WINAPI FakeTestAdd(int a, int b) { return (a + b) * 100; // 故意放大，便于观察 }

注册RegisterFunctionOverride(GetModuleHandleA("test.dll"), "TestAdd", (FARPROC)FakeTestAdd)，然后触发一次GetProcAddress调用，如果返回值变成了FakeTestAdd，且调用结果变成放大后的值，说明整条链路工作正常。

这个验证方法看起来简单，实际操作中十分必要。不要上来就接复杂业务，先用最小验证确认Hook链路本身的正确性，再逐步扩展。

6. 扩展思考：从“替换函数”到“调用审计”的进阶玩法

基础方案跑通之后，你会发现替换GetProcAddress只是打开了一扇门。在此基础上我做过的两个实用扩展，分享出来供参考。

6.1 调用参数审计与返回值监控

替换函数不仅能改变行为，还能完整记录调用参数和返回值。比如想审计某第三方DLL到底怎么调用RegOpenKeyExA：注册一个替换函数，内部先记录参数，再调用原函数，记录返回值，最后把日志写到环形缓冲区。这样能还原出第三方模块的全部注册表操作行为。

这个玩法在兼容层调试时价值极大。之前接一个上古时代的商业组件，它在初始化时反复读某个注册表项，旧系统上能读到，新系统上读不到，一直查不出原因。用GetProcAddress替换+参数审计，一眼就看到它读的注册表路径拼写错误，问题即刻定位。

6.2 免改IAT的动态Mock与测试替身

在自动化测试场景，经常需要模拟某个外部DLL返回特定结果。传统做法是改测试机环境、或者注入工程专用Mock DLL。有了GetProcAddress替换机制，你可以在测试框架启动时动态注册一批Mock函数，测试用例运行期间所有动态解析都走Mock，跑完再反注册恢复原状。

相比改环境、改文件这种重操作，这属于纯内存态Mock，不落盘、不进注册表、不污染环境，对CI流水线特别友好。不过要强调一点：这种Mock方式对静态导入路径无效（静态导入走IAT，提前绑定了），需要与IAT Hook配合才能做到全覆盖。

6.3 与IAT Hook的组合拳

我最终的架构是双通道：

• IAT Hook负责“模块加载后，静态导入的调用”。
• GetProcAddress替换负责“运行时动态解析的调用”。

两个通道都汇总到同一个“函数覆盖注册表”里。新增一个需要替换的函数时，先注册到注册表，再遍历已加载模块的IAT做替换；后续新加载的模块在加载回调里也做同样的IAT处理。同时动态解析路径天然被GetProcAddress跳板覆盖。三条路径（静态已加载、静态未加载、动态任意时刻）合起来，才算一个完整的Hook体系。

这个组合拳代码量比单通道大不少，但收益也明显：你在业务层就再也不需要关心“这个目标是通过什么方式被链接的”，所有的替换注册都无差别生效。从工程角度讲，把调用路径差异收敛到基础设施层，是这套方案最值得复用的设计思想。