简介Hyperdbg 是一款面向操作系统内核开发与安全研究人员的 ring0 级内核调试器定位与经典 SoftIce、WinDbg 相仿用于在最高特权层跟踪系统调用、中断处理等内核事件适合驱动开发、恶意软件行为分析与系统性能优化等场景。资源包共 93 个文件约 212KB以 38 个 h 头文件与 35 个 c 源文件为主体另含 4 个 sources、4 个 makefile、3 个 asm 汇编文件及 readme、copying、install 等辅助文件覆盖 vmx、mmu、idt、events、symsearch、udis86 反汇编等核心模块目录按 core、libudis86、tools 等分层组织便于按模块研读源码。目前已有 548 人学习下载。借助这套源码读者可深入理解 ring0 调试的实现机制掌握断点设置、内存查看修改、寄存器监控与调试日志回放等能力并借鉴其工程结构与构建脚本为内核级调试工具的开发与二次改造提供参考。1. 从一次蓝屏说起为什么我最终留下了 HyperDbg第一次在物理机上跑驱动过滤的时候蓝屏来得毫无征兆WinDbg 双机调试又得再搭一台机器、拉串口线、配符号路径折腾半小时才连上结果断点还没下稳目标机已经重启了。后来同事甩给我一个开源项目 HyperDbg说这是 ring0 内核调试器里少见的能直接在本地跑、还带脚本引擎的方案。我抱着试试看的心态编译了一遍结果从那以后本机内核态排查基本就靠它了。HyperDbg 是一个基于虚拟化技术的 ring0 内核调试器核心思路是用 Intel VT-x / AMD SVM 把目标系统放进一个轻量 hypervisor 里从而在不依赖第二台机器、不依赖串口的前提下对内核执行流做断点、单步、内存访问监控和事件追踪。它解决的就是「本机内核态调试」这个长期被双机调试垄断的场景适合做驱动开发、内核安全研究、Rootkit 行为分析以及需要频繁下内核断点又不想反复搭环境的从业者。关键词 ring0、内核调试器、kernel debugger 这几个词基本就是它的全部定位。2. HyperDbg 的架构与本地编译从 VT-x 到可执行文件2.1 为什么它能在本机跑内核调试传统内核调试依赖 WinDbg 的串口或网络双机模式本质是把调试器放在另一台机器上通过 KD 协议和目标机通信。HyperDbg 换了个思路它自己先加载一个 hypervisor把当前操作系统降级为 guest然后在这个 hypervisor 层拦截 guest 的内核执行。因为 hypervisor 的权限高于 ring0所以它能在不修改 guest 内核代码的前提下对指定地址下断点、监控 MSR 读写、跟踪 CR3 切换。这个设计带来两个直接好处。第一不需要第二台机器单机就能完成内核态断点调试。第二断点不依赖 int3 指令改写而是通过 EPTExtended Page Tables的页权限控制实现所以对目标代码是无侵入的不容易被反调试逻辑检测到。代价是它要求 CPU 支持硬件虚拟化并且要处理 Hyper-V、VBS 等已有 hypervisor 的冲突。常见做法是先在 BIOS 里确认 VT-x 和 VT-d 都打开然后在 Windows 里用systeminfo看 Hyper-V 相关条目。如果系统已经启用了 Hyper-V 或内核隔离HyperDbg 的 hypervisor 可能加载失败这时候要么在启动项里关掉要么用它的兼容模式。2.2 编译环境与依赖准备HyperDbg 的源码托管在 GitHub编译需要 Visual Studio 2019 或 2022加上 WDKWindows Driver Kit。我一般用 VS2022 WDK 10.0.22621 这套组合实测比较稳。先装 VS2022 的「使用 C 的桌面开发」和「Windows 驱动开发」两个工作负载WDK 会自动带上。# 克隆源码注意用 --recursive 拉子模块 git clone --recursive https://github.com/HyperDbg/HyperDbg.git cd HyperDbg # 查看目录结构确认关键模块都在 ls # 常见输出hyperdbg-cli hyperdbg-driver hyperdbg-hypervisor script-engine ...这里--recursive不能省因为脚本引擎和部分公共库是以子模块形式引入的漏掉会导致编译时报找不到头文件。克隆完成后用 VS 打开HyperDbg.sln解决方案配置选Release平台选x64。如果只是本机调试不需要签名的测试模式可以直接编译如果要长期用建议开启测试签名模式否则每次重启后驱动加载会被拦截。# 以管理员身份运行开启测试签名模式 bcdedit /set testsigning on # 重启后生效 shutdown /r /t 0testsigning on的作用是允许加载未签名的内核驱动HyperDbg 的驱动和 hypervisor 模块在开发阶段通常没有正式签名不开这个会直接加载失败。重启后桌面右下角会出现「测试模式」水印这是正常的不影响使用。2.3 加载 hypervisor 与驱动编译产物主要在build或x64/Release目录下核心是三个东西hyperdbg-cli.exe、hyperdbg-driver.sys、hyperdbg-hypervisor.sys。加载顺序不能乱必须先加载 hypervisor再加载驱动最后启动 CLI。# 进入编译输出目录 cd x64/Release # 1. 加载 hypervisor以管理员身份 sc create hyperdbg-hypervisor type kernel binPath C:\path\to\hyperdbg-hypervisor.sys sc start hyperdbg-hypervisor # 2. 加载驱动 sc create hyperdbg-driver type kernel binPath C:\path\to\hyperdbg-driver.sys sc start hyperdbg-driver # 3. 启动 CLI hyperdbg-cli.exesc create里的type kernel指定这是内核驱动binPath必须写绝对路径且等号后面要有空格这是sc命令的坑。如果sc start报错 577 或 1275通常是签名问题或 hypervisor 冲突先确认测试签名已开、Hyper-V 已关。加载成功后CLI 里执行load命令会看到 hypervisor 状态变成 running这时候才算真正进入可调试状态。3. 断点、事件与脚本HyperDbg 的实操命令拆解3.1 下内核断点的几种方式HyperDbg 的断点分两类一类是基于 EPT 的「隐藏断点」不修改目标内存另一类是传统的软件断点会改写指令。日常排查我优先用隐藏断点因为对目标代码无侵入。# 在 CLI 中连接到本地调试目标 load # 在指定内核函数地址下隐藏断点EPT 断点 bp 0xfffff80012345678 # 查看当前所有断点 bl # 删除断点 bc 0bp后面跟的是内核虚拟地址格式用反引号分隔高低 32 位这是 WinDbg 风格的写法HyperDbg 兼容。bl列出断点编号和地址bc按编号删除。隐藏断点的原理是把这个地址所在页在 EPT 里标记为不可执行guest 执行到这一页时触发 VM-Exithypervisor 捕获后再判断是不是目标地址是就暂停不是就放行。所以它不会改写指令反调试逻辑很难通过校验和发现。如果要监控内存访问而不是执行用bp的变体# 监控对指定地址的读写 bp 0xfffff80012345678 rw # r 表示读w 表示写rw 表示读写都监控这个在读敏感结构体、追踪谁改了某个全局变量时特别有用。比如排查某个内核对象被意外释放直接对它的引用计数地址下rw断点谁改的一目了然。3.2 事件追踪与脚本引擎HyperDbg 内置了一个脚本引擎语法接近 C可以在断点触发时执行自定义逻辑比如打印寄存器、修改内存、条件判断。这比 WinDbg 的断点命令强不少因为它是编译执行的不是逐条解释。// 示例在断点触发时打印 RCX 和当前进程 // 保存为 script.dbg { printf(RCX %llx\n, $rcx); printf(Current process %llx\n, cr3); }在 CLI 里用bp 0xfffff800\12345678 script { script.dbg }把脚本挂到断点上。$rcx是寄存器变量cr3是当前 CR3 值通过 CR3 可以反查当前进程。脚本里还能用if、while、内存读写函数做条件断点非常方便。我一般会写一个判断当前进程名是不是目标进程的脚本避免在其他进程触发时被无关断点打断。// 条件断点只在目标进程命中时暂停 { if (cr3 0x1ab000) { printf(Hit target process!\n); // 这里可以加 pause 或 break } }cr3的值需要提前用!process或从 EPROCESS 里拿到不同系统版本偏移不一样建议先用dt nt!_EPROCESS确认。脚本引擎支持的热键和函数在官方文档里有完整列表常用的有printf、pause、eb写字节、ed写双字。3.3 用 HyperDbg 做一次实际的驱动排查假设有个驱动在特定 IOCTL 下会蓝屏但不知道具体哪一行。常规做法是双机调试下断点现在用 HyperDbg 单机就能做。第一步找到驱动入口和分发函数地址。用lm命令列出已加载模块找到目标驱动的基址再加上从 PDB 或反汇编里拿到的偏移。# 列出内核模块 lm # 输出里找到目标驱动比如 mydriver.sys 基址 0xfffff80010000000第二步在分发函数下断点并挂脚本打印 IOCTL 码。bp 0xfffff80010001234 script { printf(IOCTL %x\n, $r8); }x64 调用约定里分发函数的第三个参数是 IOCTL 码放在 R8。这样每次有 IOCTL 进来都会打印能快速定位是哪个码触发的蓝屏。第三步在可疑分支下第二个断点单步跟进。HyperDbg 支持t单步和p步过用法和 WinDbg 类似。如果蓝屏发生在某个内存访问上可以对该地址下rw断点看是谁先写坏的。这套流程下来原本要两台机器的事现在一台就够而且断点不侵入驱动里的反调试逻辑基本不会干扰。4. 避坑与常见问题HyperDbg 加载失败的六种排查4.1 现象hypervisor 加载失败报错 0x00000001原因通常是 CPU 虚拟化没开或者系统里已经有 Hyper-V、VBS、WSL2 占用了 VT-x。HyperDbg 的 hypervisor 需要独占硬件虚拟化和这些功能冲突。解决先在 BIOS 里确认 Intel VT-x / AMD SVM 是 Enabled然后在 Windows 功能里关掉 Hyper-V、虚拟机平台、Windows 沙盒、内核隔离。WSL2 也要关因为它底层就是 Hyper-V。关完重启再用systeminfo确认「基于虚拟化的安全性」是「未启用」。4.2 现象驱动加载报错 577提示签名无效原因是测试签名模式没开或者驱动文件被系统标记为不受信任。解决管理员运行bcdedit /set testsigning on重启。如果还报错检查驱动文件是不是从编译输出目录直接拿的有时候杀软会隔离或篡改。可以临时关掉实时防护再试。另外Windows 11 的某些版本对测试签名驱动有额外限制需要同时开bcdedit /set nointegritychecks on但这个选项有安全风险仅限测试机用。4.3 现象CLI 里load成功但bp下断点没反应原因是地址不对或者目标页不在 EPT 监控范围内。HyperDbg 的隐藏断点只对已经建立 EPT 映射的页生效如果地址是无效的或者属于用户态不会触发。解决先用lm确认模块基址再用u反汇编确认地址处确实有指令。如果是用户态地址需要先切换到目标进程上下文或者用!process拿到内核地址。另外某些内核页是 large page2MBEPT 断点对 large page 的支持有限可能需要先拆分页表这个在文档里有说明。4.4 现象脚本编译报错提示找不到函数原因是脚本引擎的函数名和 C 标准库不完全一样比如printf是支持的但sprintf可能没有。解决查官方脚本引擎文档里的函数列表常用的输出用printf内存读写用eb/ed/eq寄存器访问用$reg或reg。脚本里不要用复杂宏和模板保持简单。如果脚本逻辑复杂建议拆成多个小脚本挂不同断点。4.5 现象调试过程中目标机卡死或重启原因是断点触发太频繁或者脚本里有死循环导致 VM-Exit 风暴。解决给断点加条件只在目标进程或目标地址命中时暂停。脚本里避免while(1)如果要做轮询加计数器上限。另外隐藏断点虽然不侵入但每次命中都会 VM-Exit高频地址比如调度器、中断处理不要下断点否则系统会明显变卡。4.6 现象卸载后系统不稳定原因是 hypervisor 卸载不干净或者驱动还在引用已释放的内存。解决按顺序卸载先停 CLI再sc stop hyperdbg-driver再sc stop hyperdbg-hypervisor最后sc delete。不要直接删文件。如果卸载后蓝屏进安全模式用sc delete清理残留服务再重启。我一般会在虚拟机里先跑一遍完整加载卸载流程确认稳定后再上物理机。5. 进阶技巧用 HyperDbg 做无侵入的 SSDT 与 MSR 监控HyperDbg 真正让我留下来的是它能监控 MSR 和 SSDT 这类传统调试器很难处理的目标。比如要检测某个 Rootkit 有没有挂钩 SSDT常规做法是读KeServiceDescriptorTable然后逐个比对但这样只能看静态结果看不到「谁在什么时候改的」。用 HyperDbg 可以对 SSDT 所在页下w断点谁写谁触发。# 找到 SSDT 基址示例实际地址因系统版本而异 # 在 CLI 里用 !syscall 或手动从 nt!KeServiceDescriptorTable 读取 bp 0xfffff8000a000000 w script { printf(SSDT modified by %llx, new value %llx\n, rip, *(unsigned long long*)0xfffff8000a000000); }rip是触发写的指令地址通过它反查模块就能知道是谁在改。这个技巧在分析内核 Rootkit 时非常直接比事后扫描可靠得多。MSR 监控同理比如要追踪IA32_LSTAR系统调用入口有没有被改可以对该 MSR 下监控。HyperDbg 支持msr相关命令具体语法在 CLI 里用help msr查。我一般会写一个脚本在 MSR 被写时打印旧值和新值然后对比是否指向了合法模块。// MSR 写监控脚本示例 { printf(MSR write: old %llx, new %llx, rip %llx\n, $old_msr, $new_msr, rip); }这里$old_msr和$new_msr是 HyperDbg 在 MSR 事件里预定义的变量不同版本可能名字有差异以实际文档为准。关键是这个能力传统调试器要监控 MSR 得改 hypervisor 或者用硬件断点数量有限而 HyperDbg 是在自己的 hypervisor 层统一拦截理论上可以监控任意多个 MSR。还有一个我常用的场景是跟踪 CR3 切换也就是进程切换。对nt!SwapContext或者直接对 CR3 写操作下断点能看到完整的进程切换序列配合脚本过滤目标进程可以精确知道某个进程什么时候被调度、什么时候退出。这在排查「进程莫名消失」这类问题时特别有用因为用户态工具往往看不到退出前的最后状态。验证 HyperDbg 是否真的在拦截有个简单办法下一个断点然后用另一个工具去读那个地址看是否触发。或者用!epthook之类的命令查看当前 EPT 状态。我习惯在每次正式排查前先在一个已知会频繁调用的内核函数上下断点确认能命中再换到目标地址。这个习惯帮我省了很多「以为没触发其实是地址错了」的时间。从那以后我每次上物理机跑 HyperDbg 之前都会先在虚拟机里走一遍加载、下断、卸载的完整流程确认没有残留服务再上真机。内核调试这事后悔药不好买稳一点比快一点重要。希望帮到你。本文还有配套的精品资源点击获取