[原创]ETW机制与InfinityHook的新姿势-编程技术-看雪安全社区

# 1. Silo
Windows内核中引入了 **Silo（服务隔离对象，Service Isolation Object）** 机制，用于实现细粒度资源隔离。Silo 最初在 Windows Server 2019 和 Windows 10 后期版本中逐步引入，并在后续版本（如 Windows 11 和 Windows Server 2022）中进一步完善。

+ Silo 是 Windows 内核中用于隔离进程、线程、对象命名空间、安全上下文等的一种容器机制。
+ 每个 Silo 拥有独立的全局状态（如对象目录、注册表视图、安全令牌策略等）。
+ 主机 Silo（Host Silo）是默认的系统 Silo，而容器化场景（如 Windows 容器、WSL2、Azure Host OS）会创建额外的 Silo。

## 1.1 PspHostSiloGlobals
全局变量 `PspHostSiloGlobals` 指向一个类型为 `_ESERVERSILO_GLOBALS` 的结构体，描述主操作系统 Silo（即传统 Windows 环境）。其中，PspHostSiloGlobals::EtwSiloState 为描述 ETW 子系统的 Silo。

```
nt!_ESERVERSILO_GLOBALS
   +0x000 ObSiloState      : _OBP_SILODRIVERSTATE	// 对象管理器（Object Manager）的 Silo 状态
   +0x2e0 SeSiloState      : _SEP_SILOSTATE			// 安全子系统（Security Reference Monitor）的 Silo 状态
   +0x310 SeRmSiloState    : _SEP_RM_LSA_CONNECTION_STATE	// LSA（Local Security Authority）连接状态
   +0x360 EtwSiloState     : 0xffffa908`459c1000 _ETW_SILODRIVERSTATE	// ETW
   +0x368 MiSessionLeaderProcess : 0xffffa908`478ad400 _EPROCESS	
       // 内存管理器（Mm）的会话领导者进程: smss.exe（Session Manager Subsystem）
       // 作为会话内存配额和页面文件分配的参考点
   +0x370 ExpDefaultErrorPortProcess : 0xffffa908`47c424c0 _EPROCESS	
       // 默认硬错误（Hard Error）接收进程: 默认硬错误（Hard Error）接收进程
       // csrss.exe 或 svchost.exe (DcomLaunch)
       // 当应用崩溃时：错误对话框由该进程弹出
   +0x378 ExpDefaultErrorPort : 0xffffa908`47593d30 Void
       // 指向 LPC（Local Procedure Call）端口对象
       // 内核通过此端口向 ExpDefaultErrorPortProcess 发送崩溃通知
   +0x380 HardErrorState   : 1
       // 硬错误处理状态	0:禁用硬错误（如无头服务器）; 1:启用（桌面系统默认）
       // 1 → 系统会弹出“xxx 已停止工作”对话框
   +0x388 WnfSiloState     : _WNF_SILODRIVERSTATE	// Windows Notification Facility (WNF) 的 Silo 状态
   +0x3c0 DbgkSiloState    : _DBGK_SILOSTATE		// 内核调试器（Debugging Subsystem）的 Silo 状态
   +0x3e0 PsProtectedCurrentDirectory : _UNICODE_STRING "C:\Windows"
       // 受保护进程（Protected Process Light, PPL）的当前目录
       // 防止恶意 DLL 注入到 PPL（如 lsass.exe, MsMpEng.exe）
   +0x3f0 PsProtectedEnvironment : _UNICODE_STRING "Path=C:\Windows\System32"
       // 受保护进程的环境变量: 限制 PPL 加载非系统路径的 DLL，提升安全性
   +0x400 ApiSetSection    : (null) 
   +0x408 ApiSetSchema     : (null) 
   +0x410 OneCoreForwardersEnabled : 0 ''	// 是否启用 OneCore API 转发（用于通用 Windows 平台）
   +0x418 NtSystemRoot     : _UNICODE_STRING "C:\Windows"	// 系统根目录
   +0x428 SiloRootDirectoryName : _UNICODE_STRING ""
   +0x438 Storage          : 0xffffa908`45874a00 _PSP_STORAGE	// Silo 的私有存储区
   +0x440 State            : 1 ( SERVERSILO_STARTED )			// Silo 生命周期状态
   +0x444 ExitStatus       : 0n259								// Silo 退出码
   +0x448 DeleteEvent      : (null) 							// Silo 销毁完成事件
   +0x450 UserSharedData   : 0xffffa908`458742b0 _SILO_USER_SHARED_DATA	
       // 用户模式共享数据区（User-Shared Data）的 Silo 版本
   +0x458 UserSharedSection : (null) 		// 用户共享数据的节对象（Section Object）	
   +0x460 TerminateWorkItem : _WORK_QUEUE_ITEM	// Silo 终止时的延迟工作项		
```

## 1.2 EtwpHostSiloState
_ETW_SILODRIVERSTATE 用于记录**Silo（Windows 容器/Job 隔离环境）中的 ETW 全局状态**，包含该 Silo 内的所有 GUID 注册表、Logger 列表等。
```
nt!_ETW_SILODRIVERSTATE	EtwpHostSiloState
   +0x000 Silo             : Ptr64 _EJOB // 主操作系统 Silo（即非容器、非 Job 隔离的传统 Windows 环境）
   +0x008 SiloGlobals      : 0xfffff800`22a47540 _ESERVERSILO_GLOBALS
       // 全局内核对象表（如进程、线程、注册表等命名空间）, 即 PspHostSiloGlobals
   +0x010 MaxLoggers       : 0x40		// 当前 Silo 允许的最大 ETW Logger 数量
   +0x018 EtwpSecurityProviderGuidEntry : _ETW_GUID_ENTRY
   +0x1a8 EtwpLoggerRundown : 0xffffa908`459c2900  -> 0xffffa908`45850510 _EX_RUNDOWN_REF_CACHE_AWARE
       // 用于 Logger 引用计数与安全析构
   +0x1b0 EtwpLoggerContext : 0xffffa908`459c2b00  -> 0xffffa908`49a4c040 _WMI_LOGGER_CONTEXT
       // 指向 LoggerTable[LoggerId] 
   +0x1b8 EtwpGuidHashTable : [64] _ETW_HASH_BUCKET 
       // 可通过 hash_table 计算 guid 快速获取 GuidEntry, 例如函数 EtwpFindGuidEntryByGuid
   +0xfb8 EtwpSecurityLoggers : [8] 3
   +0xfc8 EtwpSecurityProviderEnableMask : 0x3 ''
   +0xfcc EtwpShutdownInProgress : 0n0	// Silo 关闭标志
   +0xfd0 EtwpSecurityProviderPID : 0x344	
       // lsass.exe （Local Security Authority Subsystem Service） 是当前注册安全提供者的进程
       // LSASS 负责处理本地安全和登录管理等关键任务
   +0xfd8 PrivHandleDemuxTable : _ETW_PRIV_HANDLE_DEMUX_TABLE
       // 私有句柄多路复用表. 允许用户态通过 OpenTrace 获取 Logger 句柄; 维护句柄到 _WMI_LOGGER_CONTEXT 的映射.
   +0xff8 EtwpCounters     : _ETW_COUNTERS	// ETW 性能计数器集合
   +0x1008 LogfileBytesWritten : _LARGE_INTEGER 0x17d1800
   +0x1010 ProcessorBlocks  : 0xffffa908`459c2240 _ETW_SILO_TRACING_BLOCK
   +0x1018 ContainerRestoreWnfSubscription : 0xffffe283`2a98ac40 _EX_WNF_SUBSCRIPTION
   +0x1020 PartitionId      : _GUID {00000000-0000-0000-0000-000000000000}
   +0x1030 ParentId         : _GUID {00000000-0000-0000-0000-000000000000}
   +0x1040 QpcOffsetFromRoot : _LARGE_INTEGER 0x0
   +0x1048 PartitionType    : 0			// Silo 分区类型
       // 0: 主系统; 1:WSL2; 2:Windows Server Container; 3: Job Object Isolation.
   +0x104c SystemLoggerSettings : _ETW_SYSTEM_LOGGER_SETTINGS	// 系统级 Logger 全局配置
   +0x11c0 EtwpStartTraceMutex : _KMUTANT
```

# 2. ETW 机制
## 2.1 Logger 
Logger 是一个 ETW tracing session（跟踪会话），负责收集来自一个或多个 Provider 的事件，实现日志的收集与存储。Logger 对象的关键成员为 `LoggerId/InstanceGuid/SiloState`。其中，LoggerId描述当前 Logger 位于 EtwpLoggerContext 中的索引——EtwpHostSiloStat::EtwpLoggerContext[LoggerId]；SiloState 指向当前所属 Silo 对象。

_WMI_LOGGER_CONTEXT 用于记录**ETW 日志会话（Logger Session）**，负责收集事件、管理缓冲区、连接消费者等。
```
dt nt!_WMI_LOGGER_CONTEXT ffffa908`458d79c0
   +0x000 LoggerId         : 2
   +0x004 BufferSize       : 0x1000
   +0x008 MaximumEventSize : 0xfb8
   +0x00c LoggerMode       : 0x2800480
   +0x010 AcceptNewEvents  : 0n0
   +0x014 EventMarker      : [2] 0xc0130000
   +0x01c ErrorMarker      : 0xc00d0000
   +0x020 SizeMask         : 0xffff
   +0x028 GetCpuClock      : 0xfffff800`225f5700     int64  nt!EtwpGetCycleCount+0
       // 函数指针的指向依据CKCL_TRACE_PROPERIES.EVENT_TRACE_PROPERTIES.Wnode.ClientContext进行赋值
       // 1:PpmQueryTime, 2:EtwpGetSystemTime, 3:EtwpGetCycleCount
       /* unsigned __int64 EtwpGetCycleCount()
          {
          	return __rdtsc();
          } */
   +0x030 LoggerThread     : (null) 
   +0x038 LoggerStatus     : 0n0	// 会话状态
   +0x03c FailureReason    : 0
   +0x040 BufferQueue      : _ETW_BUFFER_QUEUE
   +0x050 OverflowQueue    : _ETW_BUFFER_QUEUE
   +0x060 GlobalList       : _LIST_ENTRY [ 0xffffa908`45aed038 - 0xffffa908`45aee038 ]
       // 全局ETW日志器列表
   +0x070 DebugIdTrackingList : _LIST_ENTRY [ 0xffffa908`458d7a30 - 0xffffa908`458d7a30 ]
   +0x080 DecodeControlList : (null) 
   +0x088 DecodeControlCount : 0
   +0x090 BatchedBufferList : (null) 
   +0x090 CurrentBuffer    : _EX_FAST_REF
   +0x098 LoggerName       : _UNICODE_STRING "Circular Kernel Context Logger"
   +0x0a8 LogFileName      : _UNICODE_STRING ""
   +0x0b8 LogFilePattern   : _UNICODE_STRING ""
   +0x0c8 NewLogFileName   : _UNICODE_STRING ""
   +0x0d8 ClockType        : 3		// 时钟类型	3:QPC
   +0x124 InstanceGuid     : _GUID {54dea73a-ed1f-42a4-af71-3e63d056f174}
		// InstanceGuid 不直接与 _ETW_GUID_ENTRY 进行关联
		// 而是通过通过 ETW 的会话启用（Enable）机制和事件投递路径在运行时发生逻辑关联
   +0x150 CollectionOn     : 0n1	// 事件收集已启用(CKCL已激活)
   +0x154 ProviderInfoSize : Uint4B
   +0x158 Consumers    	   : _LIST_ENTRY [ 0xffffa908`4aff0ea0 - 0xffffa908`4aff0ea0 ] 
       	// 消费者, 接收事件
   +0x2c0 LoggerLock       : _EX_PUSH_LOCK
   +0x458 SiloState        : _ETW_SILODRIVERSTATE	// 指向当前所属 Silo
   +0x518 CallbackContext  : Ptr64 _ETW_EVENT_CALLBACK_CONTEXT
       // 在函数 EtwpLogKernelEvent 中, 调用 EtwpReserveTraceBuffer 写入 ETW 后, 
       // 判断是否需要调用 EtwpInvokeEventCallback 执行回调
```

## 2.2 Provider
Provider 是事件的来源，通常是驱动程序、内核组件或用户态应用程序，它通过 ETW API 注册自己，并在运行时发出事件。每个 Provider 由一个唯一的 **GUID（全局唯一标识符）** 标识。

- 调用 `EventWrite`、`EventWriteString` 或内核中的 `EtwWrite` 等函数来写入事件。
- 可以被多个 Logger 会话启用（enabled）或禁用（disabled）。
- 支持不同级别的事件（如 Information、Warning、Error）和关键字（Keywords），用于过滤。

> 在内核中，驱动程序通常使用 `EtwRegister` 注册为 Provider，使用 `EtwUnregister` 注销。

**_ETW_GUID_ENTRY** 表示一个 Provider GUID 的全局注册信息（如 `{69079C8B-...}`），包含所有对该 GUID 的注册（即多个 _ETW_REG_ENTRY）。

**_ETW_REG_ENTRY** 表示 某一会话/进程对某个 GUID 的一次启用（Enable）操作，记录谁启用了、启用级别、回调等，提供 Provider 与 Logger 之间的绑定记录。
```
nt!_ETW_GUID_ENTRY
   +0x000 GuidList         : _LIST_ENTRY [ 0xffffa908`459fe390 - 0xffffa908`45b3ba50 ]	
       // _ETW_GUID_ENTRY
   +0x010 RefCount         : 0n2	// 引用计数
   +0x018 Guid             : _GUID {e02a841c-75a3-4fa7-afc8-ae09cf9b7f23}
   +0x028 RegListHead      : _LIST_ENTRY [ 0xffffa908`458f8710 - 0xffffa908`458f8710 ]
       // _ETW_REG_ENTRY
       // 当事件发生时，ETW 遍历此列表，将事件分发给每个注册的 Logger
   +0x038 SecurityDescriptor : 0xffffe283`2a911520 Void
   +0x040 LastEnable       : _ETW_LAST_ENABLE_INFO
   +0x040 MatchId          : 0
   +0x050 ProviderEnableInfo : _TRACE_ENABLE_INFO
   +0x070 EnableInfo       : [8] _TRACE_ENABLE_INFO	// 支持8项
   +0x170 FilterData       : (null) 	// 事件过滤器（如 PID 过滤、事件 ID 过滤）
   +0x178 SiloState        : 0xffffa908`459c1000 _ETW_SILODRIVERSTATE	// 指向所属 silo
   +0x180 Lock             : _EX_PUSH_LOCK
   +0x188 LockOwner        : (null)

nt!_ETW_REG_ENTRY
   +0x000 RegList          : _LIST_ENTRY	// _ETW_REG_ENTRY
   +0x010 GroupRegList     : _LIST_ENTRY
   +0x020 GuidEntry        : Ptr64 _ETW_GUID_ENTRY
   +0x028 GroupEntry       : Ptr64 _ETW_GUID_ENTRY
   +0x030 ReplyQueue       : Ptr64 _ETW_REPLY_QUEUE
   +0x030 ReplySlot        : [4] Ptr64 _ETW_QUEUE_ENTRY
   +0x030 Caller           : Ptr64 Void
   +0x038 SessionId        : Uint4B		
       // 提供 Provider 与 Logger 之间的绑定记录, 时间上为 LoggerId
       // 通过 _ETW_SILODRIVERSTATE::EtwpLoggerContext[LoggerId] 进行索引 _WMI_LOGGER_CONTEXT 
   +0x050 Process          : Ptr64 _EPROCESS
   +0x050 CallbackContext  : Ptr64 Void	// 回调上下文
   +0x058 Callback         : Ptr64 Void	// ETW 将在跟踪会话启用或禁用此提供程序时调用
   +0x060 Index            : Uint2B		// 哈希表桶索引
   +0x062 Flags            : Uint2B
   +0x062 DbgKernelRegistration : Pos 0, 1 Bit
   +0x062 DbgUserRegistration : Pos 1, 1 Bit
   +0x062 DbgReplyRegistration : Pos 2, 1 Bit
   +0x062 DbgClassicRegistration : Pos 3, 1 Bit
   +0x062 DbgSessionSpaceRegistration : Pos 4, 1 Bit
   +0x062 DbgModernRegistration : Pos 5, 1 Bit
   +0x062 DbgClosed        : Pos 6, 1 Bit
   +0x062 DbgInserted      : Pos 7, 1 Bit
   +0x062 DbgWow64         : Pos 8, 1 Bit
   +0x062 DbgUseDescriptorType : Pos 9, 1 Bit
   +0x062 DbgDropProviderTraits : Pos 10, 1 Bit
   +0x064 EnableMask       : UChar
   +0x065 GroupEnableMask  : UChar
   +0x068 Traits           : Ptr64 _ETW_PROVIDER_TRAITS
```

## 2.3 Consumer

```
nt!_ETW_REALTIME_CONSUMER
   +0x000 Links            : _LIST_ENTRY		// 链接Consumer对象
   +0x010 ProcessHandle    : Ptr64 Void
   +0x018 ProcessObject    : Ptr64 _EPROCESS	// 内核进程对象
   +0x020 NextNotDelivered : Ptr64 Void			// 指向下一个尚未交付给该消费者的缓冲区（若为实时传输模式）
   +0x028 RealtimeConnectContext : Ptr64 Void
   +0x030 DisconnectEvent  : Ptr64 _KEVENT
   +0x038 DataAvailableEvent : Ptr64 _KEVENT
       // 当有新事件数据写入缓冲区并可被此消费者读取时，ETW 会置位此事件，唤醒等待的 ProcessTrace() 线程
   +0x040 UserBufferCount  : Ptr64 Uint4B		// 记录当前已交付但未确认的缓冲区数量（用于流控）
   +0x048 UserBufferListHead : Ptr64 _SINGLE_LIST_ENTRY
       // 指向用户态的单链表头，用于传递已填充的缓冲区地址（ETW 将缓冲区地址写入此链表，用户态通过 ProcessTrace 读取）
   +0x050 BuffersLost      : Uint4B				// 自上次读取以来丢失的缓冲区数（因消费者处理太慢）
   +0x054 EmptyBuffersCount : Uint4B			// 当前可供 ETW 写入的空闲缓冲区数量（由消费者提供或系统分配）
   +0x058 LoggerId         : Uint2B
   +0x05a Flags            : UChar
   +0x05a ShutDownRequested : Pos 0, 1 Bit
   +0x05a NewBuffersLost   : Pos 1, 1 Bit
   +0x05a Disconnected     : Pos 2, 1 Bit
   +0x05a Notified         : Pos 3, 1 Bit
   +0x05a Wow              : Pos 4, 1 Bit
   +0x060 ReservedBufferSpaceBitMap : _RTL_BITMAP
   +0x070 ReservedBufferSpace : Ptr64 UChar
   +0x078 ReservedBufferSpaceSize : Uint4B
   +0x07c UserPagesAllocated : Uint4B
   +0x080 UserPagesReused  : Uint4B
   +0x088 EventsLostCount  : Ptr64 Uint4B
   +0x090 BuffersLostCount : Ptr64 Uint4B
   +0x098 SiloState        : Ptr64 _ETW_SILODRIVERSTATE
```

# 3. CKCL查找的新方法
全局变量 `PspHostSiloGlobals` 虽然是未导出函数，但可通过硬编码计算直接获取。
 ![图片描述](upload/attach/202512/832354_554XBDWV6WWED5A.webp)

相关函数，如 `PsGetServerSiloServiceSessionId`、`PsGetServerSiloGlobals`、`PsGetServerSiloActiveConsoleId`，可直接在函数硬编码中获取。
 ![图片描述](upload/attach/202512/832354_JCJWWV8HEPRPU5P.webp)

## 3.1 CKCL 获取路径
>PspHostSiloGlobals+0x360/EtwpHostSiloState -> +0x1b0(假设为LoggerContextTable) -> LoggerContextTable[LoggerId] -> _WMI_LOGGER_CONTEXT

![图片描述](upload/attach/202512/832354_EHHXVRQXBW8EGRT.webp) 
![图片描述](upload/attach/202512/832354_BNKSZAWGWDBCBN6.webp)

PspHostSiloGlobals+0x360(记录与ETW相关数据的指针)与全局变量EtwpHostSiloState一致，这是在 `EtwInitializeSiloState` 函数中完成赋值的。其中，rdi 指向 `_ETW_SILO_STATE` 结构体(未导出，暂且如此称呼吧...)。
 ![图片描述](upload/attach/202512/832354_K2JTGRNT3ZC93T7.webp)

LoggerContextTable[LoggerId]的相关来源可参见函数 `EtwpAcquireLoggerContextByLoggerId`，反汇编伪代码如下：
``` c
// PWMI_LOGGER_CONTEXT
// EtwpAcquireLoggerContextByLoggerId(
//     _In_ PVOID GlobalLoggerInfo,   // rcx: 全局 Logger 管理结构（如 EtwpGlobalLoggerInfo）
//     _In_ ULONG LoggerId,           // edx: 要获取的 Logger ID（0~255）
//     _In_ BOOLEAN AcquireRef        // r8b: 是否获取引用（rundown protection）
// );
__int64 __fastcall EtwpAcquireLoggerContextByLoggerId(__int64 a1, unsigned int a2, char a3)
{
  __int64 v4; // rbx
  __int64 v6; // rsi
  __int64 v7; // rcx
  __int64 v8; // rdx
  __int64 logger_context; // rbx

v4 = a2;
  v6 = a2;
  if ( a2 >= *(_DWORD *)(a1 + 16) )
    LOBYTE(v7) = 1;
  else
    v7 = *(_QWORD *)(*(_QWORD *)(a1 + 432) + 8i64 * a2);
  if ( (v7 & 1) != 0
    || !(unsigned __int8)ExAcquireRundownProtectionCacheAwareEx(*(_QWORD *)(*(_QWORD *)(a1 + 424) + 8i64 * a2), 1i64) )
  {
    return 0i64;
  }
  if ( (unsigned int)v4 >= *(_DWORD *)(a1 + 16) )
  {
    logger_context = 1i64;
  }
  else
  {
    _mm_lfence();
    logger_context = *(_QWORD *)(*(_QWORD *)(a1 + 0x1B0) + 8 * v4);
  }
  if ( (logger_context & 1) != 0 )
  {
    ExReleaseRundownProtectionCacheAwareEx(*(_QWORD *)(*(_QWORD *)(a1 + 424) + 8 * v6), 1i64);
    return 0i64;
  }
  if ( a3 )
    KeWaitForSingleObject(logger_context + 648, 0, 0, 0, 0i64);
  if ( !*(_DWORD *)(logger_context + 336) )     // CollectionOn
  {
    LOBYTE(v8) = a3;
    EtwpReleaseLoggerContext(logger_context, v8);
    return 0i64;
  }
  return logger_context;
}
```

## 3.2 Syscall 与 ETW 触发
系统调用服务例程的执行位于 KiSystemServiceCopyEnd 函数中，通过 `call rax` 实现。图示可以看到，在执行系统调用前进行了两次全局标记的判断，即 KiDynamicTraceMask 和 PerfGlobalGroupMask。前者用于动态调试信息记录，而后者用于 ETW 日志记录。
 ![图片描述](upload/attach/202601/832354_FHW5JPW6B5PG8UV.webp)

`KiDynamicTraceMask__systemcall` 代码段内部在“call rax”前后分别调用 KiTrackSystemCallEntry/KiTrackSystemCallExit 进行事件追踪。事实上，这两个函数内部分别调用 PerfInfoLogSysCallEntry/PerfInfoLogSysCallExit 进行 ETW 记录。
 ![图片描述](upload/attach/202601/832354_5Z8ZACD5ESXUY4E.webp)

类似的，`PerfGlobalGroupMask__systemcall` 内部采用了同样的策略。
 ![图片描述](upload/attach/202601/832354_Y4HWRF3XQCK4TBN.webp)

值得注意的是，ETW 的触发依赖于 `test    dword ptr cs:PerfGlobalGroupMask+8, 40h`。

# 4. InfinityHook
我所参考的 <a href="elink@462K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6r3K9g2W2t1k6i4u0Q4x3V1k6u0L8X3k6A6L8X3W2@1P5f1S2G2L8$3E0b7M7X3!0Q4x3V1k6@1M7X3g2W2i4K6u0r3L8h3q4A6L8R3`.`.">InfinityHook</a> 项目中，ckcl logger context 的定位依赖于 `EtwpDebuggerData` 特征码扫描定位，而栈帧中存储系统调用服务例程地址的定位依赖于 `PerfInfoLogSysCallEntry` 函数中的压入栈帧中的 magic。事实上，函数 `PerfInfoLogSysCallExit` 也同样存在 magic。可以通过两个函数的 magic 差异以判断当前栈帧是 `call rax` 前/后被触发，可进行定制化的操作。
```
.text:0000000140330EF0                            PerfInfoLogSysCallEntry proc near
.text:0000000140330F1F BF 33 0F 00 00                             mov     edi, 0F33h
.text:0000000140330F3D C7 44 24 28 02 18 50 00                    mov     [rsp+58h+var_30], 501802h
.text:0000000140330F4B 66 89 7C 24 20                             mov     [rsp+58h+var_38], di
.text:0000000140330F7A                            PerfInfoLogSysCallEntry endp

.text:0000000140330F90                            PerfInfoLogSysCallExit proc near
.text:0000000140330FBF BF 34 0F 00 00                             mov     edi, 0F34h
.text:0000000140330FDD C7 44 24 28 02 18 50 00                    mov     [rsp+58h+var_30], 501802h
.text:0000000140330FEB 66 89 7C 24 20                             mov     [rsp+58h+var_38], di
.text:000000014033101A                            PerfInfoLogSysCallExit endp
```

此外，由于记录 system__call 的 LoggerContext->GetCpuLock 触发路径是固定的，可通过计算调用栈来进行快速定位，以尽可能降低延迟。
> **path1 (test dword ptr cs:PerfGlobalGroupMask+8, 40h)**:  PerfGlobalGroupMask__systemcall ==> PerfInfoLogSysCallEntry
**path2 (test    cs:KiDynamicTraceMask, 1)**: KiDynamicTraceMask__systemcall ==> KiTrackSystemCallEntry ==> PerfInfoLogSysCallEntry

可通过 trap_frame 指针进行快速定位，_kthread::trap_frame 指针指向 trap_frame+0x00，即 PerfGlobalGroupMask__systemcall/KiDynamicTraceMask__systemcall 的栈顶。需要注意的是，如果系统调用参数个数大于4，函数 `KiSystemServiceGdiTebAccess` 中将会进行栈扩展以复制来自用户态的参数。
```
.text:00000001401D2C30 83 E0 0F                                   and     eax, 0Fh        ; 获取系统调用栈中参数的个数
.text:00000001401D2C33 0F 84 B7 00 00 00                          jz      KiSystemServiceCopyEnd
.text:00000001401D2C39 C1 E0 03                                   shl     eax, 3
.text:00000001401D2C3C 48 8D 64 24 90                             lea     rsp, [rsp-70h]  ; rsp指向_KTrap_Frame-70, 扩展栈, 用于填充额外参数
.text:00000001401D2C41 48 8D 7C 24 18                             lea     rdi, [rsp+70h+var_58] ; 取填充位首地址
.text:00000001401D2C46 48 8B B5 00 01 00 00                       mov     rsi, [rbp+100h] ; _KTrap_Frame::Rsp
.text:00000001401D2C4D 48 8D 76 20                                lea     rsi, [rsi+20h]  ; 用于取用户态栈帧上的参数
.text:00000001401D2C51 F6 85 F0 00 00 00 01                       test    byte ptr [rbp+0F0h], 1 ; _KTrap_Frame::SegCs
.text:00000001401D2C58 74 16                                      jz      short loc_1401D2C70
.text:00000001401D2C5A 48 3B 35 17 FA 1A 00                       cmp     rsi, cs:MmUserProbeAddress
.text:00000001401D2C61 48 0F 43 35 0F FA 1A 00                    cmovnb  rsi, cs:MmUserProbeAddress
.text:00000001401D2C69 0F 1F 80 00 00 00 00                       nop     dword ptr [rax+00000000h]
.text:00000001401D2C70
.text:00000001401D2C70                            loc_1401D2C70:                          ; CODE XREF: KiSystemServiceGdiTebAccess+71↑j
.text:00000001401D2C70 4C 8D 1D 79 00 00 00                       lea     r11, KiSystemServiceCopyEnd
.text:00000001401D2C77 4C 2B D8                                   sub     r11, rax        ; 根据栈中参数个数进行复制
.text:00000001401D2C7A 41 FF E3                                   jmp     r11
.text:00000001401D2C7A                            KiSystemServiceGdiTebAccess endp
```

<a href="elink@a26K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6i4j5h3&6Z5N6g2)9J5k6p5&6A6k6g2)9J5c8X3g2@1N6#2)9#2k6X3S2S2j5$3E0W2M7R3`.`.">etw_hacker</a> 运行截图及其调用栈如下所示：
 ![图片描述](upload/attach/202601/832354_QRKZX8V5HZTZGK9.webp)
 ![图片描述](upload/attach/202601/832354_M9UPWD9WNFAY49B.webp)

## Ref.
1. [[原创] 剖析 InfinityHook 原理 掀起一场更激烈的攻与防恶战](https://bbs.kanxue.com/thread-253450.htm)
2. <a href="elink@a52K9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6Y4K9i4c8Z5N6h3u0Q4x3X3g2U0L8$3#2Q4x3V1k6r3K9g2W2t1k6i4u0Q4x3V1k6u0L8X3k6A6L8X3W2@1P5f1S2G2L8$3E0b7M7X3!0Q4x3V1k6@1M7X3g2W2i4K6u0r3L8h3q4A6L8R3`.`.">InfinityHookPro</a>

登录后可查看完整内容

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

最后于 2026-1-7 11:42 被ALwalker编辑，原因：补充内容

#驱动开发 #系统内核 #HOOK/注入

最新回复 (7)
幸运三叶草雪币： 575 活跃值： (2396) 能力值： ( LV2，RANK：10 ) 在线值：发帖 1 回帖 25 粉丝 1 关注私信	幸运三叶草 2 楼学到了,又多了一种if hook姿势 2026-1-7 17:02 0
小周学习站雪币： 38 活跃值： (1416) 能力值： ( LV2，RANK：10 ) 在线值：发帖 3 回帖 26 粉丝 13 关注私信	小周学习站 3 楼感谢大佬,学习了 2026-1-9 09:35 0
Cr_Ring 雪币： 296 活跃值： (953) 能力值： ( LV2，RANK：10 ) 在线值：发帖 0 回帖 26 粉丝 0 关注私信	Cr_Ring 4 楼感谢大佬，希望大佬能出一个写好的代码 2026-1-24 10:41 0
saloyun 雪币： 2230 活跃值： (5398) 能力值： ( LV2，RANK：10 ) 在线值：发帖 8 回帖 273 粉丝 4 关注私信	saloyun 5 楼厉害的，其实还有很多姿势 2026-1-24 11:09 0
ALwalker 雪币： 2732 活跃值： (8671) 能力值： ( LV6，RANK：80 ) 在线值：发帖 33 回帖 93 粉丝 53 关注私信	ALwalker 1 6 楼 saloyun 厉害的，其实还有很多姿势请问是有其他可以代替loggerContext->getcpulock进行回调触发吗？我所知道的可通过etw日志记录的全局变量PerfGlobalGroupMask来控制，可实现在内核相关位置触发回调。loggerContext有一个回调例程项，但还没研究。 2026-1-24 11:19 0
wx_._549 雪币： 0 能力值： ( LV1，RANK：0 ) 在线值：发帖 0 回帖 21 粉丝 0 关注私信	wx_._549 7 楼 25h2物理机搜索栈magic找不到ssdt func 2026-7-17 00:42 0
ALwalker 雪币： 2732 活跃值： (8671) 能力值： ( LV6，RANK：80 ) 在线值：发帖 33 回帖 93 粉丝 53 关注私信	ALwalker 1 8 楼 wx_._549 25h2物理机搜索栈magic找不到ssdt func 你可以研究一下KiSystemServiceCopyEnd这个函数。 2026-7-17 09:32 0
	游客登录 \| 注册方可回帖回帖表情雪币赚取及消费高级回复