文章总结： 本文介绍了使用模型上下文协议(MCP)结合大语言模型和WinDbg进行调试、逆向工程和威胁分析的方法。文章详细说明了MCP如何降低复杂工具的使用门槛，使经验较少的分析师也能通过自然语言交互进行恶意软件研究。作者提供了完整的设置教程，包括安装VisualStudioCode、配置MCP服务器和WinDbg，并演示了使用GitHubCopilot分析崩溃转储文件的全过程。文章指出这项技术有巨大潜力，可以扩展到简单的Windows崩溃转储分析之外，未来可能应用于Windows内核驱动程序漏洞分类等高级安全任务。 综合评分： 85 文章分类： AI安全,逆向分析,漏洞分析,恶意软件,威胁情报

---

使用 MCP 进行调试、逆向与威胁分析

Alan Sguigna

securitainment

2025年12月19日 13:37 中国香港

使用 MCP 进行调试、逆向与威胁分析

今年早些时候，Sven Scharmentke 发表了题为《崩溃分析的未来：AI 与 WinDBG 的结合》（The Future of Crash Analysis: AI Meets WinDBG）的文章，记录了一个利用 AI 分析 Windows 崩溃转储文件的精彩项目。该项目使用模型上下文协议（Model Context Protocol，MCP）作为大语言模型（LLM）、Visual Studio Code 中的 GitHub Copilot 与崩溃转储文件之间的接口，用于查询和解释应用程序崩溃的根本原因。我对这篇文章深感兴趣，因为它在降低问题代码的创建和分析门槛方面又向前迈进了一步，在调试、逆向工程和威胁分析方面都有实际应用价值。这意味着经验较少的人现在可以用自然语言与复杂工具交互来进行恶意软件研究；而领域专家也能轻松获得”AI 辅助”来执行上述任务。

为什么这很重要？正如我在网络研讨会《使用 AI、IDA 和 SourcePoint JTAG 调试器的高级威胁分析与逆向工程》(Advanced Threat Analysis and Reverse Engineering using AI, IDA, and the SourcePoint JTAG Debugger) 中所述，AI 在正确使用的情况下，能让工程师显著提高生产力和输出质量。它可以抽象掉某些需要数月甚至数年才能掌握的工具的复杂性；Microsoft 的 WinDbg 应用程序就是一个典型例子。虽然它支持图形用户界面 (GUI)，但它最初是作为命令行界面 (CLI) 工具开发的，其大部分核心功能在可视化界面中并不可用。这一点在它的语言集成查询 (Language-Integrated Query, LINQ) 语法支持方面尤为明显，该语法用于查询调试器对象；以下是一个例子：

dx -g Debugger.Sessions.First().Processes.Select(p => new { Name = p.Name, ThreadCount = p.Threads.Count() }).OrderByDescending(p => p.ThreadCount),5

虽然对外行来说可能不太明显，但上述命令可以识别调试会话中线程数最多的前 5 个进程。简单吧？😊

正如 Sven 所说，我引用：

说实话——虽然软件开发的其他方面以极快的速度发展，但崩溃转储分析感觉就像被保存在数字琥珀中几十年了。我们有自动驾驶汽车和口袋大小的超级计算机，但我们仍然像互联网黎明时代一样在命令提示符前敲击。为什么调试是唯一一个我们仍然坚守那些看起来像属于计算机历史博物馆的工具的领域？

想象一下：作为 2025 年的专业软件工程师，你蜷缩在终端前，手动输入像 !analyze -v和 .ecxr这样的神秘命令，盯着十六进制内存地址，在脑海中翻译堆栈跟踪。与此同时，你在其他行业的朋友们正在将工作委托给能编写完整文档、创作艺术作品或自动化复杂工作流程的 AI 助手。

这画面有问题，对吧？

而 Sven 的文章只是触及了冰山一角；这项技术具有巨大潜力，可以扩展到简单的 Windows 崩溃转储分析之外，我将在本系列的后续文章中详细阐述。

但首先，一些背景知识：该项目的本质是开发一个工具，使 AI 能够通过模型上下文协议 (MCP) 与 WinDbg 交互，用于崩溃转储分析和实时调试。MCP 是由 Anthropic 开发的开放标准，允许 AI 系统（如大语言模型）高效地与外部工具和数据源交互。它将多个工具连接在一起，并为它们提供自然语言接口：例如，对于营销人员，一个简单的提示如 “请生成我上周的每周绩效报告”，就可以立即读写公司的 HubSpot、Google Analytics、Salesforce、LinkedIn 和其他账户以收集和更新数据。但 MCP 是新技术，已记录的漏洞包括身份验证和授权问题、供应链风险、恶意提示注入攻击等多种风险。

MCP 架构图

如果你对这些话题感兴趣，Git 存储库 Model Context Protocol Servers 是一个很好的参考资料，其中列出了不同类别的 MCP 服务器，但有一些注意事项：

参考服务器

这些服务器旨在演示 MCP 功能和官方 SDK。

第三方服务器

官方集成由为其平台构建生产就绪 MCP 服务器的公司维护。

社区服务器

一套不断增长的社区开发和维护的服务器展示了 MCP 在不同领域的各种应用。

注意:

社区服务器未经测试，使用风险自负。它们不隶属于 Anthropic，也未得到 Anthropic 的认可。

快速说明:如果你有兴趣将 GitHub Copilot 与 MCP 扩展到 VS Code 以外的其他 IDE，这是一个很好的参考：扩展 Copilot Chat 与 MCP。

Sven 的项目显然处于开发阶段，并在他的 Git 存储库中有文档记录，包括源代码和示例：mcp-windbg。README 虽然写得很好，但假设了一定的知识水平，一些非程序员和 WinDbg 新手可能不具备。因此，我在下面创建了一个教程来帮助新手入门。请注意，我有一台全新的 PC，所以我从头开始一切，这可能对新手更有帮助。我想帮助这项技术的大规模采用——即使是那些可能不是开发人员的人。所以，这里是教程，任何有一点经验的人都可以跟随：

• 安装 Visual Studio Code 和 Python 扩展。运行 VS Code。
• 启用从 PowerShell 内运行脚本。注意你可能不想设置为 Bypass；在此处阅读执行策略指南：about_Execution_Policies（目前将你带到：PowerShell 执行策略文档）：

PS C:\WINDOWS\system32>Get-ExecutionPolicy
Restricted

PS C:\WINDOWS\system32>Set-ExecutionPolicy-ExecutionPolicy Bypass
Execution Policy Change

执行策略帮助保护你免受不信任的脚本。更改执行策略可能会使你面临上述帮助主题中描述的安全风险。系统会提示你确认是否要更改执行策略。

但我确实信任 Sven。😊

• 在 VS Code 终端窗口中，克隆存储库，并切换到该目录：

git clone https://github.com/svnscha/mcp-windbg.git
cd mcp-windbg

• 创建并激活虚拟 Python 环境：

python -m venv .venv
.\.venv/Scripts\activate

• 在开发模式下安装包，并安装测试依赖项：

pip install -e .
pip install -I ".[test]"

顺便说一句，对于后续开发，将 MCP 服务器与 VS Code 集成是通过在 .vscode目录中放置包含以下内容的 mcp.json文件来完成的（该文件应该已经存在）：

{
"servers": {
"mcp_server_windbg": {
"type": "stdio",
"command": "${workspaceFolder}/.venv/Scripts/python",
"args": [
"-m",
"mcp_server_windbg"
            ],
"env": {
"_NT_SYMBOL_PATH": "SRV*C:\\Symbols*https://msdl.microsoft.com/download/symbols"
            }
        }
    }
}

• 在 GitHub Copilot Chat 窗口的右下角，选择 “Agent”（从 Agent、Ask 和 Edit 中选择），以及你想使用的模型（我撰写本文时使用的是 Claude Sonnet 3.5，但还有其他可选项，包括 Manage Models 和 Add Premium Models，真是太棒了）。
• 从这里开始应该就顺利了。你可以使用 GitHub Copilot 来帮助确保 WinDbg（实际上是其 CLI 基础 CDB，即 Console Debugger 的缩写）已安装、Windows SDK 存在、演示崩溃转储文件可用等等。以下是 VS Code 中 Copilot 的完整聊天窗口（我在其中犯了很多错误，这样你就不必重蹈覆辙了），供想要跟随操作的人参考：

alansguigna1:open_windbg_dump

GitHub Copilot:我注意到你想使用 open_windbg_dump命令。我看到测试目录中有一个崩溃转储文件，位于 DemoCrash1.exe.7088.dmp。让我为你分析它。

运行 open_windbg_dump

完成并输入：{

“dump_path”: “c:\Users\alans\OneDrive\mcp-windbg\mcp-windbg\src\mcp_server_windbg\tests\dumps\DemoCrash1.exe.7088.dmp”,

“include_stack_trace”: true,

“include_modules”: true,

“include_threads”: true

}

我为错误道歉。看起来 WinDbg/CDB (Windows 调试器) 未安装或未在你的系统上正确配置。要分析崩溃转储，你需要：

1. 安装包括 CDB (命令行调试器) 的 Windows 调试工具
2. 确保 CDB 在你的系统 PATH 中或在你的环境中配置

你想让我帮你在系统上设置 Windows 调试工具吗？

alansguigna1:是的

GitHub Copilot:我会帮你安装 Windows 调试工具。有两种主要方法来获取 WinDbg 和 CDB:

1. 通过 Windows SDK (推荐)
2. 通过 Windows Store (WinDbg Preview)

让我们使用 Windows SDK 方法，因为它更完整。我将运行一个命令来检查你是否已安装 Windows SDK。

运行终端命令：Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object { $_.DisplayName -like "*Windows SDK*" } | Select-Object DisplayName, InstallLocation

看起来你没有安装完整的 Windows SDK。我们需要做的是：

1. 下载 Windows SDK 安装程序
2. 使用调试工具组件安装它
3. 将调试器添加到你的 PATH

让我帮你完成这些步骤：

运行终端命令：$url = 'https://go.microsoft.com/fwlink/?linkid=2164145'; $outPath = 'winsdksetup.exe'; Invoke-WebRequest -Uri $url -OutFile $outPath

我已经下载了 Windows SDK 安装程序。现在你需要：

1. 运行下载的 winsdksetup.exe文件
2. 当安装程序打开时：
3. 选择 “Debugging Tools for Windows”
4. 如果你不需要其他组件，可以取消选中它们
5. 点击 Install

安装完成后，我们需要将调试器添加到你的 PATH。调试器的默认安装路径是：

• 64 位调试器：C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
• 32 位调试器：C:\Program Files (x86)\Windows Kits\10\Debuggers\x86

你完成安装后想让我帮你将调试器添加到你的 PATH 吗？完成 SDK 安装后告诉我，我会帮你进行下一步。

alansguigna1:是的，我已完成。请继续。

GitHub Copilot:很好！我会帮你将调试器添加到你的 PATH。让我们添加 x64 和 x86 调试器路径，使两者都可用。首先，让我们验证安装路径：

运行终端命令：Test-Path 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe'

太好了！调试器已安装。现在让我们将其永久添加到你的 PATH 环境变量：

运行终端命令：$x64Path = 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64'; $x86Path = 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x86'; $currentPath = [Environment]::GetEnvironmentVariable('Path', 'Machine'); if (-not $currentPath.Contains($x64Path)) { [Environment]::SetEnvironmentVariable('Path', $currentPath + ';' + $x64Path, 'Machine') }; if (-not $currentPath.Contains($x86Path)) { [Environment]::SetEnvironmentVariable('Path', $currentPath + ';' + $x86Path, 'Machine') }

我为错误道歉——看起来我们需要管理员权限来修改系统 PATH。让我为你提供手动执行此操作的步骤：

1. 按 Windows + X 并选择 “System”
2. 点击右侧的 “Advanced system settings”
3. 点击底部的 “Environment Variables”
4. 在 “System variables” 部分 (下半部分),找到并选择 “Path”
5. 点击 “Edit”
6. 点击 “New” 并添加这两个路径：

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86

1. 点击所有窗口上的 “OK” 以保存

完成此操作后，请打开一个新的 PowerShell 窗口并通过运行以下命令验证安装：

运行终端命令：cdb -version

将路径添加到系统环境变量后，你需要重新启动 PowerShell 会话。请：

1. 完成我上面提供的手动 PATH 添加步骤
2. 关闭所有 PowerShell 窗口
3. 打开一个新的 PowerShell 窗口
4. 准备好后告诉我，我会帮你验证安装

完成后，我们可以继续分析崩溃转储！

alansguigna1:我已准备好，请继续验证安装。

GitHub Copilot:让我们验证 CDB 现在是否已正确安装并可在你的 PATH 中访问：

运行终端命令：cdb -version

看起来 CDB 仍然无法访问。让我们仔细检查安装路径并确保文件存在：

运行终端命令：Get-ChildItem 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe'

好消息!CDB 可执行文件存在于正确的位置。让我们尝试使用完整路径运行它来验证它是否工作：

运行终端命令："C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe" -version

让我尝试另一种方式运行它 (PowerShell 对路径中的空格可能很挑剔):

运行终端命令：& 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe' -version

太好了!CDB 已安装并正常工作。问题可能是 PATH 环境变量在当前 PowerShell 会话中尚未刷新。让我们刷新它：

运行终端命令：$env:Path = [System.Environment]::GetEnvironmentVariable("Path","Machine") + ";" + [System.Environment]::GetEnvironmentVariable("Path","User")

现在让我们再次尝试 CDB 命令：

运行终端命令：cdb -version

我看到我们仍然在 PATH 方面遇到一些问题。现在，我们可以使用 CDB 的完整路径继续分析崩溃转储。让我尝试分析崩溃转储：

运行 open_windbg_dump

完成并输入：{

“dump_path”: “c:\Users\alans\OneDrive\mcp-windbg\mcp-windbg\src\mcp_server_windbg\tests\dumps\DemoCrash1.exe.7088.dmp”,

“include_threads”: true,

“include_modules”: true,

“include_stack_trace”: true

}

我为持续的问题道歉。让我建议一些尝试的事情：

1. 确保在将路径添加到环境变量后完全关闭并重新打开 VS Code。
2. 通过在新的 PowerShell 窗口中运行以下命令验证路径添加：

$env:Path-split';'|Where-Object { $_-like'*Debuggers*' }

1. 如果未显示调试器路径，你可能需要验证环境变量是否已正确添加：
2. 按 Windows + X
3. 选择 “System”
4. 点击 “Advanced system settings”
5. 点击 “Environment Variables”
6. 在 “System variables” 下，找到 “Path”
7. 验证这些路径是否存在：

C:\Program Files (x86)\Windows Kits\10\Debuggers\x64
C:\Program Files (x86)\Windows Kits\10\Debuggers\x86

你想让我帮你验证这些设置吗？此外，作为变通方法，我们可以通过检查 cdb_session.py文件并在需要时更新它，临时将项目配置为使用 CDB 的完整路径。

alansguigna1:是的

GitHub Copilot:让我们验证环境设置，然后查看如何使用完整路径配置项目。首先，让我们检查当前 PATH 中的调试器条目：

运行终端命令：$env:Path -split ';' | Where-Object { $_ -like '_Debuggers_' }

我看到 x64 调试器路径在那里。现在，让我们查看 cdb_session.py文件，看看它是如何配置来查找 CDB 的：

读取文件：file:///c%3A/Users/alans/OneDrive/mcp-windbg/mcp-windbg/src/mcp_server_windbg/cdb_session.py#1-1，第 1 至 50 行

很好，我可以看到代码已经有一个默认 CDB 路径列表，并且可以接受自定义路径。让我们验证哪个 CDB 路径存在并使用它来配置项目：

运行终端命令：$paths = @('C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe','C:\Program Files (x86)\Windows Kits\10\Debuggers\x86\cdb.exe','C:\Program Files\Debugging Tools for Windows (x64)\cdb.exe','C:\Program Files\Debugging Tools for Windows (x86)\cdb.exe'); foreach ($path in $paths) { if (Test-Path $path) { Write-Host "Found CDB at: $path" }}

完美！我们找到了 x64 和 x86 版本的 CDB。让我们现在尝试分析崩溃转储，明确指定 x64 CDB 路径：

运行 open_windbg_dump

完成并输入：{

“dump_path”: “c:\Users\alans\OneDrive\mcp-windbg\mcp-windbg\src\mcp_server_windbg\tests\dumps\DemoCrash1.exe.7088.dmp”,

“include_threads”: true,

“include_modules”: true,

“include_stack_trace”: true

}

让我检查转储文件是否需要任何特定权限或要求：

运行终端命令：Get-Acl "c:\Users\alans\OneDrive\mcp-windbg\mcp-windbg\src\mcp_server_windbg\tests\dumps\DemoCrash1.exe.7088.dmp" | Format-List

权限看起来不错。让我们尝试直接在转储文件上运行 CDB，看看是否能得到任何有用的错误消息：

运行终端命令：& 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\cdb.exe' -z "c:\Users\alans\OneDrive\mcp-windbg\mcp-windbg\src\mcp_server_windbg\tests\dumps\DemoCrash1.exe.7088.dmp"

啊！现在我们有一个清晰的错误消息：”Could not match Dump File signature – invalid file format”。这表明：

1. 转储文件可能已损坏

2. 转储文件可能与 CDB 期望的格式不同

3. 转储文件可能不完整

让我们检查转储文件的大小和内容：

运行终端命令：Get-Item "c:\Users\alans\OneDrive\mcp-windbg\mcp-windbg\src\mcp_server_windbg\tests\dumps\DemoCrash1.exe.7088.dmp" | Select-Object Length, CreationTime, LastWriteTime

转储文件只有 132 字节，对于有效的崩溃转储来说太小了。Windows 崩溃转储通常应该有几 MB 的大小，因为它包含内存内容、寄存器状态和其他调试信息。

这表明：

1. 该文件可能是占位符或测试文件

2. 转储文件未正确创建

3. 文件可能在创建或传输期间被截断或损坏

你想让我：

1. 使用 examples 文件夹中的示例程序之一帮助你生成新的崩溃转储？

2. 在工作区中查找其他转储文件？

1. 帮助你配置 Windows 以创建适当的崩溃转储？

请告诉我你想继续哪个选项。

alansguigna1:我已用有效的文件替换了它。请重试。

GitHub Copilot:我会再次尝试分析转储文件，既然你已经用有效的替换了它：

运行 open_windbg_dump

完成并输入：{

“dump_path”: “c:\Users\alans\OneDrive\mcp-windbg\mcp-windbg\src\mcp_server_windbg\tests\dumps\DemoCrash1.exe.7088.dmp”,

“include_threads”: true,

“include_modules”: true,

“include_stack_trace”: true

}

很好！现在我可以正确分析崩溃转储了。这似乎是一个空指针解引用崩溃。以下是关键发现：

1. 崩溃类型

   :空指针写入访问冲突 (0xC0000005)

ExceptionCode: c0000005 (Access violation)
Attempt to write to address 0000000000000000

1. 崩溃位置

   :DemoCrash1.exe中偏移量 0x1ee4 处

DemoCrash1+0x1ee4: movdword ptr [rax],2Ah

代码试图将值 0x2A (十进制 42) 写入 RAX 寄存器指向的内存位置，但 RAX 包含 0 (空)。

1. 崩溃时的寄存器状态

   :

rax=0000000000000000 (导致崩溃的空指针)
rip=00007ff700131ee4 (崩溃位置的指令指针)

1. 堆栈跟踪

   :

DemoCrash1+0x1ee4
DemoCrash1+0x5730
kernel32!BaseThreadInitThunk+0x14
ntdll!RtlUserThreadStart+0x21

崩溃发生在程序初始化期间，如调用堆栈中存在 BaseThreadInitThunk和 RtlUserThreadStart所证明。

这似乎来自存储库中的示例程序之一，专门设计用于演示崩溃分析。查看 examples 目录，这可能来自 nullptr-dereference.cpp示例。

你想让我：

1. 运行更多分析命令以获取有关崩溃的更多详细信息？

2. 查看导致此崩溃的示例的源代码？

3. 关闭此调试会话并分析不同的崩溃转储？

请告诉我你想如何继续！

alansguigna1:用 k 命令给我显示调用堆栈

GitHub Copilot:我将使用 run_windbg_cmd工具在转储上执行 ‘k’ 命令：

运行 run_windbg_cmd

完成并输入：{

“command”: “k”,

“dump_path”: “c:\Users\alans\OneDrive\mcp-windbg\mcp-windbg\src\mcp_server_windbg\tests\dumps\DemoCrash1.exe.7088.dmp”

}

此调用堆栈显示崩溃时的函数调用序列，从下到上阅读：

1. 程序以 RtlUserThreadStart开始 (正常的 Windows 进程初始化)

2. 通过 BaseThreadInitThunk(线程启动)

3. 进入 DemoCrash1.exe应用程序的两个位置：

• DemoCrash1+0x5730

• DemoCrash1+0x1ee4

  (崩溃发生的地方)

1. 堆栈的其余部分显示崩溃发生后的 Windows 错误处理链：

• KiUserExceptionDispatch

  (异常处理)

• RtlDispatchException

  (异常分派)

• UnhandledExceptionFilter

  (系统错误处理)

• WerpReportFault

  (Windows 错误报告)

崩溃发生在 DemoCrash1+0x1ee4,这是空指针解引用发生的地方。由于这是一个剥离的可执行文件 (没有调试符号),我们看到的是 DemoCrash1模块中的偏移量而不是函数名称。

你想让我：

1. 显示有关调用堆栈中任何特定帧的更多详细信息？

2. 查看崩溃点周围的反汇编？

3. 运行任何其他 WinDbg 命令以收集更多信息？

alansguigna1:查看崩溃点周围的反汇编，并详细说明导致空指针解引用的最后三条指令。

GitHub Copilot:我将使用 run_windbg_cmd工具查看崩溃点周围的反汇编。我将使用 u命令显示崩溃位置之前和之后的指令：

运行 run_windbg_cmd

完成并输入：{

“dump_path”: “c:\Users\alans\OneDrive\mcp-windbg\mcp-windbg\src\mcp_server_windbg\tests\dumps\DemoCrash1.exe.7088.dmp”,

“command”: “u DemoCrash1+0x1ee4 L8”

}

让我获取崩溃点之前的几条指令，看看是什么导致了它：

运行 run_windbg_cmd

完成并输入：{

“dump_path”: “c:\Users\alans\OneDrive\mcp-windbg\mcp-windbg\src\mcp_server_windbg\tests\dumps\DemoCrash1.exe.7088.dmp”,

“command”: “ub DemoCrash1+0x1ee4 L3”

}

现在我可以分析导致崩溃的最后三条指令：

1. mov rcx,rbx

• 将 rbx 寄存器中的值复制到 rcx

• 可能是为函数调用准备参数

1. call DemoCrash1+0x2660

• 对程序中另一个位置进行函数调用

• 此函数可能返回应存储在 rax 中的某个值

1. xor eax,eax

• 此指令将 eax 寄存器 (rax 的低 32 位) 清零

• 这就是为什么崩溃发生时 rax 为 0 的原因

• 这是在 x86/x64 汇编中将寄存器设置为 0 的常见方法

然后崩溃发生在：

movdword ptr [rax],2Ah

此指令尝试将值 0x2A (十进制 42) 写入 rax 指向的内存位置。但是，由于 rax 被 xor eax,eax指令显式设置为 0，这会导致空指针解引用。

这看起来像是故意导致崩溃的代码 (这是有道理的，因为它来自示例程序)。代码：

1. 进行函数调用

2. 显式地将 rax 设置为 0

3. 立即尝试写入 rax 指向的内存位置

这种模式是设计用于演示空指针崩溃的测试代码的典型，并且与我们期望从存储库中的 nullptr-dereference.cpp示例中看到的相匹配。

你想让我：

1. 查看被调用的函数 (在 DemoCrash1+0x2660处)?

2. 检查崩溃时其他寄存器中的值？

3. 查看 nullptr-dereference.cpp中的源代码以与此汇编相关联？

alansguigna1:运行 run_windbg_cmd .ecxr

GitHub Copilot:运行 run_windbg_cmd

完成并输入：{

“dump_path”: “c:\Users\alans\OneDrive\mcp-windbg\mcp-windbg\src\mcp_server_windbg\tests\dumps\DemoCrash1.exe.7088.dmp”,

“command”: “.ecxr”

}

.ecxr命令向我们显示异常上下文记录，它在崩溃时为我们提供所有 CPU 寄存器的状态。以下是我们可以看到的：

1. rax=0000000000000000

• 导致崩溃的空指针

1. rbx=00007ff700160320

• 指向 DemoCrash1 模块中的某个地方

1. rip=00007ff700131ee4

• 崩溃位置的指令指针

1. efl=00010246

• CPU 标志显示：

• zr

  (零标志) 已设置

• pl

  (符号标志) 已清除

• ei

  (中断标志) 已设置

指令 mov dword ptr [rax],2Ah试图将值 0x2A 写入地址 0，这触发了访问冲突。ds:0000000000000000=????????` 表示地址 0 处的内存不可访问 (对于空指针是预期的)。

大多数其他寄存器 (rsi, r12-r15) 为零，这在程序启动时是典型的。rbx中的非零值 (指向 DemoCrash1 模块) 可能是 this 指针或崩溃发生时正在操作的其他对象引用。

你可以看到，我运行了 open_windbg_dump 来自动查找和分析 DemoCrash1.exe.7088.dmp。那真是太酷了。在我的一些失误之后，它很好地提供了对崩溃的根本原因洞察。

我想向那些可能想知道在上面的示例中同时使用 GitHub Copilot 和 Claude Sonnet 3.5 的人指出一些事情……它们不都是 LLM 和聊天机器人吗？在这种情况下，答案是断然否定的:Copilot 是 VS Code UI 中的前端服务，Claude 是后端 LLM。换句话说，Copilot 只是一个 VS Code 扩展，它在幕后使用 Claude LLM。所以，当我请求帮助设置环境变量时，是 Claude 给出了答案，而 Copilot 将其转达给我。

还有一件事：我经常被问到这些研究需要多少令牌，以及是否所有这些都可以通过 LLM 和应用程序的免费版本完成，或者我们是否必须升级到付费版本。对我自己来说，我在很久以前就升级到了 ChatGPT Pro (20/月),因为我想要我能得到的最大令牌上下文窗口(当然，在我的预算内);Plus计划似乎是32K令牌，Free计划是8K令牌。我这样做是为了根据我之前的博客处理大型IntelProcessorTrace文件:《MicrosoftWinDbgTimeTravelDebuggingversusIntelProcessorTrace》。在为这篇博客工作的早期，Microsoft暂停了我的问题一段时间，要求升级到GitHubCopilotPro(10/月)。我也进行了此升级，此后没有遇到任何暂停。是的，这是一笔费用，但在我看来，非常值得。

如果你想直观地看到整个 MCP/WinDbg 配置过程，请查看我的视频：

设置 VS Code、MCP Server 和 WinDbg 崩溃转储分析：https://whiteknightlabs.com/wp-content/uploads/2025/10/MCP-WinDbg.mp4

我们从这里去哪里？我相信这是一种新兴技术方法，将在攻击性安全参与的未来发挥巨大作用。在之前的 White Knight Labs 博客文章《理解 Windows 内核驱动程序中的空指针解引用》(Understanding Null Pointer Dereference in Windows Kernel Drivers) 中，我们探讨了类似的访问冲突，但在 Windows 内核中。我们将在未来的文章中看到如何使用 MCP 来分类 Windows 内核驱动程序漏洞。

---

资源

• https://whiteknightlabs.com/2025/10/21/using-mcp-for-debugging-reversing-and-threat-analysis/ Alan Sguigna

Using MCP for Debugging, Reversing, and Threat Analysis

免责声明：本博客文章仅用于教育和研究目的。提供的所有技术和代码示例旨在帮助防御者理解攻击手法并提高安全态势。请勿使用此信息访问或干扰您不拥有或没有明确测试权限的系统。未经授权的使用可能违反法律和道德准则。作者对因应用所讨论概念而导致的任何误用或损害不承担任何责任。

---

查看原文：《使用 MCP 进行调试、逆向与威胁分析》