Tl;dr. autofz is a meta fuzzer that combines a group of fuzzers and outperforms each of individual fuzzers. Since each fuzzer shows completely different characteristics for each targets, it was cumbersome for developers to determine which fuzzer to adopt and to evaluate them for best fit. With autofz, it simply figures out -- based on past execution behavior and responses of each fuzzer, at runtime, and allocates the proper resource to maximize the output (i.e., bug finding and code coverage) of the fuzzing process.
The (preprint) paper links to its repository, where its code eventually will be. I suspect it will be pushed around August 2023, before USENIX Security'23, where it will be published.
They do refer to AFL++ in their footnote [17], citing that they took various improvements from them. I believe AFLfast would be from AFL++ then. And maybe they wanted the exclude RADAMSA into it's own category. Hongfuzz is also missing
> “Also, we use the implementation provided by [17] for Radamsa, Redqueen, and LAF-INTEL. Note that autofz can adopt any fuzzer sup- porting seed synchronization, and no fundamental obstacles prevent their integration. Therefore, autofz can truly enjoy the benefit of increasing diversity of the fuzzers.”
From my read of it, they took very specific parts of AFL++, but not the whole thing. The strength of AFL++ comes from having many optimized subcomponents, which is similar to the goal of this paper. Why not compare against the optimized AFL++? This leads me to suspect that autofz compares poorly to AFL++.
5 comments
[ 4.4 ms ] story [ 23.5 ms ] threadTl;dr. autofz is a meta fuzzer that combines a group of fuzzers and outperforms each of individual fuzzers. Since each fuzzer shows completely different characteristics for each targets, it was cumbersome for developers to determine which fuzzer to adopt and to evaluate them for best fit. With autofz, it simply figures out -- based on past execution behavior and responses of each fuzzer, at runtime, and allocates the proper resource to maximize the output (i.e., bug finding and code coverage) of the fuzzing process.
https://github.com/sslab-gatech/autofz
In this particular case, they specifically mention using particular parts of AFL++, but not the whole thing.
To me, this is a consistent “smell” about the quality of the fuzzer & paper.
> “Also, we use the implementation provided by [17] for Radamsa, Redqueen, and LAF-INTEL. Note that autofz can adopt any fuzzer sup- porting seed synchronization, and no fundamental obstacles prevent their integration. Therefore, autofz can truly enjoy the benefit of increasing diversity of the fuzzers.”
From my read of it, they took very specific parts of AFL++, but not the whole thing. The strength of AFL++ comes from having many optimized subcomponents, which is similar to the goal of this paper. Why not compare against the optimized AFL++? This leads me to suspect that autofz compares poorly to AFL++.