如何利用 WinDbg 进行双机调试

转载自:佘华煜 (Eric Sheh)，微软 MVP

其实并不是只有在生成不了转储文件的情形下才能使用双机调试，在任何情况下都是可以使用的，尤其是调试内核问题时，双机调试不必限于转储文件类型，均可获得一切可以获得的信息，相当于完全内存转储了。而且，双机调试可以调试到系统启动阶段和之后任意时刻的问题，这是内存转储做不到的。因此只要满足连接条件，将两台机器相连，我们就可以进行双机调试了。下面我们通过表格比较一下可用的三种连接方式：

连接类型

说明

COM

使用零调制解调器(Null-Modem)线缆，也就是两个头都是母孔的RS232线，通过COM端口连接

1394

利用IEEE 1394线缆连接，要求调试机和被调机运行相同版本的至少为Windows XP的系统

USB 2.0

使用一种内置硬件芯片来支持调试的特制 USB 线缆连接，要求被调机运行的系统至少为Windows Vista

在双机调试中，我们一般选择对硬件和软件复杂度要求最低的 COM 对接方式进行连接。当然，目前很多的笔记本计算机并没有再保留 COM 端口，那就要采取别的方式进行双机调试了。这样，笔记本用户进行双机调试就显得复杂了许多，所以在能生成内存转储文件的情况下还是尽量分析内存转储比较好。另外，在双机调试之前，除了连接好线缆，我们还必须在被调机上做一些设置才能让我们进行调试。下面我们一起看看需要做哪些设置。

其实要做的设置也不难，就是开启系统的调试功能。鉴于现在 Windows XP Service Pack 3 的支持周期还没有结束，我将讲解 XP 和 Windows 7 两个系统下的典型配置方式。（在这里，我们统一设置连接口为 COM1 口，波特率为115200）

对于 Windows XP，由于启动使用的是 boot.ini 数据，因此我们可以手动修改 C:\boot.ini 文件（假设您的系统装在 C 盘），在像 multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect 这样的启动项目后增加参数 /debug /debugport=com1 /baudrate=115200。当然，编辑 boot.ini 之前，您需要显示所有隐藏文件并且取消隐藏受保护的系统文件，而且还需清除该文件的只读属性。配置好的结果如下图所示（该记事本启用了自动换行，蓝色高亮部分其实在同一行）：

除了直接编辑 boot.ini，还可以使用 msconfig 实用程序。启动 msconfig，切换到 BOOT.INI 选项卡，点击 高级 按钮，在d出的对话框中进行如下配置后两次单击 确定 来退出 msconfig 即可：

或者，还有一种推荐的命令行方式来设置：

在 cmd 下键入并执行命令：bootcfg /debug ON /port COM1 /baud 115200 /ID 1

这里的 /ID 开关用于决定对 boot.ini 中的哪一条启动项进行设置。可用的启动项可通过执行不带参数的 bootcfg 命令查看。更多自定义调试参数的方式请执行 bootcfg /debug /? 查询。

说到自定义调试参数，那我也得说说默认的调试参数：（默认调试参数即借助 /debug ON 参数单纯启用调试而没有配置调试口、波特率时的系统默认调试参数）

说完了 Windows XP 的配置，我们再来说说现行主流系统 Windows 7 的调试配置：

Windows Vista 和 Windows 7 下，就没有那么多的方法了。如果采用 Windows 自带的工具，就只能使用 

bcdedit 命令了。Vista 之后，启动摒弃了 boot.ini 

的方式，而是读取启动配置数据库。为了简化 *** 作，我们可以使用默认调试配置，因此我们只需开启调试即可：

在以管理员身份运行的 cmd 

下键入并执行命令：（每行一条命令）

bcdedit /bootdebug ON

bcdedit /debug ON

执行后得到的正确结果如下图所示：

您还可以通过执行 bcdedit /dbgsettings 命令来查看当前的调试参数设置。如果您要自定义调试参数，请执行命令 bcdedit /dbgsettings /? 获取帮助。

好了，做好了被调机的设置，我们还需做调试机的设置，这样才能进行调试。

由于条件所限，我只能使用我的笔记本计算机作为调试机，将安装在本机上的 Windows 7 家庭普通版虚拟机作为被调机，使用 NirSoft 的 StartBlueScreen 程序造成系统崩溃。

设置好了命名管道之后，我们在 WinDbg 的 Kernel Debugging 配置对话框中单击 确定。在询问是否 

Save WorkSpace 的对话框中，我们选择 Yes。然后，WinDbg 

就等待连接命名管道了。好了，后面的步骤就跟使用零调制解调器线缆连接的真实案例一样了。

接下来重启被调机。等待被调机重启并进入系统引导阶段后，WinDbg 会连上被调机并在 Waiting to 

reconnect… 状态下出现新的显示：

连上后，我们可以在任意阶段，于 WinDbg 内使用 Ctrl+Break 

快捷键来中断被调机系统的运行，并配合相应命令进行即时分析。例如，就在这个启动阶段，我们使用 Ctrl+Break 

快捷键来中断启动过程，我们可以看见启动过程的 UI 动画也随即停止：

如果要被调机继续运行，键入 g 并运行或者按下 F5 

键即可。下面，我们就等待登录系统。登录系统后，我们使用提升权限的 cmd 运行 NirSoft 

的系统崩溃软件来模拟一个平时我们见过的 0xc5 蓝屏，命令是 StartBlueScreen 0xc5 0 0 0 

0。被调机蓝屏后，我们其实看不见以往的蓝屏，但是可以在 WinDbg 

中立即看见捕获的信息，就跟分析内存转储文件一样，我们可以开始以往的分析工作了：

使用 !anaylze -v 命令，我们就可以定位出，造成蓝屏的驱动是 

NirSoftBlueScreenDriver.sys。这个分析比较简单。但是值得注意的是，这个 bugcheck （即 

0x000000C5）并不是系统像往常一样根据错误类型自动给出的，而是驱动 NirSoftBlueScreenDriver.sys 

直接向 KeBugCheckEx 函数传递的参数，这个参数是笔者在利用 StartBlueScreen 

程序时传递给程序的自定义参数，因此借助 StartBlueScreen 我们可以自定义蓝屏的五个参数。

win7 sp1 32bits srv.sys 6.1.7601.17514

srvnet.sys 6.1.7601.17514

PS:这两个文件在 C:\Windows\System32\drivers 下

windbg双机调试

该漏洞主要是利用smb1在处理一个结构体转换过程中，错误计算了大小，导致的溢出。Nasa的工具集的EternalBlue利用这个溢出，对后面相连的一个内存池做了覆盖，并利用堆喷射的技巧，精准覆盖了0xffdff000的可执行内存，这个内存本来是系统预留用于存储一些配置信息的（Win7x86中是这个地址，Win7x64中是0xffffffffffd00010），最终在srvnet!SrvNetWskReceiveComplete这个函数中触发了shellcode。

溢出漏洞的函数链 ：

srv!SrvSmbOpen2 ->srv!SrvOs2FeaListToNt ->srv!SrvOs2FeaListSizeToNt ->srv!SrvOs2FeaToNt

3.下以下几个断点

bu srv!SrvOs2FeaListSizeToNt内存长度计算出错的函数

bu srv!SrvOs2FeaToNt内存实际溢出的函数

bu srv!SrvOs2FeaListToNt 上层函数

bu srv!SrvSmbOpen2 接收数据的地方

10. SrvOs2FeaListSizeToNt 的函数分析如下图

关键点在于 mov word ptr [eax], si 这个汇编语句，仅赋值了低位数据 ：

11.下个断点，看一下poc的结构体分布。

本来后面想研究一下它怎么实现的堆布局，以及覆盖这部分内存是什么结构体，以及shellcode写入的包是在哪个部分的，发现自个有点搞不动了，看几天书回忆回忆再来弄。

之前分析wanacry的时候感觉挺简单的，内核分析感觉像是在盲人摸象，每一次观察都能有新的东西，但是又始终无法有一个完整清晰的轮廓。

一份好心人的windows源码

https://github.com/Hengle/windows_nt_3_5_source_code

一份可以让你在三环弄明白大致原理的分析文章

https://paper.seebug.org/280/

一份隐藏了利用细节，但是展现详细调试细节的文章

https://www.anquanke.com/post/id/86270

光给这个提示不好判断原因，你看看WinDBG中kernel debugging的配置参数是不是和被调试端系统配置的一样，是不是把调试端pipe参数给勾上了哦，虚拟机调试的时候用管道，实机不要用。你也可是试试监视一下COM口，看看是不是COM设置错了。

---