LLM4Decompile：使用 LLM 对二进制代码进行反编译

模型性能与训练

• 据称较小的 6B 模型优于 33B 模型；评论者将此归因于大模型训练不足，以及对数据质量、学习率调度等因素的敏感性。
• 该反编译模型是在 DeepSeek-Coder 的基础上微调得到的；考虑到只有约 4B tokens，而通用 LLM 往往需要万亿级 tokens，从零开始训练被认为不可行。
• 讨论中提到的大致硬件需求：1B 参数约需 2GB VRAM，7B 约需 14GB，33B 约需 80GB。

与 GPT‑4 和其他 LLM 的比较

• 尽管没有针对任务的专门训练，GPT‑4 在反编译上表现出人意料地好。
• 它比专用模型更常生成语法上有效（可重新编译）的 C，但在语义正确性（可重新执行）方面更差。
• 也有人报告用 GPT‑4/3.5 对 JavaScript 进行去混淆和美化代码，取得了部分但并不完全的成功。

与传统反编译器和逆向工程的关系

• 有几位评论者指出，现代原生代码反编译器（IDA、Ghidra、Binja、rev.ng 等）是很强的基线，应该纳入基准测试，并使用此前的指标，如 goto、圈复杂度和图编辑距离。
• 一些实践者认为，复杂二进制，尤其是手写汇编或高度优化代码的反编译，可能无法完全自动化；工具主要是在放大专家的工作效率。
• 也有人指出，编译器多样性、非确定性，以及二进制与源代码之间不存在双射，都是硬限制；精确的往返转换往往是不可能的。

评估、正确性与“幻觉”

• 该项目目前衡量：
  • 可重新编译性：生成的 C 能否通过编译？
  • 可重新执行性：重新编译后的二进制能否通过测试用例？
• 即使可重新编译性高得多，可重新执行率也很低（约 10–15%），凸显了语义上的差距。
• 关于往返转换或生成完全相同的二进制是否是现实可行的指标，存在争论；许多人强调，测试质量和模糊测试是更实用的检查方式。
• 有人提出形式化验证：LLM 输出代码及其证明，由非 LLM 验证器检查等价性。也有人质疑其可行性以及不可判定性的限制。

用例、范围与未来方向

• 建议用途包括：辅助逆向工程、安全分析、恶意软件和混淆 JavaScript 分析、工具链检测、提升到中间表示（例如 RzIL），以及作者归因实验。
• 许多人认为，LLM 更适合作为叠加在现有反汇编器/IR 之上的“副驾驶”，而不是独立的反编译器。
• 从开源 C（以及可能的合成代码）生成数据集，被视为这一研究方向的关键优势。