Page 23 - 《软件学报》2026年第6期
P. 23

2342                                                       软件学报  2026  年第  37  卷第  6  期


                  5   讨 论

                    本节讨论本文所提       BinDec 方法的局限性以及所开展实验方法的效度威胁.
                  5.1   局限性
                    本文提出的     BinDec 方法存在   3  个主要局限性, 分别涉及符号执行过程中的模型简化策略、对                   LLM  错误结
                 果的处理方式以及等价性检查策略.
                    首先, 在针对单个函数进行符号执行时, 为兼顾准确性与效率, 我们采用了                      3  种模型简化策略以支持代码等价
                 性检查. 其一, 我们仅对函数输入参数至返回值之间的传递关系进行建模, 而忽略函数执行过程中可能产生的副作
                 用. 然而, 真实应用场景中存在大量不符合该假定的函数, 例如无参数函数、无返回值函数以及功能主要依赖于副
                 作用的函数. 这一限制使本文方法仅能适用于同时具有输入参数和明确返回值的函数. 其二, 为实现独立针对单个
                 函数的符号执行, 我们对其中的外部调用进行了简化处理, 具体表现为将所有外部调用的功能定义为“返回所有输
                 入参数的最低字节之和”. 该策略虽有效避免了符号值传递过程的中断, 但在某些情况下可能导致多个不同外部调
                 用被误建模为相同逻辑, 从而引发符号执行中的路径合并错误. 其三, 我们在对函数参数进行符号化建模时, 限制
                 了对复杂类型参数的递归展开深度, 这种策略在处理深度不确定或递归定义的动态数据结构                              (例如, 长度可变的链
                 表) 时存在局限, 因为预设的深度限制可能无法覆盖所有可能的情况.
                    其次, 当前   BinDec 方法无法充分复用 LLM 生成的错误结果. 在            BinDec 的流程中, 若  LLM  生成的代码存在
                 编译错误, 框架会尝试要求        LLM  对其进行修复; 然而, 若生成的代码虽可编译但与预期语义不一致, 则当前做法会
                 直接丢弃该结果. 一种可行的改进思路是引导               LLM  基于语义不一致的代码进行局部修复, 而非完全重新生成. 但
                 由于难以根据符号执行的结果精确定位导致语义偏差的具体代码位置, 因此无法构建有效的提示词以指导 LLM
                 完成语义层面的修复.
                    最后, 在二进制代码提升阶段的等价性检查中, 我们当前依赖于基于符号执行生成的测试用例进行动态测试,
                 而未采用完全符号化的约束求解方法. 这主要是由于现阶段面向二进制代码的符号执行技术仍存在一定局限性.
                 现有成熟工具如      BINSEC [35] , 需先将二进制代码提升至其自定义中间表示           DBA  再进行符号执行, 本质上仍依赖于
                 中间表示转换. 而     BinSym [36] 虽支持直接在二进制层面进行符号执行, 但目前仅适用于               RISC-V  架构, 无法满足本
                 文构建架构无关反编译框架的目标. 因此, 我们采用符号执行生成高覆盖率测试用例作为现阶段可行性较高的验
                 证方案, 其可靠性高度依赖于测试用例对代码行为的覆盖程度. 尽管如此, 本方法仍具有一致性优势, 即两个阶段
                 的验证均基于同一符号执行引擎 KLEE 实现, 在工具层面保持了统一, 也避免了引入额外中间表示或架构相关工
                 具所带来的复杂性. 未来, 随着二进制符号执行技术的进一步发展, 采用统一的、完全符号化的端到端验证框架,
                 将有望进一步提升本方法的整体可靠性与形式化保证强度.
                    综上所述, 尽管实验结果表明将           LLM  与符号执行相结合能够有效提升二进制代码反编译能力, 当前方法在
                 LLM  与符号执行引擎之间的交互机制仍较为薄弱, 导致其在场景适应性与能效比方面存在明显局限. 未来的研究
                 工作需探索更有效的协同策略, 以加强            LLM  与符号执行技术之间的互补与融合, 从而充分发挥二者各自的优势.
                  5.2   实验效度威胁
                    本节讨论本文实验方法可能面临的效度威胁. 效度威胁是指实验过程中可能对结论有效性产生不利影响的因
                 素, 主要包括构建效度和外部效度两方面.
                    构建效度关注于度量指标是否能够有效反映所研究的核心概念. 在本研究中, 具体指所采用的准确性和可读
                 性评估指标是否能够准确衡量反编译代码的质量. 对于准确性, 当前的评估流程要求代码必须先成功编译才能进
                 行后续的可执行性验证和单元测试. 这意味着, 一个语义上几乎完全正确但无法通过编译的反编译结果                                 (例如, 细
                 微的语法错误或不符合特定编译器规范) 将在所有功能维度上得分为                       0. 这种“一票否决”机制可能导致评估体系
                 过于严格, 尤其可能会对       Ghidra 这类代码格式并非完美无缺的工具产生不公平的低估. 尽管存在此威胁, 但我们
                 认为将可编译性作为基础要求符合工程实践. 不过需要说明的是, 这一设计意味着我们的功能评估主要反映代码
   18   19   20   21   22   23   24   25   26   27   28