当我们在谈论大模型辅助编程时，我们在谈论什么（二）之MCP

最近逼逼的频率确实有点高，证明最近没有偷懒，有在认真的思考问题，每天梦里有也都是各种LLMs和Agents。但还是那句话，本文只是笔者一家之言，仅仅代表自己，不代表任何组织观点，有不同看法或者发现错误的朋友欢迎留言交流。

在上一篇中我们简单聊了下大模型辅助漏洞挖掘解决的第一类问题：开源项目代码审计。讲到了笔者认为的最好的形态是AI Coding工具。顺便插句题外话，解决这个问题最重要的部分肯定不是提示词，而是前面提前的所有能力的总和。顺便根据最近的经验做点补充，笔者认为要想真正实现AI挖洞，微调是必不可少的一步。虽然DeepSeek-R1已经拥有了很强的推理能力和安全领域的先验知识，但当观察它的思考链后不难发现它的思考过程十分轴。举个栗子：xxx，懒狗不想举栗子了，实践过的必然知道。如果不知道的读者可以后台私信笔者，如何微调DeepSeek的文章可以参考鸭鸭的公众号。言归正传，在这一篇中笔者将会谈谈对大模型辅助漏洞挖掘解决二进制漏洞的想法，但由于各种各样的原因，本文只会聊到很小的一个部分，和真正的辅助漏洞挖掘工具相差甚远，一步一步来，后面的部分都会讲到的！

为了方便后面的表述先在此约定：将第一篇文章中解决的问题称为开源漏洞问题；将本篇中解决的问题称为二进制漏洞问题。

想使用LLMs解决二进制漏洞问题的首先需要的解决就是二进制文件的处理，如何将二进制文件转为LLMs理解的语言，不管是自然语言还是代码语言。用AI解决问题的思路无非就是两个方向：

1. 微调或训练一个模型，绝大多数科班出身的机器学习从业者会选择这个方法
2. 使用LLMs应用，绝大多数普通的工程师会选择这个方法

模型

LLM4Decompile

这大概是相关领域最出名的模型了，是否还有更新，更好用的模型笔者并未进行考证，有兴趣的读者可自行搜索。回到正题，这篇论文中提出了两个模型，一个是基座模型LLM4Decompile-End，另一个是在基座模型上进行微调的LLM4Decompile-Ref。前者通过优化LLM训练过程可以直接反编译二进制代码；后者是一种"精炼"模型，通过微调基座模型来优化Ghidra的反编译输出。先抛开模型最终效果不谈，模型的使用成本就是比较高的，不太适合笔者这种爱折腾但贫穷的人类。

LLMs应用

解决这个问题的另一个思路就是遇事不决上应用。在LLMs刚推出不久，就已经有了各种尝试，总结起来就是各种反编译工具的插件，在插件中调用LLMs。笔者已经忘了用过的工具是什么了，但基本上是日抛型工具。这种工具看起来解决一些的问题，但是其实并没有真正的用到LLMs，原因如下：

• 这类工具看起来自动化了，但本质上并不是自动化，只是省去了人类把内容粘在对话框的时间
• LLMs真正的魅力在于Understanding - Planning - Excuting - Reflecting，而不是简单的理解伪代码

总结

如果总结上述方案的问题的话，笔者会总结成一句话：上面的方案都是将LLMs当作工具，而没有将LLMs当成一个智能体，让反编译工具成为它们的工具。

事物总是快速发展的，随着技术的发展很快又有了新的解决方案：AI Agent技术。使用Claude的表述解释一下AI Agent:

AI Agent是一种能够代表用户或其他系统自主执行任务的软件程序，它可以设计自己的工作流程并利用各种可用工具来完成任务，AI Agent能够感知其环境、收集数据，并基于这些数据执行自决策任务以实现预定目标。

插句题外话，现在会有很多不同的看法，比如：

• AI Agent只是大模型还不够成熟的中间产物
• AI Agent和WorkFlow到底谁更好

笔者认为，不同的场景有不同的使用方案，依场景而定，做大量的实验验证就行了。言归正传，也有不少相关项目用到了AI Agent，用于实现自动化打CTF的目的，这里随便列几个工具（笔者都没用过，只是调研的时候看到了，所以不对工具效果负责）：

• https://github.com/Protosec-Research/AutoGDB
• https://github.com/Protosec-Research/BinaryChat

AI Agent中最有用的部分就是function calling或者tool calling，让大模型去决定调用什么工具，是执行什么操作。AI Agent虽好，但并不是所有人都能有开发AI Agent的能力，那有没有什么方案能够无痛让不同的LLMs调用工具呢？当然有，那就是Claude提出的MCP协议，协议用比较官方的话说就是：

MCP是一种开放协议标准，专为建立AI模型（如Claude）与开发环境之间的统一上下文交互而设计。它使AI能够更好地理解和处理代码结构、项目环境和开发者意图，通过MCP用户可以扩展Claude的功能，例如读取计算机文件系统、写入新文件、移动文件甚至搜索文件

但其实说人话就是让function calling和tool calling更加标准化，让使用更加简单，本质上就是工具调用。这里不展开讲了，感兴趣的读者可以读读Claude的官方文档。MCP完美解决前面遇到的问题：

• 可以将反编译工具当作LLMs的工具，爱接多少接多少：甚至可以根据不同语言来：dnspy，java decompiler，IDA等等
• 并不需要每个人都写代码；插件化，即插即用

下面将会介绍一下笔者实践过的一些方案，这里以IDA MCP SERVER为例：

IDA中使用IPython

灵感来源于两个项目：

• https://github.com/eset/ipyida
• https://github.com/datalayer/jupyter-mcp-server

实现逻辑很简单：在IDA中安装IPython插件，启动jupyter notebook，再改一改上述的jupyter-mcp-server即可。理想很美好，现实很残酷，主要遇到几个问题：

1. ipyida年头有点长了，还在用jupyter 7.0以下的版本，所以和jupyter-mcp-server不兼容，得自己实现一套
2. 当笔者自己手撸了一套WS请求的API之后，发现在MCP中没法直接调用IDA的SDK

所以这个方案就先搁置了。

headless ida

这个方案的灵感来源于在寻找如何通过外部Python调用IDA SDK方案时，群友给出的建议。相关项目：

• https://github.com/DennyDai/headless-ida
• https://github.com/hugsy/ida-headless

这两个项目采用两种不同的实现方法，这里简单讲一下：

• headless-ida是使用了idat，类似于headless chromium
• ida-headless则是使用了rpyc，使用rpyc有个很大的问题就是IDA中rpyc暴露的接口太少太少了

总结

综上所述，笔者会选择headless-ida作为最终的方案去实现IDA MCP SERVER。如果有其他方案的读者，可以在后台留言交流！

以笔者懒狗的性格，本来不应该这么快产出下一篇文章的。促使笔者写这篇文章的原因是：今天开源了很多IDA MCP SERVER！不完全统计如下：

• https://github.com/MxIris-Reverse-Engineering/ida-mcp-server
• https://github.com/LaurieWired/GhidraMCP
• https://github.com/taida957789/ida-mcp-server-plugin

但这些笔者都没还来得及用，更来不及仔细研究它们是如何实现的，感兴趣的读者就蹲一下下一篇文章。笔者看到这些开源项目的时候，越发的感觉到：这真是个最好的时代，也是个最坏的时代。

• https://www.anthropic.com/engineering/building-effective-agents
• https://www.anthropic.com/news/model-context-protocol