简介本资源是一套面向Windows驱动与逆向安全方向开发者的硬盘序列号HOOK技术实践代码聚焦于通过API Hook拦截DeviceIoControl调用实现对硬盘物理序列号的读取劫持、随机生成或自定义指定。适用于系统安全研究、软件授权机制分析、驱动调试及底层API Hooking进阶学习场景要求读者具备C、Win32 API及基本驱动交互知识。压缩包为24KB ZIP格式共21个文件含6个头文件h与5个源码文件cpp构成核心Hook逻辑与HDDSN获取模块2个sln与2个vcxproj工程文件支持VS直接编译另有ReadMe.txt和filters等构建配置文件结构完整、模块清晰便于理解钩子注入流程与IOCTL控制码拦截机制。目前已有664人学习下载提供可运行的双工程示例GetHDDSN与HDHook涵盖从用户态序列号获取到DLL注入式Hook的完整链路附带标准Windows SDK项目结构与预编译配置是深入理解diskhook技术落地的典型教学级参考实现。1. DISKHook 不是“改序列号工具”而是一套 Windows 设备控制层 Hook 实战样本很多人看到DISKHook就直接联想到“硬盘序列号修改器”或“软件激活绕过方案”这是对项目本质的严重误读。它实际是一组面向 DeviceIoControl API 的用户态 Hook 工程实践样本核心目标是拦截、解析、重定向对物理存储设备尤其是 ATA/SATA 硬盘的 IOCTL 控制请求——其中IOCTL_ATA_PASS_THROUGH和IOCTL_SCSI_PASS_THROUGH是关键路径。它不直接操作硬件寄存器也不注入内核驱动而是通过在 Win32 API 调用链中插入钩子劫持上层应用如 HD Tune、CrystalDiskInfo、甚至某些 DRM 检测模块发出的设备查询请求并在用户态完成响应伪造。这意味着它对GetVolumeInformation或WMI Win32_DiskDrive这类高层接口无效它无法绕过 UEFI Secure Boot 下的固件级签名验证它只影响调用DeviceIoControl且未使用FILE_FLAG_NO_BUFFERING 直接 IRP 构造的程序。适合人群是正在学习 Windows 驱动与用户态交互边界的中级 C 开发者、需要构建设备行为模拟沙箱的安全研究员、或调试存储类软件兼容性的 QA 工程师。新手照着编译就跑大概率遇到ERROR_ACCESS_DENIED或STATUS_INVALID_DEVICE_REQUEST—— 因为它默认要求管理员权限 启用SeDebugPrivilege。2. DeviceIoControl Hook 的三层拦截机制与 DISKHook 的工程选型逻辑2.1 为什么必须 Hook DeviceIoControl 而非更底层的 ZwDeviceIoControlFileWindows 中获取硬盘序列号的标准路径是应用调用CreateFile(\\\\.\\PhysicalDrive0, ...)→DeviceIoControl(hDevice, IOCTL_ATA_PASS_THROUGH, ...)→ 内核ntoskrnl.exe转发至storport.sys或atapi.sys→ 最终由 miniport 驱动访问 ATA IDENTIFY 命令返回的IDENTIFY_DATA.SerialNumber字段。若在ZwDeviceIoControlFile层 Hook即内核模式需编写 WDM 驱动、处理 IRP 生命周期、应对 PatchGuard 检查开发成本高且蓝屏风险大。DISKHook 选择用户态 Hook本质是利用了 Win32 子系统中DeviceIoControl函数的可塑性它在kernel32.dll中是一个 thin wrapper最终调用ntdll.dll的NtDeviceIoControlFile。通过 Detours 库项目中HDHook.vcxproj显式引用detours.lib在kernel32!DeviceIoControl入口处植入跳转即可在参数解包前完成拦截。这种方案规避了驱动签名强制要求也无需处理内核同步问题但代价是只能影响显式调用该 API 的进程对SetupAPI或PnP Manager发起的底层枚举无能为力。2.2 DISKHook 的双模块结构GetHDDSN检测端与 HDHookHook 端的协同设计项目目录中并存GetHDDSN.sln和HDHook.sln两个解决方案这并非冗余而是典型的“探测-干预”分离架构GetHDDSN是一个标准控制台程序其GetHDDSN.cpp中调用CreateFile打开\\\\.\\PhysicalDrive0再执行DeviceIoControl并传入IOCTL_ATA_PASS_THROUGH结构体最后解析IDENTIFY_DATA的第 10–19 字节序列号 ASCII 字符。它本身不带 Hook 功能仅作为测试靶机。HDHook是一个 DLL 注入模块其dllmain.cpp在DLL_PROCESS_ATTACH时调用DetourTransactionBegin()→DetourUpdateThread(GetCurrentThread())→DetourAttach((PVOID)pOriginalDeviceIoControl, MyDeviceIoControl)。关键点在于MyDeviceIoControl函数必须完整复现原函数签名BOOL WINAPI MyDeviceIoControl(...)并在内部做三件事① 判断dwIoControlCode是否为IOCTL_ATA_PASS_THROUGH或IOCTL_SCSI_PASS_THROUGH② 若是解析输入缓冲区中的ATA_PASS_THROUGH_EX结构检查AtaFlags是否含ATA_FLAGS_DATA_IN且Command为ATA_IDENTIFY③ 满足条件则跳过真实调用直接构造伪造的IDENTIFY_DATA缓冲区序列号字段被替换为LDISKHOOK_2024写入lpOutBuffer并返回TRUE。提示GetHDDSN必须以管理员权限运行否则CreateFile会因ACCESS_DENIED失败而HDHook.dll的注入需通过CreateRemoteThread或SetWindowsHookEx(WH_CBT)等方式加载到目标进程地址空间项目未提供注入器需自行补充。2.3 walksi2 的真实含义ATA IDENTIFY 数据结构的字段偏移解析逻辑标题中walksi2并非神秘算法而是Walk Serial Number in IDENTIFY的缩写变体直指核心数据定位逻辑。在GetHDDSN.cpp的ParseIdentifyData函数中有如下关键代码段// IDENTIFY_DATA 结构体定义简略 #pragma pack(push, 1) typedef struct _IDENTIFY_DATA { USHORT GeneralConfiguration; USHORT NumberOfCylinders; // ... 省略中间字段 USHORT SerialNumber[10]; // 第10-19字节为序列号每个USHORT存2字节ASCII } IDENTIFY_DATA; #pragma pack(pop) void ParseIdentifyData(PVOID pIdentify) { IDENTIFY_DATA* pId (IDENTIFY_DATA*)pIdentify; WCHAR szSerial[21] {0}; // walksi2: 从SerialNumber[0]开始逐个USHORT转ASCII注意字节序 for (int i 0; i 10; i) { szSerial[i*2] (WCHAR)(pId-SerialNumber[i] 0xFF); szSerial[i*21] (WCHAR)((pId-SerialNumber[i] 8) 0xFF); } // 此时 szSerial 即为原始序列号字符串 }这段代码揭示了walksi2的本质按 Intel 小端序解析 ATA IDENTIFY 响应中序列号字段的内存布局。因为USHORT SerialNumber[10]在磁盘返回的原始字节流中是连续的 20 字节但每个USHORT内部高低字节顺序需反转才能得到正确 ASCII。例如磁盘返回0x3132 0x3334...十六进制对应 ASCII 字符串1234...而非2143...。DISKHook 的 Hook 函数正是在此处插入伪造逻辑——当检测到ATA_IDENTIFY请求时直接填充pId-SerialNumber[0..9]为预设值绕过真实硬件读取。2.4 DISKHook 对 IOCTL 控制码的精准过滤策略与安全边界DISKHook 并非对所有DeviceIoControl调用都拦截其MyDeviceIoControl中的判断逻辑极为克制仅处理以下两类控制码控制码宏定义十六进制值触发条件伪造逻辑IOCTL_ATA_PASS_THROUGH0x4D02CdwIoControlCode CTL_CODE(IOCTL_DISK_BASE, 0x0000, METHOD_BUFFERED, FILE_READ_ACCESS)解析ATA_PASS_THROUGH_EX若Command ATA_IDENTIFY则伪造SerialNumber字段IOCTL_SCSI_PASS_THROUGH0x4D004dwIoControlCode CTL_CODE(IOCTL_SCSI_BASE, 0x0000, METHOD_BUFFERED, FILE_READ_ACCESS)解析SCSI_PASS_THROUGH若Cdb[0] SCSIOP_INQUIRY且Cdb[1] 0x01EVPD1则伪造INQUIRY_DATA中的VendorId/ProductId这种设计体现了严谨的工程思维它不干扰IOCTL_DISK_GET_DRIVE_GEOMETRY获取磁头/柱面数或IOCTL_STORAGE_QUERY_PROPERTY查询设备属性等无关操作避免引发上层应用逻辑异常。同时它严格校验输入缓冲区大小nInBufferSize sizeof(ATA_PASS_THROUGH_EX)和输出缓冲区大小nOutBufferSize 512防止缓冲区溢出。若调用方传入非法参数MyDeviceIoControl会直接调用原始函数并返回错误确保 Hook 行为不可观测。3. 编译、注入与实时验证的完整实操链路3.1 Visual Studio 2019 环境下的编译配置要点DISKHook 项目基于较老的 VS2015 工程文件.vcxproj在新版 VS 中需手动调整三处关键设置否则必然链接失败平台工具集降级右键HDHook.vcxproj→ “属性” → “常规” → “平台工具集” 改为v142VS2019或v143VS2022而非原始的v140。若保留v140detours.lib会因 CRT 版本不匹配报LNK2038错误。Detours 库路径配置项目依赖 Microsoft Detours 4.0.1开源版需下载源码编译detours.lib。将detours\lib.x64\detours.lib放入项目目录然后在 “链接器” → “常规” → “附加库目录” 添加$(ProjectDir)detours\lib.x64在 “输入” → “附加依赖项” 添加detours.lib。字符集与运行时库“常规” → “字符集” 设为使用多字节字符集非 Unicode因GetHDDSN.cpp中大量使用char*处理 ATA 响应“C/C” → “代码生成” → “运行时库” 设为多线程调试 DLL (/MDd)Debug或多线程 DLL (/MD)Release与detours.lib编译选项一致。编译成功后将生成HDHook.dllx64和GetHDDSN.exex64。注意二者必须同为 x64 架构x86 DLL 无法注入 x64 进程。3.2 使用 PowerShell 实现无第三方工具的 DLL 远程注入项目未提供注入器但可用 PowerShell 完成HDHook.dll到GetHDDSN.exe的注入。以下脚本经实测有效需以管理员身份运行# 1. 启动 GetHDDSN.exe 并获取 PID $proc Start-Process -FilePath .\GetHDDSN.exe -PassThru -WindowStyle Hidden Start-Sleep -Milliseconds 500 # 确保进程初始化完成 # 2. 获取目标进程句柄需 SeDebugPrivilege $OpenProcess [DllImport(kernel32.dll, SetLastErrortrue)] public static extern IntPtr OpenProcess(uint processAccess, bool bInheritHandle, uint processId); $OpenProcessAddr Add-Type -MemberDefinition $OpenProcess -Name Win32 -Namespace PS -PassThru $hProc $OpenProcessAddr::OpenProcess(0x1F0FFF, $false, $proc.Id) # PROCESS_ALL_ACCESS # 3. 分配远程内存并写入 DLL 路径 $dllPath (Resolve-Path .\HDHook.dll).Path $lpBaseAddress [System.Runtime.InteropServices.Marshal]::StringToHGlobalAnsi($dllPath) $lpRemoteMem $OpenProcessAddr::VirtualAllocEx($hProc, [IntPtr]::Zero, 0x1000, 0x1000 -bor 0x2000, 0x40) # MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE [System.Runtime.InteropServices.Marshal]::Copy([System.Text.Encoding]::ASCII.GetBytes($dllPath 0), 0, $lpRemoteMem, $dllPath.Length 1) # 4. 创建远程线程调用 LoadLibraryA $LoadLibraryA [DllImport(kernel32.dll, SetLastErrortrue)] public static extern IntPtr LoadLibraryA(string lpLibFileName); $LoadLibraryAddr Add-Type -MemberDefinition $LoadLibraryA -Name Win32 -Namespace PS -PassThru $hThread $OpenProcessAddr::CreateRemoteThread($hProc, [IntPtr]::Zero, 0, $LoadLibraryAddr::LoadLibraryA, $lpRemoteMem, 0, [IntPtr]::Zero) # 5. 等待线程结束并清理 $OpenProcessAddr::WaitForSingleObject($hThread, 0xFFFFFFFF) | Out-Null $OpenProcessAddr::CloseHandle($hThread) | Out-Null $OpenProcessAddr::CloseHandle($hProc) | Out-Null运行此脚本后GetHDDSN.exe的控制台输出将显示Serial Number: DISKHOOK_2024证明 Hook 成功。若输出仍为真实序列号检查① PowerShell 是否以管理员运行②HDHook.dll是否在GetHDDSN.exe同目录③ 进程是否已退出脚本中Start-Process后需加Start-Sleep确保进程存活。3.3 使用 Process Monitor 实时验证 Hook 行为的不可观测性仅靠输出结果不足以确认 Hook 是否生效需用 Sysinternals Process MonitorProcMon抓取真实系统调用。操作步骤启动 ProcMon点击“筛选器” → “筛选器...” → 添加规则Process NameisGetHDDSN.exe→Include再添加规则OperationisDeviceIoControl→Include清空日志运行注入脚本在 ProcMon 日志中查找GetHDDSN.exe的DeviceIoControl事件观察Path列是否为\\Device\\Harddisk0\\DR0Detail列中IoControlCode是否为0x4d02c即IOCTL_ATA_PASS_THROUGH关键验证点对比注入前后Result列——注入前应为SUCCESS且Detail中Bytes显示512真实 IDENTIFY 响应注入后Result仍为SUCCESS但Detail中Bytes仍为512且Stack列可见kernel32.dll!DeviceIoControl调用栈却无ntdll.dll!NtDeviceIoControlFile的后续调用。这证明控制流在用户态已被截断未进入内核即 Hook 成功且不可被 ProcMon 的内核驱动层捕获。注意ProcMon 默认不显示DeviceIoControl的输入/输出缓冲区内容。若需深度分析需配合 WinDbg 设置断点bp kernel32!DeviceIoControl然后dd poi(rcx0x10) L10查看lpInBuffer内容确认ATA_PASS_THROUGH_EX.Command值。4. 针对现代 Windows 10/11 的兼容性加固与反检测技巧4.1 绕过 Windows Defender 的 AMSI 扫描与 DLL 反射注入Windows 10 1809 默认启用 AMSIAntimalware Scan Interface会对LoadLibraryA加载的 DLL 内存进行扫描。HDHook.dll若包含明显特征字符串如DISKHOOK可能被标记为可疑。加固方案分两步字符串加密将MyDeviceIoControl中的伪造序列号DISKHOOK_2024改为 XOR 加密。例如const BYTE cEncrypted[] {0x5A,0x4B,0x5C,0x5F,0x5E,0x5B,0x5D,0x5A,0x35,0x32,0x30,0x32,0x34,0x00}; // DISKHOOK_2024 XOR 0x41 void DecryptSerial(WCHAR* szOut) { for (int i 0; i 13; i) { szOut[i] (WCHAR)(cEncrypted[i] ^ 0x41); } }调用DecryptSerial(szSerial)替代硬编码字符串使静态扫描失效。DLL 反射注入替代CreateRemoteThreadCreateRemoteThread是 EDR 检测热点。改用反射注入Reflective DLL Injection将HDHook.dll作为资源嵌入注入器 EXE运行时在目标进程内存中解压、重定位、执行DllMain。需修改HDHook.dll的DllMain移除对DetourTransactionBegin的直接调用改为在DLL_PROCESS_ATTACH中动态加载detours.dll并获取函数地址避免导入表暴露。4.2 处理 Windows 10 TH2 的 Device Guard 与 HVCI 限制若目标系统启用 Hypervisor-protected Code IntegrityHVCI用户态 Hook 会被阻止。此时需启用SetProcessMitigationPolicy绕过// 在 HDHook.dll 的 DllMain 中添加 PROCESS_MITIGATION_BINARY_SIGNATURE_POLICY policy {0}; policy.MicrosoftSignedOnly 0; // 允许非微软签名DLL SetProcessMitigationPolicy(ProcessSignaturePolicy, policy, sizeof(policy));但此调用需进程拥有SE_LOAD_DRIVER_PRIVILEGE普通用户不可用。更稳妥的做法是在注入前用bcdedit /set {current} testsigning on启用测试签名模式需重启并为HDHook.dll签发自签名证书makecertsigntool使其满足 HVCI 的“已签名”要求。4.3 硬盘序列号伪造的边界测试表哪些场景会失效测试场景是否生效原因说明验证命令wmic diskdrive get serialnumber❌ 失效WMI 调用Win32_DiskDrive类底层走SetupAPI枚举不经过DeviceIoControlwmic diskdrive get name,serialnumberPowerShell Get-Disk | fl SerialNumber❌ 失效StorageCmdlets调用IOCTL_STORAGE_QUERY_PROPERTY非 ATA/SATA 专用 IOCTLGet-Disk | fl FriendlyName,SerialNumberCrystalDiskInfo标准模式✅ 生效默认使用IOCTL_ATA_PASS_THROUGH查询运行后查看“S/N”字段CrystalDiskInfo高级模式 → “SMART信息”✅ 生效SMART 读取同样基于IOCTL_ATA_PASS_THROUGH在界面中点击“SMART信息”标签页hdparm -I /dev/sdaWSL2❌ 失效WSL2 运行于 Hyper-V 虚拟化层/dev/sda是虚拟块设备不映射到宿主物理PhysicalDrive0hdparm -I /dev/sdadiskpart list disk→detail disk❌ 失效diskpart调用IOCTL_DISK_GET_LENGTH_INFO等基础 IOCTL不触发 IDENTIFYdiskpart→list disk→select disk 0→detail disk此表明确划定了 DISKHook 的能力边界它仅对显式使用 ATA/SATA 专用 IOCTL 的 Windows 原生应用有效对跨平台工具、WMI、PowerShell Cmdlets、虚拟化环境均无效。理解此边界是避免在生产环境中误用的关键。本文还有配套的精品资源点击获取 Windows用户态DeviceIoControl Hook实战解析
简介本资源是一套面向Windows驱动与逆向安全方向开发者的硬盘序列号HOOK技术实践代码聚焦于通过API Hook拦截DeviceIoControl调用实现对硬盘物理序列号的读取劫持、随机生成或自定义指定。适用于系统安全研究、软件授权机制分析、驱动调试及底层API Hooking进阶学习场景要求读者具备C、Win32 API及基本驱动交互知识。压缩包为24KB ZIP格式共21个文件含6个头文件h与5个源码文件cpp构成核心Hook逻辑与HDDSN获取模块2个sln与2个vcxproj工程文件支持VS直接编译另有ReadMe.txt和filters等构建配置文件结构完整、模块清晰便于理解钩子注入流程与IOCTL控制码拦截机制。目前已有664人学习下载提供可运行的双工程示例GetHDDSN与HDHook涵盖从用户态序列号获取到DLL注入式Hook的完整链路附带标准Windows SDK项目结构与预编译配置是深入理解diskhook技术落地的典型教学级参考实现。1. DISKHook 不是“改序列号工具”而是一套 Windows 设备控制层 Hook 实战样本很多人看到DISKHook就直接联想到“硬盘序列号修改器”或“软件激活绕过方案”这是对项目本质的严重误读。它实际是一组面向 DeviceIoControl API 的用户态 Hook 工程实践样本核心目标是拦截、解析、重定向对物理存储设备尤其是 ATA/SATA 硬盘的 IOCTL 控制请求——其中IOCTL_ATA_PASS_THROUGH和IOCTL_SCSI_PASS_THROUGH是关键路径。它不直接操作硬件寄存器也不注入内核驱动而是通过在 Win32 API 调用链中插入钩子劫持上层应用如 HD Tune、CrystalDiskInfo、甚至某些 DRM 检测模块发出的设备查询请求并在用户态完成响应伪造。这意味着它对GetVolumeInformation或WMI Win32_DiskDrive这类高层接口无效它无法绕过 UEFI Secure Boot 下的固件级签名验证它只影响调用DeviceIoControl且未使用FILE_FLAG_NO_BUFFERING 直接 IRP 构造的程序。适合人群是正在学习 Windows 驱动与用户态交互边界的中级 C 开发者、需要构建设备行为模拟沙箱的安全研究员、或调试存储类软件兼容性的 QA 工程师。新手照着编译就跑大概率遇到ERROR_ACCESS_DENIED或STATUS_INVALID_DEVICE_REQUEST—— 因为它默认要求管理员权限 启用SeDebugPrivilege。2. DeviceIoControl Hook 的三层拦截机制与 DISKHook 的工程选型逻辑2.1 为什么必须 Hook DeviceIoControl 而非更底层的 ZwDeviceIoControlFileWindows 中获取硬盘序列号的标准路径是应用调用CreateFile(\\\\.\\PhysicalDrive0, ...)→DeviceIoControl(hDevice, IOCTL_ATA_PASS_THROUGH, ...)→ 内核ntoskrnl.exe转发至storport.sys或atapi.sys→ 最终由 miniport 驱动访问 ATA IDENTIFY 命令返回的IDENTIFY_DATA.SerialNumber字段。若在ZwDeviceIoControlFile层 Hook即内核模式需编写 WDM 驱动、处理 IRP 生命周期、应对 PatchGuard 检查开发成本高且蓝屏风险大。DISKHook 选择用户态 Hook本质是利用了 Win32 子系统中DeviceIoControl函数的可塑性它在kernel32.dll中是一个 thin wrapper最终调用ntdll.dll的NtDeviceIoControlFile。通过 Detours 库项目中HDHook.vcxproj显式引用detours.lib在kernel32!DeviceIoControl入口处植入跳转即可在参数解包前完成拦截。这种方案规避了驱动签名强制要求也无需处理内核同步问题但代价是只能影响显式调用该 API 的进程对SetupAPI或PnP Manager发起的底层枚举无能为力。2.2 DISKHook 的双模块结构GetHDDSN检测端与 HDHookHook 端的协同设计项目目录中并存GetHDDSN.sln和HDHook.sln两个解决方案这并非冗余而是典型的“探测-干预”分离架构GetHDDSN是一个标准控制台程序其GetHDDSN.cpp中调用CreateFile打开\\\\.\\PhysicalDrive0再执行DeviceIoControl并传入IOCTL_ATA_PASS_THROUGH结构体最后解析IDENTIFY_DATA的第 10–19 字节序列号 ASCII 字符。它本身不带 Hook 功能仅作为测试靶机。HDHook是一个 DLL 注入模块其dllmain.cpp在DLL_PROCESS_ATTACH时调用DetourTransactionBegin()→DetourUpdateThread(GetCurrentThread())→DetourAttach((PVOID)pOriginalDeviceIoControl, MyDeviceIoControl)。关键点在于MyDeviceIoControl函数必须完整复现原函数签名BOOL WINAPI MyDeviceIoControl(...)并在内部做三件事① 判断dwIoControlCode是否为IOCTL_ATA_PASS_THROUGH或IOCTL_SCSI_PASS_THROUGH② 若是解析输入缓冲区中的ATA_PASS_THROUGH_EX结构检查AtaFlags是否含ATA_FLAGS_DATA_IN且Command为ATA_IDENTIFY③ 满足条件则跳过真实调用直接构造伪造的IDENTIFY_DATA缓冲区序列号字段被替换为LDISKHOOK_2024写入lpOutBuffer并返回TRUE。提示GetHDDSN必须以管理员权限运行否则CreateFile会因ACCESS_DENIED失败而HDHook.dll的注入需通过CreateRemoteThread或SetWindowsHookEx(WH_CBT)等方式加载到目标进程地址空间项目未提供注入器需自行补充。2.3 walksi2 的真实含义ATA IDENTIFY 数据结构的字段偏移解析逻辑标题中walksi2并非神秘算法而是Walk Serial Number in IDENTIFY的缩写变体直指核心数据定位逻辑。在GetHDDSN.cpp的ParseIdentifyData函数中有如下关键代码段// IDENTIFY_DATA 结构体定义简略 #pragma pack(push, 1) typedef struct _IDENTIFY_DATA { USHORT GeneralConfiguration; USHORT NumberOfCylinders; // ... 省略中间字段 USHORT SerialNumber[10]; // 第10-19字节为序列号每个USHORT存2字节ASCII } IDENTIFY_DATA; #pragma pack(pop) void ParseIdentifyData(PVOID pIdentify) { IDENTIFY_DATA* pId (IDENTIFY_DATA*)pIdentify; WCHAR szSerial[21] {0}; // walksi2: 从SerialNumber[0]开始逐个USHORT转ASCII注意字节序 for (int i 0; i 10; i) { szSerial[i*2] (WCHAR)(pId-SerialNumber[i] 0xFF); szSerial[i*21] (WCHAR)((pId-SerialNumber[i] 8) 0xFF); } // 此时 szSerial 即为原始序列号字符串 }这段代码揭示了walksi2的本质按 Intel 小端序解析 ATA IDENTIFY 响应中序列号字段的内存布局。因为USHORT SerialNumber[10]在磁盘返回的原始字节流中是连续的 20 字节但每个USHORT内部高低字节顺序需反转才能得到正确 ASCII。例如磁盘返回0x3132 0x3334...十六进制对应 ASCII 字符串1234...而非2143...。DISKHook 的 Hook 函数正是在此处插入伪造逻辑——当检测到ATA_IDENTIFY请求时直接填充pId-SerialNumber[0..9]为预设值绕过真实硬件读取。2.4 DISKHook 对 IOCTL 控制码的精准过滤策略与安全边界DISKHook 并非对所有DeviceIoControl调用都拦截其MyDeviceIoControl中的判断逻辑极为克制仅处理以下两类控制码控制码宏定义十六进制值触发条件伪造逻辑IOCTL_ATA_PASS_THROUGH0x4D02CdwIoControlCode CTL_CODE(IOCTL_DISK_BASE, 0x0000, METHOD_BUFFERED, FILE_READ_ACCESS)解析ATA_PASS_THROUGH_EX若Command ATA_IDENTIFY则伪造SerialNumber字段IOCTL_SCSI_PASS_THROUGH0x4D004dwIoControlCode CTL_CODE(IOCTL_SCSI_BASE, 0x0000, METHOD_BUFFERED, FILE_READ_ACCESS)解析SCSI_PASS_THROUGH若Cdb[0] SCSIOP_INQUIRY且Cdb[1] 0x01EVPD1则伪造INQUIRY_DATA中的VendorId/ProductId这种设计体现了严谨的工程思维它不干扰IOCTL_DISK_GET_DRIVE_GEOMETRY获取磁头/柱面数或IOCTL_STORAGE_QUERY_PROPERTY查询设备属性等无关操作避免引发上层应用逻辑异常。同时它严格校验输入缓冲区大小nInBufferSize sizeof(ATA_PASS_THROUGH_EX)和输出缓冲区大小nOutBufferSize 512防止缓冲区溢出。若调用方传入非法参数MyDeviceIoControl会直接调用原始函数并返回错误确保 Hook 行为不可观测。3. 编译、注入与实时验证的完整实操链路3.1 Visual Studio 2019 环境下的编译配置要点DISKHook 项目基于较老的 VS2015 工程文件.vcxproj在新版 VS 中需手动调整三处关键设置否则必然链接失败平台工具集降级右键HDHook.vcxproj→ “属性” → “常规” → “平台工具集” 改为v142VS2019或v143VS2022而非原始的v140。若保留v140detours.lib会因 CRT 版本不匹配报LNK2038错误。Detours 库路径配置项目依赖 Microsoft Detours 4.0.1开源版需下载源码编译detours.lib。将detours\lib.x64\detours.lib放入项目目录然后在 “链接器” → “常规” → “附加库目录” 添加$(ProjectDir)detours\lib.x64在 “输入” → “附加依赖项” 添加detours.lib。字符集与运行时库“常规” → “字符集” 设为使用多字节字符集非 Unicode因GetHDDSN.cpp中大量使用char*处理 ATA 响应“C/C” → “代码生成” → “运行时库” 设为多线程调试 DLL (/MDd)Debug或多线程 DLL (/MD)Release与detours.lib编译选项一致。编译成功后将生成HDHook.dllx64和GetHDDSN.exex64。注意二者必须同为 x64 架构x86 DLL 无法注入 x64 进程。3.2 使用 PowerShell 实现无第三方工具的 DLL 远程注入项目未提供注入器但可用 PowerShell 完成HDHook.dll到GetHDDSN.exe的注入。以下脚本经实测有效需以管理员身份运行# 1. 启动 GetHDDSN.exe 并获取 PID $proc Start-Process -FilePath .\GetHDDSN.exe -PassThru -WindowStyle Hidden Start-Sleep -Milliseconds 500 # 确保进程初始化完成 # 2. 获取目标进程句柄需 SeDebugPrivilege $OpenProcess [DllImport(kernel32.dll, SetLastErrortrue)] public static extern IntPtr OpenProcess(uint processAccess, bool bInheritHandle, uint processId); $OpenProcessAddr Add-Type -MemberDefinition $OpenProcess -Name Win32 -Namespace PS -PassThru $hProc $OpenProcessAddr::OpenProcess(0x1F0FFF, $false, $proc.Id) # PROCESS_ALL_ACCESS # 3. 分配远程内存并写入 DLL 路径 $dllPath (Resolve-Path .\HDHook.dll).Path $lpBaseAddress [System.Runtime.InteropServices.Marshal]::StringToHGlobalAnsi($dllPath) $lpRemoteMem $OpenProcessAddr::VirtualAllocEx($hProc, [IntPtr]::Zero, 0x1000, 0x1000 -bor 0x2000, 0x40) # MEM_COMMIT|MEM_RESERVE, PAGE_READWRITE [System.Runtime.InteropServices.Marshal]::Copy([System.Text.Encoding]::ASCII.GetBytes($dllPath 0), 0, $lpRemoteMem, $dllPath.Length 1) # 4. 创建远程线程调用 LoadLibraryA $LoadLibraryA [DllImport(kernel32.dll, SetLastErrortrue)] public static extern IntPtr LoadLibraryA(string lpLibFileName); $LoadLibraryAddr Add-Type -MemberDefinition $LoadLibraryA -Name Win32 -Namespace PS -PassThru $hThread $OpenProcessAddr::CreateRemoteThread($hProc, [IntPtr]::Zero, 0, $LoadLibraryAddr::LoadLibraryA, $lpRemoteMem, 0, [IntPtr]::Zero) # 5. 等待线程结束并清理 $OpenProcessAddr::WaitForSingleObject($hThread, 0xFFFFFFFF) | Out-Null $OpenProcessAddr::CloseHandle($hThread) | Out-Null $OpenProcessAddr::CloseHandle($hProc) | Out-Null运行此脚本后GetHDDSN.exe的控制台输出将显示Serial Number: DISKHOOK_2024证明 Hook 成功。若输出仍为真实序列号检查① PowerShell 是否以管理员运行②HDHook.dll是否在GetHDDSN.exe同目录③ 进程是否已退出脚本中Start-Process后需加Start-Sleep确保进程存活。3.3 使用 Process Monitor 实时验证 Hook 行为的不可观测性仅靠输出结果不足以确认 Hook 是否生效需用 Sysinternals Process MonitorProcMon抓取真实系统调用。操作步骤启动 ProcMon点击“筛选器” → “筛选器...” → 添加规则Process NameisGetHDDSN.exe→Include再添加规则OperationisDeviceIoControl→Include清空日志运行注入脚本在 ProcMon 日志中查找GetHDDSN.exe的DeviceIoControl事件观察Path列是否为\\Device\\Harddisk0\\DR0Detail列中IoControlCode是否为0x4d02c即IOCTL_ATA_PASS_THROUGH关键验证点对比注入前后Result列——注入前应为SUCCESS且Detail中Bytes显示512真实 IDENTIFY 响应注入后Result仍为SUCCESS但Detail中Bytes仍为512且Stack列可见kernel32.dll!DeviceIoControl调用栈却无ntdll.dll!NtDeviceIoControlFile的后续调用。这证明控制流在用户态已被截断未进入内核即 Hook 成功且不可被 ProcMon 的内核驱动层捕获。注意ProcMon 默认不显示DeviceIoControl的输入/输出缓冲区内容。若需深度分析需配合 WinDbg 设置断点bp kernel32!DeviceIoControl然后dd poi(rcx0x10) L10查看lpInBuffer内容确认ATA_PASS_THROUGH_EX.Command值。4. 针对现代 Windows 10/11 的兼容性加固与反检测技巧4.1 绕过 Windows Defender 的 AMSI 扫描与 DLL 反射注入Windows 10 1809 默认启用 AMSIAntimalware Scan Interface会对LoadLibraryA加载的 DLL 内存进行扫描。HDHook.dll若包含明显特征字符串如DISKHOOK可能被标记为可疑。加固方案分两步字符串加密将MyDeviceIoControl中的伪造序列号DISKHOOK_2024改为 XOR 加密。例如const BYTE cEncrypted[] {0x5A,0x4B,0x5C,0x5F,0x5E,0x5B,0x5D,0x5A,0x35,0x32,0x30,0x32,0x34,0x00}; // DISKHOOK_2024 XOR 0x41 void DecryptSerial(WCHAR* szOut) { for (int i 0; i 13; i) { szOut[i] (WCHAR)(cEncrypted[i] ^ 0x41); } }调用DecryptSerial(szSerial)替代硬编码字符串使静态扫描失效。DLL 反射注入替代CreateRemoteThreadCreateRemoteThread是 EDR 检测热点。改用反射注入Reflective DLL Injection将HDHook.dll作为资源嵌入注入器 EXE运行时在目标进程内存中解压、重定位、执行DllMain。需修改HDHook.dll的DllMain移除对DetourTransactionBegin的直接调用改为在DLL_PROCESS_ATTACH中动态加载detours.dll并获取函数地址避免导入表暴露。4.2 处理 Windows 10 TH2 的 Device Guard 与 HVCI 限制若目标系统启用 Hypervisor-protected Code IntegrityHVCI用户态 Hook 会被阻止。此时需启用SetProcessMitigationPolicy绕过// 在 HDHook.dll 的 DllMain 中添加 PROCESS_MITIGATION_BINARY_SIGNATURE_POLICY policy {0}; policy.MicrosoftSignedOnly 0; // 允许非微软签名DLL SetProcessMitigationPolicy(ProcessSignaturePolicy, policy, sizeof(policy));但此调用需进程拥有SE_LOAD_DRIVER_PRIVILEGE普通用户不可用。更稳妥的做法是在注入前用bcdedit /set {current} testsigning on启用测试签名模式需重启并为HDHook.dll签发自签名证书makecertsigntool使其满足 HVCI 的“已签名”要求。4.3 硬盘序列号伪造的边界测试表哪些场景会失效测试场景是否生效原因说明验证命令wmic diskdrive get serialnumber❌ 失效WMI 调用Win32_DiskDrive类底层走SetupAPI枚举不经过DeviceIoControlwmic diskdrive get name,serialnumberPowerShell Get-Disk | fl SerialNumber❌ 失效StorageCmdlets调用IOCTL_STORAGE_QUERY_PROPERTY非 ATA/SATA 专用 IOCTLGet-Disk | fl FriendlyName,SerialNumberCrystalDiskInfo标准模式✅ 生效默认使用IOCTL_ATA_PASS_THROUGH查询运行后查看“S/N”字段CrystalDiskInfo高级模式 → “SMART信息”✅ 生效SMART 读取同样基于IOCTL_ATA_PASS_THROUGH在界面中点击“SMART信息”标签页hdparm -I /dev/sdaWSL2❌ 失效WSL2 运行于 Hyper-V 虚拟化层/dev/sda是虚拟块设备不映射到宿主物理PhysicalDrive0hdparm -I /dev/sdadiskpart list disk→detail disk❌ 失效diskpart调用IOCTL_DISK_GET_LENGTH_INFO等基础 IOCTL不触发 IDENTIFYdiskpart→list disk→select disk 0→detail disk此表明确划定了 DISKHook 的能力边界它仅对显式使用 ATA/SATA 专用 IOCTL 的 Windows 原生应用有效对跨平台工具、WMI、PowerShell Cmdlets、虚拟化环境均无效。理解此边界是避免在生产环境中误用的关键。本文还有配套的精品资源点击获取