AFLplusplus中afl-clang-fast处理Bitcode转ELF的问题分析

背景介绍

AFLplusplus作为著名的模糊测试工具，其afl-clang-fast编译器前端在将LLVM bitcode转换为可执行ELF文件时可能出现问题。本文将深入分析这一现象的技术原因，并探讨正确的使用方法。

问题现象

当用户尝试使用afl-clang-fast将bitcode转换为ELF可执行文件时，会遇到两种不同类型的错误：

1. 在较新版本LLVM(如17)中：会出现断言失败错误，提示sancov.module_ctor_trace_pc_guard相关断言不满足，导致编译器崩溃。

2. 在较旧版本LLVM(如10)中：会出现链接器错误，提示sancov_guards相关符号未定义，包括__start___sancov_guards和__stop___sancov_guards等。

根本原因分析

经过深入分析，发现问题的核心在于重复插桩：

1. 当用户首先使用afl-clang-fast -c -emit-llvm生成bitcode时，AFL已经完成了第一次插桩，在bitcode中植入了SanitizerCoverage相关的代码和符号。

2. 随后当用户再次使用afl-clang-fast链接bitcode时，编译器会尝试进行第二次插桩，这导致了符号冲突和重复定义问题。

3. 在LLVM 10中表现为链接器找不到符号，而在LLVM 17中则直接触发了内部断言失败。

正确使用方法

正确的做法应该是：

1. 使用常规clang而非afl-clang-fast来链接已插桩的bitcode：

   clang -o test_elf test.bc /path/to/afl-compiler-rt.o
   

2. 这样避免了重复插桩，同时通过显式链接AFL的运行时库(afl-compiler-rt.o)来提供必要的运行时支持。

版本兼容性说明

值得注意的是，不同LLVM版本间的插桩机制存在差异：

1. LLVM 10使用较旧的trace-pc-guard插桩方式，会产生sancov_guards相关符号。

2. LLVM 17使用更现代的PCGUARD插桩方式，内部实现更为复杂。

3. 不同版本生成的插桩代码互不兼容，不应混用。

技术建议

对于需要在bitcode层面进行操作的用户，建议：

1. 明确区分插桩阶段和链接阶段，避免重复插桩。

2. 保持工具链版本一致性，特别是LLVM版本与AFL++版本的匹配。

3. 对于复杂的bitcode处理流程，考虑使用-fno-sanitize=all等选项临时禁用插桩。

4. 在调试时，可以使用nm等工具检查目标文件中的符号，帮助诊断问题。

总结

AFL++的插桩机制是其高效模糊测试的核心，理解其工作原理对于解决类似问题至关重要。通过正确区分插桩和链接阶段，并选择合适的工具链组合，可以避免这类bitcode转换问题，充分发挥AFL++的强大功能。