本文分析仅代表个人看法,如有错误请指教,好的项目值得深入,如果你也对 LLM + Fuzzer 感兴趣,CKGFuzzer 是个不错的研究项目。本文 Fuzz 针对库函数,实现细节分析的项目基于 CKGFuzzer ,该项目的论文即将要发表于 2025 年 ICSE 会议的论文 CKGFuzzer,它通过结合代码知识图谱,让大语言模型可以更加高效且准确地生成模糊驱动器。论文地址:CKGFuzzer: LLM-Based Fuzz Driver Generation Enhanced By Code Knowledge Graph项目地址:security-pride/CKGFuzzer: CKGFuzzer: LLM-Based Fuzz Driver Generation Enhanced By Code Knowledge Graph项目详细注释+Patch版本:Kernel/CKGFuzzer_mowen注释版 at master · mowenroot/Kernel作者二开版本:mowenroot/AiLibFuzzer: LLM + FuzzerCKGFuzzer 是一个将多智能体系统与代码知识图谱相结合的模糊驱动器生成框架,其目标是针对 API 组合生成高效的模糊驱动器,以提升模糊测试的质量和覆盖率。大致工作流:1、解析被测目标及其库 API,提取并嵌入代码知识图谱,包括解析抽象语法树,提取数据结构、函数签名、调用关系等关键信息。
2、查询代码知识图谱的 API 组合,关注那些具有调用关系的 API,生成相应的模糊驱动器。
3、编译生成的模糊驱动器,并且通过一个动态更新的库使用情况,修复出现的编译错误。
4、执行编译成功的模糊驱动器,监控库文件的代码覆盖率,对未能覆盖的新路径 API 组合进行变异,迭代该过程并持续进行。
5、使用链式推理分析在模糊测试过程中产生的崩溃,参考包含了真实 CWE 相关的源码示例,来验证这些崩溃的有效性。CKGFuzzer 好处显而易见,优点也很多,相比于现有的方法(如 PromptFuzz)通过不同的 API 变异组合利用 LLM 生成模糊驱动器,甚至手动编码,CKGFuzzer 能够基于代码知识图的 LLM 驱动的模糊驱动器代理,指导 LLM 为模糊驱动器生成更高质量的 API 组合和基于覆盖引导的变异。但是详细分析完也是存在一定缺点的:1、使用的一些库是相对老的、codeql 也是基于老版本,ql 采用老版本编写的。2、文件目录处理不清晰,代码和项目会混淆在一起,如果你不是很熟悉该项目,可能会被他的文件夹搞混。3、使用 LLM 时确实采用了记忆的功能,但是没有切片的处理,在实际测试中,利用 LLM 生成 API 描述信息的时候,要发送的信息量太大,会导致tokens 不足。4、项目存在一定的 BUG,在本文搜索 Patch 可以看到,其实也不能算是 BUG,只是在测试中,环境不一致导致的不兼容。5、多组 API 时,采用单进程进行 Fuzz,耗时会成倍的增加,这里是可以采用多线程处理的,即使 python 有 Gil 锁。也能大幅度提升效率。代码执行流程,官方提供了三步骤:1、repo从 Target 库中提取信息2、preproc构建外部知识库3、fuzzing运行模糊测试进程整体流体大致如下,这里做了简化实际执行没有这么简单,但是总体逻辑大致一样:分析也采用三步走,下面开始万字的详细分析底层实现,因为 CKGFuzzer 的核心就是 LLM 操作生成高质量的 target_fuzz 和 Fuzz 的覆盖率回调的 API 优化,所有会针对相关操作细致化分析,其他部分会粗略过。在 10 线程下整个流程大概花了 3小时40分钟文件位于添加codeql到环境变量中这里有个小bug,已经修复Patch原程序只有 ../ ,会导致定位不到外层的 docker_shared , 只会在fuzzing_llm_engine获取传入参数初始化该 RepositoryAgent 类,完成以下事情.「1」 维护该类中的字段,「2」 调用 check_create_folder() 检查输出目录是否存在,如果不存在则新建「3」 调用 self.init_repo() 使用提供的参数初始化存储库。「1」 init_repo() 会先检查codeqldb是否存在,以 .successfully_created 文件来判断,如果该文件存在则表示codeqldb存在。如果不存在调用 self._add_local_repo_to_database() 开始创建 database。「2」 如果当 src_folder 源码目录不存在时,会调用 self.copy_source_code_fromDocker() ,从docker中复制数据出来。「1」 使用 getpass.getuse() 获取当前用户名,用于后面更改docker 中的文件所有者,因为文件映射中docker权限为root。「2」 获取项目目录, 目录指向 fuzzing_llm_engine/projects/{project_name},该项目的目录下面包括 build.sh dockerfile project.yaml三个文件,用于构建环境使用。「3」 维护 image_name 、 build_command变量。 image_name 为 docker的img名称,一般为"项目name"+"_base_image",build_command 为 构建 docker 的命令。然后执行 build_command 开始构建 docker 镜像未检查 docker_img 是否存在,这里增加检测构建可以成功,但是可能会出现两个警告,警告原因因为,WORKDIR c-ares 未使用绝对目录,建议使用绝对目录。ENV OLD_LLVMPASS 1 的设置 应该为 ENV OLD_LLVMPASS=1
「4」 在 docker 中 创建 codql 数据库,通过以下命令拉起docker 并构建codeql数据库,这里执行语句带入了我本机的目录,方便理解。并在创建完 codeql database 后,在docker_shared/codeqldb/项目 目录下 创建 .successfully_created 文件来表示数据库创建成功。可能会因为 /usr/local/bin/compile: line 27: FUZZING_LANGUAGE: unbound variable 报错 ,需要加上 -e FUZZING_LANGUAGE={args.language}这里为了方便调试我使用 docker保活,然后进去看docker配置这个时候可能还有问题,提示没有codeql这个目录,这里我直接用脚本添加,当然也可以手动添加主要做了,-v 映射文件夹到docker,-e 指定了环境变量, -t 指定启动镜像, -c 执行了codeql 创建数据库语句。在使用codeql 创建数据库时,编译语句使用 /src/fuzzing_os/wrapper.sh c-ares。wrapper主要负责 定位到项目
...(已截断)
---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-287415.htm
[原创]国际前沿技术 AI+Fuzz 实现细节(CKGFuzzer)
283 浏览
1 回复
不懂ai,看的头疼。但是能感觉的到,是很重要的分享。感恩