AI辅助逆向工程：用大语言模型读懂二进制代码

1. 这个31.2K Star的项目到底解决的是什么问题

先聊点实际的。做逆向工程的朋友应该都有过这种体验：拿到一个二进制文件，扔进反汇编器，一打开全是十六进制和跳转指令，头瞬间就大了。尤其是碰到那种没有符号表、没有调试信息、甚至可能是混淆过的二进制，光靠肉眼和传统工具一点点看，一个简单函数推导半天都不一定搞得清楚。

我自己最早做逆向还是大学的时候，某次为了分析一个CTF的模拟题目，抱着IDA F5按了整整一下午，那感觉就像在一堆乱麻里面挑一根有颜色的线，挑着挑着就麻了。后来工作以后接触真实场景，才发现CTF那点量根本不算啥——真实世界里的固件、恶意样本、遗留的老系统程序，体积和复杂度能让人崩溃。

所以当我看到这个在GitHub上拿到了31.2K Star的项目时，第一反应是：终于有人把AI拉到逆向这条老路上来干活了。它做的事情用大白话讲，就是让AI辅助分析二进制代码，能反编译、能解析函数意图、能做代码注释、能尝试识别变量名和函数名，甚至可以和用户对话式地对样本进行提问分析。

这个项目的热度本身就说明一件事：逆向工程这个领域太苦了，大家对AI辅助的期待值早就拉满了。31.2K Star不是凭空来的，它是全球大量逆向工程师、安全研究员、CTF选手、红队蓝队成员用脚投票的结果。这个项目不是“玩具”，它是真的在尝试把大语言模型的能力嫁接到二进制分析这个硬核场景里，而且从社区反馈来看，实际效果还算能打。

那这篇文章我就想以“用户”和“实践者”的双重身份，把这个项目从原理到实操完整拆一遍。我会把它是什么、怎么跑起来、实际测试效果如何、有哪些坑、怎么用更顺手这些点全部分享出来，尽量让已经入门的同学能直接照着操作出一套自己的AI逆向辅助工作流。

2. 项目核心原理：它如何让大模型看懂二进制

这个项目本质上是一个把二进制分析链路和大语言模型（LLM）能力揉在一起的工程框架。它不是说拿一个ChatGPT直接把二进制喂进去问，而是在二进制、反编译器输出、模型之间搭了一座结构化的桥。

2.1 输入端：先行反编译，再喂给模型

这里有个很容易被误解的点：AI并不是直接理解机器码。机器码对现在的LLM来说属于完全不可读的胡言乱语，哪怕是参数千亿的模型也读不懂原始字节流。所以这个项目的处理流程一般是这样：

1. 首先用反编译工具（比如Ghidra、IDA Pro、Radare2等）对目标二进制做静态分析，生成伪代码、函数列表、反汇编结果。
2. 然后项目内部会把反编译结果进行结构化提取，比如把每个函数、每个变量、每个调用关系、相关字符串引用都做标记。
3. 最后把这些结构化信息拼接成设计好的Prompt模板，送给LLM去做推理、注释、命名、总结等工作。

换句话说，这个项目做的是**“翻译”和“转述”**：它是把人类看不懂的二进制通过传统逆向工具翻译成半可读的伪代码，再让LLM把这种“半可读”变成“完全可读”的工程级解释，比如重构出函数名、变量名、加注释、理清逻辑。

我记得有次拿一个混淆过的Linux程序做测试，反编译出来的伪代码里充满了类似local_28、DAT_00302a58这种无意义的命名，我自己看了半天都不确定某个缓冲区是不是溢出的源头。换到这个AI辅助流程以后，它直接把那个函数标成了类似“根据用户输入执行命令解析并对命令格式进行校验”的描述，变量名也重新梳理了，整个可读性提升了一个数量级。

2.2 模型路径：本地部署和API两种方式都能接

这个项目不是只绑某一个模型，它设计的时候就已经把多个LLM后端给列进支持范围了。常见支持的方向包括：

• 调用云端API，比如OpenAI系（虽然现在国内访问麻烦，但技术上支持）、Anthropic的Claude系列等；
• 接入本地模型，比如通过Ollama跑Qwen、Llama、DeepSeek这类开源模型；
• 某些版本还支持通过代理直接接自定义模型接口。

为什么要提这点？因为逆向工程很多场景是涉密或者内部环境的，不可能把二进制代码传到云端的API。所以支持本地模型这一点极其重要——在实际的“某大型企业内网”安全测试和样本分析场景里，数据离线是硬要求。另外本地跑模型还省钱，尤其是分析大量样本时，云端API调用费用会滚雪球。

我当时实际用的是Ollama跑Qwen系列（因为机器是4090，显存有限），效果虽然不能说吊打GPT-4，但应付常见的CTF题和普通ELF样本分析绰绰有余，而且便宜、私密、随时能改参数。

2.3 交互方式：不只是单向输出，还能“对话式分析”

这个项目的另一个亮点是它做了会话式交互。简单说，你分析完一个函数之后，可以继续追问：“这个函数在处理哪类输入时可能溢出？”“这个指针指向的数据结构可能是什么？”模型会结合上下文中已经分析过的代码继续回答。

这个体验非常像有一个懂逆向的老手坐在你旁边，你随时能问问题，它随时根据已有上下文帮你推理。传统工具比如IDA的自带注释，是死的，写什么就是什么；而这个是活的，能跟你来回讨论。这一点在实际分析复杂恶意样本的时候尤其好用，因为样本里的逻辑往往是层层嵌套的，一次性输出解释根本不够，多轮追问才能真正把逻辑链理清楚。

3. 从零跑通这个项目：环境准备和实操记录

我估计有不少人看到GitHub README就已经懵了，因为涉及的工具链路确实有点多。我第一次搭环境的时候也踩了不少坑，这里把从零到跑通的完整过程写出来，你照着走基本不会卡壳。

3.1 前置环境需求

你需要准备这些基础组件：

组件	说明	推荐版本/路径
Python	项目核心语言	建议3.10以上，我用的是3.10.12
Git	拉取代码	无特别要求，有就行
Ghidra 或 IDA Pro	反编译器支持	Ghidra推荐用11.x以上，IDA的话版本越高越好
Ollama（可选）	本地拉取LLM	官方脚本一键装
对应LLM API Key（可选）	云端模型	按自己需求准备

这里多说一句，Ghidra是免费开源的，对个人使用者来说完全够用，而且它和这个项目的配合度很高——项目很多自动化脚本都是优先针对Ghidra写的。如果手里没有IDA授权，直接用Ghidra就行，功能上一点不虚。

3.2 拉取项目并安装依赖

操作过程基本是这样的：

git clone https://github.com/项目地址（按你自己看到的为准） cd 项目目录 python -m venv venv source venv/bin/activate pip install -r requirements.txt

这里面有个容易踩的坑：如果网络环境不太好，pip install的时候会非常容易超时，建议给pip配上国内镜像源：

pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple

装完依赖以后，还需要确认Ghidra的路径是否写进环境变量，如果没有，项目配置里能手动指定。很多人在这一步卡住，因为Ghidra的安装目录结构里，真正用于命令行调用的程序是support/analyzeHeadless，路径写不对，后续反编译脚本就死活起不来。

3.3 安装和初始化反编译器

以Ghidra为例，你在项目配置文件里需要指定类似这样的路径：

[ghidra] ghidra_path = /opt/ghidra_11.1_PUBLIC

然后运行一次初始化脚本，验证反编译器能不能正常调用。一般会输出类似“Ghidra initialized successfully”的提示。这时候可以先用一个简单的测试二进制跑一遍全流程，比如拿系统自带的一些小程序试手，确认没有断裂再上真实目标。

我当时就是忽略了这一步，直接跑真实样本，结果脚本报错说找不到Ghidra的headless analyzer，又回头折腾了大半个小时。所以提前用小文件验证链路，绝对是节省时间的明智操作。

3.4 配置模型后端并开始第一次分析

我这边用的是Ollama本地模型，所以首先要拉一个模型下来：

ollama pull qwen2.5:14b

然后在项目配置文件里把LLM类型改成ollama，并指定模型名称。如果你用的是云端API，更多是把对应的Key和模型名填进去，这里不展开，README里写得很清楚。

配置好以后，对目标二进制的分析流程通常是：

python 主脚本.py -i 目标二进制文件 -o 输出目录

跑起来之后，可以看到脚本自动调用Ghidra生成反编译结果，然后会有一段等待时间——这就是模型正在处理函数。等结束后，打开输出目录，能看到每个函数都生成了对应的分析报告，包括重构的函数名、变量名、详细注释等。

我第一次跑通的时候，说不震撼是假的。原来需要两三个小时才能大致摸清逻辑的函数，现在大概几分钟就能给你一个靠谱的骨架，剩下就是人肉验证细节了。

4. 实际测试效果：我用三类不同样本做了一次横向评测

光看流程顺利还不够，关键问题是这玩意儿分析出来的结果到底靠不靠谱。为了验证真实水平，我专门找了三类典型样本来做横向测试。

4.1 测试样本一：一个简单的CTF逆向题

测试样本是某CTF比赛的一个签到级逆向题，逻辑很简单——输入一个字符串，经过一个固定异或和一个简单字节替换，然后和内存里的一串密文比较。传统人工做这类题，熟练选手大概五到十分钟内能搞定。

AI辅助分析的效果很让我意外，它直接识别出了“输入经过0x7F异或后进行校验”的规律，并且把密文数组自动提取为可见字符串常量。我根本没有花什么时间看反汇编，直接照着它给的逻辑写了爆破脚本，几十秒就出了flag。

这个结果和人工做基本持平，但效率高出太多了。CTF场景下时间就是分数，这种简单题能被AI秒杀掉，体验简直不要太爽。

4.2 测试样本二：一个加了轻微混淆的真实ELF程序

第二个样本是我从某开源项目里自己编译出来的程序，然后用了现成的混淆工具做了一层控制流平坦化，典型特征是原始代码里的if-else全被改成了while+dirty flag的形式，反编译出来的逻辑很绕，人工梳理很容易看走眼。

这种场景对AI的挑战就大多了。因为控制流平坦化之后，函数的CFG（控制流图）极其难看，变量名的语义已经完全丢失，普通的模型推理在这种结构下非常容易产生幻觉，胡编乱造出一些不存在的逻辑关系。

实际测试的结果：能给出合理猜测，但不是100%准确。比如它把一个和输入长度有关的循环判断注释为“遍历输入字符串计算长度”，实际上那是用来做栈保护校验的，方向偏了点，但是结构上的复杂度它确实帮你看懂了七八成。这种效果已经非常有价值了，因为人工看混淆代码最耗时间的就是识别主干逻辑，AI能把主干先抓出来，细节上的错误可以靠人工修正。

4.3 测试样本三：一个物联网固件里的网络服务程序

第三个样本是我从一个模拟的IoT固件里提取出来的网络服务二进制，主要逻辑是监听端口、接收数据、简单解析后存文件。这个样本特点是有大量字符串引用和明显的socket调用序列。

AI在这个样本上的表现是三类里最好的，几乎是一针见血：它直接总结了“该程序监听8080端口，接收长度最多4096字节的数据包，解析头部后写入本地日志目录”，连协议格式都给画了个大概。原因很简单，网络程序的信息密度高——字符串、端口号、系统调用一目了然，LLM非常擅长从这些线索里做归纳。

4.4 横向效果对比总结

样本类型	人工分析耗时（经验估算）	AI辅助耗时	结果准确率（自我评估）
简单CTF题	5到10分钟	1分钟以内	接近100%
混淆ELF程序	1到2小时	10分钟以内	70%至80%
IoT固件网络服务	半小时到1小时	3分钟左右	90%以上

结论很明显：AI不是万能的，但它在常规分析场景下的提效效果非常可观。尤其是对字符串丰富、逻辑相对线性的目标，它能直接把分析时间压缩到原来的十分之一甚至更低；而对混淆严重的样本，它能帮你把骨架抽出来，至少不会让你在开头阶段就迷失方向。

5. 关键坑和避坑经验：哪些地方最容易踩雷

这类项目听着高大上，真正用起来坑是真的多。我前后跑了两天多，踩了不少雷，下面挑最典型几个做个总结。

5.1 模型太小输出会明显“幻觉”

如果你本机显存不够，硬上7B甚至更小的模型，那分析结果基本没法看。小模型非常容易一本正经地胡编乱造，比如把一个函数标注成“解密函数”，实际上里面压根没有解密逻辑。这种错误比不标注危害更大，因为它会误导你的后续分析方向。

实测下来，14B模型是本地部署的底线，再小就只能当玩具玩。如果显存允许（比如24G以上），直接上32B甚至65B量化版，效果会有质的飞跃。我的4090跑14B其实已经有点紧，生成速度不算快，但这已经是能在效果和性能上找到平衡的选项了。如果实在跑不动大模型，不如直接用云端API，别硬撑小模型。

提示：本地部署的时候一定要检查模型量化版本，一般用Q4_K_M这种量化档位能在效果和资源占用之间取得平衡。

5.2 Ghidra版本和脚本兼容性问题

这个项目对Ghidra版本是有要求的，太老的版本某些API接口对不上，脚本跑一半直接报错。我当时一开始用的10.x版本，某一步处理导出函数列表时报了个晦涩的Java异常，查了半天才发现是版本太老导致接口不对。

建议直接用最新稳定版，省掉一堆兼容性破事。另外Ghidra的安装路径里不要有中文或空格，别问为什么，都是眼泪。

5.3 大函数分析容易超时或超Token上限

函数越大，反编译生成的伪代码越长，LLM的上下文窗口很快就会被占满。碰到一个几百行的大函数，模型要么直接报错，要么只分析前半部分，后半部分就直接失真了。

解决办法有三个：

1. 尽量用反编译器的“分隔函数”功能，把大函数按逻辑块拆开。
2. 调整项目配置里的Token上限，只要模型支持，往大了设。
3. 先让AI做整体结构概览，再锁定重点函数逐步深追，不要一把梭全塞进去。

这个经验在分析完整恶意样本的时候尤其重要。大多数恶意软件的函数并不长，但如果你拿到的是一个大型框架打包出来的样本，函数体可能有几百行，这种时候千万别指望AI一口气全懂，分块喂才是正路。

5.4 混淆代码和多层嵌套结构会显著拉低效果

前面测试里那个混淆样本已经证明了这点。控制流平坦化、虚拟机保护这类高级混淆手段，对LLM来说属于“跨语种理解”——本来就是把人类代码故意扭曲成非人类结构，再强的模型也会被绕晕。

如果目标是带商业级保护壳的样本，我的建议是：先用传统的静态脱壳工具把壳去掉，再用反编译器拿到相对干净的伪代码，最后才交给AI。跳过脱壳直接喂，结果基本是瞎蒙。

5.5 输出不稳定，同一函数两次分析结果可能完全不同

LLM的采样策略决定了同一输入可能产生不同输出。这既是特点也是问题：有时第一次分析跑偏，第二次反而说对了。我的做法是设置temperature比较低的值（比如0.1到0.2），并把多次分析结果做交叉验证。实际使用中，对关键函数多跑两次，哪怕有一点微调，都比较容易识别出模型的哪部分结论是“稳定输出”，哪部分是“即兴发挥”。

6. 进阶玩法：如何把这个项目融进自己的逆向工程工作流

跑通基础功能和踩完坑以后，我感觉这个项目最大的价值不在于替代人工，而在于重新定义了逆向分析任务的执行顺序。下面分享几个我实际用着很顺的进阶姿势。

6.1 批量化样本筛选：先AI粗筛，再人工精查

做恶意样本分析的时候，经常一次拿到几十上百个样本，不可能全部人工细看。我的做法是先把所有样本用这个项目的批量模式扫一遍，让它生成每个样本的“功能摘要”——比如“窃取浏览器cookie”、“截屏并发送到固定C2”、“键盘记录”等等。

然后我再根据摘要有针对性地抽重点样本细看。这个流程让一个人干出了以前至少三四个人的活。尤其是红队和应急响应场景，时间就是一切，这种方式能快速锁定高危样本，把精力花在最关键的10%上。

6.2 自然语言搜索历史样本库

因为有对话式分析的支持，可以把自己这边积累的历史样本反编译结果全部索引起来，然后随时用自然语言去查：“哪个样本会对文件加密并释放勒索说明？”“哪段代码用了XX加密算法？”这种检索方式比传统深挖快太多了——以前想在样本库里找特定模式，基本只能靠人力一个个过，现在一句自然语言就能圈出候选范围。

这也是我目前觉得最有想象力的方向：把分析结果沉淀成知识库，让AI成为团队里的“活文档”。新人接手项目的时候不需要从头啃上百份报告，直接问AI，就能快速掌握项目全貌。

6.3 配合动态调试做交叉验证

静态分析毕竟是静态的，很多逻辑只有跑起来才能确认。我的进阶流程是：

1. AI出静态分析结论。
2. 在GDB或其它调试器里下断点验证关键函数。
3. 把运行时的真实数据（比如寄存器值、栈上的参数）回传给AI继续追问。
4. 循环几次，直到结论和实际行为完全对上。

这套流程让AI分析从来不只停留在“猜”，而是能在动态数据辅助下收敛到“事实”。我从这个流程里得到了不少传统静态分析根本发现不了的细节，包括某些隐藏分支和错误处理路径。

7. 一些补充建议：什么场景适合用，什么场景最好别指望它

最后说点人间清醒。这类AI辅助逆向项目再火，也不代表它无所不能，更不代表你装了它就能成为逆向高手。我在实践中总结了一套“能用/慎用/别用”的判断标准。

能用：CTF题目、普通软件的功能逆向、恶意样本的初步快速归类、前端或后端简单程序的分析、固件里网络服务程序的协议还原。这些场景下，字符串丰富、逻辑线性、符号信息略多、函数规模适中，AI的发挥空间最大。

慎用：代码混淆程度较高的样本、大型商业软件核心模块、涉及底层硬件交互的初始化代码、涉及复杂算法的加密实现。这些不是不能跑，而是跑出来的结果需要大量人工校验，可能省不了多少时间，甚至因为误导反而拖慢节奏。

别用：商业壳保护的恶意样本（必须先脱壳）、极度精简的汇编手写代码、需要在芯片指令集层面做精确分析的场景。这些地方AI很难提供实质帮助，老老实实用传统手艺反而更快。

我的原则很简单：AI是加速器，不是替代者。没有一个真正成熟的逆向工程师会因为用了这个项目而丢掉吃饭的本事，但用了它之后，能省出来大量时间去深入研究真正复杂的问题——这才是它带给我们的最大价值。