EAT Hook是通过修改DLL导出地址表（EAT）中函数RVA，将调用方获取的导出函数地址劫持为自定义函数的技术；它仅对显式链接并从EAT中解析地址的调用有效，如MessageBoxA、LoadLibraryA等导出函数，不适用于未导出函数或隐式调用。
什么是EAT Hook，它能拦截哪些API
EAT Hook 是通过修改目标模块的导出地址表（Export Address Table）中函数地址，把原始函数指针替换成自定义函数指针的技术。它只对被目标模块显式导入并调用的导出函数有效，比如 kernel32.dll 中的 LoadLibraryA、VirtualAlloc，或第三方库如 user32.dll 的 MessageBoxA。
但它无法拦截未导出的函数（例如 ntdll.dll 中未出现在 EAT 里的 NtCreateThreadEx），也不能拦截直接通过 GetProcAddress 动态获取地址后调用的函数——除非你同时 hook 了 GetProcAddress 本身。EAT Hook 的本质是“劫持调用方看到的符号地址”，不是内存级指令拦截。
如何定位并修改目标模块的EAT
关键步骤是：解析 PE 结构 → 找到导出目录 → 定位 AddressOfFunctions 数组 → 替换对应函数的 RVA 地址。注意以下几点：
- 必须在目标模块已加载、且其 PE 映像处于可写状态时操作（通常需先调用
VirtualProtect修改页保护） - 导出函数索引不等于序号（ordinal）；应通过
AddressOfNames和AddressOfNameOrdinals查找函数名对应的真实索引 - 若目标模块是 ASLR 启用的（默认），其基址是随机的，所有 RVA 需加上实际加载基址（
HMODULE值）才能得到真实地址 - 修改前建议保存原始地址，便于后续恢复或转发调用
// 简化示意：替换 kernel32!CreateFileA FARPROC orig_CreateFileA = nullptr; DWORD oldProtect; VirtualProtect(pEATEntry, sizeof(DWORD), PAGE_READWRITE, &oldProtect); orig_CreateFileA = (FARPROC)(baseAddr + *pEATEntry); *pEATEntry = (DWORD)((BYTE*)my_CreateFileA - baseAddr); VirtualProtect(pEATEntry, sizeof(DWORD), oldProtect, &oldProtect);
为什么EAT Hook在现代系统上容易失效
- Windows 10 1809+ 默认启用 CFG（Control Flow Guard），会校验间接调用目标是否为合法函数入口；直接跳转到你自己分配的页（如堆/栈上的 hook 函数）会被拦截，触发异常
- 某些安全软件或 EDR 会监控
VirtualProtect、WriteProcessMemory 等 API，或扫描模块内存中非预期的代码页，触发告警甚至终止进程
- 如果目标进程启用了 ACG（Arbitrary Code Guard）或 HVCI（Hypervisor-protected Code Integrity），用户态下根本无法将内存设为可执行（
PAGE_EXECUTE_READWRITE），EAT Hook 的跳转目标无法运行
- 多线程环境下，若未同步控制（如用
SRWLock 或临界区），可能在替换过程中有线程刚好读取到半更新的地址，导致崩溃
替代方案比硬刚EAT更实用
VirtualProtect、WriteProcessMemory 等 API，或扫描模块内存中非预期的代码页，触发告警甚至终止进程PAGE_EXECUTE_READWRITE），EAT Hook 的跳转目标无法运行SRWLock 或临界区），可能在替换过程中有线程刚好读取到半更新的地址，导致崩溃真正想拦截“未导出 API”，比如 ntdll.dll 中的 NtProtectVirtualMemory，EAT Hook 不适用（它压根不在 ntdll 的导出表里）。此时应考虑：
立即学习“C++免费学习笔记（深入）”；
- 使用
DetourAttach（Microsoft Detours）或 MinHook 进行 inline hook：直接 patch 函数开头几字节为跳转指令 - hook
LdrLoadDll或LdrGetProcedureAddress，在模块加载/函数解析时注入逻辑 - 对于驱动级需求，用内核回调（如
PsSetCreateProcessNotifyRoutine）配合用户态通信，而非死磕用户态 EAT - 如果只是调试/分析用途，优先用 ETW 或 DbgEng 接口，避免修改内存带来的稳定性风险
EAT Hook 的适用边界很窄：仅限你清楚知道目标模块导入了哪个导出函数，且该模块没有启用 CFG/ACG/HVCI。一旦条件不满足，强行 patch EAT 表只会让程序 crash 或被拦截，而不是静默生效。
