实时焦点:WinAFL小白踩坑指南,你学会了吗?
本文主要内容包括:WinAFL介绍与安装、以ABC看图程序为例构建Fuzz最小案例库、执行Fuzz跑出Crash,以及最终利用Bugid对Crash分类
(资料图)
WinAFL介绍与安装WinAFL,是Ivan Fratric基于lcumtuf的AFL创建的大型Fuzzing程序,由于AFL无法在windows下直接使用,Winafl弥补了这一空白,使用DynamoRIO来插桩&测量代码覆盖率,并使用Windows API进行内存和进程创建。
WinAFL 项目地址:https://github.com/ivanfratric/winafl
请注意:Windows 10 1809及更高版本的最新Windows版本要使用DynamoRIO 8.0.0以上版本
此时如果直接进行操作可能会出现以下报错
需要re-compiled ,这个过程为:
(1) 下载安装DynamoRio源码,或者直接下载DynamoRio Windows版的二进制包(https://github.com/DynamoRIO/dynamorio/wiki/Downloads)
(2) 打开Visual Studio命令提示工具,如果要安装成64位版本的则打开Visual Studio x64命令提示工具(一般在【开始—所有程序—Visual Stdio—Visual Studio Tools】中可找到)。因为在对64位程序进行fuzz时,需要有64-bit的winafl.dll,所以安装时要选择好版本
(3)在命令提示工具中进入WinAFL的目录下
(4) 在Visual Studio命令提示工具中输入如下命令进行WinAFL编译安装(需将-DDynamoRIO_DIR参数设置为你的DynamoRIO cmake文件所在位置)
32-bit build:
mkdir build32cd build32cmake -G"Visual Studio 16 2019" -A Win32 .. -DDynamoRIO_DIR=..\path\to\DynamoRIO\cmake cmake --build . --config Release
64-bit build:
mkdir build64cd build64cmake -G"Visual Studio 16 2019" -A x64 .. -DDynamoRIO_DIR=..\path\to\DynamoRIO\cmakecmake --build . --config Release
这里需要注意一下-G选择平台时VS16与之前版本默认目标平台架构是有些区别的:
cmake -G "Visual Studio 16 2019" -A Win32 ;x32cmake -G "Visual Studio 16 2019" -A x64 ;x64 默认目标平台名称(架构)为Win64cmake -G "Visual Studio 15 2017" ;x32 默认目标平台名称(架构)为Win32cmake -G "Visual Studio 15 2017 Win64" ;x64
winafl 命令行参数,主要分为三段,(afl执行参数–dynamoRIO执行参数–程序执行参数)
afl执行参数主要包括-i -o指定输入和输出文件夹
-D指定DynamoRIO根目录
-t每一次样本执行的超时时限
-ffuzz 程序读取的位置
-M \ -S分布式模式
-x可选的fuzz字典
dynamRIO执行参数主要包括-coverage_module计算覆盖率的模块
-fuzz_iterations在重新启动目标进程之前,目标函数要运行的最大迭代次数。
-target_module包含目标函数的模块(一个可执行文件镜像)需要与该选项一起指定-target_method或-target_offset
-target_method目标函数,需要export或者带符号
-target_offset目标偏移,相对于target_module的偏移,在method无法导出的时候使用
-nargs程序执行所需要的参数个数
-debug调试模式。不要尝试连接到服务器。输出包含已加载模块,打开的文件和覆盖率信息的日志文件
-logdir指定将日志文件写入哪个目录(仅与-debug一起使用)
程序执行参数就是要fuzz的程序的命令行构建Fuzz最小案例库现在我们从网上搜集一堆ABC看图支持的格式,包括tif、jpg、png、ico等,github上有许多Fuzz的案例库,这样的案例库中包含大量的文件,运行起来效率会很差。根据学长博客,AFL是存在语料库蒸馏(Corpus Distillation)工具的,afl-cmin和afl-tmin。
移除执行相同代码的输入文件——AFL-CMINafl-cmin的核心思想是:尝试找到与语料库全集具有相同覆盖范围的最小子集。举个例子:假设有多个文件,都覆盖了相同的代码,那么就丢掉多余的文件。减小单个输入文件的大小——AFL-TMIN整体的大小得到了改善,接下来还要对每个文件进行更细化的处理。afl-tmin尽量缩减文件体积。在winafl中,他们存在于 winafl-cmin.py,对输入的样本文件进行最小化处理,以用来提高 WinAFL 的执行效率。
筛选命令
python winafl-cmin.py --working-dir C:\Users\test\Desktop\winafl-master\build32\bin\Release -D C:\Users\test\Desktop\DynamoRIO-Windows-8.0.0-1\bin32 -t 100000 -i C:\Users\test\Desktop\jpg -o C:\Users\test\Desktop\jpg\out -coverage_module FreeImage.dll -target_module Project1.exe -target_method main -nargs 2 -- C:\Users\test\source\repos\Project1\Release\Project1.exe @@
此时可能出现[!] Dry-run failed, 2 executions resulted differently:Tuples matching? False的报错
看来测试用例中存在一些坏的用例,导致不能正确精简,在语料库所在文件夹可以利用以下bash脚本简单判断一下
λ for file in *; do printf "==== FILE: $file =====\n";/c/Users/test/source/repos/Project1/Release/Project1.exe $file ;echo $?; done
正常运行的文件返回值都是0,有问题的文件返回结果都不太正常
把这些返回结果不太正常的删除之后,再运行一次语料库蒸馏,发现运行成功了
可以看到原本429张被精简到了148张,确实少了不少,根据参考教程中的提示,Winafl在处理大于4Kb的图片时,速度会变得很慢,因此再删除一波,最终语料库就剩下这么点了。
开始运行经过动态和静态的简单分析后,发现ABC看图主要调用Freeimage.dll进行图片解析的,决定对 FreeImage 库的载入函数进行模糊测试,针对 FreeImage_LoadU 函数编写测试程序
#define _CRT_SECURE_NO_WARNINGS#include
在对该程序进行编译之后,可以先简单测试一下WinAFL 是否可以正常使用。-debug 表示设置为调试模式。
\winafl\bin32> C:\Users\test\Desktop\DynamoRIO-Windows-8.0.0-1\bin32\drrun.exe -c winafl.dll -debug -coverage_module FreeImage.dll -target_module Project1.exe -target_method main -fuzz_iterations 10 -nargs 2 -- C:\Users\test\source\repos\Project1\Debug\Project1.exe C:\Users\test\Desktop\jpg\1x1-low.jpg
如下图所示,日志文件当中模块加载正常并没有错误显示
下面就要开始模糊测试了,按照教程进行的,但是它的目标函数是main,我们来看看结果如何。
afl-fuzz.exe -i C:\Users\test\Desktop\jpg\out -o C:\Users\test\Desktop\jpg\re -D C:\Users\test\Desktop\DynamoRIO-Windows-8.0.0-1\bin32 -t 9000 -- -coverage_module FreeImage.dll -target_module Project1.exe -target_method main -fuzz_iterations 5000 -nargs 2 -- C:\Users\test\source\repos\Project1\Debug\Project1.exe @@
如图所示,可以跑是可以跑,但是这个速度实在太慢了,执行main函数浪费了太多时间,实际上我们的load函数只测test函数就可以,我们将-target_method改为test尝试一下
afl-fuzz.exe -i C:\Users\test\Desktop\jpg\out -o C:\Users\test\Desktop\jpg\re -D C:\Users\test\Desktop\DynamoRIO-Windows-8.0.0-1\bin32 -t 9000 -- -coverage_module FreeImage.dll -target_module Project1.exe -target_method test -fuzz_iterations 5000 -nargs 2 -- C:\Users\test\source\repos\Project1\Debug\Project1.exe @@
然后就蹦框了,看起来是没有找到我们写的test函数,忘了在vs里把test函数也导出
这里导出后再编译一遍,再尝试一下,成功了,这速度明显提升了好几倍啊
为了让fuzz效率更高一点,充分利用cpu的多核,进行多核系统的并行测试
afl-fuzz.exe -i C:\Users\test\Desktop\jpg\out -o C:\Users\test\Desktop\jpg\re -M master -D C:\Users\test\Desktop\DynamoRIO-Windows-8.0.0-1\bin32 -t 9000 -- -coverage_module FreeImage.dll -target_module Project1.exe -target_method test -fuzz_iterations 5000 -nargs 2 -- C:\Users\test\source\repos\Project1\Debug\Project1.exe @@afl-fuzz.exe -i C:\Users\test\Desktop\jpg\out -o C:\Users\test\Desktop\jpg\re -S slaver01 -D C:\Users\test\Desktop\DynamoRIO-Windows-8.0.0-1\bin32 -t 9000 -- -coverage_module FreeImage.dll -target_module Project1.exe -target_method test -fuzz_iterations 5000 -nargs 2 -- C:\Users\test\source\repos\Project1\Debug\Project1.exe @@afl-fuzz.exe -i C:\Users\test\Desktop\jpg\out -o C:\Users\test\Desktop\jpg\re -S slaver02 -D C:\Users\test\Desktop\DynamoRIO-Windows-8.0.0-1\bin32 -t 9000 -- -coverage_module FreeImage.dll -target_module Project1.exe -target_method test -fuzz_iterations 5000 -nargs 2 -- C:\Users\test\source\repos\Project1\Debug\Project1.exe @@
因为我的配置比较垃圾只有四核,所以就开这么多了,我们先试一下
扔到ABC看图里,发现真的崩溃了
利用Bugid对Crash分类这样一堆crash,里面肯定有不少重复的,原因也有各不相同,如何对他们进行快速分类并找到问题点呢?
在这里我使用了BugID,它可以反馈崩溃和死机的可利用性的详细报告,BugID安装所需要的环境如下:
最新的Python 2.7.14Windows的最新调试工具最新的BugId版本如果使用默认设置安装Windows的Python和调试工具,则BugId应该能够运行而无需调整任何设置。您可以在本地文件系统上任意位置解压缩BugId
但是理论上BugID需要一个一个进行文件分析,而Crash这么多,只是就可以写一个Python脚本来帮助我们
import sysimport ossys.path.append(r"C:\Users\test\Desktop\BugId-master")testcases = []for root, dirs, files in os.walk(r"C:\Users\test\Desktop\jpg\re\slaver01\crashes", topdown=False): for name in files: testcase = os.path.abspath(os.path.join(root, name)) testcases.append(testcase)for testcase in testcases: print ("[*] Gonna run: ", testcase) os.system(r"PageHeap.cmd "Project1.exe" ON") os.system(r"python C:\Users\test\Desktop\BugId-master\BugId.py C:\Users\test\source\repos\Project1\Debug\Project1.exe --isa= x86 -- %s" % testcase)
请注意在最后的程序后面加上--isa= x86哦,不加默认作为64位调试会报错
运行脚本之后,我们就看到源源不断的bug信息出来了
最后可以写到一个文档里保存下来,看起来字符好像有点问题,不过问题不大
这只是简要信息,BugID在运行时已经自动生成了较为详细的分析报告,打开BugID目录就可以看到
随便打开一个看看,很详细
参考文献winafl使用 http://www.simp1e.site/2020/04/18/winafl/
模糊测试工具WinAFL使用指南 https://www.freebuf.com/articles/system/216437.html
初识 Fuzzing 工具 WinAFL https://paper.seebug.org/323/
Fuzz 工具 WinAFL 的使用感受 https://bbs.pediy.com/thread-255162.htm
Fuzzing the MSXML6 library with WinAFL https://symeonp.github.io/2017/09/17/fuzzing-winafl.html