今天分享的论文是《D-LIFT: Improving LLM-based Decompiler Backend via Code Quality-driven Fine-tuning》原文链接[2506.10125] D-LiFT: Improving LLM-based Decompiler Backend via Code Quality-driven Fine-tuning这是一篇关于LLM应用二进制反汇编的论文主要是两个点一个是微调LLM提升反汇编代码质量另一方面提出了集成式代码质量评估系统从多维度对反汇编代码进行评分。作为众多安全任务中的关键工具之一反编译器能够从二进制文件中重构人类可读的源代码。然而尽管近年来取得了诸多进展其输出结果仍常常存在语法和语义错误且可读性较差。近年来随着大型语言模型LLMs的兴起研究人员开始探索利用LLM优化反编译器输出的潜力。但本文对这些现有方法的研究发现它们存在诸如引入新错误、依赖不可靠的准确性验证等问题。在本文中提出了D-LIFT——一种增强型反编译器-LLM流水线其核心是通过代码质量感知的强化学习对LLM进行微调。与以往忽视准确性保留的研究不同D-LIFT遵循一条提升反编译代码质量的关键原则在提高可读性的同时确保准确性不受损害。D-LIFT的核心组件是D-SCORE这是一种集成式代码质量评估系统能够从多个维度对反编译源代码进行评分并将其用于指导强化学习微调过程以及在推理阶段筛选最优输出。根据上述原则D-SCORE会给任何不准确的输出分配低分仅对通过准确性检查的代码才会根据其可读性给予更高分数。本文基于Ghidra反编译器和多种LLM实现了D-LIFT并在coreutils和util-linux项目的准确反编译代码上进行了评估。结果表明与未经过D-SCORE驱动微调的基准LLM相比本文训练后的LLM生成的反编译函数质量提升比例增加了55.3%。总体而言D-LIFT将原生反编译器生成的所有函数质量提升了68.2%。本文主要贡献如下- 设计了D-LIFT——一种增强型反编译器-LLM流水线通过代码质量感知的强化学习对LLM进行微调以提升反编译代码质量且遵循“在提高可读性的同时保留准确性”的核心原则。- 提出了D-SCORE——一种集成式评分机制用于定量评估反编译代码质量。该框架整合了现有分析工具和经过验证的度量指标能够从语法正确性、语义正确性和可读性等多个维度对反编译代码进行评估为LLM训练提供有效反馈并为推理阶段提供可靠的筛选依据。- 基于Ghidra和三种LLM实现了D-LIFT并在常用基准函数上实现了反编译代码质量的显著提升。III. 设计挑战第二节D部分的研究动机促使本文提出一种不牺牲准确性的“反编译器-LLM”流水线。本节将总结该流水线在设计层面面临的挑战。A. 框架设计由于本文的框架围绕LLM构建本文将挑战分为训练和推理两部分。1. 训练阶段通过训练提升LLM的代码质量并非新课题[32]、[55]、[56]、[46]、[15]但这些方法大多难以适配反编译代码优化任务。与通用代码优化任务不同反编译代码优化面临一个独特挑战存在多个有效真值。具体而言单个二进制文件可能由多个语义等价的源程序编译生成而每个源程序都应被视为有效真值。例如如下图所示两个不同的源文件各约300个字符编辑距离为74在x86 Linux平台上使用GCC[1]的-O2优化编译后生成了完全相同的二进制输出。但在实际研究中研究人员通常只能获取其中一个源文件变体作为真值。此外如第二节C部分所述许多微调方法如有监督微调SFT和强化学习中的演员-评论员范式仅接受单一参考来计算训练损失忽略了可能存在的完整正确备选方案集。这种约束可能降低模型效果例如LLM4Decompile仅基于单个源代码进行有监督微调就是典型例子。2. 推理阶段当存在来自反编译器本身或不同LLM的多个优化代码输出时需要一个客观定量的指标对其质量进行排序。遗憾的是现有唯一相关框架DeGPT并未提供自动化可读性度量指标而是依赖人类参与者的评估结果。B. 反编译代码质量评估如前所述训练阶段存在多个有效真值、推理阶段存在多个优化候选方案的现状要求本文必须设计一种定量的代码质量指标来评估每个候选方案。据本文所知目前没有任何现有指标能满足“在提升可读性的同时保持语法和语义准确性”这一双重要求。对于反编译器准确性评估如第二节D部分所述需要从语法和语义两个方面进行验证。由于反编译代码评估函数必须具有确定性因此排除了模糊测试[70]及其衍生方法如DeGPT的MSSC[11]。此外为确保语义直接与二进制文件而非原始源代码对比本文排除了依赖源代码相关检查的方法如单元测试或Alive2[39]。剩余可选的是D-helix[75]它通过迭代重编译器检测语法错误并通过符号执行验证代码与原始二进制文件的语义一致性。然而将D-helix直接集成到本文的框架中也存在挑战D-helix仍依赖反编译代码的某些输出产物如外部函数调用进行分析而LLM生成的代码常常遗漏指令导致这些产物缺失或不可靠进而影响D-helix的有效性。对于可读性评估大多数现有指标[10]、[42]、[48]、[52]忽略了反编译器特定产物如引用/解引用次数。据本文所知R2I[17]是唯一专门针对反编译代码设计的可读性度量指标但如第二节B部分所述它是一种相对度量指标——其特征是为对比不同反编译器而设计的无法为单个LLM生成的代码分配绝对得分。例如“不必要的goto标签数量”这一特征需要通过对比angr[62]或RetDec[5]与Ghidra[3]、Hex-Rays[2]的输出来计算而当仅提供单个反编译代码时该特征无法计算。综上所述目前没有任何单一代码质量指标能满足本文“在提升可读性的同时保留准确性”的核心原则。IV. D-LIFT设计D-LIFT是一种自动反编译流水线由反编译器前端和能够提升反编译代码质量的LLM后端组成。如上图所示D-LIFT的工作流程分为训练阶段第4.1.1节和推理阶段第4.1.2节。具体而言训练阶段以基准模型待训练的LLM、一组训练二进制文件和反编译器为输入通过强化学习对LLM进行微调最终生成具备优化反编译能力的模型推理阶段首先使用反编译器为输入二进制文件生成初始反编译代码然后利用基准LLM和微调后LLM对代码进行优化并从所有输出中筛选出最优质量的结果。为指导训练和推理过程D-LIFT引入了多维度代码质量评估指标D-SCORE从准确性和可读性两个方面对候选代码进行评估第4.2节。具体而言D-SCORE采用分步评估方法先验证语法正确性第4.2.1节再验证代码与原始二进制文件的语义一致性第4.2.2节仅当候选代码通过这两项准确性检查后才会进行可读性评估第4.2.3节。A. 系统工作流程D-LIFT的工作原理如下首先通过组相对策略优化GRPO对LLM进行微调使其获得感知准确性的奖励机制然后在运行时基于D-SCORE得分从反编译器、基准LLM和微调后LLM的输出中为每个输入二进制文件选择最优质量的反编译代码。1. 训练阶段第三节A部分描述的挑战凸显了现有方法的关键局限——反编译代码可能对应多个语义等价的源代码表示每个表示都是有效真值。这种多真值特性给有监督微调如LLM4Decompile等仅适用于单一正确答案的方法带来了巨大训练困难。尽管强化学习在训练过程中会生成多个候选方案理论上可覆盖多种有效解但传统强化学习策略在计算损失时仍受限于单一真值约束。幸运的是组相对策略优化GRPO[54]通过对多个候选输出的奖励进行归一化来计算损失突破了这一约束。2. 推理阶段如第二节D部分所述LLM在优化代码时常常引入错误因此需要一个基于定量指标的筛选系统。为此本文设计了如图3所示的筛选系统其工作流程分为两步① 接收用户输入的二进制文件通过反编译器生成原始代码再将原始代码输入基准LLM和微调后LLM生成两个优化版本② 利用训练阶段使用的同一评分工具D-SCORE对原始反编译代码、基准LLM输出和微调后LLM输出这三类结果进行评估选择得分最高的作为最终结果返回给用户。B. D-SCORE设计下图展示了D-SCORE的整体流程。然而直接将D-helix应用于LLM生成的候选代码进行外部函数调用验证时会产生大量假阴性结果。这一局限源于D-helix的核心依赖——它需要基于反编译代码建立外部函数调用的真值基准。具体而言D-helix通过参数最低有效字节之和近似外部函数调用的返回值来建模但这一建模过程仅在反编译代码中检测到外部函数调用时才会初始化。由于LLM生成的代码常常遗漏指令包括函数调用D-helix可能无法正确初始化其函数调用建模流程进而导致假阴性结果。事实上准确恢复外部函数调用的原型是一个开放性问题[34]因为这类“真值”信息并未包含在二进制文件本身中。适用性结果D-SCORE成功完成了80.7%1573/1948函数的准确性检查即成功生成这些函数的符号模型并从SMT求解器中获得无错误结果。为了解局限性本文随机抽取了50个D-SCORE检查失败的函数进行人工分析无放回抽样。这些错误分为三类1底层工具错误例如angr中的漏洞或遇到无返回调用时函数边界识别错误43%2函数规模导致的超时34%3D-SCORE内部错误例如不支持浮点指令14%。精确率结果本文从1573个D-SCORE可分析的函数中随机抽取100个无放回抽样通过人工对比每个LLM生成输出与原始二进制文件的语义验证D-SCORE判定结果的正确性。分析发现1假阳性的产生是因为D-SCORE的内存模型会为符号化指针分配新的内存地址即使生成代码语义正确指针值也与原始二进制文件不同导致符号执行器报告虚假不匹配2假阴性的产生是因为本文假设所有外部函数调用都返回常量值当条件指令中使用该常量返回值时二进制文件的符号执行可能永远不会探索某一分支。不过用户可以修改假设的常量值通过多次运行D-SCORE可能覆盖大多数分支从而消除这些假阴性。如果LLM输出遗漏了这些未访问分支的代码D-SCORE无法检测到差异进而忽略错误。为更好地理解D-LIFT的训练过程对LLM性能的影响本文通过直接对比微调后模型的输出与基准模型的输出进行了额外分析。具体而言本文从两个维度分析训练对函数性能的改变一是“优化”微调后模型成功解决了基准模型输出中存在的问题二是“退化”原本无错误的基准模型函数在微调后出现了新问题。基于此本文将这些变化分为六类语法修复、语义修复、语法退化、语义退化、可读性优化、可读性退化。结果显示经过D-LIFT微调的LLM在准确性方面获得了显著提升而退化案例始终保持在可接受的低水平。为探究优化和退化的根本原因本文从每组优化组和退化组中随机选择50个函数进行人工代码审查。微调主要纠正了五类错误1缺失指令例如缺失goto标签、变量声明和赋值语句2条件表达式中的括号错误例如if语句缺少括号或括号位置错误导致指针解引用异常3变量命名和类型转换错误例如在仅定义__mode_t的情况下使用mode_t4多余指令插入例如重复的goto标签和不必要的函数调用5字面量值错误例如常量值与原始值不一致。然而微调也在三个方面引入了退化1缺失指令2条件表达式中的括号错误3多余指令插入。D-LIFT实现的更具代表性的优化示例见第6.4节。总结当原始反编译代码不存在语法或语义错误时D-LIFT在优化函数的数量和平均D-SCORE两方面均实现了显著提升。为探究LLM在OIA数据集上表现不佳的原因本文随机选取了50个函数进行人工分析——其中25个是被任意LLM包括基准LLM和微调后LLM成功优化的函数另外25个是未被任何LLM优化的函数。对于25个被LLM成功优化的函数本文意外发现了一个一致模式每个函数都包含声明为“undefined [16]”的变量一种16字节、符号性未知的类型。LLM通常会将这些带有模糊声明的变量转换为固定长度数组并相应更新成员访问方式。例如变量声明从“undefined [16] auVar1;”改为数组形式“ulong auVar1[2]”而该变量的前8字节赋值操作从“auVar1._0_8_ 0;”修改为“auVar1[0] 0;”。尽管这些转换有时会引入细微的语义偏差但它们能稳定消除语法错误从而获得更高的D-SCORE。对于25个未被LLM优化的函数本文发现主要存在三大原因1未解析的函数指针类型导致语法错误。13个案例中错误源于类似“(code *)puVar3[4]”这样未解析的函数指针类型2无法解决的类型模式导致语法错误。7个案例中问题出现在“CONCAT31((int3)XX)”这类结构中其中“int3”属于格式不规范的类型3未初始化的全局变量导致语义错误。5个案例中反编译代码未能将全局变量初始化为正确值。总结当原始反编译代码包含语法或语义错误时无论是基准LLM还是本文微调后的LLM都难以实现真正的优化。这一结果既凸显了反编译器前端的重要性也揭示了当前LLM在修正反编译器引入的错误方面存在局限性。VII. 讨论适用性如第6.3.2节所示当反编译器前端无法生成准确代码时D-LIFT的性能表现较差。此外由于D-LIFT依赖函数级别的反编译输出若反编译器无法处理该二进制文件D-LIFT也无法发挥作用。因此D-LIFT在解决反编译器内部问题时效果不佳例如导致反编译器崩溃的漏洞或长期存在的反编译难题如函数边界识别、类型恢复、间接调用等。需要指出的是反编译只是二进制逆向工程的一个方面其核心是为用户提供目标二进制文件更易读的源代码。逆向工程的其他方面更适合由专门的逆向工程工具支持例如用于类型恢复[35]、[12]、控制流图重构[7]和函数边界恢复[65]的工具这些工具与反编译功能相互补充。底层工具限制由于D-LIFT采用了D-helix它继承了D-helix的局限性包括不支持浮点指令、双指针受内存模型限制以及因超时而无法处理大型二进制文件。外部函数调用对于外部函数调用D-SCORE与D-helix的建模方式不同D-helix通过参数最低有效字节之和近似外部函数返回值而D-SCORE仅统计调用次数。这种简化在函数返回值影响控制流时可能存在问题。默认情况下本文将所有外部函数调用的返回值设为常量如0这可能导致某些分支无法被探索。然而准确判断外部调用是否会返回有意义的值本身就是一个开放性难题[34]。本文将更精确的外部函数调用建模留作未来工作。相关工作基于LLM的反编译代码增强已有多项研究提出了基于LLM的反编译代码增强方法。除LLM4Decompile[56]外研究人员还提出了DecGPT[64]其核心目标是提高反编译代码的可重编译性但该方法未处理LLM引入的语义错误如幻觉错误。据本文所知DeGPT[25]是唯一尝试验证LLM生成反编译代码准确性的现有工作。DeGPT引入了MSSC一种静态分析框架通过为输入分配随机值观察反编译代码与LLM生成代码中符号值的变化以检测差异并识别不准确之处。然而该方法存在明显缺陷例如MSSC不进行代码重编译无法检测语法错误同时使用随机输入进行测试会导致验证结果在不同运行中不一致。LLM微调生成高质量代码通过微调LLM生成更高质量的代码并非新课题。PPOcoder[55]将源代码与生成代码之间的结构差异通过数据流图DFG和抽象语法树AST度量作为奖励信号以提升LLM在多个代码生成任务中的性能。StepCoder、CodeRL和Palit[15]、[46]、[32]利用编译器和单元测试作为强化学习的反馈。然而上述所有方法均仅接受单一真值这使其不适用于反编译场景反编译中可能存在多个语义等价的有效真值。符号执行工具验证LLM生成代码的语义研究人员还探索了使用符号执行工具验证LLM生成代码的语义。Taneja[57]将Alive2[39]应用于LLM生成的向量化代码以验证其语义正确性。类似地Wang[63]将Alive2集成到编译器的翻译验证流水线中确保语义保真度。然而由于Alive2的设计初衷是检测编译器优化导致的漏洞如未定义行为它可能会遗漏反编译特有的错误。代码可读性度量基于BW框架后续研究提出了多种扩展方法。具体而言研究人员[23]、[52]、[48]、[42]、[58]将研究重点转向更广泛的“代码可理解性”概念——该概念在可读性基础上还将代码之外的元素如相关文档纳入评估范围。然而这些度量指标均假设存在注释和外部文档而反编译代码通常缺乏这些特征因此它们并不适合评估反编译输出。做个总结本文设计了D-LIFT——一种增强型反编译器-LLM流水线其核心是通过代码质量感知的强化学习对LLM进行微调以提升反编译代码质量并遵循“在提高可读性的同时保留准确性”的核心原则。本文提出了D-SCORE这是一种专为反编译恢复任务设计的集成式评分机制。本文基于Ghidra实现了D-LIFT并对三个LLM进行了微调最终在广泛使用的基准函数上实现了反编译代码质量的显著提升。与基准LLM相比本文微调后的LLM平均多优化了55.3%的函数质量。总体而言D-LIFT生成的函数质量比原生反编译器高出68.2%其中47.3%的函数优化来自D-SCORE驱动的微调模型仅20.9%来自基准模型。伦理考量本文注意到本文发现的漏洞不会对用户或开发者构成直接威胁因为它们主要影响LLM生成代码的准确性。本文声明仅将Chat-GPT[45]和Claude-AI[4]用作释义辅助工具以提升内容的清晰度和可读性在任何情况下本文均未允许它们生成新的内容、观点或论点。所有实质性工作和原创见解均为本文独立完成。