SK²Decompile 在 BringUpBench O1 优化级别上的反编译评估：379 个函数从编译到可执行的全链路结果解读

人工智能大模型逆向工程微调代码模型【免费下载链接】LLM4DecompileReverse Engineering: Decompiling Binary Code with Large Language Models项目地址https://gitcode.com/GitHub_Trending/ll/LLM4Decompile点击查看免费下载导读本文以 SK²Decompile 项目在 BringUpBench 基准上的O1 优化级别评估报告sk2decompile/evaluation/bringupbench/reports/O1_results.md为核心完整解读该次评估的实验设置、379 个函数的统计结果、逐基准细分数据以及失败案例分析并结合仓库中的评估脚本eval_infer_out.py与数据文件说明这些数字是如何一步步计算出来的。读完本文你将理解 SK²Decompile 的两阶段反编译输出在 替换→编译→执行 三级验证下的真实表现掌握 O1 报告的数据结构与评估脚本的复现方法。实验背景O1 报告在 SK²Decompile 评估体系中的位置SK²Decompile 将反编译拆分为两阶段第一阶段Phase 1Structure Recovery从汇编恢复代码骨架输出infer-out-model1第二阶段Phase 2Identifier Naming为骨架中的占位符命名输出最终函数体infer-out-model2。BringUpBench 评估正是对第二阶段的最终产物做端到端验证。O1 报告标题 Infer-Out Model 2 Evaluation 指的就是对infer-out-model2字段的评估。本仓库在 sk2decompile/evaluation/bringupbench/README.md 中说明BringUpBenchAustin, 2024是包含90 个自包含 C 程序的基准套件零外部库依赖仅依赖内置libmin库和 4 个系统调用非常适合在无缺失头文件/库干扰的真实二进制上做反编译评估。项目对全部程序在 O0–O3 四个优化级别下进行了编译、反编译与执行验证共得到 1488 个函数并与 IDA ProHex-Rays对比。O1 报告正是这一整体评估中优化级别为 O1 的那一份。从同一目录的 O0_results.md、O2_results.md、O3_results.md 可以看出每个优化级别对应一份独立报告。O1 级别共评估 379 个函数这是四个级别中评估数量最多的O0 为 382O2 为 368O3 为 359也是理解 SK²Decompile 中等优化强度下表现的关键样本。O1 评估报告逐项解读报告头部元数据O1 报告头部给出了这次评估的完整上下文信息字段值含义Timestamp20251119-171212报告生成时间戳格式为YYYYMMDD-HHMMSSSource JSONLmerged.O1.func_map.infer.jsonl评估输入数据文件位于 data/infer_results/Targethost编译目标平台即原生 x86-64 LinuxTotal cases379参与评估的函数总数Replacement success379 (100.00%)反编译函数体成功替换进原源码的比例Compilable155 (40.90%)替换后能通过make build编译的函数比例Executable148 (39.05%)编译通过且通过make test测试的函数比例其中三个核心指标的严格定义在 README.md 的 Evaluation Metrics 一节中给出Replacement Rate替换率反编译输出能被定位并替换进原始源文件的比例Compilable Rate可编译率替换后的源码能成功编译make build的比例Executable Rate可执行率编译后的程序通过其测试套件make test输出与参考一致的比例。O1 级别在三个指标上分别达到100% 替换率、40.90% 可编译率、39.05% 可执行率。值得注意的细节是所有 379 个函数都成功完成了源码替换说明 SK²Decompile 输出的函数体在文本层面都能被准确定位并替换回原文件而从编译到执行之间存在少量损耗155 → 148这 7 个函数编译通过但测试失败被记录在 Execution Failures 列表中。逐基准细分表Benchmark BreakdownO1 报告的核心主体是覆盖全部基准程序的逐基准统计表每个基准行给出 4 列数据Cases该基准参与评估的函数数、Replacement%替换率、Build%可编译率、Exec%可执行率。这张表包含 90 余个基准程序覆盖了从经典算法bubble-sort、heapsort、n-queens、knapsack到密码学aes、blake2b、rsa-cipher、cipher、信号处理fft-int、idct-alg、图算法graph-tests、topo-sort、shortest-path、数值计算k-means、lu-decomp、grad-descent、压缩lz-compress、huff-encode、rle-compress等广泛领域。从这张表中可以观察到几个有代表性的数据点全绿基准bubble-sort3 例、lz-compress2 例、nr-solver1 例三个基准的 Build% 与 Exec% 均为 100.00%说明这些函数体被反编译后可以直接编译并正确运行高表现基准huff-encode13 例92.31%、checkers16 例81.25%、bit-kernels5 例80.00%、priority-queue5 例80.00%、qsort-test5 例80.00%、rho-factor4 例75.00%、convex-hull4 例75.00%等零分基准audio-codec、banner、boyer-moore-search、ccmac、congrad、distinctness、gcd-list、grad-descent、heat-calc、mandelbrot、matmult、max-subseq、mersenne、monte-carlo、murmur-hash、natlog、nbody-sim、parrondo、pi-calc、quaternions、rabinkarp-search、rand-test、ransac、rle-compress、rsa-cipher、sieve、simple-grep、spelt2num、topo-sort、transcend、uniquify、verlet、weekday 等基准的 Build% 为 0.00%这些基准中的函数替换后均未能通过编译编译与执行不一致cipherBuild 33.33% / Exec 0.00%、idct-algBuild 66.67% / Exec 33.33%、lifeBuild 21.43% / Exec 14.29%、minspanBuild 37.50% / Exec 25.00%、regex-parserBuild 25.00% / Exec 12.50%、tetris-simBuild 75.00% / Exec 66.67%、vectors-3dBuild 12.50% / Exec 0.00%等基准存在编译通过但执行失败的情况这些正是报告末尾 Execution Failures 列表中的函数来源。按函数数量看评估规模较大的基准包括 graph-tests19 例、checkers16 例、avl-tree17 例、life14 例、anagram13 例、connect4-minimax13 例、huff-encode13 例、tetris-sim12 例、c-interp10 例、frac-calc10 例这些复杂程序为评估提供了足够的函数样本量。失败清单解读Compilation Failures 与 Execution Failures报告的第三、四部分分别是失败函数的完整清单每一条以路径/文件名.c::函数名地址格式标识例如aes/aes.c::aes_decrypt0x161b。Compilation Failures编译失败共 224 条涵盖 379 个函数中的大部分379 − 155 224。这些函数的反编译输出替换回源码后无法通过make build。从清单中可以观察到几类典型的反编译失败模式多文件基准中的辅助函数如 avl-tree 的 avlcore.c、element.ccheckers 的 functions.c这些函数与主函数位于不同源文件反编译时容易丢失类型信息涉及系统相关操作或特殊调用约定的函数如__readfsqword、__stack_chk_fail等栈保护相关调用在 aes 的多个函数中出现长函数与复杂控制流c-interp 的 eval0x35d3等解释器核心函数体量庞大反编译易出错小工具函数大量基准的辅助函数地址为 0x11e9如 banner/main0x11e9、ccmac/main0x11e9这是 IDA 为多个程序分配的第一个函数地址这些简单函数在 O1 优化后往往被内联或变换反编译结果难以直接编译。Execution Failures执行失败共 7 条即编译通过但测试未通过cipher/cipher.c::decipher0x1251 idct-alg/idct-alg.c::idct_2d0x1216 life/life.c::init0x11e9 minspan/minspan.c::displayTree0x16b7 regex-parser/regex-parser.c::matchpattern0x2491 tetris-sim/tetris-sim.c::clear_lines0x12b6 vectors-3d/vectors-3d.c::get_angle0x1429这 7 个函数编译成功但运行时行为与参考不一致可能的原因包括逻辑改写错误如循环条件、边界判断、位运算顺序被反编译器误改、符号语义偏差等。从数据上看执行失败仅占编译成功函数的约 4.5%7/155说明 SK²Decompile 第二阶段输出的函数体一旦能通过编译其语义正确率较高。报告数据从何而来评估脚本的完整调用链O1 报告不是手工整理的表格而是由 eval_infer_out.py 自动生成的。理解该脚本的调用链就能完全理解报告上每个数字的来源。数据输入merged.O1.func_map.infer.jsonl报告的输入是 data/infer_results/merged.O1.func_map.infer.jsonl共 379 行。每一行是一个 JSON 对象包含函数的源码source、IDA 伪代码pseudo、规范化伪代码pseudo_normalize、二进制路径binary、汇编assembly以及 SK²Decompile 两阶段输出infer-out-model1、infer-out-model2和修正后的最终函数体pseudo.content-fix。以报告数据文件中的 ackermann 的ack函数为例source.content是原始 C 源码带注释的递归 Ackermann 实现pseudo.content是 IDA Hex-Rays 输出的伪代码包含__fastcall调用约定、// eax寄存器注释等 IDA 特有信息pseudo_normalize是规范化后的伪代码去除了 IDA 类型十六进制转十进制clang-format 格式化infer-out-model1是第一阶段输出占位符命名 var1、var2、var3...infer-out-model2是第二阶段输出语义化命名 x、y、depth、table、maxdepth...pseudo.content-fix是用于源码替换的最终反编译函数体。这份文件的前 3 行示例恰好覆盖了 ackermann 和 aes 两个基准其中 ackermann/ackermann.c 的 main 函数在 O1 报告的 Compilation Failures 清单中ackermann/ackermann.c::main0x131c而 ack、aes 的多个函数也出现在失败清单中与报告中相应基准的低 Build% 相互印证。三级验证的核心逻辑替换 → 编译 → 执行从 eval_infer_out.py 的源码可以梳理出报告数据的完整产生流程其核心在process_case函数中第一级函数体替换决定 Replacement 指标replace_function_body函数eval_infer_out.py将原始源文件中与case[source][content]精确匹配的文本片段替换为case[pseudo][content-fix]。为了应对换行符差异它会尝试三种候选匹配方式原文、去尾部换行加\n、strip 后原文任一命中即视为替换成功。若在源文件中定位不到原始函数片段则replacement_appliedFalse该 case 被记入失败。O1 报告的 100% 替换率说明全部 379 个函数的content-fix都能被定位并替换。第二级隔离工作区编译决定 Build 指标每个 case 都在独立的工作区中执行prepare_workspace函数eval_infer_out.py将 BringUpBench 仓库的 Makefile、common 目录、target 目录以及该基准目录复制到临时工作区然后在工作区内执行make TARGEThost clean make TARGEThost buildrun_command函数eval_infer_out.py负责执行命令并记录日志支持超时控制。若make build返回 0 则build_statussucceeded否则为 failed并跳过测试阶段。报告中的 Build% 即为build_statussucceeded的 case 数除以总 case 数。第三级测试执行决定 Exec 指标编译成功后继续执行make TARGEThost test若make test返回 0 则test_statussucceeded否则为 failed。报告中的 Exec% 即为test_statussucceeded的 case 数除以总 case 数。O1 的 7 条 Execution Failures 就是那些 build 成功但 test 失败的 case。并行与日志细节脚本通过ThreadPoolExecutoreval_infer_out.py以--jobs参数默认 96并行处理各 case。每个 case 生成独立的输出目录与case.log日志保留modified_source.c、original_source.c、infer_function.c等工件write_case_artifactseval_infer_out.py。完成后由compute_summary与write_summary汇总生成 Markdown 与 JSON 双份报告O1 报告正是write_summary以merged.O1.func_map.infer-host为文件名、host为目标生成的产物。参数解析与配置优先级脚本支持通过命令行参数精细控制评估过程常用参数包括参数默认值作用--bench-root来自 config.envBringUpBench 仓库根路径--limit N无只处理前 N 个 case用于调试--targethost编译目标平台作为TARGET传给 make--report-dirreports/infer_out_eval汇总报告输出目录--workspace-rootreports/infer_out_eval/workspaces临时工作区目录--skip-clean关闭跳过make clean--keep-workspaces关闭保留临时工作区--command-timeout S20每条 make 命令超时秒数0 表示禁用--jobs N96并行处理的 case 数路径解析遵循 CLI 参数 环境变量 config.env 的优先级_get_bench_root函数eval_infer_out.pyconfig.env 中声明BENCH_REPO_ROOT、IDA_BIN、DEFAULT_TARGET三个键注释明确说明这一优先级。复现 O1 评估结果的操作指南O1 报告的评估数据data/infer_results/merged.O1.func_map.infer.jsonl已随仓库提供若只想复现评估环节Step 5只需 BringUpBench 源码仓库无需重新编译与反编译# 1. 克隆 BringUpBench 基准 git clone https://github.com/toddmaustin/bringup-bench.git # 2. 进入评估目录并配置路径 cd sk2decompile/evaluation/bringupbench # 编辑 config.env将 BENCH_REPO_ROOT 指向 bringup-bench 路径 # 3. 运行 O1 评估并指定 16 个并行任务、20 秒命令超时 python3 scripts/eval_infer_out.py data/infer_results/merged.O1.func_map.infer.jsonl \ --jobs 16 \ --command-timeout 20 # 4. 查看生成的报告 cat reports/O1_results.md若要复现报告中的 100% 替换率数字可注意脚本在替换时尝试三种候选片段匹配见replace_function_body这是实现高替换率的关键实现细节。若机器资源有限可先用--limit 5 --keep-workspaces调试少量 case 验证流程再放开到全量 379 个 case。如需从零开始复现完整流水线编译 → IDA 反编译 → 映射构建 → SK²Decompile 推理 → 评估可参考 bringupbench/README.md 中 Step 1–5 的完整说明build-host-opt-levels.sh编译 O0–O3 二进制decompile-all-pseudo.sh 调用 IDA 批量反编译每个函数以/* function_name 0xADDRESS */分隔由 dump_pseudo.py 实现disasm-all-objdump.sh与build-func-maps.py构建函数级映射推理阶段由 sk2decompile_inf.py 完成两阶段反编译结果写入pseudo.content-fix字段。O1 结果在整体评估中的定位与对比将 O1 报告与同目录下其余三份报告对照可以看到优化级别对反编译难度的影响优化级别函数数可编译率可执行率O038250.26%49.48%O137940.90%39.05%O236837.77%34.24%O335931.75%29.53%O0/O2/O3 数据分别来自 O0_results.md、O2_results.md、O3_results.md。可以清晰地看到一条下降曲线优化级别越高函数内联、寄存器重分配、控制流改写越激进反编译恢复的难度越大可编译率与可执行率随之降低。O1 处于 O0 与 O2 之间作为中等优化强度的代表其 39.05% 的可执行率更贴近真实世界中带优化的发布二进制场景。总结O1 报告完整呈现了 SK²Decompile 在 BringUpBench O1 优化级别上的端到端评估结果379 个函数全部成功完成源码替换100%155 个40.90%能重新编译148 个39.05%能通过测试执行。报告中的每个数字都可以在 eval_infer_out.py 的替换 → 编译 → 执行三级验证流程中找到对应实现失败清单则精确记录了哪些函数、哪个优化级别下的反编译尚未达到可编译/可执行标准为后续改进提供了清晰的函数级证据。结合四份优化级别报告的横向对比还可以量化优化强度对 LLM 反编译成功率的系统性影响。赞分享人工智能大模型逆向工程微调代码模型【免费下载链接】LLM4DecompileReverse Engineering: Decompiling Binary Code with Large Language Models项目地址https://gitcode.com/GitHub_Trending/ll/LLM4Decompile点击查看免费下载相关推荐SK²Decompile 在 BringUpBench O2 优化级别上的反编译评估报告解读368 个函数的替换、编译与可执行率全解析SK²Decompile 在 BringUpBench O2 优化级别上的反编译评估报告解读368 个函数的替换、编译与可执行率全解析 本篇技术指南围绕 SK人工智能大模型逆向工程微调代码模型SK²Decompile 在 BringUpBench 上的反编译评估从编译到函数级验证的完整复现指南SK²Decompile 在 BringUpBench 上的反编译评估从编译到函数级验证的完整复现指南 本文聚焦于 LLM4Decompile 项目中 SK²人工智能大模型逆向工程微调代码模型SK²Decompile 在 BringUpBench O0 基准上的评估报告解读382 个函数的替换—编译—执行全链路验证SK²Decompile 在 BringUpBench O0 基准上的评估报告解读382 个函数的替换—编译—执行全链路验证 本篇技术指南以仓库内生成的 O0人工智能大模型逆向工程微调代码模型上一篇动态提示新纪元Powerlevel10k的Transient Prompt全解析下一篇手机实时换脸只要 3 步Deep-Live-Cam 三端部署实操创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考