第9章动态分析工具进阶

课程目录第9章动态分析工具进阶

9、动态分析工具进阶：WinDbg内核调试、远程调试、脚本自动化

说实话，WinDbg 这工具，入门容易，精通难。

很多人用它打个断点、看个调用栈就觉得够了。但真正的高手，能用它做内核调试、远程调试，甚至写脚本自动化分析。我当年刚接触内核调试时，一个蓝屏分析搞了三天，最后发现是驱动里一个野指针。嗯，从那以后，我就把 WinDbg 的脚本自动化当成了必修课。

9.1 内核调试：不只是看蓝屏

内核调试，说白了就是调试操作系统本身。你想想看，普通的用户态调试，你只能看到自己的进程。但内核调试，你能看到整个系统的内存、进程、线程、驱动、甚至硬件中断。

我个人习惯用双机调试。一台跑目标系统（被调试的），一台跑 WinDbg。连接方式我推荐用网络调试，比串口快得多。

核心概念：内核调试需要目标系统开启调试模式。Windows 启动时按 F8，选择「调试模式」即可。或者用 bcdedit 命令永久开启。

设置网络调试的命令：

# 在目标系统上（管理员权限）
bcdedit /debug on
bcdedit /dbgsettings net hostip:192.168.1.100 port:50000 key:1.2.3.4

# 重启后，WinDbg 连接
windbg -k net:port=50000,key=1.2.3.4

连接成功后，你会看到 WinDbg 停在系统启动的早期阶段。这时候，你可以设置内核断点、查看内核结构、甚至修改内存。

小技巧：用 !process 0 0 列出所有进程，用 !thread 查看当前线程。我经常用 !analyze -v 自动分析蓝屏原因，省了我不少时间。

9.2 远程调试：跨机器的艺术

远程调试，不是让你在远程桌面上跑 WinDbg。那是伪远程。真正的远程调试，是调试器在 A 机器，被调试程序在 B 机器，两者通过网络通信。

为什么要这么做？

嵌入式设备：你没法在 IoT 设备上装 Visual Studio
生产环境：不能随便在服务器上装调试工具
性能敏感：调试器本身会拖慢程序，远程跑不影响目标

WinDbg 的远程调试有两种模式：

模式	命令	适用场景
进程服务器	`.server tcp:port=5000`	调试器在远程，目标进程在本地
调试客户端	`windbg -remote tcp:server=192.168.1.100,port=5000`	调试器在本地，连接远程调试会话

我曾经帮一个朋友调试一个奇怪的死锁问题。程序跑在他的笔记本上，我在办公室用远程调试连过去。我这边下断点、看堆栈，他那边继续操作 UI。半小时就定位到了问题——一个锁没释放。要是没有远程调试，我得飞过去，或者让他把整个环境打包发给我，想想就头疼。

注意：远程调试时，网络延迟会影响体验。建议用有线网络，别用 WiFi。另外，防火墙要开放对应端口，不然连不上。

9.3 脚本自动化：让 WinDbg 自己干活

手动敲命令，一次两次还行。但如果你要分析 100 个 dump 文件呢？或者每天都要做同样的检查？这时候，脚本自动化就派上用场了。

WinDbg 支持三种脚本方式：

命令脚本（.txt）：把命令写进文本文件，用 $$>< 执行
JavaScript 脚本：WinDbg 内置了 JavaScript 引擎，可以写复杂的逻辑
Python 脚本：通过 pykd 扩展，用 Python 控制调试器

我个人最常用的是 JavaScript 脚本。为什么？因为它不需要额外安装，而且能直接操作调试器对象。

来看一个例子：自动分析所有线程的调用栈，找出哪个线程持有锁时间最长。

// find_long_lock.js
// 遍历所有线程，打印调用栈和锁信息

var ctrl = host.namespace.Debugger.Utility.Control;
var threads = ctrl.ExecuteCommand("~* k");

for (var i = 0; i < threads.Count; i++) {
    var line = threads[i];
    if (line.Contains("nt!KeWaitForSingleObject")) {
        // 找到了等待锁的线程
        var tid = ctrl.ExecuteCommand("~.")[0];
        host.diagnostics.debugLog("线程 " + tid + " 在等待锁\n");
        host.diagnostics.debugLog(line + "\n");
    }
}

在 WinDbg 中执行：

$$>< find_long_lock.js

脚本会自动扫描所有线程，找到那些在等待锁的，然后打印出来。你想想看，如果手动做，你得一个个线程切换，敲 ~1 k、~2 k…… 100 个线程就得敲 100 次。脚本一秒钟搞定。

进阶用法：我写过一个脚本，自动分析 dump 文件中的内存泄漏。它遍历所有堆分配，按大小排序，找出前 10 大的未释放内存，然后打印出分配时的调用栈。配合定时任务，每天凌晨自动跑一遍，第二天早上看报告就行。

9.4 实战：用脚本自动化分析崩溃 dump

假设你有一堆 dump 文件，都是用户反馈的崩溃。你想快速找出共性原因。手动一个个分析？太慢了。

写一个脚本，自动遍历所有 dump，提取崩溃时的异常信息和调用栈：

// analyze_dumps.js
// 批量分析 dump 文件

var dumps = ["crash1.dmp", "crash2.dmp", "crash3.dmp"];

for (var i = 0; i < dumps.length; i++) {
    var dumpFile = dumps[i];
    
    // 打开 dump
    ctrl.ExecuteCommand(".opendump " + dumpFile);
    ctrl.ExecuteCommand("g");
    
    // 分析异常
    var analysis = ctrl.ExecuteCommand("!analyze -v");
    
    // 提取异常类型
    for (var j = 0; j < analysis.Count; j++) {
        if (analysis[j].Contains("EXCEPTION_CODE")) {
            host.diagnostics.debugLog(dumpFile + " 异常代码: " + analysis[j] + "\n");
        }
        if (analysis[j].Contains("STACK_TEXT")) {
            host.diagnostics.debugLog(dumpFile + " 调用栈:\n");
            // 打印接下来的 10 行
            for (var k = j + 1; k < j + 11 && k < analysis.Count; k++) {
                host.diagnostics.debugLog(analysis[k] + "\n");
            }
        }
    }
    
    // 关闭 dump
    ctrl.ExecuteCommand(".close");
}

跑完这个脚本，你就能看到每个 dump 的异常代码和调用栈。如果多个 dump 的异常代码相同、调用栈相似，那基本就是同一个 bug。

避坑指南：我曾经写脚本时忘了加 g 命令，结果 dump 打开后停在初始断点，后面的分析命令全没执行。浪费了我一上午。记住：打开 dump 后一定要 g 一下，让系统跑起来。

9.5 知识体系总览

下面这张图，是我梳理的 WinDbg 进阶调试的知识结构。你可以把它当作学习路线图。

内核调试让你看到系统全貌，远程调试让你不受物理限制，脚本自动化让你从重复劳动中解放出来。这三块都掌握了，你就能在逆向工程中游刃有余。

嗯，今天就到这里。记住，工具是死的，思路是活的。多写脚本，多总结套路，你会发现 WinDbg 其实挺有意思的。

公众号:蓝海资料掘金营，微信deep3321

📚 课程目录

9、动态分析工具进阶：WinDbg内核调试、远程调试、脚本自动化

9.1 内核调试：不只是看蓝屏

9.2 远程调试：跨机器的艺术

9.3 脚本自动化：让 WinDbg 自己干活

9.4 实战：用脚本自动化分析崩溃 dump

9.5 知识体系总览