New AFL++ fuzzer.py #90
Conversation
| @@ -61,7 +61,8 @@ def append_flags(env_var, additional_flags, env=None): | |||
| '-pthread', '-Wl,--no-as-needed', '-Wl,-ldl', '-Wl,-lm', | |||
| '-Wno-unused-command-line-argument' | |||
| ] | |||
| NO_SANITIZER_COMPAT_CXXFLAGS = ['-stdlib=libc++'] + NO_SANITIZER_COMPAT_CFLAGS | |||
| NO_SANITIZER_COMPAT_CXXFLAGS = ['-stdlib=libc++', '-pthread'] + \ | |||
There was a problem hiding this comment.
I don't want to make you spend more time debugging linking issues, but I'm curious why this change was necessary.
- Why don't you use these variables?
- Is the change to CXXFLAGS necessary given this change?
- Why does the flag need to be added here? Is what we were doing before to append not sufficient?
- Can you change this to
NO_SANITIZER_COMPAT_CXXFLAGS = (['-stdlib=libc++', '-pthread'] +
NO_SANITIZER_COMPAT_CFLAGS)
We prefer using paren to backslash to break up lines in python.
| ENV CXXFLAGS -stdlib=libc++ -pthread |
There was a problem hiding this comment.
do you remember where this failed?
If not, it's fine I can look into this..
There was a problem hiding this comment.
I tested libpng and afl-clang-fast++ failed to link the harness binary due to the lack of -pthread.
The printed errors were related to functions in libc++ that use pthread.
Fix comments and formatting issues in pull request #90.
|
Yeah sorry for the late reply but I was at dinner. |
Don't worry, I landed because I assumed we weren't in the same timezone, so I wasn't expecting a response until tommrrow. |
|
Btw you should use -d also for all other AFL based fuzzers. I noticed that you are performing the deterministic stages, this explains why MOPT results to be the best fuzzer. Deterministic stages are useful, in my experience, when having parallel instances. In AFL++ we didn't change the default behavior for retro compatibility with AFL, but in most cases, it performs much better with -d, especially on structured formats like video formats. |
Interesting! I have to think about doing this because I sort of prefer using the defaults for each fuzzer. I'm fine with individual fuzzers turning on knobs but I'm less sure about doing it for all AFL fuzzers. |
|
AFLSmart for sure will benefit, @thuanpv will agree, they use this configuration by default (not here, probably he didn't notice that -d is missing). |
|
I support the observation of @andreafioraldi. The -d option seems to work well. It was the reason why in the evaluation of our AFLSmart paper, we used that option for both two selected baselines, AFL and AFLFast, to have a fair comparison. Please see the 3rd paragraph in subsection 5.5 (Infrastructure) of our TSE'19 paper (https://thuanpv.github.io/publications/TSE19_aflsmart.pdf) for more information. A bit of clarification, AFLSmart mutators are not implemented for the deterministic stage yet so -d is its default option. I think having structure-aware mutations in that stage could be beneficial but there are some technical issues. For example, since most of our new mutators (e.g., chunk deletion, chunk duplication, chunk swapping) could change the size of the seeds, how do we keep the stage deterministic along with the normal byte/bit-level mutation operators (e.g., bit flipping). While all the mutation operators supported in the current AFL deterministic stage are working on single seed input, AFLSmart mutators could work on multiple seed inputs -- one target input to be mutated but many more inputs from which we get source chunks for swapping and insertion. It is hard to deterministically select source input(s) and source data chunk(s) to do mutation in my opinion. The situation is a bit similar for the "splicing" operator and as we see, splicing is not a part of the deterministic phase. |
This AFL++ fuzzer.py works fine. There is the support to build configurations, but the conf is harcoded ATM.
I added also a small fix that includes -pthread by default because I experienced some errors while linking C++ (libc++ uses pthread).