9.2 命名恢复与人机协作

9.2 命名恢复与人机协作

本节摘要：stripped 二进制反编译出来是命名荒漠——FUN_00401190 与 sub_4011a4 满屏，读三个函数就要建一张外号表。本节把命名当工程问题解决：先说清为什么名字是逆向的地基——它是索引、是上下文、是后续一切分析的速度因子；然后给出 LLM 命名建议的提示词骨架——喂调用、字符串、被调关系三类线索，只要结构化 JSON 输出，并带置信度分级；再引入 binsync（约 0.75k stars，2026-10 社区口径）：以 git 为底座，让 Ghidra、IDA、Binary Ninja 三个反编译器共享重命名成果，可审计、可回滚；随后立纪律——AI 建议的名字是假设，行为验证（第 08 章闭环）之后才转正，并给出一段完整的转正会话示例；最后算命名的复利账：名字改善检索、改善模型上下文、改善下一个人的每一天。

学习目标

• 论证「命名是逆向地基」：名字对后续分析的三重影响。
• 写出结构化的命名建议提示词并约束输出格式。
• 用 binsync 组织跨反编译器的命名协作并解释其审计能力。
• 执行「假设、验证、转正」的命名纪律。
• 识别「带病转正」的反面案例并说明其危害。

一、命名荒漠：stripped 的真实代价

编译时 strip 掉符号表，反编译器只能按地址起名：Ghidra 给 FUN_ 加地址，IDA 给 sub_ 加地址。代价不体现在第一条函数——那条你还记得住；代价体现在第三十条：你已经在草稿纸上维护一张「外号表」，每读一段伪代码都要人肉查表。

更深一层，名字缺失直接伤害前面各章的成果：

• 第 08 章的闭环：LLM 读一堆 FUN_ 互相调用的伪代码，提假设的质量随上下文可读性陡降。
• 第 07 章的 CPG：查询结果里函数名全是地址，人工复核慢一个量级。
• 第 10 章的挖掘：智能体在仓库级导航时，命名荒漠是其第一天敌（第 10.3 节）。

所以命名恢复不是「锦上添花的整洁癖」，而是把后续所有分析都提速的地基工程。名字的三重身份：索引（可检索的键）、上下文（模型与人共同依赖的语义）、记忆（团队知识的存储形态）。

二、LLM 命名建议：喂线索、要结构

命名建议的提示词设计有三个要点：喂足线索（模型看不到图，只能看你给的）、限定输出（只要 JSON，防散文）、给出命名风格约束（下划线、动宾结构）。

# name_suggest.py —— 命名恢复提示词骨架（线索三类：调用、字符串、被调关系）
PROMPT = """你是逆向工程命名助手。下面是一个 stripped 函数的伪代码与线索。
给出命名建议，只输出 JSON，格式：
{{"func": "snake_case 函数名", "vars": ["前三个变量名"],
  "role": "一句话职责判断", "confidence": "high/medium/low"}}
命名风格：动宾结构、小写加下划线、避免臆测协议名。
线索：
- 调用的外部函数：{calls}
- 引用的字符串：{strings}
- 被哪些函数调用：{callers}
伪代码：
{pseudocode}"""
​

三类线索的判别力各有擅长：

confidence 字段留给下游分级处理：high 自动入候选、medium 人工过目、low 只留档不落库——第 10 章会看到同样的分级思想用在漏洞置信度上。批量执行时按函数出度排序：被引用最多的函数先命名（一个热点函数的名字能让十处伪代码同时可读），这是命名工程的「性价比排序」。

批量执行的骨架（按出度排序喂线索、按置信度分流）：

# batch_naming.py —— 批量命名建议的调度骨架
def order_by_outdegree(cpg_calls: dict) -> list:
    """cpg_calls: 函数名到其调用列表的映射；出度大者优先"""
    return sorted(cpg_calls, key=lambda f: len(cpg_calls[f]), reverse=True)

def route(suggestion: dict) -> str:
    """按置信度分流：high 进候选队列，medium 进人工队列，low 留档"""
    level = suggestion.get("confidence", "low")
    return {"high": "candidate", "medium": "human_review", "low": "archive"}[level]
​

骨架刻意保持单薄：提示词在 name_suggest.py，路由在这里，验证在第 08 章闭环——三件事分三个文件，任何一处出问题都能独立替换，这是第 11.3 节 SOP 喜欢的模块边界。

三、binsync：git 底座的跨反编译器协作

命名建议再多，落在单机反编译器的会话里就是一次性消费品。binsync 解决沉淀问题：它以 git 仓库为底座存储重命名等同步信息，Ghidra、IDA、Binary Ninja 三家都有插件端。工作流：

# binsync_flow.sh —— binsync 协作流（命令与菜单以官方文档为准）
pip install binsync
# 初始化共享仓库（任意 git 服务均可，内网 git 更符合敏感样本纪律）
git init team-sync.git
# Ghidra 端：安装 binsync 插件 → 连接 team-sync.git → 拉取他人命名
# 提交：把 FUN_00401190 重命名为 check_license 后 Push Changes
# 队友的 IDA 端 Pull 后同名函数自动改名；命名错了？git revert 即回滚
​

三个特性让它成为人机协作的合格底座：跨工具（团队各用各的反编译器，名字互通）；可审计（谁在何时改了哪个名字，git 历史全记录——第 11.1 节证据链的理想补充材料）；可回滚（AI 批量建议翻车时，revert 一次即恢复）。社区热度约 0.75k stars（2026-10 社区口径），属于小而稳的基础设施。

四、命名纪律：假设、验证、转正

AI 给的名字再像样也是猜。纪律三步：

• 假设：LLM 建议 check_license，confidence 为 high——此刻它只是候选。
• 验证：第 08 章闭环跑一遍——构造输入让该函数走到成功分支，或调试器断点确认其读入与比较行为（8.3 三动作）；伪代码侧可再让模型解释命名依据。
• 转正：验证通过，人在反编译器里确认改名，binsync 提交——从这一刻起它才是事实。

# naming_discipline.txt —— 转正流程与拒绝分支

LLM 建议（候选名）──行为验证──▶ 人工确认 ──binsync 提交──▶ 团队事实
        │                        │
        └── low 置信或验证失败 ──┴──▶ 留档不转正，避免污染上下文
​

一段完整的转正会话示例（对象为 8.1 节自编 crackme 的 check 函数）：模型依据线索（调用 scanf 的 caller、字符串 Access granted、被 main 调用）建议 check_license，confidence 为 medium；验证侧用 8.3 节批处理脚本断点确认该函数读入 buf、逐字节与常量比较、返回值决定输出串——三动作全过；人工确认改名为 check_password（比模型的 license 更贴行为），binsync 提交并附验证输出哈希。注意最后一步：人把名字从 check_license 改成 check_password——模型建议是输入，人的裁决是输出，这就是「人机协作」而非「人机代工」。

反面案例值得记住：一个未经证实的错误名字比 FUN_ 更危险——地址至少是中立的，错误名字会主动误导后来者与模型的推理。宁可慢一点，不可带病转正。

命名风格的三条铁律（写进团队规范，省掉评审时的反复拉扯）：

• 见行为不见猜测：名字描述函数做了什么（check_password），不猜它属于什么协议或产品（ssl_verify 除非真的验证了 SSL）。
• 长度换信息：宁可 parse_license_header 也不要 parse2；后缀数字是外号表的复活。
• 保留证据：转正提交的说明里写清验证依据（哪次会话、哪条链），让半年后的你还能复核。

五、命名的复利

命名的收益是复利式的：

• 名字即检索键：恢复命名的二进制配合《语义代码检索》的方法建索引后，能按「函数名加字符串」直接检索定位，而不是肉眼扫地址。
• 名字即模型上下文：第 8.2 节闭环里，带正确名字的伪代码让假设质量显著上升——同一模型、同一伪代码，只因名字从 FUN_00401190 变成 check_password，输出可靠性立刻不同。
• 名字即团队记忆：新人接手项目，第一小时就能读懂调用链，而不是重建你三个月前建过的外号表。
• 名字即智能体导航：第 10.3 节的仓库级挖掘里，命名质量直接决定智能体的导航效率。

把命名恢复写进 SOP（第 11.3 节）的理由正在于此——它是少数「做一次、天天受益」的逆向投资。

本节要点回顾

• 命名是逆向地基：影响检索、模型上下文、人工复核与智能体导航四个速度因子。
• 提示词三要点：喂三类线索、只要 JSON、约束命名风格；批量时按出度排序。
• binsync 以 git 为底座实现跨反编译器共享，可审计、可回滚。
• 纪律：AI 命名是假设，行为验证加人工确认后才转正；错误名字比地址更危险。
• 复利：名字改善检索与上下文，写进 SOP 是「做一次、天天受益」的投资。

读懂了代码、恢复了名字，接下来把镜头拉远：当 AI 不仅帮你读一个函数，而是对整个仓库发起漏洞挖掘时，方法论长什么样、成绩怎么衡量、成本如何控制——第 10 章进入 AI 漏洞挖掘方法论。