人工智能大模型逆向工程微调代码模型【免费下载链接】LLM4DecompileReverse Engineering: Decompiling Binary Code with Large Language Models项目地址https://gitcode.com/GitHub_Trending/ll/LLM4Decompile点击查看免费下载LLM4Decompile 是面向“用大语言模型将二进制代码反编译为可读 C 源码”的开源项目evaluation/README.md 集中说明了其官方评估流程推荐用 vLLM 批量生成反编译结果再通过“编译 运行 断言”的方式统计可再执行率Re-executability。本文以该文档为主干结合evaluation/目录下的三个评测脚本与scripts/目录的启动脚本逐项讲解测试集的选择、vLLM 评估命令的每个参数、评测的底层执行逻辑以及单 GPU 与 TGI 两套历史方案的用法帮助读者独立完成对任意 LLM4Decompile 系模型的客观评测。评测体系概览从“能反编译”到“可再执行”LLM4Decompile 将反编译质量量化为一个非常务实的指标可再执行率Re-executability。它的定义不是字符串层面的相似度而是“反编译出来的 C 代码能否被 gcc 重新编译、并作为可执行文件运行且通过全部预设断言”。这一指标贯穿了主仓库 README 中列出的所有模型对比数据1.3B22B 各版本均以 Re-executability 百分比呈现。在评测物料上项目按模型版本区分了两份测试集详见 legacy-test 目录V2 模型LLM4Decompile-Ref 系列应使用decompile-eval-executable-gcc-ghidra.json。该测试集的input_asm_prompt是由 Ghidra 反编译出的伪代码pseudo-code例如下面这种带DAT_001020d0、param_1等典型 Ghidra 风格的中间表示undefined8 func0(float param_1,long param_2,int param_3) { int local_10; int local_c; local_10 0; do { local_c local_10; if (param_3 local_10) { return 0; } while (local_c local_c 1, local_c param_3) { if ((float)(DAT_001020d0 (uint)(*(float *)(param_2 (long)local_10 * 4) - *(float *)(param_2 (long)local_c * 4))) param_1) { return 1; } } local_10 local_10 1; } while( true ); }V1.5 模型LLM4Decompile-End 系列应使用decompile-eval-executable-gcc-obj.json。该测试集的input_asm_prompt是由 objdump 反汇编得到的 x86-64 汇编指令每条指令带有地址与二进制编码例如func0: endbr64 push %rbp mov %rsp,%rbp mov %rdi,-0x18(%rbp) ...两份测试集都是 JSON 列表格式每条样本包含五个字段task_id问题编号、type优化级别取值 O0/O1/O2/O3、c_funcHumanEval 问题的 C 参考实现、c_testC 断言测试、input_asm_prompt带提示词的汇编/伪代码输入。每个问题对应 4 个优化级别条目因此官方所称的“164 个函数”在评测数据中体现为 164×4 条样本。推荐方案基于 vLLM 的评估脚本官方 README 明确标注 vLLM 方案为Recommended推荐原因是 vLLM 提供连续批处理continuous batching与张量并行能在多 GPU 上以较高吞吐完成整批反编译生成。相关说明与更新记录见 evaluation/README.md脚本主体为 evaluation/run_evaluation_llm4decompile_vllm.py。安装依赖pip install -r requirements.txt仓库根目录的 requirements.txt 中vLLM 相关关键依赖包括vllm0.4.0、numpy1.23.3同时评估脚本运行时还需要tqdm、loguru、transformers、multiprocessing等标准组件。若希望进一步加速接口侧的前缀计算可额外安装 flash-attention 后端pip install flash-attn运行命令与参数逐项解析在运行前必须把--model_path改为本地模型路径vLLM 从本地目录加载模型权重。官方给出的完整命令如下cd evaluation # Before running the evaluation script, please update the model_path to your local model path. python run_evaluation_llm4decompile_vllm.py \ --model_path LLM4Binary/llm4decompile-6.7b-v1.5 \ --testset_path ../decompile-eval/decompile-eval-executable-gcc-obj.json \ --gpus 8 \ --max_total_tokens 8192 \ --max_new_tokens 512 \ --repeat 1 \ --num_workers 16 \ --gpu_memory_utilization 0.82 \ --temperature 0对照 run_evaluation_llm4decompile_vllm.py 中的parse_args()各参数的默认值与作用如下参数默认值作用说明--model_path必填无默认本地模型权重目录脚本启动时会校验model_path.exists()且必须是目录否则直接报Invalid model并返回 -1见 脚本 L174-L178--testset_path必填无默认测试集 JSON 路径脚本用json.load加载并统计用例数--gpus8张量并行度tensor_parallel_size即用多少张 GPU 分摊一个模型--max_num_seqs8批处理中的最大序列数源码中该参数被注释掉实际未传入 vLLM--gpu_memory_utilization0.82vLLM 可占用的单卡显存比例显存紧张时应调低--temperature0采样温度评测默认取 0贪心解码保证结果可复现--max_total_tokens8192vLLM 的max_model_len即输入输出总长度上限对应 v1.5 系列 4096 最大训练长度时留有余量--max_new_tokens512每个样本最多生成的新 token 数--repeat1整批生成重复轮数1时最终按多轮结果取平均用于评估稳定性--output_pathNone若指定把testset[output]写入生成的解码结果后 dump 到该 JSON 文件--num_workers16评测阶段multiprocessing.Pool的进程数控制 gcc 编译/运行检查的并发度底层执行链路vLLM 脚本是如何工作的从源码结构看run_evaluation_llm4decompile_vllm.py 的run_eval_pipeline()依次完成四件事校验模型与加载测试集确认模型目录合法后读取 JSON并用AutoTokenizer.from_pretrained(model_path)加载分词器stop_sequences [tokenizer.eos_token]作为生成停止符。构造提示词脚本内部维护一个提示词前缀字典对每条样本按其typeO0O3拼接# This is the assembly code:\n 样本中的input_asm_prompt\n# What is the source code?\n构成送入模型的标准输入格式。vLLM 批量生成以LLM(modelargs.model_path, tensor_parallel_sizeargs.gpus, max_model_lenargs.max_total_tokens, gpu_memory_utilizationargs.gpu_memory_utilization)初始化引擎用SamplingParams(temperature..., max_tokens..., stopstop_sequences)控制生成repeat轮循环内把每轮输出整理为[[output.outputs[0].text] ...]收集到gen_results_repeat。统计可再执行率调用decompile_pass_rate()用multiprocessing.Pool(args.num_workers)并行对每条反编译结果做编译运行检查详见下一节。指标计算的真正机制编译检查与运行检查这是整个评估体系最核心的部分两个脚本的实现逻辑一致。evaluate_func()见 vllm 脚本 L36-L106对每条样本做如下处理抽取头文件遍历c_func与c_test中所有包含#include的行集中到c_include并从函数体与测试体中移除避免声明与定义重复。拼接两种产物c_combine c_include 反编译代码 c_test用于编译成可执行文件c_onlyfunc c_include 反编译代码用于生成汇编、验证语法。编译检查flag_compile先执行gcc -S onlyfunc.c -o onlyfunc -lm验证反编译代码能否单独通过编译再执行gcc combine.c -o combine -lm生成可执行文件两次编译各有 10 秒超时任何一次失败即返回(0, 0)。运行检查flag_run以 10 秒超时执行生成的combine可执行文件捕获输出并要求checkTrue即退出码为 0 才视为通过若可执行文件因断言失败assert不通过或崩溃而返回非零退出码则flag_run 0。随后decompile_pass_rate()按优化级别type分别累计compile、run与total最终输出类似下面的结果其中Run Rate 即可再执行率Optimization O0: Compile Rate: 0.xxxx, Run Rate: 0.xxxx Optimization O1: Compile Rate: 0.xxxx, Run Rate: 0.xxxx Optimization O2: Compile Rate: 0.xxxx, Run Rate: 0.xxxx Optimization O3: Compile Rate: 0.xxxx, Run Rate: 0.xxxx值得注意的是repeat 1时脚本会先按轮次分别统计再对多轮结果取平均源码中all_stats累加后除以len(gen_results_repeat)因此它衡量的是“生成代码能够重新编译并跑通断言”的端到端能力与 README 中强调的测试断言式验证re-executability完全对应。测试集字段c_func、c_test、input_asm_prompt的格式定义也可在 README.md 与 legacy-test 的样例数据中直接核对。历史方案一单 GPU、单进程评估脚本legacy对于单卡、单进程的快速验证场景官方保留了未随 vLLM 方案同步更新的旧脚本cd LLM4Decompile python ./evaluation/run_evaluation_llm4decompile_singleGPU.py该脚本run_evaluation_llm4decompile_singleGPU.py是理解整个指标机制的“最小实现”默认参数为--model_path LLM4Binary/llm4decompile-6.7b-v1.5、--data_path ../decompile-eval/decompile-eval-executable-gcc-obj.json也可通过命令行覆盖。直接以AutoModelForCausalLM.from_pretrained(..., torch_dtypetorch.bfloat16).cuda()加载模型用model.generate(**inputs, max_new_tokens512)逐条生成不设 temperature等价于贪心解码并将tokenizer.pad_token tokenizer.eos_token以对齐 padding。提示词构造为# This is the assembly code with {opt_state} optimization:\n 汇编 \n# What is the source code?\n其中opt_state取自样本的type字段。指标统计同样复用“gcc 编译 执行”二元判定最后把各优化级别的 compile rate 与 run rate 追加写入当前目录的results.txt格式为model:{...},opt:{...},compile rate:{...},run_rate:{...}。由于该脚本使用shellTrue方式调用 gcc、未设置编译超时运行超时为 5 秒且逐条串行生成官方明确标注为 “legacy, not updated”适合教学或单卡环境验证大批量评测仍建议使用 vLLM 方案。历史方案二基于 TGI 的多进程评估legacy官方 README 还记录了基于 Hugging Facetext-generation-inferenceTGI的评估方案说明其特点是“10x faster, support multiple GPUs and multi-process”相对单 GPU 串行而言但同样标注为 “legacy, not updated”git clone https://github.com/albertan017/LLM4Decompile.git cd LLM4Decompile pip install -r requirements.txt # Before running the evaluation script, please update the model_path to your local model path. bash ./scripts/run_evaluation_llm4decompile.sh其中 TGI 的安装需按官方项目指引单独完成。整个 TGI 链路由三部分组成scripts/run_evaluation_llm4decompile.sh入口脚本通过workspace$(pwd)定位仓库根目录再调用 Python 评估脚本并传入--model_path llm4decompile-1.3b --max_new_tokens 512 --testset_path $workspace/decompile-eval/decompile-eval.json --repeat 1 --dtype bfloat16 --port 8080 --max_input_len 8000 --max_total_tokens 8512 --max_batch_prefill_tokens 36000 --num_shards 4 --num_workers 8。注意该脚本中测试集路径指向decompile-eval/decompile-eval.json是较早版本的测试集命名若当前仓库使用需按实际情况替换为 legacy-test/decompile-eval-executable-gcc-obj.json 或 Ghidra 版本。evaluation/run_evaluation_llm4decompile.py评估主脚本。与 vLLM 版本几乎同构同样包含evaluate_func的编译/运行检查与decompile_pass_rate的统计差异仅在推理后端它通过 evaluation/server/text_generation.py 拉起 TGI 服务端并建立客户端。evaluation/server/text_generation.py封装TextGenerationServer与TextGenerationClient。服务端以text-generation-launcher拉起模型参数包括--model-id、--port、随机生成的--master-port、--num-shard、--dtype、--max-input-length、--max-total-tokens、--max-batch-prefill-tokens并轮询 127.0.0.1:8080 端口等待服务就绪客户端基于AsyncClient异步并发请求generate_code_results()以 50 个请求为一组task_size50做asyncio.gather并发收集num_outputs 1时开启采样do_sampleTrue默认 temperature 0.8、top_p 0.95否则贪心解码并在返回前剔除stop_sequences中的停止符。对应 run_evaluation_llm4decompile.py 的参数还包括--dtype默认 bfloat16、--port默认 8080、--max_input_len默认 8192、--max_total_tokens默认 8800、--max_batch_prefill_tokens默认 72000、--num_shards默认 4供调整服务端显存与吞吐。测试集格式与样例解读两份核心测试集均为 4594 行规模的 JSON 数组每 4 条样本O0O3对应同一个 HumanEval 函数。以decompile-eval-executable-gcc-obj.json的task_id: 0判断数组中是否存在任意一对元素之差小于阈值的func0为例c_func给出参考 C 实现含#include stdio.h、stdlib.h、math.hc_test给出main()内的多组assert断言如assert(func0(a, 6, 0.3) 1)等评估时将其拼接到反编译代码之后input_asm_prompt为objdump -d输出的func0:函数体汇编包含endbr64、push %rbp、mov %rdi,-0x18(%rbp)等指令以及被 README 预处理脚本清洗掉的地址/二进制列。Ghidra 版本decompile-eval-executable-gcc-ghidra.json对应样本则直接给出 Ghidra 反编译伪代码作为模型输入。因此选错测试集例如用 V2 模型评测 obj 测试集会因输入分布不匹配而无法反映模型真实能力务必遵循 README 的版本对应关系。评估前置条件与环境要求评测输入是 x86-64 Linux 上的 GCC 产物evaluate_func依赖本机gcc含-S与-lm链接数学库以及能够执行编译产物因此评估环境应为 Linux 并安装 gcc 工具链这一点从两个评估脚本对subprocess调用 gcc 的硬编码可直接印证。vLLM 方案要求 GPU 环境满足显存与 CUDA 要求--gpu_memory_utilization需按实际显存调低避免 OOM--gpus张量并行度应不超过可用 GPU 数量。测试集路径请以当前仓库实际位置为准仓库中评测数据位于 legacy-test 目录README 中引用的../decompile-eval/...路径对应其历史布局运行 vLLM 命令时需将--testset_path指向实际文件例如../legacy-test/decompile-eval-executable-gcc-obj.json。模型路径必须为本地目录vLLM 方案中model_path.exists() and model_path.is_dir()校验不通过会直接终止运行前请把LLM4Binary/llm4decompile-6.7b-v1.5等占位符替换为已下载的 Hugging Face 模型本地路径。小结三条评估路径如何选择方案推荐度并发/吞吐适用场景vLLMrun_evaluation_llm4decompile_vllm.py官方推荐张量并行 连续批处理 num_workers进程池多卡环境下的正式评测、复现模型对比TGIrun_evaluation_llm4decompile.py scripts/run_evaluation_llm4decompile.shlegacy异步并发 num_shards多分片已部署 TGI 或需要自定义推理服务的场景单 GPUrun_evaluation_llm4decompile_singleGPU.pylegacy单进程串行教学、快速验证、单卡小规模实验无论选择哪条路径其核心判定逻辑完全一致把反编译代码与c_test断言拼接gcc 编译、运行、断言全通过才算“可再执行”。理解这一点后即使更换测试集或模型也能准确解释评估脚本输出的 Compile Rate 与 Run Rate并据此判断模型的真实反编译质量。赞分享人工智能大模型逆向工程微调代码模型【免费下载链接】LLM4DecompileReverse Engineering: Decompiling Binary Code with Large Language Models项目地址https://gitcode.com/GitHub_Trending/ll/LLM4Decompile点击查看免费下载相关推荐LLM4Decompile终极微调指南从零构建63.6%可执行率的反编译模型LLM4Decompile终极微调指南从零构建63.6%可执行率的反编译模型 LLM4Decompile是一款面向软件逆向工程领域的革命性工具它利用大型语言人工智能大模型逆向工程微调代码模型dex2jar与反编译质量评估代码还原度指标dex2jar与反编译质量评估代码还原度指标 引言反编译质量评估的重要性 在Android应用开发与逆向工程领域.dex文件与Java字节码之间的转换是一逆向工程开发工具Recommenders模型评估指南10种评估指标全面解析与应用Recommenders模型评估指南10种评估指标全面解析与应用 Recommenders是一款专注于推荐系统最佳实践的开源项目提供了全面的模型评估工具帮人工智能机器学习深度学习上一篇Civitai Prompt-Analysis 指南全量回滚状态追踪基于测量驱动的每生态提示增强 Guide 部署记录Rollout Status下一篇OpenMed 2.1 到 2.2 迁移指南API 兼容边界、PHI 安全诊断与本地优先新运行时创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考