第 29 章 AI 辅助逆向（LLM 驱动反编译）

2025-2026 年逆向工程最大的范式转变：LLM 直接把汇编/反编译代码翻译成可读源码，并能自动验证正确性。本章讲清楚"AI 能替你做什么、不能做什么、怎么用"。

📍 知识点地图 | 主题：AI辅助逆向 | 前置：第4章 | 后续：第95章 | 核心概念：LLM4Decompile、神经反编译、验证循环

29.1 AI 辅助逆向的能力边界（核心认知）

AI 擅长（放心用）:
  ✅ 函数语义概括（这函数干什么）
  ✅ 命名建议（把 sub_401000 变成 check_license）
  ✅ 已知算法识别（AES/RC4/TEA/自定义 XOR 变体）
  ✅ 字符串/常量分类（URL/密钥/路径/协议）
  ✅ 伪代码到 C 的翻译（神经反编译）
  ✅ 注释生成（大段代码快速理解）
  ✅ 协议格式推断（给 hex dump 猜结构）
  ✅ 反汇编片段模式识别（反调试/虚拟机检测）

AI 不擅长（别指望）:
  ❌ 虚拟化混淆/重度控制流平坦化
  ❌ 复杂间接调用（vtable/函数指针链）
  ❌ 超长函数（>1000 行，上下文窗口限制）
  ❌ 浮点/向量化语义恢复
  ❌ 需要精确地址/偏移的判断（幻觉风险）
  ❌ 没有"运行验证"的纯静态还原

原则：AI 是"语义助手"，不是"事实来源"。AI 的输出都要在运行时验证。

29.2 工具生态（2026 现状）

29.3 AI 辅助逆向工作流（架构）

┌─ 1. 快速侦察 ─────────────────────────────┐
│ strings → LLM 分类（URL/密钥/路径/协议）    │
│ 导入表 → LLM 推断（加密=OpenSSL? 网络=libcurl?）│
│ 反汇编片段 → LLM 识别模式（算法/反调试/VM检测）│
└───────────────────────────────────────────┘
┌─ 2. 神经反编译 ───────────────────────────┐
│ LLM4Decompile: 汇编 → C 源码               │
│ 验证: 重编译 → 对比行为等价性               │
└───────────────────────────────────────────┘
┌─ 3. 语义理解 ─────────────────────────────┐
│ 函数命名 / 类型恢复 / 算法识别 / 注释生成    │
│ 协议推断（hex dump → 字段结构）             │
└───────────────────────────────────────────┘
┌─ 4. 多 Agent 验证 ────────────────────────┐
│ Agent1 语法: 生成的 C 能解析吗              │
│ Agent2 编译: GCC 能编过吗                  │
│ Agent3 行为: 原始 vs 重编译输出一致吗       │
│ 任何一步失败 → 反馈给 LLM 迭代修正          │
└───────────────────────────────────────────┘

29.4 侦察阶段 Prompt 模板

函数语义分析

You are a reverse engineering expert. Analyze this decompiled function:

[伪代码]

1. What does this function do? (one sentence)
2. Suggest a meaningful function name.
3. What are the input parameters and their likely types?
4. What is the return value?
5. What external APIs/functions does it depend on?
6. Any security-relevant operations (crypto, auth, network, file I/O)?

算法识别

Analyze this assembly for cryptographic operations:

[汇编代码]

1. Is this a known cryptographic algorithm?
   (AES/DES/RC4/TEA/ChaCha20/custom?)
2. Identify the key schedule and round structure.
3. What is the key size?
4. Are there hardcoded constants that identify the algorithm?

协议格式推断

Given this network packet sequence, infer the protocol structure:

[hex dump]

1. Identify magic bytes and length fields.
2. Propose a struct definition for the packet header.
3. What field(s) appear to be checksums/CRCs?
4. Is this a known protocol or custom?

29.5 神经反编译实操

# LLM4Decompile（本地）
python llm4decompile.py --binary target.so --arch arm64 --output target.c

# 验证（重编译 + 行为对比）
gcc -O2 -fPIC -shared -o recompiled.so target.c
# → 用相同输入跑原始和重编译版本，对比输出
# 一致 → 反编译正确；不一致 → 反馈差异给 LLM 修正

验证是 AI 反编译的生命线——没有验证的 AI 输出只能当"参考意见"。

29.6 与现有工作流的整合（最佳实践）

场景 1: 大规模样本（恶意软件批量分析）
  strings + 导入表 → LLM 批量分类 → 标注可疑 → 人工深挖重点

场景 2: 卡在某个混淆函数
  反汇编片段 → LLM 识别模式 → 命中已知混淆（OLLVM?）→ 用对应工具（D-810）

场景 3: 协议逆向
  抓包 hex → LLM 猜结构 → 人工验证字段 → 再问 LLM 细化

场景 4: 函数批量重命名（迁移到新版本）
  符号迁移: 旧版符号表 + 新版函数特征 → LLM 批量匹配（binary-diff 技能）

29.7 局限与防幻觉纪律

□ AI 会"一本正经编答案"——特别是地址/偏移/常量值
□ 每个关键结论要能在反汇编/运行时找到证据
□ 优先让 AI 做"理解类"任务（语义/模式/结构），少做"事实类"任务（精确数值）
□ 大函数先切块再喂（上下文窗口限制）
□ 结合编译反馈验证（29.5）或多 Agent 验证（29.3）
□ 代码和工具是辅助——核心分析框架还是你脑子里的（第 23 章）

29.8 决策树

分析某个函数
├─ 看不懂它在干什么? → LLM 语义分析（29.4 模板）
├─ 需要 C 级还原? → LLM4Decompile + 编译验证
├─ 识别算法/协议? → LLM 模式识别（给它特征+上下文）
├─ 批量命名? → LLM 批量 + 人工抽查
└─ AI 与工具矛盾? → 以运行时行为为准（交叉验证）

动手练习

1. 拿一个 C 编译的小函数（已知功能），用 LLM4Decompile（或直接用 Claude 粘贴伪代码）还原，对比准确度。
2. 用 29.4 的函数语义模板分析一个陌生函数，验证 LLM 输出的每一条结论（1 分钟每条）。
3. 练习"编译反馈验证"：让 AI 生成代码 → 编译 → 对比行为 → 反馈迭代 2 轮。
4. 找一个混淆函数测试 AI 的边界，总结"哪些问题 AI 会答错"。

深入阅读

• 仓库：skills/reverse-engineering/references/ai-assisted-re.md（AI 辅助逆向全量参考）
• 仓库：skills/binary-diff/SKILL.md（LLM 批量符号迁移）
• 仓库：skills/patch-diff-exploit/references/root-cause-and-poc.md（LLM 辅助根因分析）
• 仓库：skills/llm-security/SKILL.md（LLM 安全（反向视角））