Can we call afl a whitebox fuzzer ?

377 views
Skip to first unread message

Nicolas Dubrana

unread,
Oct 21, 2016, 10:42:10 AM10/21/16
to afl-users
Hi guys, I'm a beginner in fuzzing so maybe it's a really stupid question.

Can we call afl a white box fuzzer ? Because Microsoft call their fuzzer (Project Springfield) a white box fuzzer and for me it's looking like the same type of fuzzing than afl ?

Sorry for the spelling errors, English is not my mother tongue.

Regards,
Nicolas

Brandon Perry

unread,
Oct 21, 2016, 10:44:55 AM10/21/16
to afl-...@googlegroups.com
It depends on how you use it. It can also be used as just a dumb fuzzer with no feedback.

Also, afl-dyninst instruments black-box binaries for fuzzing with AFL.


I don’t think label like black-box or white-box fits well with AFL.


Regards,
Nicolas

--
You received this message because you are subscribed to the Google Groups "afl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to afl-users+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

signature.asc

Sami Liedes

unread,
Oct 21, 2016, 10:53:51 AM10/21/16
to afl-...@googlegroups.com
On October 21, 2016 5:44:48 PM GMT+03:00, Brandon Perry <bperry....@gmail.com> wrote:
>Also, afl-dyninst instruments black-box binaries for fuzzing with AFL.

I think this confuses the colors of different boxes. I believe whitebox fuzzing means treating the target as a white box. Any kind of instrumentation and using the results from that is peeking inside the box. This really has nothing to do with whether you have source code to the binary.

So, yes, to me AFL is a quite stereotypical whitebox fuzzer (expect when run in dumb mode).

-Sami

Brandon Perry

unread,
Oct 21, 2016, 10:59:42 AM10/21/16
to afl-...@googlegroups.com

> On Oct 21, 2016, at 9:53 AM, Sami Liedes <sami....@iki.fi> wrote:
>
> On October 21, 2016 5:44:48 PM GMT+03:00, Brandon Perry <bperry....@gmail.com> wrote:
>> Also, afl-dyninst instruments black-box binaries for fuzzing with AFL.
>
> I think this confuses the colors of different boxes. I believe whitebox fuzzing means treating the target as a white box. Any kind of instrumentation and using the results from that is peeking inside the box. This really has nothing to do with whether you have source code to the binary.

Good point, I concede.

>
> So, yes, to me AFL is a quite stereotypical whitebox fuzzer (expect when run in dumb mode).
>
> -Sami
>
signature.asc

nicolas1...@gmail.com

unread,
Oct 21, 2016, 11:07:40 AM10/21/16
to afl-users
Hi guys, I'm a beginner in fuzzing so maybe it's a really stupid question.

Can we call afl a white box fuzzer ? Because Microsoft call their fuzzer (Project Springfield) a white box fuzzer and for me it's looking like the same type of fuzzing than afl do ?

Sorry for the spelling errors, English is not my mother tongue.

Regards,    
Nicolas

Jonas Wagner

unread,
Oct 25, 2016, 4:27:41 AM10/25/16
to afl-users
Hi,

Can we call afl a white box fuzzer ? Because Microsoft call their fuzzer (Project Springfield) a white box fuzzer and for me it's looking like the same type of fuzzing than afl do ?

Maybe it would be more precise to use different terms entirely.

I would personally call SAGE/Springfield a concolic execution engine. The technique it uses is symbolic execution, starting from concrete inputs. SAGE very closely looks at the program under test, trying to model the effect of each instruction that touches input data. SAGE then uses a constraint solver to generate new inputs that would take the program down different paths. Because it examines the program under test very deeply, you could call it "white-box". On the other hand, SAGE does not require source code AFAIK.

AFL is a fuzzer because randomness is key in exploring the program. It also looks at the program under test, but only gathers limited information -- mostly whether an input causes some edge in the control-flow graph to be executed or not. I'd call it a coverage-guided fuzzer for this reason.

To me, fuzz testing is strongly linked to randomness. AFL very much relies on randomness, while SAGE/Springfield tries to use a constraint solver instead. Use of randomness in SAGE/Springfield is more of a fallback for cases where the constraint solver is not precise.


Caveat: my understanding of SAGE is based on research papers by Ella Bounimova, Patrice Godefroid and others, which are five years old or more. So this might not reflect the current state of Springfield very well.


Hope this helps,
Jonas
Reply all
Reply to author
Forward
0 new messages