- 关于AFL
American fuzzy lop 号称是当前最高级的Fuzzing 测试工具之一，由谷歌的Michal Zalewski 所开发。通过对源码进行重新编译时进行插桩（简称编译时插桩）的方式自动产生测试用例来探索二进制程序内部新的执行路径。与其他基于插桩技术的fuzzers 相比，afl-fuzz 具有较低的性能消耗，有各种高效的fuzzing 策略和tricks 最小化技巧，不需要先行复杂的配置，能无缝处理复杂的现实中的程序。
下面还是以a.out为例
通过管道命令传参数个它看看
- 尽量使测试用例足够小
大用例不光使得目标进程解析时需要耗费更多CPU 时间和更多内存，也会使得fuzz 进程效率非常低下。举个例子，如果要对一个图片处理程序进行fuzz，就没必要将高分辨率的照片作为用例，一个16×16 分辨率的图片就足矣。再举个例子，从数据上来看，如果一个用例的大小为100 字节，那么fuzz 1000 次，可以有71% 的机会触发到有问题的执行路径；如果用例的大小变为1k 字节，则同样的执行次数，触发有问题的分支的概率降低为%11；如果用例规模进一步增长，变为10k字节，则同样的执行次数，触发问题分支的概率将降低为%1。 - 确保测试对象足够简单
有些基本的文件格式处理库被不同的处理程序使用，有些处理程序功能复杂，有些简单，那么，我们应该选择那些功能简单的处理程序来fuzz。举个例子，就图片格式处理程序来说，djpeg、readpng 以及gifhisto 要比ImageMagick 在执行效率上快5 到10 倍，但是他们都用同样的图片格式解析库。 - 只给需要测的库进行打桩因为AFL
是在汇编级别对被测程序的源码进行插桩的，也就是说，插桩的点越多，编译出来的程序执行效率就会越低。那么，如果只想对其中某一个库进行fuzz 的话，可以用未插桩的库替换掉被测程序中使用AFL 编译器编译出来的库。 - 并行
afl-fuzz 设计成只给工作进程分配一个核，现在的机器都具备多个CPU，每个CPU 又有多个核，所以我们可以最大地发挥硬件效率，同时执行多个afl-fuzz。
8 参考资源
- 台湾国立交通大学的一个大佬写的入门教程http://spencerwuwu-blog.logdown.com/posts/-a-simple-guide-of-afl-fuzzer
- 看雪一篇结合gdb分析crash的关于afl的教程https://bbs.pediy.com/thread-249179.htm
- 多种afl工具使用及多种情况下afl处理的文章https://0x00sec.org/t/fuzzing-projects-with-american-fuzzy-lop-afl/6498
- 使用afl来fuzz binutils的例子 https://www.evilsocket.net/2015/04/30/fuzzing-with-afl-fuzz-a-practical-example-afl-vs-binutils/
- 使用afl挖imagemagick的cve的文章https://github.com/lcatro/Fuzzing-ImageMagick/blob/master/%E5%A6%82%E4%BD%95%E4%BD%BF%E7%94%A8Fuzzing%E6%8C%96%E6%8E%98ImageMagick%E7%9A%84%E6%BC%8F%E6%B4%9E.md
- 天融信阿尔法实验介绍afl的文章https://www.freebuf.com/articles/system/191536.html
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请联系我们举报，一经查实，本站将立刻删除。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/201969.html原文链接：https://javaforall.net
