[原创]"无痕"驱动的检测与分析：重映射驱动靶场构造、扫描与特征剥离，附源码-编程技术-看雪安全社区

[原创]"无痕"驱动的检测与分析：重映射驱动靶场构造、扫描与特征剥离，附源码

发表于: 2026-4-21 23:33 21331

[原创]"无痕"驱动的检测与分析：重映射驱动靶场构造、扫描与特征剥离，附源码

__Shinn

2026-4-21 23:33

21331

## 写在前面

本文定位为`抛砖引玉`，分享一系列`实验性质`思路、代码实现方法，并非一整套体系化、成熟化的商业对抗方案。

文中涉及的内容，均基于`自建靶场`环境下的模拟分析与验证，仅用于技术研究和交流。若文中有表述不够准确、理解不到位，或存在笔误、疏漏之处，也欢迎各位朋友在评论区指正。

文中涉及到的教学代码也已整理并完整开源到GitHub，欢迎各位朋友交流、指正。

## 早期驱动隐藏

在内核对抗、游戏安全方面，`驱动隐藏`总是一个津津乐道的话题。最早的驱动隐藏为断链隐藏驱动，一个标准流程加载的驱动将自身`DriverObject`从系统模块链表中摘除，再通过各种DKOM手法，使得PCHunter一类的ARK工具也无法在驱动列表中找到相关信息。

## "无痕"驱动

在2019年，GitHub上一个名为kdmapper的开源项目，该项目利用了存在安全缺陷的驱动，可以绕过DSE，直接在内核态中分配内存、拉伸PE镜像、解析导入等等操作，最后调用驱动入口点，实现把未签名的内核驱动手动映射进内核。这就是自己实现了一套ImageLoader，不走系统正常加载流程，根本不会创建正常的`DRIVER_OBJECT`，从隐蔽性角度来优于早期的断链隐藏驱动。

kdmapper刚开源那段时间，游戏安全简直就是一场无序的乱战，各路开发者利用kdmapper的能力随意将驱动程序映射到内核态实现提权，绕过游戏保护，当时大多数反作弊（AC）厂商都没有很完善的检测方案。早期检测方案是向可疑线程发送APC，在APC回调中采集堆栈信息，后来演进到注册NMI回调。

在笔者印象中，所谓`无痕驱动`一词被广泛提及，大概是在PUBG爆火的那几年，当时大量的灰产、外挂在宣传时都声称自己所谓的无痕化驱动。

在2025年，随着某国产摸金搜打撤游戏的爆火，某些社区论坛出现帖子，公然宣传、售卖所谓的`无痕化`商业驱动，这些商业驱动大多声称"可以稳定xxx反作弊保护"，提供的功能无非是：读写内存、注入、模拟键鼠...

笔者对于`无痕驱动`一词的理解是：不存在绝对意义上的无痕化驱动，只要其加载、驻留在内存中，一定会留下痕迹。只是人为地将这些特征隐藏、抹除，从而抬高分析成本，使得短时间内绕过了安全审查。

## 文章目录速览

1. 重映射方式加载驱动

1.1 重映射加载驱动原理

1.2 重映射加载驱动的重定位问题

1.3 重映射加载驱动的通讯问题

2. 劫持系统调用指针实现通讯

2.1 劫持系统调用指针原理

2.2 IDA脚本搜索内核模块中所有的CFG调用

2.3 筛选可利用的CFG点

2.4 符合要求的CFG点分析

2.5 利用特征码定位CFG点

2.6 兼容Win10~Win11多系统版本驱动通讯

2.7 修复通讯回调寻址问题

2.8 替换CFG函数指针

2.9 多系统通讯测试

2.10 小结

3. 检测PoolBigPageTable内存痕迹(Win11 25H2)

3.1 MmAllocateContiguousMemory分析

3.2 MiAllocateContiguousMemory分析

3.3 ExInsertPoolTag分析

3.4 ExpAddTagForBigPages分析

3.5 调用链、参数分析

3.6 PoolBigPageTable对象中成员结构

3.7 利用PoolBigPageTable检测匿名内存分配行为可行性分析

3.8 利用特征码定位PoolBigPageTable表

3.9 遍历PoolBigPageTable中的成员

3.10 检测敏感内存分配行为

3.11 对抗PoolBigPageTable内存扫描

4. 扫描内核态下所有可执行内存

4.1 扫描内核态下PTE

4.2 Win11 25H2环境下测试

4.3 通过扫描可执行内核页面检测Shellcode驱动

4.4 小结

5. 利用编译器特征扫描"无痕"驱动

5.1 利用导入表特征检测原理

5.2 测试结果

5.3 剥离导入表Stub特征

5.4 延迟导入API

6. 扫描被劫持的系统调用指针

6.1 扫描 ntoskrnl 中的CFG间接调用点

6.2 定位当前内核中的__guard_dispatch_icall

6.3 扫描内核模块代码中所有对__guard_dispatch_icall的调用

6.4 还原数据指针槽位

6.5 过滤正常CFG点

6.6 扫描、检测测试

6.7 绕过常规的指针扫描

7. Github开源仓库地址

8. 结束语

## 1. 重映射方式加载驱动

常见的手动映射加载驱动方式往往分为`两层`，外层驱动仅作为Loader（使用未被AC厂商拉黑的签名），内层驱动（无签名）负责实现各种功能，以Shellcode、无模块镜像的形式驻留 / 运行在内核态（Ring 0）中。根据笔者接触到的一些样本来看，常规的Loader驱动工作流程往往分为以下几步：

- 从云端 / 本地PE文件中取得被加密内层功能驱动资源
- 解密Shellcode驱动二进制
- 解析PE头中的SizeOfImage字段，在内核态分配内存
- 手动拉伸PE，将初步处理好的Shellcode放置到分配好的内存中
- 修复重定位表（Reloc）
- 修复导入表（IAT）
- 刷新SecurityCookie
- 调用AddressOfEntryPoint入口点程序
- 抹除整个PE文件头

### 1.1 重映射加载驱动原理

本文会介绍一种取巧的思路：先让当前驱动按系统正常流程被加载一次，等内核加载器把镜像映射、重定位、导入解析等工作全部完成后，在 `DriverEntry` 阶段将自身重新映射到另一块匿名内核内存中继续执行，原始的`DriverEntry` 主动返回`STATUS_UNSUCCESSFUL`。此时我们的重映射驱动不再依赖原始的`DRIVER_OBJECT`和模块加载记录。

重映射并没有像传统手动映射那样，从头实现一整套 PE Loader。当 `DriverEntry` 被调用时，`DrvObj->DriverStart` 指向的已经不是磁盘上的原始PE文件，而是系统完成装载后的运行时镜像。所以我们在重映射时，很多初始化结果天然被继承下来了，例如PE已经被拉伸、IAT导入表中的函数地址已经被系统处理好。

### 1.2 重映射加载驱动的重定位问题

我们将驱动自身直接重映射到一块新的匿名内核内存中，此时Shellcode驱动还不能直接运行，原因在于新旧镜像的基址（ImageBase）不同，镜像内部凡是依赖固定基址的绝对地址项，都需要根据新的地址重新修正。修正流程、部分关键代码如下：

- 计算原始镜像与新镜像之间的基址差值：`LocationDelta = MappedBase - SourceBase`
- 解析新镜像中的DOS头、NT头，定位 `IMAGE_DIRECTORY_ENTRY_BASERELOC` 重定位目录
- 逐个遍历 `IMAGE_BASE_RELOCATION` 块，枚举每一个重定位条目
- 针对x64环境下，仅处理最常见的 `IMAGE_REL_BASED_DIR64` 类型重定位项
- 根据 `VirtualAddress + Offset` 计算待修补地址，并将 LocationDelta 累加到目标指针上

```c++
static VOID RelocateImage(PVOID SourceBase, PVOID MappedBase)
{
    const ULONG_PTR LocationDelta = (ULONG_PTR)MappedBase - (ULONG_PTR)SourceBase;
    if (LocationDelta == 0)
    {
        return;
    }

auto DosHeader = (PIMAGE_DOS_HEADER)MappedBase;
    auto NtHeaders = (PIMAGE_NT_HEADERS)((PUCHAR)MappedBase + DosHeader->e_lfanew);
    auto OptionalHeader = &NtHeaders->OptionalHeader;
    if (OptionalHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].Size == 0)
    {
        return;
    }

auto RelocationBlock = (PIMAGE_BASE_RELOCATION)(
        (PUCHAR)MappedBase +
        OptionalHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].VirtualAddress);

auto RelocationEnd = (PIMAGE_BASE_RELOCATION)(
        (PUCHAR)RelocationBlock +
        OptionalHeader->DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC].Size);

while (RelocationBlock < RelocationEnd && RelocationBlock->SizeOfBlock != 0)
    {
        const ULONG_PTR EntryCount = (RelocationBlock->SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(USHORT);
        PUSHORT RelocationInfo = (PUSHORT)(RelocationBlock + 1);
        for (ULONG_PTR Index = 0; Index < EntryCount; ++Index, ++RelocationInfo)
        {
            if (!IsDir64Relocation(*RelocationInfo))
            {
                continue;
            }

PUINT_PTR PatchAddress = (PUINT_PTR)(
                (PUCHAR)MappedBase +
                RelocationBlock->VirtualAddress +
                ((*RelocationInfo) & 0x0FFF));

*PatchAddress += LocationDelta;
        }

RelocationBlock = (PIMAGE_BASE_RELOCATION)((PUCHAR)RelocationBlock + RelocationBlock->SizeOfBlock);
    }
}
```

### 1.3 重映射加载驱动的通讯问题

当重定位修正完成后，这份新镜像在执行层面就已经具备了独立运行的基础。此时再结合后续的特征剥离操作，例如抹除PE头，以及让原始 DriverEntry 主动返回失败，就可以把真正的执行逻辑切换到这段匿名内存中。

笔者这些年接触、分析过诸多灰产驱动样本，这些驱动样本往往是提供一系列绕过AC保护、实现提权的功能，处于内核态的驱动程序大部分时间都是`被动地`接收来自应用层（Ring 3）程序的命令，解析命令后执行不同的动作。这一行为笔者笼统地概括为`驱动通讯`，常见的驱动通讯方式有：IO通讯、注册表回调通讯、MiniFilter通讯端口、共享内存通讯、本机Socket通讯等等。
	本文提及的重映射加载驱动方式，本质上算是一种特殊的手动映射加载驱动。由于没有标准流程中的系统创建的`DRIVER_OBJECT`，所以常规的IO通讯、注册表回调、Filter端口通讯都会注册失败，必须寻找一条不依赖设备对象、同时又能被用户态正常触发的替代入口。

下一章节会介绍一种另类、相对隐蔽（指常规的ARK工具找不到痕迹）的驱动通讯方式。

## 2. 劫持系统调用指针实现通讯

### 2.1 劫持系统调用指针原理

在本文靶场中，劫持思路是基于`CFG`（Control Flow Guard，控制流保护）相关的特性，`CFG` 的设计目标，是对间接调用、间接跳转这类控制流转移行为进行约束和校验。内核运行时，会在特定分支上通过`间接函数指针`进入特定的处理逻辑，通过劫持这个`间接函数指针`，为重映射驱动提供了一条可被利用的隐藏通讯通道。

关于`PG`（PatchGuard）问题：有别于修改`SSDT`、`IDT`表项本身，这里真正劫持、改写的是某条系统调用内部会间接访问的函数指针或回调槽位，笔者测试时最长40h内无任何蓝屏状况。

如图2-1 IDA反汇编所示，就是一条可被利用`CFG`劫持点：
 ![](upload/attach/202604/953262_YC7GERYCVHR3KN2.webp)
![](Image/2-1CFG.png)

其反汇编大多可以总结为如下格式：

``` c
// 从全局变量中取出函数指针
mov rax, cs:qword_140xxxxxx

// 构造调用参数，rcx、rdx、r8、r9等等
mov r9, xxx
mov r8, xxx
mov rdx, xxx
mov rcx, xxx

// ....

call _guard_dispatch_icall
```

### 2.2 IDA脚本搜索内核模块中所有的CFG调用

内核中存在着大量的CFG间接调用，依赖手动分析明显不现实，所以这里我们使用Python编写用于IDA的脚本文件，自动化的方式减轻我们的重复劳动，运行效果如图2-2所示：
![](Image/2-2ScriptFile.png)
 ![](upload/attach/202604/953262_XJ9YXQ4T27CXJ6R.webp)

### 2.3 筛选可利用的CFG点

从IDA脚本执行结果来看，内核中这类通过 `CFG` 保护的间接调用点非常多，但绝大多数位置并不具备实际研究价值。原因很简单：很多间接调用只出现在初始化路径、错误处理分支、一次性回调、或者只能由内核内部状态机触发的逻辑中，既不稳定，R3应用程序也无法发起调用。对于当前场景而言，真正值得重点关注的应该是那些恰好位于用户态可触发系统调用链上的间接分发点。

这类`CFG`点需要具备以下几个共同特征：

- 它必须处于某条稳定、可`重复进入`的系统服务路径中，也就是说，用户态程序在Ring 3下能够通过正常系统调用请求反复触发它。
- 这条路径最好能够一路`携带调用参数`，使得内核在执行到该间接调用点之前，仍然保留着来自用户态的上下文信息，例如8字节指针信息。

### 2.4 符合要求的CFG点分析

经过笔者分析Win11 24H2版本的内核文件后，分析出一个符合我们要求的`CFG`点，如图2-4-1所示：
 ![](upload/attach/202604/953262_4EGX6S84JNBNR6N.webp)
![](Image/2-4CFG.png)

笔者首先关注到的函数为 `sub_140A0AE40`，从反编译结果来看，这个函数本身的逻辑非常简单：先检查一个全局函数指针是否为空，随后读取 `SeILSigningPolicy` / `SeILSigningPolicyRuntime` 相关状态，整理出一个布尔值，最后通过 `guard_dispatch_icall_no_overrides` 发起一次受`CFG`保护的间接调用。
 ![](upload/attach/202604/953262_7BK62ENU7FXUB5U.webp)
![](Image/2-4-1sub_140A0AE40.png)

也就是说，`sub_140A0AE40` 本质上只是一个非常薄的`Wrapper`，真正决定执行流走向的并不是它自身，而是全局变量 `qword_140F03D58` 所保存的目标函数。

接下来继续查看 `sub_140A0AE40` 的交叉引用，可以发现它并不是一个孤立存在的内部函数，而是由 `ExpQuerySystemInformation` 在特定分支中调用。当 `SystemInformationClass == 103` 时，`ExpQuerySystemInformation` 会执行如下逻辑，如图2-4-2所示
 ![](upload/attach/202604/953262_8PJ57SYSY3HEJQU.webp)
![](Image/2-4-2ExpQuerySystemInformation.png)

由以下代码可知，到了 `sub_140A0AE40` 这一层，来自 Ring 3 的`缓冲区地址` `缓冲区长度` 几乎原样保留、传递下来了。

```c++
// 这条调用语句非常关键，因为它直接展现了参数是如何传递到最终CFG落点前一层的：
// a4：用户态传入的 SystemInformation 缓冲区指针
// Length：用户态传入的 SystemInformationLength
// &Size：内核栈上的局部变量地址，用于保存返回长度
SystemProcessorFeaturesInformation = sub_140A0AE40(a4, Length, (__int64)&Size);
```

再继续向上追，就能回到最外层的系统调用入口 `NtQuerySystemInformation`，从反编译结果来看，`103` 这个分支并不属于那些需要特殊线程上下文处理的情况，因此它最终会走默认路径，如图2-4-3所示：
 ![](upload/attach/202604/953262_ZTND23DB79J2M46.webp)
![](Image/2-4-3NtQuerySystemInformation.png)

至此，这条调用链已经可以完整串联起来：

```c
NtQuerySystemInformation(
    SystemInformationClass = 103,
    SystemInformation,
    SystemInformationLength,
    ReturnLength
)
    ->
ExpQuerySystemInformation(103, ..., SystemInformation, SystemInformationLength, ReturnLength)
    ->
sub_140A0AE40(SystemInformation, SystemInformationLength, &Size)
    ->
guard_dispatch_icall_no_overrides(...)
```

### 2.5 利用特征码定位CFG点

在前文中，笔者已经通过逆向分析确认了一条符合要求的 `CFG` 调用链。但在实际研究中，仅靠手工在 IDA 里逐层点交叉引用并不高效，尤其是在需要适配多个系统版本、反复验证目标点是否发生偏移时，更需要一种相对稳定、可重复的定位方法。出于这个目的，笔者选择使用 IDA 脚本辅助提取目标代码片段的上下文特征，再结合模式匹配的方式，在不同版本内核中快速确认该 `CFG` 点是否仍然存在，IDA脚本运行效果如图所示：
 ![](upload/attach/202604/953262_SFBUXWU22G9FJAQ.webp)
![](Image/2-4-5sig_code.png)

### 2.6 兼容Win10~Win11多系统版本驱动通讯

我们提取好特征码后，就可以在驱动运行时动态搜索特征码，定位到`CFG`点，部分关键代码如下：

```c++
	// Win10 19041 ~ Win11 24H2
	if (VersionInformation.dwBuildNumber >= 19041 && VersionInformation.dwBuildNumber < 26200)
	{
		CodeAddr = SearchFeatureCode(
			"ntoskrnl.exe",
			"PAGE",
			(PCUCHAR)"\x48\x8B\x05\xB9\xF6\x51\x00\x85\xC9\x49\x8B\xCA\x41\x0F\x95\xC0\xE8\x93\x1F\xD0\xFF\x48\x83\xC4\x38\xC3",
			"xxx????xxxxxxxxxx????xxx?x",
			0);
	}
	// Win11 25H2 or higher
	else if (VersionInformation.dwBuildNumber >= 26200)
	{
		CodeAddr = SearchFeatureCode(
			"ntoskrnl.exe",
			"PAGE",	(PCUCHAR)"\x48\x8B\x05\xA4\x10\x53\x00\x4C\x8D\x4C\x24\x44\x8B\xD7\x48\x8B\xCB\xE8\xAD\x46\xCD\xFF\x89\x44\x24\x40\xE9\x4F\x17\x00\x00",
			"xxx????xxxx?xxxxxx????xxx?x????",
			0);
	}
	// non supported
	else
	{
		CodeAddr = 0;
	}
```

### 2.7 修复通讯回调寻址问题

笔者编写的驱动通讯回调代码如下所示，需要修复全局变量的寻址问题：

```c++
// 这里保存的是CFG原本的函数地址
// 由于我们是重映射驱动，这里的全局变量地址还是原始驱动的，如果不修复必定BSOD
// 所以需要修复重映射后真实的g_OldCommCallback寻址
fn_CommCallback g_OldCommCallback = nullptr;

__int64 HookCallback(IN __int64 a1,IN __int64 a2,IN __int64 a3, IN __int64 a4)
{
	PDRV_COMM_PACKAGE CommPackage = (PDRV_COMM_PACKAGE)a1;
	if (a1 == 0 || a2 != sizeof(DRV_COMM_PACKAGE) || CommPackage->Magic != DRV_COMM_MAGIC)
	{
		return g_OldCommCallback(a1, a2, a3, a4);
	}

CommPackage->RetValue = 0x12345678;
	DbgPrint("[+] Magic = 0x%llX  CtlCode = 0x%X. \n", CommPackage->Magic, CommPackage->CtlCode);
	return 0;
}
```

使用IDA反汇编我们的`靶场驱动`，其中的`HookCallback`函数需要修复的地方，如图所示：
 ![](upload/attach/202604/953262_8HB3X6NKX7P7ER9.webp)
![](Image/2-7FixRemapCallback.png)

修复代码如下所示：

```c
VOID FixRemapCallback(IN PVOID NewCallback,IN PVOID FixCallback)
{
    // 定位到mov rax, cs:g_OldCommCallback后修复其寻址即可
	ULONG_PTR CodeAddr = SearchFeatureCode((ULONG_PTR)NewCallback, (SIZE_T)0x100, (PCUCHAR)"\x48\x8B\x05", "xxx", 0);
	if (0 != CodeAddr)
	{
		*DEREF_RELATIVE_ADDR(PVOID, CodeAddr, 3) = FixCallback;
	}
}
```

### 2.8 替换CFG函数指针

到了这一步，我们就可以替换`CFG`中的回调指针了，代码如下所示：

```c
_InterlockedCompareExchangePointer((PVOID volatile*)pCallback,Callback,OldCallback);
```

### 2.9 多系统通讯测试

至此我们的劫持CFG通讯方式算是完成了，剩下的就是由Ring 3应用程序主动发起`NtQuerySystemInformation`调用，让我们的Shellcode靶场驱动接管调用流程，关键代码如下所示：

```c
// R3、R0约定的识别码
#define DRV_COMM_MAGIC		0x789456123ull

// 通讯协议
#pragma pack(push, 1)
typedef struct _DRV_COMM_PACKAGE
{
	ULONG64 Magic;
	ULONG CtlCode;
	PVOID Buffer;
	ULONG BufferSize;
	ULONG RetValue;
} DRV_COMM_PACKAGE, *PDRV_COMM_PACKAGE;
#pragma pack(pop)

// R3程序发送命令
NTSTATUS DrvComm::SendMsg(PVOID Buffer,ULONG BufferSize,PULONG ReturnLength) const
{
	if (Buffer == nullptr || BufferSize == 0)
	{
		return STATUS_INVALID_PARAMETER;
	}

return m_NtQuerySystemInformation(
		SystemCodeIntegrityInformation,	// 103
		Buffer,
		BufferSize,
		ReturnLength
	);
}
```

笔者针对多系统版本做了特征码提取，理论上可适配 Win10 19041 及之后的 Win10/Win11 版本。

驱动通讯测试结果如图所示，分别测试`Win10 19044`、`Win11 25H2`：
 ![](upload/attach/202604/953262_5Q73HW7GRDH7KJV.webp)
![](Image/2-9CommTest_19044.png)
 ![](upload/attach/202604/953262_7YK63Y52NQ6BMKA.webp)
![](Image/2-9CommTest_25H2.png)

### 2.10 小结

至此，一个用于实验与分析的所谓"无痕"驱动框架就基本构造完成了。当然，当前`靶场驱动`仍然保留了不少明显特征尚未处理，例如`注册表`、`文件`以及 `PiDDBCacheTable` 等相关痕迹。但这些内容并不属于本文的讨论重点。

本文阶段性目标，是构造一份以 `Shellcode` 形式驻留于内核中的驱动样本，作为后续分析与检测的`模拟靶场`。从成果来看，当前驱动已经具备了`重映射加载`与`隐蔽通讯`的基本能力，足以支撑后续章节的实验与分析。

接下来的内容中，笔者将从多个角度出发，对这类所谓"无痕"驱动进行剖析，展示如何一步步检测其残留特征。

## 3. 检测PoolBigPageTable内存痕迹(Win11 25H2)
	在检测这类 Shellcode 驱动时，一个很自然的切入点就是内核内存分配痕迹。因为无论是手动映射驱动，还是本文这种重映射后的匿名驱动，想要在内核中长期驻留，都必须先拿到一块新的可用内存。以本靶场中使用的 `MmAllocateContiguousMemory` 为例进行逆向分析。

### 3.1  MmAllocateContiguousMemory分析

先看最外层的 `MmAllocateContiguousMemory`。从 `Win11 25H2` 的反编译结果来看，它本身只是一个较薄的Wrapper。函数首先将调用者传入的 `NumberOfBytes` 保存到局部变量 `v4` 中，然后把 `HighestAcceptableAddress` 右移 12 位，转换成页帧号上限（PFN Upper Bound）。随后，它调用内部的 `MiAllocateContiguousMemory`：
 ![](upload/attach/202604/953262_YU7KQS9D8CY5Z3Y.webp)
![](Image/3-1MmAllocateContiguousMemory.png)

### 3.2 MiAllocateContiguousMemory分析

进入 `MiAllocateContiguousMemory` 后，内存管理器首先读取 *a1，并根据是否页对齐计算本次实际需要的页数：
 ![](upload/attach/202604/953262_HD4XFJZFQA57A4G.webp)
![](Image/3-2MiAllocateContiguousMemory.png)

也就是说，`v17` 就是最终需要分配的页数，后续真正参与记录的大小也是 `v17 << 12`，而不是最初用户请求的原始字节数。随后，函数会在指定物理范围内搜索连续物理页，并在成功找到后调用 `MiMapContiguousMemory` 把这段物理内存映射成内核虚拟地址，紧接着调用`ExInsertPoolTag`，这条调用链已经把2个最关键的信息凑齐了：

- `v32`：分配完成后的内核虚拟地址 VA
- `v17 << 12`：按页对齐后的分配大小 Size
 ![](upload/attach/202604/953262_NEDZ4V5MJ6R2X72.webp)
![](Image/3-2-2MiAllocateContiguousMemory.png)

### 3.3 ExInsertPoolTag 分析

`ExInsertPoolTag` 会先把传入的大小再次按页对齐，随后调用核心函数`ExpAddTagForBigPages`，如图所示：

可以把 `ExpAddTagForBigPages` 的2个关键参数理解为：

- a1 = a2：大块分配对应的虚拟地址 VA
- a3 = v9：页对齐后的分配大小 Size
 ![](upload/attach/202604/953262_3Y7FXFYQR6E5UH3.webp)
![](Image/3-3ExInsertPoolTag.png)

### 3.4 ExpAddTagForBigPages分析
 ![](upload/attach/202604/953262_XJ2Z6DDKWUAPJW2.webp)
![](Image/3-4ExpAddTagForBigPages.png)
 ![](upload/attach/202604/953262_RH495PJXBCJGEDT.webp)
![](Image/3-4-2ExpAddTagForBigPages.png)

### 3.5 调用链、参数分析

```c
MmAllocateContiguousMemory(
    NumberOfBytes,
    HighestAcceptableAddress
)
    ->
MiAllocateContiguousMemory(
    a1 = &NumberOfBytes,                  // *a1 初始为请求大小
    ...,
    a3 = HighestAcceptableAddress >> 12,
    ...
)
    ->
v17 = ((*a1 >> 12) + ((*a1 & 0xFFF) != 0))   // 计算实际分配页数
    ->
MiMapContiguousMemory(..., v17 << 12, ...)
    = Va
    ->
ExInsertPoolTag(
    ...,
    Va,
    v17 << 12
)
    ->
ExpAddTagForBigPages(
    a1 = Va,
    ...,
    a3 = ALIGN_UP(v17 << 12, 0x1000)
)
    ->
PoolBigPageTable[slot].Va   = a1
PoolBigPageTable[slot].Size = a3
```

### 3.6 PoolBigPageTable对象中成员结构

目前可以知道分配出来的内存信息，都会保存到`PoolBigPageTable`对象中，并且在`Win11 25H2`下，其中的对象结构可以表示为如下：

```c
// Size = 0x20 Bytes
typedef struct _POOL_BIG_PAGE_INFO {
    volatile ULONG_PTR Va;   // +0x00
    UCHAR Reserved0[8];      // +0x08
    SIZE_T NumberOfBytes;    // +0x10
    UCHAR Reserved1[8];      // +0x18
} POOL_BIG_PAGE_INFO, *PPOOL_BIG_PAGE_INFO;
```

在Win10系统下，`PoolBigPageInfo`可以表示为如下结构：

```c
// Size = 0x18 Bytes
typedef struct _POOL_BIG_PAGE_INFO {
    volatile ULONG_PTR Va;   // +0x00，记录的虚拟地址
    UCHAR Reserved[8];       // +0x08，保留字段
    SIZE_T NumberOfBytes;    // +0x10，按页对齐后的大小
} POOL_BIG_PAGE_INFO, *PPOOL_BIG_PAGE_INFO;
```

### 3.7 利用PoolBigPageTable检测匿名内存分配行为可行性分析

经过笔者分析发现，内核中大部分常用的内存分配函数，最终都会将分配到的内存信息保存到`PoolBigPageTable`对象中，所以利用该系统特性，我们就可以遍历`PoolBigPageTable`中所有的条目，找出敏感的匿名内存分配行为。

```c
// 内核态中常用的内存分配接口
ExAllocatePool(...);
ExAllocatePoolWithTag(...);
MmAllocateContiguousMemory(...);
```

### 3.8 利用特征码定位PoolBigPageTable表
 ![](upload/attach/202604/953262_547MVX8AG8XQJY7.webp)
![](Image/3-8SigCode.png)
	利用特征码定位`PoolBigPageTable`，关键代码如下所示：

```c
	RTL_OSVERSIONINFOW VersionInformation;
	RtlGetVersion(&VersionInformation);
	if (VersionInformation.dwBuildNumber <= 22621)
	{
		CodeAddr = SearchFeatureCode(
			"ntoskrnl.exe",
			".text",
			(PCUCHAR)"\x48\x8B\x15\x47\x58\x8E\x00\x4C\x8B\x0D\x48\x58\x8E\x00\x48\x85\xD2\x74\x55\x48\x63\x05\xE4\xC6\x9F\x00",
			"xxx????xxx????xxxx?xxx????",
			0);
	}
	else
	{
		CodeAddr = SearchFeatureCode(
			"ntoskrnl.exe",
			".text",
			(PCUCHAR)"\x48\x8B\x15\x64\x2C\xB6\x00\x4C\x8B\x05\x75\x2C\xB6\x00\x48\x85\xD2\x0F\x84\x11\x01\x00\x00",
			"xxx????xxx????xxxxx????",
			0);
	}
```

### 3.9 遍历PoolBigPageTable中的成员

使用特征码搜索到`PoolBigPageTable`对象后，遍历其中所有已分配内存信息，关键代码如下所示：

```c
	POOL_BIG_PAGE_INFO_WIN11* PoolBigPageTable = NULL;
	PoolBigPageTable = *DEREF_RELATIVE_ADDR(POOL_BIG_PAGE_INFO_WIN11*, CodeAddr, 3);
	if (NULL == PoolBigPageTable)
	{
		return VOID();
	}

CodeAddr += 7;
	ULONG64 PoolBigPageTableSize = *DEREF_RELATIVE_ADDR(ULONG64, CodeAddr, 3);
	if (0 == PoolBigPageTableSize)
	{
		return VOID();
	}

for (ULONG64 i = 0; i < PoolBigPageTableSize; i++)
	{
		POOL_BIG_PAGE_INFO_WIN11 PoolPageInfo = PoolBigPageTable[i];
		if (0 != PoolPageInfo.NumberOfBytes)
		{
			DbgPrint("PoolBase = 0x%p   PoolSize = 0x%X. \n", PoolPageInfo.Va, PoolPageInfo.NumberOfBytes);
		}
	}
```

### 3.10 测试检测敏感内存分配行为

测试系统版本为`Win11 25H2`，测试流程为：

- 扫一遍`PoolBigPageTable`中的内存分配信息
- 加载我们的靶场驱动
- 再扫一遍`PoolBigPageTable`中的内存分配信息
- 此时前后新增加的条目（`Va`、`Size`），大概率就是`Shellcode`驱动所在的内存区域。
 ![](upload/attach/202604/953262_S2PMXKQV793AFUC.webp)
![](Image/3-10PoolBigPageTable_Walk.png)
 ![](upload/attach/202604/953262_RVN9T76KVR7ZM3W.webp)
![](Image/3-10-1WalkResult.png)

### 3.11 对抗PoolBigPageTable内存扫描

关于这一部分，笔者仅提供2种思路，暂不提供实现源码：

- 每次分配内存前，临时Hook `ExpAddTagForBigPages`函数，不让其将本次的内存分配信息保存到`PoolBigPageTable`

- 手动遍历`PoolBigPageTable`中所有成员，将敏感的内存分配信息清除

带来的缺陷：

释放内存前需要将抹除的信息还原，因为内核在释放内存时也会查找一次`PoolBigPageTable`对象，查找失败会触发`BugCheck`

## 4. 扫描内核态下所有可执行内存

除了前文提到的 `PoolBigPageTable` 这类"内存分配记录"思路外，另一种更直接、也更粗暴的检测方式，就是直接遍历内核态下所有虚拟地址对应的页表项（PTE）。

其核心思想很简单：既然所谓的 `Shellcode` 驱动最终总要以代码页的形式驻留在内核地址空间中，那么无论它是否存在标准的 `DRIVER_OBJECT`，也无论它是否已经抹除了 `PE` 头，只要它仍然需要执行，就必然对应着一段`可执行`的内核虚拟内存。因此，我们完全可以绕过模块链表、对象管理器等高层结构，直接从页表层面对整个内核地址空间做一次`暴力扫描`。

### 4.1 扫描内核态下PTE

首先读取当前CPU的 `CR3` 寄存器，取得当前地址空间使用的顶级页表物理基址。随后通过 `MmGetVirtualForPhysical` 将 `PML4` 对应的物理页映射成内核虚拟地址，并从这里开始逐级遍历 PML4 -> PDPT -> PD -> PT 四级页表结构。
 ![](upload/attach/202604/953262_QSKGU6VA2FSMK3G.webp)
![](Image/4-1_Paged.png)

关于其中的每一级PTE，可以使用如下结构进行描述：

```c
typedef union _PAGE_ENTRY_64
{
	ULONG64 Value;
	struct 
    {
		ULONG64 Present : 1;
		ULONG64 Write : 1;
		ULONG64 User : 1;
		ULONG64 WriteThrough : 1;
		ULONG64 CacheDisable : 1;
		ULONG64 Accessed : 1;
		ULONG64 Dirty : 1;
		ULONG64 LargePage : 1;
		ULONG64 Global : 1;
		ULONG64 CopyOnWrite : 1;
		ULONG64 Prototype : 1;
		ULONG64 Reserved0 : 1;
		ULONG64 PageFrameNumber : 36;
		ULONG64 Reserved1 : 4;
		ULONG64 SoftwareWsIndex : 11;
		ULONG64 NoExecute : 1;
	};
} PAGE_ENTRY_64, *PPAGE_ENTRY_64;
```

由于x64下内核地址通常位于高地址空间，因此这里没有从 `PML4[0]` 开始全量遍历，而是直接枚举 `PML4[256] ~ PML4[511]` 这部分条目，把扫描范围收敛到内核态虚拟地址区间。遍历过程中，只保留满足 `Present = 1` 且 `NoExecute = 0` 的页表项，也就是当前真实存在、并且具备执行权限的页面；其余不可执行页、未映射页则直接跳过。

对于命中的可执行页，再结合是否`属于已知模块映像范围`进行一次过滤，就可以把大量正常内核模块代码排除掉，把关注点集中到那些不属于任何已加载模块、但却具备执行权限的匿名内存区域上。对于手动映射驱动、重映射驱动这类 `Shellcode` 驱动而言，这类区域往往就是后续重点分析的对象。

如下为关键部分代码：

```c
VOID PteWalk(VOID)
{
    ULONG64 Cr3 = __readcr3();
    ULONG64 Pml4Pa = Cr3 & (~0xFFF);
    PHYSICAL_ADDRESS PhysicalAddress = { 0 };
    PAGE_ENTRY_64* Pml4;

PhysicalAddress.QuadPart = Pml4Pa;
    Pml4 = (PAGE_ENTRY_64*)MmGetVirtualForPhysical(PhysicalAddress);
    if (!MmIsAddressValid(Pml4))
    {
        return;
    }

for (ULONG i = 256; i < 512; i++)
    {
        PAGE_ENTRY_64 Pml4e = Pml4[i];
        if (!Pml4e.Present)
        {
            continue;
        }

PhysicalAddress.QuadPart = Pml4e.PageFrameNumber << PAGE_SHIFT;
        PAGE_ENTRY_64* Pdpt = (PAGE_ENTRY_64*)MmGetVirtualForPhysical(PhysicalAddress);
        if (!MmIsAddressValid(Pdpt))
        {
            continue;
        }

for (ULONG j = 0; j < 512; j++)
        {
            PAGE_ENTRY_64 Pdpte = Pdpt[j];
            if (!Pdpte.Present)
            {
                continue;
            }

if (Pdpte.LargePage)
            {
                if (!Pdpte.NoExecute)
                {
                    ULONG64 Va = BuildLinearAddr(i, j, 0, 0);
                    LogPageRange(Va, 1ull << 30, BuildRwxValue(Pdpte.Write != 0, TRUE), "1GB");
                }
                continue;
            }

PhysicalAddress.QuadPart = Pdpte.PageFrameNumber << PAGE_SHIFT;
            PAGE_ENTRY_64* Pd = (PAGE_ENTRY_64*)MmGetVirtualForPhysical(PhysicalAddress);
            if (!MmIsAddressValid(Pd))
            {
                continue;
            }

for (ULONG k = 0; k < 512; k++)
            {
                PAGE_ENTRY_64 Pde = Pd[k];
                if (!Pde.Present)
                {
                    continue;
                }

if (Pde.LargePage)
                {
                    if (!Pde.NoExecute)
                    {
                        ULONG64 Va = BuildLinearAddr(i, j, k, 0);
                        LogPageRange(Va, 1ull << 21, BuildRwxValue(Pde.Write != 0, TRUE), "2MB");
                    }
                    continue;
                }

PhysicalAddress.QuadPart = Pde.PageFrameNumber << PAGE_SHIFT;
                PAGE_ENTRY_64* Pt = (PAGE_ENTRY_64*)MmGetVirtualForPhysical(PhysicalAddress);
                if (!MmIsAddressValid(Pt))
                {
                    continue;
                }

for (ULONG l = 0; l < 512; l++)
                {
                    PAGE_ENTRY_64 Pte = Pt[l];
                    if (!Pte.Present || Pte.NoExecute)
                    {
                        continue;
                    }

ULONG64 Va = BuildLinearAddr(i, j, k, l);
                    ULONG Rwx = BuildRwxValue(Pte.Write != 0, TRUE);
                    Append4KbPageRange(&Page4KbRange, Va, Rwx);
                }
            }
        }
    }

FlushRange(&Page4KbRange);
}
```

### 4.2 Win11 25H2环境下测试

在Win11 25H2环境下测试，顺利枚举出所有的可执行内存页面信息，如图所示：
 ![](upload/attach/202604/953262_6DZ9AZE9XMY5U7P.webp)
![](Image/4-2PTE_Walk.png)

### 4.3 通过扫描可执行内核页面检测Shellcode驱动

这里的测试流程同`PoolBigPageTable`，先扫描一次PTE列表、加载靶场驱动、再扫描一次PTE列表，此时前后新增的可执行PTE条目大概率就是`Shellcode`驱动所在的内存范围，如图所示顺利扫描到靶场驱动所在Pool内存范围：
 ![](upload/attach/202604/953262_EVEYGCX8Z88G3KY.webp)
![](Image/4-3Walk_Result.png)

### 4.4 小结

看到这里，读者应该注意到一个细节，第3、4章节都是介绍如何利用内核下内存相关的机制，效果都是可以定位出`靶场驱动`的内存范围（起始地址、大小），那么定位到可疑的内存范围后，我们该如何利用呢？

第5章就是在确定了可疑的匿名内存范围后，利用`编译器特征`来进一步扫描。

## 5. 利用编译器特征扫描"无痕"驱动

### 5.1 利用导入表特征检测原理

在经过第3、4章节的铺垫后，我们已经顺利确定我们的`"无痕"靶场驱动`的可疑内存范围，接下来就是针对这段可疑的匿名内存，扫描其中是否存在编译器特征。

扫描编译器特征，笔者这里首先要介绍的是利用导入特征，使用IDA打开我们`靶场驱动`，切换到`Imports`页面，如图所示有着较多的导入函数：
 ![](upload/attach/202604/953262_M93QTU3EQBRSG6C.webp)
![](Image/5-1IDA_Imports.png)

我们随便选中一项，这里以`DbgPrint`为例，双击跳转，来到idata节区：
 ![](upload/attach/202604/953262_F6PXEXKX5AJA369.webp)
![](Image/5-1-2DbgPrint.png)

选中该项，背景标黄色后，查看其xref信息，来到其反汇编界面，可以看到这里的调用其实是编译器的导入Stub：
 ![](upload/attach/202604/953262_TEUN7B8VFMCJVQF.webp)
![](Image/5-1-3DbgPrint_Stub.png)

在 x64 平台下，这类编译器生成的导入 `Stub`，常见形式就是一条RIP 相对寻址的间接跳转指令：

```c
jmp qword ptr [rip+xxxx]
    
// 其机器码通常表现为：
FF 25 xx xx xx xx
```

这里的 FF 25 只是指令头，后面的 `disp32` 并不是最终导入函数地址，而是一个相对于当前指令末尾的偏移。程序执行到这里时，会先根据 `RIP + disp32` 定位到一项导入槽位，再从该地址中解引用出真正的函数指针，最终跳转到 `ntoskrnl.exe`、`Wdf01000.sys` 一类正常内核模块中的导出函数。

当我们已经通过前文的 `PTE Walk` 、`PoolBigPageTable扫描`锁定了一段匿名、可执行、且不属于任何已加载模块的可疑内存后，就可以继续在这段范围内扫描 `FF 25` 特征码。如果命中的位置在解引用后，最终跳转目标落在正常模块地址范围内，那么这往往就是一个非常典型的`导入表 Stub 特征`。对于一份经过重映射、手动映射、甚至已经抹除 PE 头的 Shellcode 驱动来说，虽然它的模块外观特征已经被剥离掉了，但编译器生成的这类导入跳转痕迹却往往仍然保留在代码段中。

如下为关键代码，传入我们扫描出来的可疑、匿名内存的起始地址、范围，即可开始扫描导入Stub特征：

```c
static ULONG ScanImportJumpTargets(IN ULONG_PTR SearchStartAddr,IN SIZE_T SearchSize)
{
    ULONG ModuleCount = 0;
    if (!QueryModuleSnapshot(NULL, 0, &ModuleCount) || ModuleCount == 0)
    {
        return 0;
    }

PMODULE_ADDRESS_RANGE ModuleRanges = (PMODULE_ADDRESS_RANGE)ExAllocatePoolWithTag(
        NonPagedPoolNx,
        sizeof(MODULE_ADDRESS_RANGE) * (ModuleCount + 16),
        IMPORT_SCAN_TAG);
    if (ModuleRanges == NULL)
    {
        return 0;
    }

if (!QueryModuleSnapshot(ModuleRanges, ModuleCount + 16, &ModuleCount))
    {
        ExFreePoolWithTag(ModuleRanges, IMPORT_SCAN_TAG);
        return 0;
    }

ULONG HitCount = 0;
    PUCHAR SearchBase = (PUCHAR)SearchStartAddr;
    for (SIZE_T Index = 0; Index + 6 <= SearchSize; ++Index)
    {
        if (SearchBase[Index] != 0xFF || SearchBase[Index + 1] != 0x25)
        {
            continue;
        }

ULONG_PTR TargetFunction = 0;
        __try
        {
            LONG RelativeOffset = *(LONG*)(SearchBase + Index + 2);
            ULONG_PTR ImportThunk = SearchStartAddr + Index + 6 + RelativeOffset;
            TargetFunction = *(ULONG_PTR*)ImportThunk;
        }
        __except (EXCEPTION_EXECUTE_HANDLER)
        {
            continue;
        }

PMODULE_ADDRESS_RANGE ModuleRange = FindModuleByAddress(
            ModuleRanges,
            ModuleCount,
            TargetFunction);
        if (ModuleRange == NULL)
        {
            continue;
        }

PCCHAR ExportName = LookupExportNameByAddress(ModuleRange->ImageStart, TargetFunction);
        DbgPrintEx(
            DPFLTR_IHVDRIVER_ID,
            DPFLTR_INFO_LEVEL,
            "可疑调用 Module = %s   ImportThunk = 0x%p   TargetFunc = 0x%p   FuncName = %s. \n",
            ModuleRange->ModuleName,
            (PVOID)(SearchStartAddr + Index),
            (PVOID)TargetFunction,
            ExportName != NULL ? ExportName : "Unknown");

++HitCount;
    }

ExFreePoolWithTag(ModuleRanges, IMPORT_SCAN_TAG);
    return HitCount;
}
```

### 5.2 测试结果

测试环境为`Win11 25H2`，将前一步扫描得到的可疑匿名内存范围硬编码到测试工程中，测试效果如下所示，成功在可疑内存范围扫描到正常的`导入表Stub特征`：
 ![](upload/attach/202604/953262_STVJ95VQS2XW8GA.webp)
![](Image/5-2ScanImportFeature.png)

### 5.3 剥离导入表Stub特征

既然前文已经证明，匿名可执行内存中的 `FF 25` 导入 `Stub` 可以作为一类较强的编译器特征，那么一个很自然的思路就是：不再依赖静态导入表。这样一来，编译器就不会再为这些导入函数生成成片的 `jmp qword ptr [rip+xxxx]` 跳转桩，IDA 中的 `Imports` 页面也会随之大幅减少，甚至不再保留那些敏感 API 的显式导入项。

### 5.4 延迟导入API

既然不依赖静态导入表，就需要驱动在运行时动态找到对应函数的绝对地址进行调用，驱动开发中，我们需要调用的大部分函数都是由`ntoskrnl.exe`进行导出，这个延迟导入必须做到以下几点：

- 不依赖任何接口，获取`ntoskrnl`内核模块地址
- 解析`ntoskrnl`模块的PE结构，解析其导出表
- 解析导出表中函数名称字符串时，需要动态计算其字符串Hash值（如果采用字符串直接对比，会在`靶场驱动`PE文件中留下敏感字符串痕迹）
- 根据函数名Hash对比，取到目标函数绝对地址

关于这个库，笔者花了点时间实现了以上几点，其中关键代码实现如下所示：

```c
PVOID GetntoskrnlExportAddressByHash(ULONG FunctionHash)
{
    if (FunctionHash == 0)
    {
        return NULL;
    }

ULONG64 ModuleBase = (ULONG64)GetKernelBaseWithoutAPI();
    if (ModuleBase == NULL)
    {
        return NULL;
    }

PIMAGE_DOS_HEADER DosHeader = (PIMAGE_DOS_HEADER)ModuleBase;
    PIMAGE_NT_HEADERS NtHeader = (PIMAGE_NT_HEADERS)(ModuleBase + (ULONG)DosHeader->e_lfanew);
    IMAGE_DATA_DIRECTORY ExportDataDirectory = NtHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT];

if (ExportDataDirectory.VirtualAddress == 0 ||
        ExportDataDirectory.Size < sizeof(IMAGE_EXPORT_DIRECTORY))
    {
        return NULL;
    }

PIMAGE_EXPORT_DIRECTORY ExportDirectory =(PIMAGE_EXPORT_DIRECTORY)(ModuleBase + ExportDataDirectory.VirtualAddress);
    PULONG AddressOfFunctions = (PULONG)(ModuleBase + ExportDirectory->AddressOfFunctions);
    PULONG AddressOfNames = (PULONG)(ModuleBase + ExportDirectory->AddressOfNames);
    PUSHORT AddressOfNameOrdinals = (PUSHORT)(ModuleBase + ExportDirectory->AddressOfNameOrdinals);

for (ULONG i = 0; i < ExportDirectory->NumberOfNames; i++)
    {
        PCHAR ExportName = (PCHAR)(ModuleBase + AddressOfNames[i]);
        if (KernelRuntimeImport::detail::StringHashConstexpr(ExportName) == FunctionHash)
        {
            USHORT OrdinalIndex = AddressOfNameOrdinals[i];
            return (PVOID)(ModuleBase + AddressOfFunctions[OrdinalIndex]);
        }
    }

return NULL;
}
```

## 6. 扫描被劫持的系统调用指针

前文中介绍了2种扫描可疑、匿名内存的方式，以及根据编译器导入特征扫描可疑内存的方法。这些操作都是针对于`靶场驱动`内存方面的检测。

在本章节中，会讲解如何检测所谓的"隐蔽"通讯，也就是剖析如何扫描`ntoskrnl`模块中疑似被劫持的CFG点。

### 6.1 扫描 ntoskrnl 中的 CFG 间接调用点

本节的目标，不再是扫描匿名可执行内存，而是反过来从 ntoskrnl.exe 自身入手，检查其中那些可能被用于隐蔽通讯的 CFG 间接调用点是否被异常修改。整体思路并不复杂，可以概括为下面 `5` 步：

- 先定位 ntoskrnl 中的 __guard_dispatch_icall
- 再搜索 .text、PAGE 节区里所有对它的 call
- 对每个命中的 call，向前回溯查找对应的 mov rax, [rip+disp32]
- 解析出真实的数据指针槽位地址，并读取其中保存的回调函数地址
- 最后判断这个回调地址是否仍然落在正常模块范围内

### 6.2 定位当前内核中的 __guard_dispatch_icall

由于不同版本内核的实现细节存在差异，这里并没有依赖固定偏移，而是按照`构建号`选择不同的特征码进行搜索：

```c
ULONG_PTR GetGuardDispatchAddress(VOID)
{
    ULONG_PTR CodeAddr = 0;
    RTL_OSVERSIONINFOW VersionInformation = { 0 };
    RtlGetVersion(&VersionInformation);

// Win10 19041 ~ Win11 24H2
    if (VersionInformation.dwBuildNumber >= 19041 && VersionInformation.dwBuildNumber < 26200)
    {
        CodeAddr = SearchFeatureCode(
            "ntoskrnl.exe",
            "PAGE",
            (PCUCHAR)"\x48\x8B\x05\xB9\xF6\x51\x00\x85\xC9\x49\x8B\xCA\x41\x0F\x95\xC0\xE8\x93\x1F\xD0\xFF\x48\x83\xC4\x38\xC3",
            "xxx????xxxxxxxxxx????xxx?x",
            16);
    }
    // Win11 25H2 or higher
    else if (VersionInformation.dwBuildNumber >= 26200)
    {
        CodeAddr = SearchFeatureCode(
            "ntoskrnl.exe",
            "PAGE",
         (PCUCHAR)"\x48\x8B\x05\xA4\x10\x53\x00\x4C\x8D\x4C\x24\x44\x8B\xD7\x48\x8B\xCB\xE8\xAD\x46\xCD\xFF\x89\x44\x24\x40\xE9\x4F\x17\x00\x00",
            "xxx????xxxx?xxxxxx????xxx?x????",
            17);
    }

PVOID GuardDispatchAddress = DEREF_RELATIVE_ADDR(PVOID, CodeAddr, 1);
    return (ULONG_PTR)GuardDispatchAddress;
}
```

### 6.3 扫描内核模块代码中所有对 __guard_dispatch_icall 的调用

拿到 `__guard_dispatch_icall` 的地址后，第二步就是在 `ntoskrnl` 的 `.text` 和 `PAGE` 节区中，搜索所有直接 `call` 到它的位置。因为 x64 下相对调用通常表现为 `E8 + disp32`，所以这里只需要在目标节区中逐字节扫描 `0xE8`，再把相对偏移还原成真实调用目标即可：

```c
static ULONG SearchGuardDispatchCallsInSection(
    IN ULONG_PTR ModuleBase,
    IN PCCHAR SectionName,
    IN ULONG_PTR GuardDispatchAddress,
    IN PLIST_ENTRY CallList)
{
    ULONG_PTR SectionStart = 0;
    ULONG_PTR SectionEnd = 0;
    if (CallList == NULL || !QuerySectionRange(ModuleBase, SectionName, &SectionStart, &SectionEnd))
    {
        return 0;
    }

ULONG HitCount = 0;
    for (ULONG_PTR Code = SectionStart; Code + 5 <= SectionEnd; ++Code)
    {
        if (*(PUCHAR)Code != 0xE8)
        {
            continue;
        }

LONG RelativeOffset = *(PLONG)(Code + 1);
        ULONG_PTR CallTarget = Code + 5 + RelativeOffset;
        if (CallTarget != GuardDispatchAddress)
        {
            continue;
        }

PGUARD_DISPATCH_CALL_ENTRY CallEntry =
            (PGUARD_DISPATCH_CALL_ENTRY)ExAllocatePoolWithTag(
                NonPagedPoolNx,
                sizeof(GUARD_DISPATCH_CALL_ENTRY),
                GUARD_CALL_TAG);

if (CallEntry == NULL)
        {
            break;
        }

RtlZeroMemory(CallEntry, sizeof(GUARD_DISPATCH_CALL_ENTRY));
        CallEntry->CodeAddr = Code;
        InsertTailList(CallList, &CallEntry->ListEntry);

++HitCount;
    }

return HitCount;
}
```

### 6.4 还原数据指针槽位

对于这类 `CFG` 间接调用点，其前面通常会有一条类似下面这样的取值指令：

```c
mov rax, [rip+disp32]
```

其作用就是先从某个全局槽位中取出函数指针，再交给后面的 __guard_dispatch_icall 去完成最终分发。因此，当前实现采用了一种比较直接的办法：对每个命中的 call __guard_dispatch_icall，向前回溯 0x40 字节，搜索最近的一条 `48 8B 05`，也就是 mov rax, [rip+disp32] 指令。

```c
static VOID AnalyzeGuardDispatchCallList ( IN PLIST_ENTRY CallList)
{
    if (CallList == NULL)
    {
        return;
    }

for (PLIST_ENTRY ListEntry = CallList->Flink; ListEntry != CallList; )
    {
        PLIST_ENTRY NextEntry = ListEntry->Flink;
        PGUARD_DISPATCH_CALL_ENTRY CallEntry = CONTAINING_RECORD(
            ListEntry,
            GUARD_DISPATCH_CALL_ENTRY,
            ListEntry);

ULONG_PTR SearchStart = CallEntry->CodeAddr - 0x40;
        ULONG_PTR SearchEnd = CallEntry->CodeAddr;
        ULONG_PTR MovRaxCodeAddr = 0;

for (ULONG_PTR Code = SearchStart; Code + 7 <= SearchEnd; ++Code)
        {
            PUCHAR Bytes = (PUCHAR)Code;
            if (Bytes[0] == 0x48 && Bytes[1] == 0x8B && Bytes[2] == 0x05)
            {
                MovRaxCodeAddr = Code;
            }
        }

if (MovRaxCodeAddr == 0)
        {
            RemoveEntryList(&CallEntry->ListEntry);
            ExFreePoolWithTag(CallEntry, GUARD_CALL_TAG);
            ListEntry = NextEntry;
            continue;
        }

CallEntry->MovRaxCodeAddr = MovRaxCodeAddr;
        CallEntry->DataPtrAddr = (ULONG_PTR)DEREF_RELATIVE_ADDR(PVOID, MovRaxCodeAddr, 3);
        if (!MmIsAddressValid((PVOID)CallEntry->DataPtrAddr))
        {
            RemoveEntryList(&CallEntry->ListEntry);
            ExFreePoolWithTag(CallEntry, GUARD_CALL_TAG);
            ListEntry = NextEntry;
            continue;
        }

CallEntry->CallbackAddr = *(PULONG_PTR)CallEntry->DataPtrAddr;
        if (!IsKernelAddress(CallEntry->CallbackAddr) ||
            !MmIsAddressValid((PVOID)CallEntry->CallbackAddr))
        {
            RemoveEntryList(&CallEntry->ListEntry);
            ExFreePoolWithTag(CallEntry, GUARD_CALL_TAG);
            ListEntry = NextEntry;
            continue;
        }

ListEntry = NextEntry;
    }
}
```

### 6.5 过滤正常CFG点

仅仅拿到槽位地址和回调地址，还不足以说明它一定被劫持。为了减少误报，当前实现又补了两层过滤。

第一层过滤，是要求这个保存回调指针的槽位本身必须位于 `ntoskrnl.exe` 的 `.data` 节区中。因为本文关注的是"内核自身数据区中的函数指针槽位被修改"这一类场景，如果槽位都不在 `.data`，那大概率并不是本文要找的目标：

```c
static VOID FilterGuardDispatchCallListByDataSection (IN PLIST_ENTRY CallList)
{
    ULONG ModuleSize = 0;
    ULONG_PTR ModuleBase = QueryModuleInfo("ntoskrnl.exe", &ModuleSize);
    if (ModuleBase == 0)
    {
        return;
    }

ULONG_PTR DataStart = 0;
    ULONG_PTR DataEnd = 0;
    if (!QuerySectionRange(ModuleBase, ".data", &DataStart, &DataEnd))
    {
        return;
    }

if (!(CallEntry->DataPtrAddr >= DataStart && CallEntry->DataPtrAddr < DataEnd))
        {
            RemoveEntryList(&CallEntry->ListEntry);
            ExFreePoolWithTag(CallEntry, GUARD_CALL_TAG);
        }

ListEntry = NextEntry;
    }
}
```

第二层过滤，则是检查槽位里当前保存的回调函数地址，是否仍然落在某个正常加载模块的映像范围内。如果该地址位于 `ntoskrnl.exe`、`Wdf01000.sys` 或其它合法模块的 [ImageBase, ImageEnd) 区间内，说明它大概率仍然是合法回调；反之，如果它落在`匿名内存`、`非模块区域`，或者其它异常地址，那么这类点就值得重点关注，演示代码中会将可疑点打印输出：

```c
static VOID FilterGuardDispatchCallListByModuleSnapshot (
    IN PLIST_ENTRY CallList,
    IN PMODULE_ADDRESS_RANGE ModuleRanges,
    IN ULONG ModuleCount)
{
    if (CallList == NULL || ModuleRanges == NULL || ModuleCount == 0)
    {
        return;
    }

BOOLEAN IsValidModuleAddress = FALSE;
        for (ULONG Index = 0; Index < ModuleCount; ++Index)
        {
            if (CallEntry->CallbackAddr >= ModuleRanges[Index].ImageStart &&
                CallEntry->CallbackAddr < ModuleRanges[Index].ImageEnd)
            {
                IsValidModuleAddress = TRUE;
                break;
            }
        }

if (IsValidModuleAddress)
        {
            RemoveEntryList(&CallEntry->ListEntry);
            ExFreePoolWithTag(CallEntry, GUARD_CALL_TAG);
        }
        else
        {
            KdPrint(("Exception ---------- Call = 0x%p   MovRax = 0x%p   Slot = 0x%p   Callback = 0x%p. \n",
                (PVOID)CallEntry->CodeAddr,
                (PVOID)CallEntry->MovRaxCodeAddr,
                (PVOID)CallEntry->DataPtrAddr,
                (PVOID)CallEntry->CallbackAddr));
        }

ListEntry = NextEntry;
    }
}
```

### 6.6 扫描、检测测试

测试系统环境为`Win11 25H2`，顺利扫描出被`靶场驱动`所劫持的系统调用指针，如图所示：
 ![](upload/attach/202604/953262_XXE4WDCNQ9HEAM3.webp)
![](Image/6-5ScanDataPtrHook.png)

### 6.7 绕过常规的指针扫描

关于绕过扫描，笔者这里仅给出简答思路，构造一个跳板，隐藏真实的通讯回调入口，在跳板函数中解密出真正的回调，再进行调用，`伪代码`如下（随手写的，不保证能用）：

```c
sub rsp, 100h
mov rax, g_HookCommEncrypted
xor rax, g_XorKey
call rax
add rsp, 100h
ret
```

在驱动初始化时，动态修复上述的跳板Shellcode，之后在正常、合法模块内搜索一处`内存空洞`，将跳板Shellcode放置过去。

当然，这种也只是奇技淫巧罢了。成熟、完备的检测方案，往往还会重载内核文件，对比回调函数指纹是否正确。

## 7. Github开源仓库地址

IDA脚本：扫描函数引用、特征码生成脚本，<a href="elink@964K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6e0K9r3W2F1L8W2)9J5k6p5S2G2L8h3g2Q4x3V1k6u0c8p5q4Q4x3X3c8e0j5%4u0A6M7s2c8K6">Shinn-Home/IDA-Scripts</a>

重映射靶场驱动、"隐蔽"通讯框架：<a href="elink@745K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6e0K9r3W2F1L8W2)9J5k6p5S2G2L8h3g2Q4x3V1k6d9k6h3#2S2M7p5c8J5K9i4k6W2M7R3`.`.">Shinn-Home/RemapDriver</a>

PoolBigPageTable对象分析与扫描：<a href="elink@b30K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6e0K9r3W2F1L8W2)9J5k6p5S2G2L8h3g2Q4x3V1k6p5k6i4c8W2j5%4c8y4j5h3&6#2j5h3I4y4j5i4m8p5M7X3W2$3k6i4t1`.">Shinn-Home/PoolBigPageTable</a>

枚举内核态下所有的可执行PTE条目：<a href="elink@70fK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6e0K9r3W2F1L8W2)9J5k6p5S2G2L8h3g2Q4x3V1k6p5k6i4c8W2j5%4c8y4j5h3&6#2j5h3I4y4j5i4m8p5M7X3W2$3k6i4t1`.">Shinn-Home/PTE_Walk</a>

根据编译器导入Stub特征进行扫描：<a href="elink@6ccK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6e0K9r3W2F1L8W2)9J5k6p5S2G2L8h3g2Q4x3V1k6p5k6i4c8W2j5%4c8y4j5h3&6#2j5h3I4y4j5i4m8p5M7X3W2$3k6i4t1`.">Shinn-Home/ScanImportFeature</a>

扫描当前内核下疑似被劫持的CFG项：<a href="elink@150K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6e0K9r3W2F1L8W2)9J5k6p5S2G2L8h3g2Q4x3V1k6p5k6i4c8W2j5%4c8y4j5h3&6#2j5h3I4y4j5i4m8p5M7X3W2$3k6i4t1`.">Shinn-Home/ScanDataPtrHook</a>

驱动运行时动态导入API：<a href="elink@f1eK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6e0K9r3W2F1L8W2)9J5k6p5S2G2L8h3g2Q4x3V1k6w2k6i4u0F1k6h3I4d9N6h3&6@1K9h3#2W2d9h3#2H3L8%4u0@1">Shinn-Home/KernelRuntimeImport</a>

## 8. 结束语

如果各位朋友看完本文觉得有所帮助、启发，欢迎点赞、收藏本文。另外，本文所涉及到的教学代码均已完整开源到Github，欢迎给仓库Star！

各位朋友、师傅们的支持，对我来说也是一种正反馈、激励。各位朋友如果对此类内容比较感兴趣，笔者以后会多抽空，将这些年学习、工作中遇到的比较有意思的技术点分享出来！

回复或点赞可查看完整内容

冰与火的战歌：Windows内核攻防实战高级班！从零到实战，融合AI与Windows内核攻防全技术栈，打造具备自动化能力的内核开发高手。

最后于 2026-4-25 15:14 被__Shinn编辑，原因：

#基础知识 #系统内核 #驱动开发 #HOOK/注入 #开源分享 #开发技巧 #工具脚本

收藏・65

点赞・205

打赏

赞赏记录

参与人

雪币

留言

时间

whca

这个讨论对我很有帮助，谢谢！

6天前

戒烟

非常支持你的观点！

2026-9-13 21:03

wx_起飞！

感谢你的积极参与，期待更多精彩内容！

2026-9-13 19:49

Eclora

感谢你分享这么好的资源！

2026-9-12 11:23

z许

为你点赞！

2026-9-11 18:35

Aar0n

为你点赞！

2026-9-9 14:21

ZGADO

期待更多优质内容的分享，论坛有你更精彩！

2026-9-8 21:15

hkdong

谢谢你的细致分析，受益匪浅！

2026-9-8 12:43

铭信

你的帖子非常有用，感谢分享！

2026-9-7 21:56

FiftySeven

你的分享对大家帮助很大，非常感谢！

2026-9-1 23:49

黑手鱼

你的分享对大家帮助很大，非常感谢！

2026-9-1 20:03

Xierluo

期待更多优质内容的分享，论坛有你更精彩！

2026-9-1 15:39

3rbbsbrb

为你点赞！

2026-8-30 23:27

1k0ct

这个讨论对我很有帮助，谢谢！

2026-8-28 10:45

xyzliao

你的帖子非常有用，感谢分享！

2026-8-27 23:14

git_29575booksnature

这个讨论对我很有帮助，谢谢！

2026-8-27 23:12

上网鱼

感谢你分享这么好的资源！

2026-8-27 22:01

git_87710XIXaa

感谢你的积极参与，期待更多精彩内容！

2026-8-27 02:54

git_99969chiaki-1999

非常支持你的观点！

2026-8-25 14:27

mb_qhcwsgua

这个讨论对我很有帮助，谢谢！

2026-8-22 14:31

mb_lthgjpwj

为你点赞！

2026-8-21 07:54

晨曦。

为你点赞！

2026-8-17 04:23

the_hs

非常支持你的观点！

2026-8-16 12:51

mb_cebxltxx

为你点赞！

2026-8-16 08:53

TnT柠檬茶

为你点赞！

2026-8-14 17:54

PLDQ

你的帖子非常有用，感谢分享！

2026-8-12 14:10

mb_jvtyvxey

感谢你的积极参与，期待更多精彩内容！

2026-8-11 21:51

蒙奇·D

这个讨论对我很有帮助，谢谢！

2026-8-10 16:43

ReCreateLife

你的帖子非常有用，感谢分享！

2026-8-10 05:07

mb_ocspwpcp

你的帖子非常有用，感谢分享！

2026-8-8 13:39

mb_xujtvamv

非常支持你的观点！

2026-8-7 23:00

git_46183EBalloon

为你点赞！

2026-8-5 03:43

DingDangCatt

谢谢你的细致分析，受益匪浅！

2026-7-28 11:09

吃辣超人

感谢你的贡献，论坛因你而更加精彩！

2026-7-23 20:32

mb_kjajfjvq

你的分享对大家帮助很大，非常感谢！

2026-7-19 14:34

javaphy

感谢你的积极参与，期待更多精彩内容！

2026-7-17 19:47

wx_晨梦

谢谢你的细致分析，受益匪浅！

2026-7-16 10:28

Hook你的心跳

为你点赞！

2026-7-15 14:10

mb_aimiyfrp

非常支持你的观点！

2026-7-12 08:37

咖啡_741298

感谢你分享这么好的资源！

2026-7-12 02:09

a小灰灰

感谢你分享这么好的资源！

2026-7-10 22:02

git_6122055555998789

期待更多优质内容的分享，论坛有你更精彩！

2026-7-9 00:20

n013ody

为你点赞！

2026-7-7 01:07

yuanyouran

感谢你的积极参与，期待更多精彩内容！

2026-7-6 17:12

wx_Jack_109

你的分享对大家帮助很大，非常感谢！

2026-7-5 14:40

NonMirror

感谢你分享这么好的资源！

2026-7-2 16:54

mb_vokyxpgb

期待更多优质内容的分享，论坛有你更精彩！

2026-7-2 13:28

黑匣子

你的帖子非常有用，感谢分享！

2026-7-2 03:13

mb_ytalqmdq

你的分享对大家帮助很大，非常感谢！

2026-6-29 13:45

萌新Peter

感谢你分享这么好的资源！

2026-6-29 08:50

x1a0f3n9

非常支持你的观点！

2026-6-29 04:54

wx_L_884

谢谢你的细致分析，受益匪浅！

2026-6-28 18:42

gongchuang

感谢你分享这么好的资源！

2026-6-27 18:29

乌克莉莉

谢谢你的细致分析，受益匪浅！

2026-6-25 05:57

X-Blades

你的分享对大家帮助很大，非常感谢！

2026-6-24 07:21

wx_洋葱

感谢你分享这么好的资源！

2026-6-24 03:51

SuuHhan

你的帖子非常有用，感谢分享！

2026-6-23 16:19

mb_iirigsjr

这个讨论对我很有帮助，谢谢！

2026-6-21 18:38

wx_123_754

为你点赞！

2026-6-20 01:14

mb_uyapkahl

你的帖子非常有用，感谢分享！

2026-6-18 13:00

KanielOutis

感谢你分享这么好的资源！

2026-6-18 00:22

领悟test

感谢你分享这么好的资源！

2026-6-16 16:08

徽墨写代码

为你点赞！

2026-6-14 22:34

劫局丶

感谢你的积极参与，期待更多精彩内容！

2026-6-12 18:01

好听的网名

感谢你的贡献，论坛因你而更加精彩！

2026-6-10 16:22

像个假号

期待更多优质内容的分享，论坛有你更精彩！

2026-6-9 16:54

mb_zhynsmev

你的帖子非常有用，感谢分享！

2026-6-9 12:08

MarsW

感谢你的积极参与，期待更多精彩内容！

2026-6-8 22:41

伟叔叔

你的帖子非常有用，感谢分享！

2026-6-6 18:22

git_96499ch3va

非常支持你的观点！

2026-6-6 16:10

mb_zdkihfht

为你点赞！

2026-6-6 09:47

nohacked

你的分享对大家帮助很大，非常感谢！

2026-6-5 20:38

寒冰心结

你的分享对大家帮助很大，非常感谢！

2026-6-3 17:13

Reverser07

期待更多优质内容的分享，论坛有你更精彩！

2026-6-3 16:13

renminbi

谢谢你的细致分析，受益匪浅！

2026-6-3 10:21

璀璨访华

你的分享对大家帮助很大，非常感谢！

2026-6-1 21:02

CSuperMan

非常支持你的观点！

2026-6-1 12:53

AyaseMiya

你的分享对大家帮助很大，非常感谢！

2026-6-1 12:06

wx_沫

你的帖子非常有用，感谢分享！

2026-5-31 18:00

冰布酱

为你点赞！

2026-5-29 10:25

khfrefhewhfl

感谢你的贡献，论坛因你而更加精彩！

2026-5-27 21:36

appview

谢谢你的细致分析，受益匪浅！

2026-5-26 13:36

samshine

为你点赞！

2026-5-26 00:07

深山樵夫

感谢你的积极参与，期待更多精彩内容！

2026-5-25 10:05

ReGenesis

为你点赞！

2026-5-25 05:41

git_20420Yusukedao-0610

这个讨论对我很有帮助，谢谢！

2026-5-25 02:05

romobin

为你点赞！

2026-5-24 18:21

宋仁杰

期待更多优质内容的分享，论坛有你更精彩！

2026-5-22 22:49

mb_zuuyenge

谢谢你的细致分析，受益匪浅！

2026-5-20 21:14

achenyuan

非常支持你的观点！

2026-5-20 17:11

耶巴蒂

你的帖子非常有用，感谢分享！

2026-5-19 09:50

xxxark

为你点赞！

2026-5-19 08:51

Liv_T

你的分享对大家帮助很大，非常感谢！

2026-5-18 21:08

逍遥m

期待更多优质内容的分享，论坛有你更精彩！

2026-5-17 01:06

边缘

你的分享对大家帮助很大，非常感谢！

2026-5-16 19:35

会逆向的萝卜

感谢你的积极参与，期待更多精彩内容！

2026-5-16 15:08

会简单的

感谢你的贡献，论坛因你而更加精彩！

2026-5-12 09:50

mb_gqhzzubh

期待更多优质内容的分享，论坛有你更精彩！

2026-5-12 01:40

范琪姆

这个讨论对我很有帮助，谢谢！

2026-5-11 16:41

銘記

这个讨论对我很有帮助，谢谢！

2026-5-9 20:28

酒敬丨自由

你的帖子非常有用，感谢分享！

2026-5-9 09:09

hahayzl

期待更多优质内容的分享，论坛有你更精彩！

2026-5-7 21:59

梦里看花

这个讨论对我很有帮助，谢谢！

2026-5-7 21:11

萌克力

感谢你的贡献，论坛因你而更加精彩！

2026-5-7 20:55

萌新一枚

感谢你的积极参与，期待更多精彩内容！

2026-5-7 12:26

5h3r10(l{

你的分享对大家帮助很大，非常感谢！

2026-5-6 15:30

DemonCall

非常支持你的观点！

2026-5-4 23:07

漫雾.

为你点赞！

2026-5-2 15:37

hy127

感谢你的积极参与，期待更多精彩内容！

2026-5-2 06:21

ink1

为你点赞！

2026-5-2 00:45

Cohen

你的帖子非常有用，感谢分享！

2026-5-1 22:44

lysha

你的分享对大家帮助很大，非常感谢！

2026-4-30 18:34

陌上陌下

谢谢你的细致分析，受益匪浅！

2026-4-30 00:04

n0.ob

这个讨论对我很有帮助，谢谢！

2026-4-29 15:44

aresmar

非常支持你的观点！

2026-4-29 11:06

mb_urzqsoer

为你点赞！

2026-4-28 23:44

git_64975dghjgg

这个讨论对我很有帮助，谢谢！

2026-4-28 23:27

Leo_Starlet

你的分享对大家帮助很大，非常感谢！

2026-4-28 21:59

Archar

为你点赞！

2026-4-28 16:37

wx_一天

为你点赞！

2026-4-28 15:41

wx_Dispa1r

你的分享对大家帮助很大，非常感谢！

2026-4-28 14:26

夏威夷果

期待更多优质内容的分享，论坛有你更精彩！

2026-4-28 13:08

AsuraCoder

为你点赞！

2026-4-28 12:05

Lnju

期待更多优质内容的分享，论坛有你更精彩！

2026-4-28 11:51

mb_ccvrbxbg

感谢你分享这么好的资源！

2026-4-28 10:23

mb_uruwpimj

为你点赞！

2026-4-28 02:00

333333

你的帖子非常有用，感谢分享！

2026-4-27 23:20

MGo

感谢你分享这么好的资源！

2026-4-27 20:32

dxasqw

期待更多优质内容的分享，论坛有你更精彩！

2026-4-27 20:11

mb_soqnauke

非常支持你的观点！

2026-4-27 19:09

Ae0LuS

为你点赞！

2026-4-27 18:52

孤木落

非常支持你的观点！

2026-4-27 16:59

mb_nzeapxjl

非常支持你的观点！

2026-4-27 14:40

paranioa

非常支持你的观点！

2026-4-27 14:31

不歪

感谢你的积极参与，期待更多精彩内容！

2026-4-27 14:24

zengsunsan

非常支持你的观点！

2026-4-27 13:13

wx_五角星

感谢你分享这么好的资源！

2026-4-27 12:22

Dy1an

为你点赞！

2026-4-27 09:47

七夜大大

你的帖子非常有用，感谢分享！

2026-4-27 08:22

Unsped

谢谢你的细致分析，受益匪浅！

2026-4-27 08:15

只会逆一点点

感谢你的积极参与，期待更多精彩内容！

2026-4-26 23:56

麦瑞鸭

非常支持你的观点！

2026-4-26 23:00

hxyyds

非常支持你的观点！

2026-4-26 20:01

苦瓜.

为你点赞！

2026-4-26 15:19

ONewTach

感谢你的积极参与，期待更多精彩内容！

2026-4-26 14:31

Peyriat

期待更多优质内容的分享，论坛有你更精彩！

2026-4-26 12:48

a0yark

感谢你的贡献，论坛因你而更加精彩！

2026-4-26 10:39

熟悉而又陌生

感谢你分享这么好的资源！

2026-4-26 05:55

程序原

为你点赞！

2026-4-26 05:50

npc0vo

你的帖子非常有用，感谢分享！

2026-4-26 01:32

lovezeng

你的帖子非常有用，感谢分享！

2026-4-25 22:10

Mxixihaha

这个讨论对我很有帮助，谢谢！

2026-4-25 17:47

mb_bogoqnvg

感谢你的积极参与，期待更多精彩内容！

2026-4-25 14:39

uvbs

这个讨论对我很有帮助，谢谢！

2026-4-25 09:18

逗号man

感谢你分享这么好的资源！

2026-4-25 02:19

pexillove

谢谢你的细致分析，受益匪浅！

2026-4-24 22:29

寻影星尘

期待更多优质内容的分享，论坛有你更精彩！

2026-4-24 21:27

wowocock

谢谢你的细致分析，受益匪浅！

2026-4-24 18:23

wake0p

为你点赞！

2026-4-24 16:28

慕容溯雪

这个讨论对我很有帮助，谢谢！

2026-4-24 14:01

fujing

非常支持你的观点！

2026-4-24 11:46

聂风云

非常支持你的观点！

2026-4-24 09:45

mb_fgsdhdlk

非常支持你的观点！

2026-4-24 07:57

mb_cntjvjao

你的帖子非常有用，感谢分享！

2026-4-24 04:23

风铃i

非常支持你的观点！

2026-4-24 01:52

Wgkhtt

你的帖子非常有用，感谢分享！

2026-4-23 23:28

asd

你的分享对大家帮助很大，非常感谢！

2026-4-23 22:58

zhangbuib

非常支持你的观点！

2026-4-23 22:01

UserXCh

为你点赞！

2026-4-23 19:54

马来

感谢你分享这么好的资源！

2026-4-23 19:02

DaiXiaoHuer

你的帖子非常有用，感谢分享！

2026-4-23 15:28

wx_苏_591

你的帖子非常有用，感谢分享！

2026-4-23 14:31

白色风信子

这个讨论对我很有帮助，谢谢！

2026-4-23 14:16

mb_timxattr

为你点赞！

2026-4-23 10:53

mb_hzfcelhs

感谢你分享这么好的资源！

2026-4-23 09:56

mb_dtidoewd

感谢你的贡献，论坛因你而更加精彩！

2026-4-23 09:49

wx_张三_488

感谢你的贡献，论坛因你而更加精彩！

2026-4-23 09:03

milko

感谢你的贡献，论坛因你而更加精彩！

2026-4-23 08:54

cloudhoter

你的分享对大家帮助很大，非常感谢！

2026-4-23 03:24

小柯南

感谢你的贡献，论坛因你而更加精彩！

2026-4-23 00:02

mb_dojbfwmz

感谢你分享这么好的资源！

2026-4-22 22:51

令狐双

为你点赞！

2026-4-22 20:14

兔子先生_168490

非常支持你的观点！

2026-4-22 19:23

DannysMask

谢谢你的细致分析，受益匪浅！

2026-4-22 15:56

kaokaoyou

非常支持你的观点！

2026-4-22 14:55

青丝梦

期待更多优质内容的分享，论坛有你更精彩！

2026-4-22 13:51

木志本柯

这个讨论对我很有帮助，谢谢！

2026-4-22 11:33

lpmjknj

感谢你的贡献，论坛因你而更加精彩！

2026-4-22 10:56

mb_thmdyxrm

为你点赞！

2026-4-22 10:53

loqich

感谢你分享这么好的资源！

2026-4-22 10:46

顽劣

谢谢你的细致分析，受益匪浅！

2026-4-22 10:32

huangyalei

非常支持你的观点！

2026-4-22 10:16

0x指纹

感谢你分享这么好的资源！

2026-4-22 10:08

pysafe

这个讨论对我很有帮助，谢谢！

2026-4-22 10:06

tacesrever

感谢你的贡献，论坛因你而更加精彩！

2026-4-22 10:06

我的小拇指啊

感谢你的积极参与，期待更多精彩内容！

2026-4-22 10:04

mb_kphqygvr

你的分享对大家帮助很大，非常感谢！

2026-4-22 09:47

nekaxi

感谢你分享这么好的资源！

2026-4-22 06:42

ldljlzw

这个讨论对我很有帮助，谢谢！

2026-4-22 06:24

mb_soqpzdaf

为你点赞！

2026-4-22 06:18

mb_vbeijwyi

你的帖子非常有用，感谢分享！

2026-4-22 05:33

mb_aorspzpl

这个讨论对我很有帮助，谢谢！

2026-4-22 04:49

relost

感谢你的积极参与，期待更多精彩内容！

2026-4-22 01:55

mb_bzkmcyjt

这个讨论对我很有帮助，谢谢！

2026-4-22 01:31

syser

非常支持你的观点！

2026-4-22 01:15

最新回复 (196) 1 2 3 4 5 6 7 8 ▶
Hxzzyyi 雪币： 29 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 4 粉丝 0 关注私信	Hxzzyyi 2 楼 666 2026-4-22 00:51 0
mb_aorspzpl 雪币： 36 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 22 粉丝 0 关注私信	mb_aorspzpl 3 楼 nb 2026-4-22 04:50 0
wfjun 雪币： 149 活跃值： (439) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 15 粉丝 0 关注私信	wfjun 4 楼 666 2026-4-22 09:22 0
DebugGirls 雪币： 6 活跃值： (1783) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 8 粉丝 0 关注私信	DebugGirls 5 楼 6 2026-4-22 09:40 0
mb_heqvlbnm 雪币： 234 活跃值： (3220) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 32 粉丝 0 关注私信	mb_heqvlbnm 6 楼 666 2026-4-22 09:42 0
幽灵XZ 雪币： 1014 活跃值： (2048) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 60 粉丝 0 关注私信	幽灵XZ 7 楼厉害了，大佬，???? 2026-4-22 09:47 0
mb_kphqygvr 雪币： 10 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 11 粉丝 0 关注私信	mb_kphqygvr 8 楼怪不得看见好多某X的5字游戏的外挂都是用的无痕映射，但是百分百触发1分钟，检测点太多了 2026-4-22 09:48 1
逆向爱好者雪币： 3536 活跃值： (7799) 能力值： ( LV3，RANK：20 ) 在线值：发帖 37 回帖 280 粉丝 24 关注私信	逆向爱好者 9 楼牛逼牛逼牛逼 2026-4-22 10:03 0
Olii 雪币： 45 活跃值： (4316) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 30 粉丝 1 关注私信	Olii 10 楼感谢分享 2026-4-22 10:33 0
Abelly 雪币： 388 活跃值： (2750) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 30 粉丝 2 关注私信	Abelly 11 楼感谢分享 2026-4-22 10:43 0
Deice 雪币： 113 活跃值： (2095) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 23 粉丝 0 关注私信	Deice 12 楼不存在绝对意义上的无痕化驱动 2026-4-22 11:27 0
糖糖9 雪币： 292 活跃值： (1707) 能力值： ( LV3，RANK：29 ) 在线值：发帖 0 回帖 41 粉丝 0 关注私信	糖糖9 13 楼感谢分享 2026-4-22 11:48 0
木志本柯雪币： 6564 活跃值： (8619) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 446 粉丝 8 关注私信	木志本柯 14 楼可以存在绝对意义的无痕化驱动，但目前的x86架构上是不存在的。要想做绝对意义的无痕驱动，首先就需要cpu和主板芯片组的支持，比如cpu提供了新架构，能够将一个32GB内存划分两个16GB的内存，这两个区域运行在不同模式上分别称为X3和X0，可以指定windows运行在X3模式里，然后X3模式里的程序只能访问自己的16GB内存，然后X0模式可以访问整个32GB的内存。 2026-4-22 11:55 0
木志本柯雪币： 6564 活跃值： (8619) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 446 粉丝 8 关注私信	木志本柯 15 楼木志本柯可以存在绝对意义的无痕化驱动，但目前的x86架构上是不存在的。要想做绝对意义的无痕驱动，首先就需要cpu和主板芯片组的支持，比如cpu提供了新架构，能够将一个32GB内存划分两个16GB的内存，这两个 ... 能自己掌握cpu架构想咋隐藏就咋隐藏，比如在X0模式调用X3任意call的时候，让call不获取X0的ret地址，而是可以自由指定call的ret地址，让通过ret地址检查非法内存空间的检查失效。 2026-4-22 12:07 2
fghtiger 雪币： 1617 活跃值： (3431) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 79 粉丝 0 关注私信	fghtiger 16 楼如何过PatchGuard 2026-4-22 12:08 0
木志本柯雪币： 6564 活跃值： (8619) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 446 粉丝 8 关注私信	木志本柯 17 楼木志本柯能自己掌握cpu架构想咋隐藏就咋隐藏，比如在X0模式调用X3任意call的时候，让call不获取X0的ret地址，而是可以自由指定call的ret地址，让通过ret地址检查非法内存空间的检查失效。绝对隐藏，也可以被发现，比如一个call一天只能调用一次，调用一次发一个包给服务端记录今天的调用次数，如果一个call一天被调用了很多次，那么服务端就可以以客户端数据异常踢掉这个用户。 2026-4-22 12:13 0
mb_iwztiktr 雪币： 257 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 19 粉丝 0 关注私信	mb_iwztiktr 18 楼学习一下谢谢分享 ???? 2026-4-22 13:18 0
wx_过往雪币： 9 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 11 粉丝 0 关注私信	wx_过往 19 楼学习一下谢谢分享 ???? 2026-4-22 17:53 0
mb_soqpzdaf 雪币： 216 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 12 粉丝 0 关注私信	mb_soqpzdaf 20 楼比较好奇怎么在git看到这些技术？我只有输入关键字才返回一些信息 2026-4-22 19:15 0
PPTV 雪币： 11423 活跃值： (4532) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 214 粉丝 0 关注私信	PPTV 21 楼 "无痕"驱动的检测与分析 2026-4-22 19:19 0
jihongwdlp 雪币： 9125 活跃值： (6178) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 18 粉丝 0 关注私信	jihongwdlp 22 楼感谢大佬的分享，好好学习一下 2026-4-22 20:25 0
空处雪币： 11865 活跃值： (7863) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 66 粉丝 2 关注私信	空处 23 楼多谢分享 2026-4-23 07:22 0
風輕澐淡雪币： 2 活跃值： (1643) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 26 粉丝 0 关注私信	風輕澐淡 24 楼感谢分享 2026-4-23 12:06 0
wx_何健雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 34 粉丝 1 关注私信	wx_何健 25 楼学习 2026-4-23 14:40 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复

__Shinn

发帖

回帖

100

RANK

关注

私信

他的文章

关于我们

联系我们

企业服务

看雪公众号

最新回复 (196) 1 2 3 4 5 6 7 8 ▶
Hxzzyyi 雪币： 29 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 4 粉丝 0 关注私信	Hxzzyyi 2 楼 666 2026-4-22 00:51 0
mb_aorspzpl 雪币： 36 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 22 粉丝 0 关注私信	mb_aorspzpl 3 楼 nb 2026-4-22 04:50 0
wfjun 雪币： 149 活跃值： (439) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 15 粉丝 0 关注私信	wfjun 4 楼 666 2026-4-22 09:22 0
DebugGirls 雪币： 6 活跃值： (1783) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 8 粉丝 0 关注私信	DebugGirls 5 楼 6 2026-4-22 09:40 0
mb_heqvlbnm 雪币： 234 活跃值： (3220) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 32 粉丝 0 关注私信	mb_heqvlbnm 6 楼 666 2026-4-22 09:42 0
幽灵XZ 雪币： 1014 活跃值： (2048) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 60 粉丝 0 关注私信	幽灵XZ 7 楼厉害了，大佬，???? 2026-4-22 09:47 0
mb_kphqygvr 雪币： 10 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 11 粉丝 0 关注私信	mb_kphqygvr 8 楼怪不得看见好多某X的5字游戏的外挂都是用的无痕映射，但是百分百触发1分钟，检测点太多了 2026-4-22 09:48 1
逆向爱好者雪币： 3536 活跃值： (7799) 能力值： ( LV3，RANK：20 ) 在线值：发帖 37 回帖 280 粉丝 24 关注私信	逆向爱好者 9 楼牛逼牛逼牛逼 2026-4-22 10:03 0
Olii 雪币： 45 活跃值： (4316) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 30 粉丝 1 关注私信	Olii 10 楼感谢分享 2026-4-22 10:33 0
Abelly 雪币： 388 活跃值： (2750) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 30 粉丝 2 关注私信	Abelly 11 楼感谢分享 2026-4-22 10:43 0
Deice 雪币： 113 活跃值： (2095) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 23 粉丝 0 关注私信	Deice 12 楼不存在绝对意义上的无痕化驱动 2026-4-22 11:27 0
糖糖9 雪币： 292 活跃值： (1707) 能力值： ( LV3，RANK：29 ) 在线值：发帖 0 回帖 41 粉丝 0 关注私信	糖糖9 13 楼感谢分享 2026-4-22 11:48 0
木志本柯雪币： 6564 活跃值： (8619) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 446 粉丝 8 关注私信	木志本柯 14 楼可以存在绝对意义的无痕化驱动，但目前的x86架构上是不存在的。要想做绝对意义的无痕驱动，首先就需要cpu和主板芯片组的支持，比如cpu提供了新架构，能够将一个32GB内存划分两个16GB的内存，这两个区域运行在不同模式上分别称为X3和X0，可以指定windows运行在X3模式里，然后X3模式里的程序只能访问自己的16GB内存，然后X0模式可以访问整个32GB的内存。 2026-4-22 11:55 0
木志本柯雪币： 6564 活跃值： (8619) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 446 粉丝 8 关注私信	木志本柯 15 楼木志本柯可以存在绝对意义的无痕化驱动，但目前的x86架构上是不存在的。要想做绝对意义的无痕驱动，首先就需要cpu和主板芯片组的支持，比如cpu提供了新架构，能够将一个32GB内存划分两个16GB的内存，这两个 ... 能自己掌握cpu架构想咋隐藏就咋隐藏，比如在X0模式调用X3任意call的时候，让call不获取X0的ret地址，而是可以自由指定call的ret地址，让通过ret地址检查非法内存空间的检查失效。 2026-4-22 12:07 2
fghtiger 雪币： 1617 活跃值： (3431) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 79 粉丝 0 关注私信	fghtiger 16 楼如何过PatchGuard 2026-4-22 12:08 0
木志本柯雪币： 6564 活跃值： (8619) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 446 粉丝 8 关注私信	木志本柯 17 楼木志本柯能自己掌握cpu架构想咋隐藏就咋隐藏，比如在X0模式调用X3任意call的时候，让call不获取X0的ret地址，而是可以自由指定call的ret地址，让通过ret地址检查非法内存空间的检查失效。绝对隐藏，也可以被发现，比如一个call一天只能调用一次，调用一次发一个包给服务端记录今天的调用次数，如果一个call一天被调用了很多次，那么服务端就可以以客户端数据异常踢掉这个用户。 2026-4-22 12:13 0
mb_iwztiktr 雪币： 257 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 19 粉丝 0 关注私信	mb_iwztiktr 18 楼学习一下谢谢分享 ???? 2026-4-22 13:18 0
wx_过往雪币： 9 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 11 粉丝 0 关注私信	wx_过往 19 楼学习一下谢谢分享 ???? 2026-4-22 17:53 0
mb_soqpzdaf 雪币： 216 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 12 粉丝 0 关注私信	mb_soqpzdaf 20 楼比较好奇怎么在git看到这些技术？我只有输入关键字才返回一些信息 2026-4-22 19:15 0
PPTV 雪币： 11423 活跃值： (4532) 能力值： ( LV2，RANK：10 ) 在线值：发帖 4 回帖 214 粉丝 0 关注私信	PPTV 21 楼 "无痕"驱动的检测与分析 2026-4-22 19:19 0
jihongwdlp 雪币： 9125 活跃值： (6178) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 18 粉丝 0 关注私信	jihongwdlp 22 楼感谢大佬的分享，好好学习一下 2026-4-22 20:25 0
空处雪币： 11865 活跃值： (7863) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 66 粉丝 2 关注私信	空处 23 楼多谢分享 2026-4-23 07:22 0
風輕澐淡雪币： 2 活跃值： (1643) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 26 粉丝 0 关注私信	風輕澐淡 24 楼感谢分享 2026-4-23 12:06 0
wx_何健雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 34 粉丝 1 关注私信	wx_何健 25 楼学习 2026-4-23 14:40 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复