MCP Crash Analyzer

MCP碰撞分析仪

使用GDB进行自动崩溃分析的模型上下文协议（MCP）服务器。

引言

此MCP工具分析程序崩溃，并提供详细的调试见解，包括寄存器状态、内存快照、反汇编和堆栈跟踪。

它是作为一项学习练习而创建的，旨在探索模型上下文协议（MCP）的工作原理，主要是在人工智能代理的帮助下构建的。该工具已经在一些特定的碰撞场景中进行了测试，并产生了有希望的结果，尽管它还没有在更复杂的情况下得到深入验证。

我不打算继续积极开发，但如果你遇到问题或有有趣的功能想法，请随时在“问题”选项卡中打开工单——如果时间允许，我会看看。贡献、反馈或分叉总是受欢迎的。

特性

🔍 自动碰撞检测 -运行程序并自动检测崩溃\ 📊 综合分析 -捕获信号、位置、回溯、寄存器、内存\ 🎯 智能拆解 -带碰撞位置标记的全功能拆卸\ 💾 内存检查 -以十六进制/ASCII格式读取任何地址的内存\ ⚙️ 注册状态 -崩溃时完成CPU寄存器快照\ 🏗️ 系统信息 -架构、调试符号、端序检测\ ⚡ 基于会话 -加载一次，查询多次进行详细分析

快速开始

安装

# Install dependencies
pip install -r requirements.txt

配置

添加到MCP设置文件中：

VS代码与Cline (~/.config/Code/User/mcp.json):

{
  "mcpServers": {
    "crash-analyzer": {
      "command": "python3",
      "args": ["/absolute/path/to/mcp_crash_analyzer.py"]
    }
  }
}

克劳德桌面 (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "crash-analyzer": {
      "command": "python3",
      "args": ["/absolute/path/to/mcp_crash_analyzer.py"]
    }
  }
}

环境变量

• MCP_CRASH_ANALYZER_LOG -自定义日志文件路径（可选）

- 违约： ~/.cache/mcp_crash_analyzer.log - 例子： export MCP_CRASH_ANALYZER_LOG=/var/log/crash_analyzer.log

用法

基本工作流程

1. 加载并运行 一个程序直到崩溃：

load_and_run("/path/to/program", args=["arg1"], timeout=10)

1. 分析坠机事件:

get_disassembly_function()  # See crash instruction
get_registers()             # Check CPU state
read_memory("$rsp", 64)     # Inspect memory

1. 完成后关闭:

close_session()

可用工具

核心工具

• load_and_run(binary_path, args=None, timeout=10)\

加载并运行程序，直到崩溃或退出

• get_registers(register_names=None)\

在崩溃时获取CPU寄存器值

• get_disassembly_function()\

完全拆卸碰撞功能

• get_disassembly_range(start_address, end_address, mode=0)\

分解特定地址范围

• read_memory(address, size, format="hex")\

读取任何地址的内存

• get_system_info()\

获取架构和调试信息

• get_full_report()\

获取完整的碰撞报告

• close_session()\

关闭GDB会话

实例分析

# 1. Run program
result = load_and_run("/path/to/crashed_program")
# {"crashed": true, "signal": "SIGSEGV", ...}

# 2. See where it crashed
disasm = get_disassembly_function()
# "0x12345: mov (%rax),%ebx ← CRASH"

# 3. Check registers
regs = get_registers(["rax", "rbx", "rsp"])
# {"rax": "0x0", "rbx": "0x7fff...", ...}

# 4. Read stack
mem = read_memory("$rsp", 128, "both")

# 5. Close
close_session()

输出示例

{
  "crashed": true,
  "signal": {
    "name": "SIGSEGV",
    "meaning": "Segmentation fault"
  },
  "location": {
    "function": "process_data",
    "address": "0x555555555234",
    "file": "main.c",
    "line": "42"
  },
  "disassembly": [
    "0x555555555230: mov    %rdi,%rax",
    "0x555555555234: mov    (%rax),%edx ← CRASH",
    "0x555555555236: add    $0x1,%edx"
  ]
}

常见信号类型

在分析崩溃时，您会遇到以下常见信号：

• 西格夫 -分段错误（无效内存访问、空指针解引用）
• 信号中止 -中止信号（断言失败， abort() 呼叫）
• 浮点异常 -浮点异常（除零，数学运算无效）
• 非法指令 -非法指令（代码损坏、架构错误）
• SIGBUS -总线错误（内存访问未对齐）
• SIGSYS -系统调用错误

需求

• Python 3.8+
• GDB（GNU调试器）
• pygdbmi -Python GDB机器接口
• fastmcp -快速MCP服务器框架

用例

• 自动化测试：检测和分析CI/CD管道中的崩溃
• 缺陷类选：生成具有完整上下文的详细碰撞报告
• 法医学：生产崩溃的事后调试
• 证券分析：分析漏洞和漏洞
• 学习：研究汇编，了解程序崩溃的原因
• 发展：无需手动GDB会话即可快速进行崩溃分析

碰撞分析工作流程

崩溃分析器提供有关程序故障的详细信息：

什么被捕获

1. 信号信息 -碰撞类型及其原因
2. 碰撞位置 -精确的函数、文件、行和地址
3. 回溯 -完整的调用堆栈，显示程序是如何到达崩溃的
4. 寄存器值 -崩溃时的CPU状态（用于低级调试）
5. 局部变量 -崩溃函数中的变量值
6. 反汇编 -碰撞地址周围的装配说明
7. 内存状态 -堆叠和堆检查
8. 控制台输出 -崩溃前的所有程序输出

分析模式

基于会话（高级）:

• 使用以下命令加载程序一次 load_and_run()
• 使用单个工具查询详细信息
• 对检查内容进行精细控制
• 最适合深度调试

完整报告（快速）:

• 立即获取所有内容 get_full_report()
• 在一次通话中完成碰撞分析
• 最适合自动报告

运作原理

1. 用途 pygdbmi 通过机器接口控制GDB
2. 在加载和分析之间保持会话状态
3. 在崩溃时刻捕获寄存器快照
4. 提供多种分析视图（反汇编、内存、寄存器）

局限性

• 平台：仅限Linux/Unix（需要GDB）
• 执行：程序必须具有适当的权限才能执行
• 可重复性：碰撞必须是可再现的（确定性）
• 调试信息：源代码行信息需要调试符号(-g 旗帜）
• 内核转储：无法直接分析核心转储（请运行程序）
• 单次碰撞：仅分析第一次碰撞（碰撞后不继续）
• 优化：高度优化的代码可能包含不完整的变量信息

最佳实践

1. 使用调试符号编译：使用 -g 源线信息标志
2. 调试期间禁用优化：使用 -O0 保存可变信息
3. 设置适当的超时：增加慢速启动程序的超时时间
4. 检查权限：确保二进制文件具有执行权限(chmod +x)
5. 使用绝对路径：提供二进制文件和源文件的完整路径

🐛 故障排除

📚 资源

• pygdbmi: https://github.com/cs01/pygdbmi
• GDB/MI: https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI.html
• 主控程序: https://modelcontextprotocol.io/

许可证

MIT许可证-免费使用和修改

作者

马格努斯·卢切斯

______________________________________________________________________

备注：此工具自动化GDB进行崩溃分析。对于交互式调试，直接使用GDB。