深入解析DLL注入：原理、C++实现与攻防实战-拓冰建站

1. 项目概述：DLL注入的攻防世界

在Windows平台的安全研究、软件调试乃至游戏外挂开发领域，DLL注入是一项基础且关键的技术。它允许你将一个动态链接库（DLL）加载到另一个正在运行的进程的地址空间中，从而能够“窥探”或“操控”目标进程的行为。听起来有点像电影里的“意识入侵”，对吧？实际上，它的技术本质是进程间通信和内存操作的一种高级形式。我接触这项技术已经超过十年，从早期的游戏辅助分析到后来的安全产品研发，DLL注入既是攻击者的利器，也是防御者必须深刻理解的标靶。本次，我将从一个资深C++开发者的视角，彻底拆解DLL注入的原理、用C++一步步实现它，并深入探讨如何从防御端识别和对抗这种技术。无论你是对逆向工程感兴趣的安全爱好者，还是需要实现插件化架构的软件工程师，理解DLL注入都将为你打开一扇新的大门。

2. DLL注入的核心原理与关键API

2.1 什么是DLL注入？为什么需要它？

DLL（Dynamic Link Library）是Windows系统的基石，多个程序可以共享同一个DLL代码，节省内存。DLL注入，顾名思义，就是强制将一个DLL文件加载到目标进程的地址空间里。一旦注入成功，你的DLL代码就与目标进程“同生共死”，运行在相同的权限和内存上下文中。这带来了巨大的能力：你可以Hook API调用、修改游戏内存数据、监控程序行为、实现无痕的插件系统，或者进行恶意代码的驻留。

从技术需求上看，注入通常出于几个目的：一是调试与逆向分析，通过注入的DLL来拦截函数调用、记录参数；二是功能扩展，比如为某个不支持插件的软件增加插件功能；三是安全研究，模拟攻击行为以测试防御方案。当然，这项技术也常被恶意软件滥用，进行权限维持和窃密。因此，理解它，是构建有效防御的前提。

2.2 注入的核心原理：远程线程与内存写入

所有DLL注入技术的核心思想都绕不开两点：在目标进程内分配内存和在目标进程内创建线程执行代码。因为每个进程都有独立的虚拟地址空间，一个进程不能直接访问或执行另一个进程的内存。操作系统提供了特定的API来跨越这个鸿沟。

最经典、最稳定的方法是远程线程注入，它主要依赖于三个关键的Windows API：

OpenProcess：获取目标进程的句柄。你需要指定足够的权限（如PROCESS_CREATE_THREAD | PROCESS_VM_OPERATION | PROCESS_VM_WRITE）。
VirtualAllocEx：在目标进程的地址空间中分配一块内存。这块内存将用来存放你要加载的DLL的路径字符串。
WriteProcessMemory：将DLL的完整路径字符串写入到刚刚在目标进程中分配的内存块里。
GetProcAddress&GetModuleHandle：在你自己的进程中，获取LoadLibrary函数（位于kernel32.dll中）的地址。关键点来了：kernel32.dll在每个进程中的加载基址是相同的（在相同系统版本下），所以这个地址在目标进程中同样有效。
CreateRemoteThread：在目标进程中创建一个远程线程，并将该线程的入口点设置为LoadLibrary的地址，同时将参数设置为指向DLL路径字符串的内存地址。

当远程线程启动后，目标进程就会“乖乖地”调用它自己的LoadLibrary来加载你的DLL，DLL的DllMain入口函数随即被执行。整个过程，你的代码像是在目标进程内部“凭空”生成了一个加载DLL的意愿，非常巧妙。

注意：CreateRemoteThread是一个明显的注入特征，现代安全软件（如EDR）会高度监控这个API的调用，尤其是跨进程的调用。因此，在实际的对抗中，攻击者会寻求更隐蔽的方法，如APC注入、线程劫持等，但远程线程注入是理解所有变种的基础。

2.3 其他注入方法简介

除了远程线程注入，还有其他几种常见技术：

SetWindowsHookEx 钩子注入：通过设置全局Windows消息钩子，当目标线程处理特定消息时，系统会自动将钩子DLL加载到目标进程。这种方法依赖消息循环，对无窗口的进程可能无效。
APC（异步过程调用）注入：向目标进程中的线程的APC队列插入一个回调，当线程进入可报警状态时，会执行这个回调来加载DLL。这种方法更隐蔽，但需要目标线程配合。
反射式DLL注入：一种不依赖LoadLibrary的高级技术。注入者将DLL的二进制映像直接写入目标进程内存，并手动完成重定位、导入表解析等加载器的工作，最后直接跳转到DLL入口点。这种方法完全避开了文件系统和LoadLibrary的监控，隐蔽性极强，但实现复杂。

3. 使用C++实现远程线程DLL注入

理论讲得再多，不如一行代码。下面，我将手把手带你用C++实现一个完整的远程线程注入器。我会假设你已经有一个编译好的DLL文件（例如myhack.dll）和一个目标进程的ID（PID）。

3.1 环境准备与项目配置

首先，创建一个新的C++控制台项目。确保你的开发环境（如Visual Studio）支持Windows SDK。在项目属性中，将“字符集”设置为“使用多字节字符集”或“使用Unicode字符集”（对应TCHAR类型），本文示例使用多字节以简化。

核心代码只需要包含Windows头文件：

#include <windows.h> #include <tlhelp32.h> // 用于进程快照，查找PID #include <iostream>

3.2 关键API函数解析与封装

在编码前，我们再深入一下几个关键API的参数和细节，这是写出健壮代码的关键。

1. OpenProcess：权限是关键

HANDLE hProcess = OpenProcess( PROCESS_CREATE_THREAD | // 允许创建远程线程 PROCESS_VM_OPERATION | // 允许VirtualAllocEx/VirtualFreeEx PROCESS_VM_WRITE | // 允许WriteProcessMemory PROCESS_QUERY_INFORMATION, // 允许查询一些信息（非必须，但建议） FALSE, // 句柄不可继承 dwTargetPid // 目标进程ID );

如果OpenProcess失败，返回NULL，可以调用GetLastError()获取错误码。常见失败原因：权限不足（需要以管理员身份运行注入器）、进程不存在或PID错误。

2. VirtualAllocEx：在别人的地盘“圈地”

LPVOID pRemoteMemory = VirtualAllocEx( hProcess, // 目标进程句柄 NULL, // 由系统决定分配地址 MAX_PATH, // 分配内存大小，一个路径长度足够 MEM_COMMIT | MEM_RESERVE, // 分配类型 PAGE_READWRITE // 内存保护属性，需要可写 );

分配的内存地址是在目标进程的虚拟空间中的地址。记住这个地址pRemoteMemory，后续写入和创建线程都要用到它。

3. WriteProcessMemory：传递“密令”

BOOL bSuccess = WriteProcessMemory( hProcess, // 目标进程句柄 pRemoteMemory, // 目标进程中的内存地址 szDllFullPath, // 本地缓冲区，包含DLL完整路径 strlen(szDllFullPath) + 1, // 写入的字节数，包含字符串结束符'\0' NULL // 可选，返回实际写入字节数 );

这里有个坑：路径字符串必须是目标进程可访问的路径。如果DLL放在一个只有管理员才能读的目录，而目标进程是普通用户权限，那么即使注入成功，LoadLibrary也会失败。最好将DLL放在一个通用路径（如%TEMP%）或与目标进程同权限的目录。

4. CreateRemoteThread：点燃导火索

// 首先，获取LoadLibraryA的地址（我们使用多字节版本） HMODULE hKernel32 = GetModuleHandleA("kernel32.dll"); LPTHREAD_START_ROUTINE pLoadLibrary = (LPTHREAD_START_ROUTINE)GetProcAddress(hKernel32, "LoadLibraryA"); // 创建远程线程 HANDLE hRemoteThread = CreateRemoteThread( hProcess, // 目标进程句柄 NULL, // 默认安全属性 0, // 默认堆栈大小 pLoadLibrary, // 线程函数地址（LoadLibraryA） pRemoteMemory, // 线程参数（DLL路径地址） 0, // 创建标志，0表示立即执行 NULL // 接收线程ID );

成功创建后，远程线程就开始执行了。我们需要等待它执行完毕，以确定DLL是否加载成功。

WaitForSingleObject(hRemoteThread, INFINITE); // 可以检查线程退出码，它等于LoadLibrary返回的模块句柄（成功）或NULL（失败） DWORD exitCode; GetExitCodeThread(hRemoteThread, &exitCode); if (exitCode == NULL) { std::cerr << "DLL加载可能失败！" << std::endl; }

3.3 完整C++实现代码与逐行解析

下面是一个整合了错误处理和清理的完整示例。这个注入器会先通过进程名查找PID，然后执行注入。

#include <windows.h> #include <tlhelp32.h> #include <iostream> #include <string> // 根据进程名查找进程ID DWORD FindProcessId(const std::string& processName) { DWORD pid = 0; HANDLE snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0); if (snapshot == INVALID_HANDLE_VALUE) { std::cerr << "创建进程快照失败！错误码: " << GetLastError() << std::endl; return 0; } PROCESSENTRY32 pe32; pe32.dwSize = sizeof(PROCESSENTRY32); if (Process32First(snapshot, &pe32)) { do { if (_stricmp(pe32.szExeFile, processName.c_str()) == 0) { pid = pe32.th32ProcessID; break; } } while (Process32Next(snapshot, &pe32)); } else { std::cerr << "遍历进程失败！" << std::endl; } CloseHandle(snapshot); return pid; } // 主注入函数 bool InjectDll(DWORD pid, const char* dllPath) { // 1. 打开目标进程 HANDLE hProcess = OpenProcess( PROCESS_CREATE_THREAD | PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_QUERY_INFORMATION, FALSE, pid ); if (hProcess == NULL) { std::cerr << "打开进程失败！PID: " << pid << " 错误码: " << GetLastError() << std::endl; return false; } std::cout << "成功打开目标进程句柄。" << std::endl; // 2. 在目标进程中分配内存 size_t pathLen = strlen(dllPath) + 1; // +1 for null terminator LPVOID pRemoteMem = VirtualAllocEx(hProcess, NULL, pathLen, MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE); if (pRemoteMem == NULL) { std::cerr << "在目标进程分配内存失败！错误码: " << GetLastError() << std::endl; CloseHandle(hProcess); return false; } std::cout << "已在远程进程分配内存地址: 0x" << std::hex << pRemoteMem << std::dec << std::endl; // 3. 将DLL路径写入目标进程内存 SIZE_T bytesWritten; if (!WriteProcessMemory(hProcess, pRemoteMem, dllPath, pathLen, &bytesWritten)) { std::cerr << "写入远程进程内存失败！错误码: " << GetLastError() << std::endl; VirtualFreeEx(hProcess, pRemoteMem, 0, MEM_RELEASE); CloseHandle(hProcess); return false; } if (bytesWritten != pathLen) { std::cerr << "写入字节数不匹配！期望: " << pathLen << ", 实际: " << bytesWritten << std::endl; } else { std::cout << "成功写入DLL路径到远程内存。" << std::endl; } // 4. 获取LoadLibraryA函数地址 HMODULE hKernel32 = GetModuleHandleA("kernel32.dll"); if (hKernel32 == NULL) { std::cerr << "获取kernel32模块句柄失败！" << std::endl; VirtualFreeEx(hProcess, pRemoteMem, 0, MEM_RELEASE); CloseHandle(hProcess); return false; } LPTHREAD_START_ROUTINE pLoadLibrary = (LPTHREAD_START_ROUTINE)GetProcAddress(hKernel32, "LoadLibraryA"); if (pLoadLibrary == NULL) { std::cerr << "获取LoadLibraryA地址失败！" << std::endl; VirtualFreeEx(hProcess, pRemoteMem, 0, MEM_RELEASE); CloseHandle(hProcess); return false; } std::cout << "LoadLibraryA函数地址: 0x" << std::hex << pLoadLibrary << std::dec << std::endl; // 5. 创建远程线程，执行LoadLibraryA HANDLE hRemoteThread = CreateRemoteThread(hProcess, NULL, 0, pLoadLibrary, pRemoteMem, 0, NULL); if (hRemoteThread == NULL) { std::cerr << "创建远程线程失败！错误码: " << GetLastError() << std::endl; VirtualFreeEx(hProcess, pRemoteMem, 0, MEM_RELEASE); CloseHandle(hProcess); return false; } std::cout << "远程线程创建成功！" << std::endl; // 6. 等待远程线程结束（即DLL加载完成） WaitForSingleObject(hRemoteThread, INFINITE); // 7. 检查DLL是否加载成功 DWORD threadExitCode; if (!GetExitCodeThread(hRemoteThread, &threadExitCode)) { std::cerr << "获取线程退出码失败！" << std::endl; } else { if (threadExitCode != NULL) { std::cout << "DLL加载成功！模块句柄: 0x" << std::hex << threadExitCode << std::dec << std::endl; } else { std::cerr << "DLL加载失败！LoadLibrary返回NULL。" << std::endl; } } // 8. 清理资源 CloseHandle(hRemoteThread); // 注意：分配的内存(pRemoteMem)在DLL加载后通常不再需要，可以释放。 // 但有些DLL在DllMain卸载时可能需要这个路径，根据实际情况决定。 VirtualFreeEx(hProcess, pRemoteMem, 0, MEM_RELEASE); CloseHandle(hProcess); return (threadExitCode != NULL); } int main() { std::string targetProcess = "notepad.exe"; // 目标进程名 std::string dllFullPath = "C:\\path\\to\\your\\myhack.dll"; // 替换为你的DLL绝对路径 std::cout << "正在查找进程: " << targetProcess << std::endl; DWORD pid = FindProcessId(targetProcess); if (pid == 0) { std::cerr << "未找到进程: " << targetProcess << std::endl; return 1; } std::cout << "找到进程PID: " << pid << std::endl; if (InjectDll(pid, dllFullPath.c_str())) { std::cout << "注入成功！" << std::endl; } else { std::cerr << "注入失败！" << std::endl; return 1; } return 0; }

代码解析与实操要点：

错误处理：每个关键的API调用后都检查了返回值，这是生产级代码的基本素养。GetLastError()能提供失败的具体原因。
路径问题：dllFullPath必须是绝对路径，且目标进程有权限访问。相对路径是相对于目标进程的当前目录，通常是不可靠的。
内存清理：使用VirtualFreeEx释放了在目标进程中分配的内存。这是一个好习惯，避免内存泄漏。虽然目标进程退出后系统会回收所有资源，但及时清理是严谨的做法。
Unicode支持：本例使用LoadLibraryA（多字节）。如果你的DLL路径包含中文或需要更好的兼容性，应使用宽字符版本（LoadLibraryW），并将所有字符串和API切换为宽字符版本（wchar_t,GetModuleHandleW,GetProcAddress获取LoadLibraryW等）。
权限提升：如果目标进程是系统进程或受保护进程（如杀毒软件），即使以管理员身份运行，OpenProcess也可能失败，需要更高的权限（如SeDebugPrivilege）。这涉及权限调整，属于更高级的话题。

4. 从防御视角检测与对抗DLL注入

了解了如何攻击，才能更好地防御。作为开发者或安全工程师，如何发现和阻止自己的进程被注入呢？防御是分层的，从代码层面到系统监控。

4.1 代码层面的防御措施

在你的应用程序中，可以主动采取一些措施来增加注入难度。

1. 定期检查进程内模块在程序运行期间，定期枚举当前进程加载的所有DLL模块（使用EnumProcessModules），与一个合法的模块白名单进行比对。发现未知的、可疑的DLL（尤其是来自临时目录、路径奇怪的）时，可以记录日志或触发警报。

// 简化的模块枚举示例 HMODULE hModules[1024]; DWORD cbNeeded; if (EnumProcessModules(GetCurrentProcess(), hModules, sizeof(hModules), &cbNeeded)) { for (DWORD i = 0; i < (cbNeeded / sizeof(HMODULE)); i++) { TCHAR szModName[MAX_PATH]; if (GetModuleFileNameEx(GetCurrentProcess(), hModules[i], szModName, MAX_PATH)) { // 检查szModName是否在白名单内 // 如果不在，可能是被注入的DLL } } }

2. Hook 关键的加载函数通过微软的Detours库或类似技术，在自身进程内部HookLoadLibrary、LoadLibraryEx、LdrLoadDll（NTDLL层）等函数。在你的Hook函数中，可以检查要加载的DLL路径、签名或哈希，如果不符合策略，就拒绝加载。这是一种主动防御，但实现复杂，且可能影响稳定性。

3. 调用栈检测（Stack Walking）在DllMain或你认为敏感的函数入口处，检查调用栈。正常的DLL加载，其调用栈最终会追溯到kernel32!LoadLibrary或ntdll!LdrLoadDll。而某些注入技术（如反射注入）可能没有经过这些标准路径。通过RtlWalkFrameChain或DBGHelp库可以检查调用栈。如果发现调用栈异常简短或来源可疑，可能就是被注入了。

4.2 系统与监控层面的防御

对于安全软件或系统管理员而言，需要在全局层面进行监控。

1. 监控进程创建与远程线程创建使用Windows提供的ETW（Event Tracing for Windows）或内核回调（如PsSetCreateThreadNotifyRoutine）来监控系统中所有CreateRemoteThread的调用。记录下源进程、目标进程、线程起始地址等信息。如果发现一个非系统进程向另一个不相关的进程（如记事本向浏览器）创建远程线程，并且线程起始地址指向LoadLibrary，这就是一个高风险的注入行为。

2. 检测内存属性异常使用VirtualAllocEx分配内存并设置为可写可执行（PAGE_EXECUTE_READWRITE）是Shellcode注入的典型特征。防御系统可以监控内存属性的变更，特别是变更为可执行属性的操作。合法的程序很少会在运行时申请可执行的内存页。

3. 用户层钩子（User-mode Hooks）检测许多注入的DLL会通过Hook API（如SetWindowsHookEx、Detours）来拦截函数。安全软件可以定期检查关键API函数的前几个字节是否被修改（跳转指令），或者使用GetProcAddress获取的地址与从磁盘模块文件中解析出的地址是否一致，来发现用户层的钩子。

4. 行为沙箱与机器学习在端点安全产品中，将未知进程放入沙箱运行，观察其行为。如果它尝试对多个其他进程进行OpenProcess、VirtualAllocEx、CreateRemoteThread这一系列操作，机器学习模型可以将其标记为潜在的注入器。同时，监控进程加载的DLL是否具有合法的数字签名，也是常见的检测手段。

4.3 防御措施对比与选择

防御层面	具体方法	优点	缺点	适用场景
代码层面	模块白名单	实现相对简单，直接有效	维护白名单麻烦，可能误杀合法插件	对安全性要求高的客户端软件
代码层面	Hook加载函数	拦截点精准，可做复杂策略	技术难度高，易引发稳定性问题，可能被绕过	安全软件、加固后的核心进程
代码层面	调用栈检测	能发现非标准加载路径	有一定性能开销，高级注入可伪造调用栈	关键函数入口的补充检测
系统监控	ETW/内核回调	全局监控，难以绕过	需要驱动或高级权限，分析数据量大	终端检测与响应（EDR）系统
系统监控	内存属性监控	能发现Shellcode注入	误报可能较高（JIT编译等也会用）	作为EDR的检测特征之一
行为分析	沙箱与ML	能发现未知威胁，泛化能力强	需要大量样本训练，有性能开销	下一代防病毒（NGAV）产品

在实际防御中，没有银弹。通常采用纵深防御策略：在自身代码中实现基础检查（如模块枚举），同时依赖系统级的安全产品（如EDR）进行更深度的行为监控和威胁狩猎。对于普通开发者，做好模块签名验证、避免进程以过高权限运行、及时更新依赖库修补漏洞，就能抵御大部分自动化攻击。

5. 常见问题与实战排查技巧

在实现和对抗DLL注入的过程中，你会遇到各种各样的问题。这里我整理了一份“踩坑实录”，希望能帮你少走弯路。

5.1 注入过程常见错误与解决

问题1：OpenProcess失败，错误码5（拒绝访问）。

原因：权限不足。目标进程可能是系统进程、受保护进程（PPL），或者你的注入器不是以管理员身份运行。

解决：

以管理员身份运行你的注入器。

如果目标是受保护进程，普通管理员权限也可能不够，需要启用SeDebugPrivilege特权。代码如下：

BOOL EnableDebugPrivilege() { HANDLE hToken; if (!OpenProcessToken(GetCurrentProcess(), TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY, &hToken)) return FALSE; TOKEN_PRIVILEGES tp; tp.PrivilegeCount = 1; LookupPrivilegeValue(NULL, SE_DEBUG_NAME, &tp.Privileges[0].Luid); tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED; BOOL result = AdjustTokenPrivileges(hToken, FALSE, &tp, sizeof(tp), NULL, NULL); CloseHandle(hToken); return result && (GetLastError() == ERROR_SUCCESS); }

在main函数开头调用此函数。注意，即使在Windows 10/11上，对某些受PsProtectedSigner保护的进程，启用调试权限也可能无效。

问题2：CreateRemoteThread成功，但DLL没有加载（线程退出码为0）。

原因：
1. DLL路径错误或不可访问：这是最常见的原因。WriteProcessMemory写入的路径字符串有误，或目标进程没有该路径的读取权限。
2. DLL依赖缺失：你的DLL依赖其他DLL（如特定的VC++运行时），而这些依赖在目标进程的环境或路径中找不到。
3. DLL的DllMain函数崩溃：在DllMain中进行了不安全的操作（如创建窗口、调用LoadLibrary、进行复杂的堆操作），导致加载失败。
排查：
1. 在注入器中打印出完整的DLL路径，并确认目标进程的账户有权访问该文件。
2. 使用Process Monitor（ProcMon）工具，过滤目标进程的Load Image操作，看是否有你的DLL加载尝试，以及失败的原因（如PATH NOT FOUND,ACCESS DENIED）。
3. 简化你的DLL，DllMain里只做最简单的日志输出，排除DLL自身问题。

问题3：注入成功，但DLL中的代码似乎没执行。

原因：DLL被加载了，但你的代码可能没有在正确的时机执行。如果你把代码写在DllMain里，并且DllMain返回了FALSE，或者在DllMain中创建了线程但线程没跑起来。

解决：最佳实践是不要在DllMain中做复杂操作。正确的做法是：

// 在DLL中 BOOL APIENTRY DllMain(HMODULE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) { switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: // 仅做初始化标记，立即返回TRUE // 创建一个线程来执行你的主要逻辑 CreateThread(NULL, 0, YourMainThread, hModule, 0, NULL); break; case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; } return TRUE; }

将你的主要功能放在YourMainThread线程函数中。

5.2 防御与检测中的疑难杂症

问题：如何区分合法的远程线程和恶意的注入？

技巧：不能单看一个API调用。需要结合上下文进行行为关联分析。
1. 源进程与目标进程的关系：一个文本编辑器向计算器创建远程线程是可疑的；一个安装程序向自己创建的子进程创建远程线程可能是正常的。
2. 线程起始地址：地址是否在kernel32.dll或ntdll.dll的LoadLibrary函数范围内？如果是，很可能是经典注入。如果地址在非映像内存区域（如堆、栈），可能是Shellcode注入。
3. 操作序列：单独一个CreateRemoteThread可能误报。但如果是OpenProcess->VirtualAllocEx(PAGE_EXECUTE_READWRITE) ->WriteProcessMemory(写入Shellcode) ->CreateRemoteThread(地址指向Shellcode) 这样的序列，恶意可能性极高。
4. 数字签名与信誉：检查源进程文件的数字签名和发行者信誉。无签名或来自未知发行者的进程进行此类操作，风险更高。

问题：反射式注入如何检测？

挑战：反射式注入不调用LoadLibrary，不依赖磁盘文件，传统基于API监控和文件扫描的方法会失效。
检测思路：
1. 内存映像特征：反射加载的DLL，其内存映像与磁盘文件可能不完全一致（如缺少PE头部分）。可以扫描进程内存，寻找具有PE结构特征但未在PEB（进程环境块）的模块列表中注册的内存区域。
2. 执行流异常：如果一段代码突然开始执行，而其所在内存区域不是通过标准模块加载映射的，就值得怀疑。ETW的Microsoft-Windows-Threat-Intelligence提供者可以捕获Kernel级别的代码执行事件。
3. Hook底层加载器：更底层的防御可以尝试HookNtMapViewOfSection等内核函数，监控所有内存映射操作。

5.3 高级技巧与注意事项

绕过杀软/EDR的简单技巧：一些EDR会HookCreateRemoteThread。可以尝试使用NtCreateThreadEx（ntdll的未文档化函数）来创建线程，或者使用APC注入、线程劫持等替代技术。但这属于猫鼠游戏，防御方也会监控这些替代方法。
DLL的持久化：注入成功后，DLL只在进程存活期间有效。要实现持久化（开机自启），需要将注入代码与持久化技术结合，如注册表Run键、服务、计划任务、COM劫持等，在系统启动或用户登录时重新执行注入。
x86与x64的兼容性：这是个大坑！你不能将一个32位（x86）的DLL注入到64位（x64）进程中，反之亦然。你的注入器必须与目标进程的架构相同。在编写注入器时，最好能自动判断目标进程的位数（通过IsWow64Process），然后启动对应架构的注入器或DLL。同样，你的DLL也需要编译对应架构的版本。

DLL注入是Windows平台上一个充满挑战和趣味的领域，它横跨了系统编程、安全攻防和软件工程。理解其原理，能让你在开发需要深度集成的软件时游刃有余；掌握其防御，能让你更好地保护自己的产品。技术本身无善恶，关键在于使用它的人。希望这篇长文能成为你探索这个领域的一块扎实的垫脚石。在实战中，多动手调试，多使用Process Monitor、Process Hacker、x64dbg这些工具观察系统行为，你的理解会深刻得多。如果在实现过程中遇到了上面没提到的问题，通常的排查思路就是：检查权限、检查路径、检查依赖、简化代码、使用工具监控。