Re: [afl-users] Better understanding AFL++. Please help!

[Marc Heuse]

Why don’t you read the extensive documentation of afl++? That would answer most your questions plus you would not use it wrongly :)

Am 29.01.2024 um 16:07 schrieb Evan Sherlock <egshe...@gmail.com>:

I am looking for a greater perspective of the in-depth workings of fuzzing with AFL++. I have lots of questions! I am using Ubuntu 22.04.

What does "deterministic" mean in regards to fuzzing (or in computer science in general)? An explanation in layman's terms would be helpful.

I have done *some* research on the definitions of the following -- statement coverage, line coverage, function coverage, basic block coverage, edge coverage, path coverage, and branch coverage.

As I understand it, map density is a metric that calculates the amount of edges observed in each cycle. And, count coverage uses a bitmap to keep track of branch coverage. Is there any kind of simplistic explanation you could give me in regards to how map density and count coverage work? A map density of 0.03% / 0.3% implies what, compared to, say, 17.4% / 40.01%? How do I interpret (for example) 1.71 bits/tuple, or bits per tuple. Can you explain what the tuples consist of? Something to do with execution path, or no? And, what about the bits? I have read about tuples over at https://github.com/google/AFL/blob/master/docs/technical_details.txt. Is this relevant?

It's my understanding that a bitflip, if given the following input, "Tom Petty" and then viewed that in binary form "01010100 01101111 01101101 00100000 01010000 01100101 01110100 01110100 01111001" is like flipping the bits of the input. So, something like changing the first 8 bits and flipping them -- like 10101011. Is my understanding of what a bitflip is satisfactory?

I have attempted fuzzing of two different programs. The first was ffmpeg and the second was libpng. I compiled these programs, including shared libraries, with afl-clang and AddressSanitizer.

---

CASE #1 (ffmpeg):

I downloaded a bunch of possible test cases for my corpus from here: https://lcamtuf.coredump.cx/afl/demo/ . I then consolidated the corpus by running afl-cmin.

Also, I generated a dictionary for the ffmpeg fuzzing by saving the output of --help to a file and stripping it with the sed tool. Seemed to work pretty well. You can view it here (on my GitHub): https://github.com/evangsherlock/AdventuresInFuzzing/blob/main/ffmpeg.dict. Is this dictionary an example of grammar based fuzzing? Noob question, but I just need to know. And does using a dictionary like this help in regards to fuzzing, or no?

Is it recommended to include the -i switch when initiating fuzzing, or should I leave this out? I ask because I don't want to restrict the fuzzer's ability to find bugs, therefore not including that switch seems logical. However, in the commands below I did use the -i switch.

The commands I used to compile and fuzz are below:

// Configure with settings like AFL-clang++ and AddressSanitizer
./configure --cc=afl-clang --cxx=afl-clang++ --extra-ldflags="-fsanitize=address -fsanitize=undefined -lubsan" --disable-stripping --enable-debug=3

// Consolidate input corpus
./AFLplusplus/afl-cmin -i image_corpus -o min_corpus -- ./ffmpeg2/ffmpeg -i @@

// Initiate fuzzing of ffmpeg
/home/evan/AFLplusplus/afl-fuzz -i ./min_corpus -o fuzz -m none -- ./ffmpeg2/ffmpeg -i @@

// An attempt at using a dictionary along with an input corpus of different kinds of media
/home/evan/AFLplusplus/afl-fuzz -x ffmpeg.dict -i ./all_media -o fuzz_all_media -m none -- ./ffmpeg-0.10.1/ffmpeg -i @@

CASE #2 (libpng):

I needed a wrapper for fuzzing libpng, since it is a shared library. I found a general purpose one that reads and writes png files. I modified it slightly so it would delete its output file since I assume there would be thousands of output files. Download/view here: https://github.com/evangsherlock/AdventuresInFuzzing/blob/main/libpng_test.c

Am I correct in assuming that if I call *more* functions from libpng within my wrapper script that I will obtain better code coverage? That seems obvious, but I still wanted to ask.

Why is my map density statistic so low? Is this normal? When running AFL++ on libpng (with wrapper) I get 0.03% / 0.03% -- can you help me understand this metric better? My count coverage is also about 1.71 bits/tuple.

It appears that my fuzzing efforts are working because my libpng program is crashing -- which is what I want. But, can I do better? Am I missing something vital? What if my libpng program performs error checking before using official libpng functions? I assume this will halt potential crashes, though I am not sure. If so, would you recommend I reduce any kind of error checking within my wrapper script?

The commands I used to compile and fuzz are below:

// Another example of using configure, but this time we are compiling libpng
CC="afl-clang" CXX="afl-clang++" CFLAGS="-fsanitize=address -fsanitize=undefined -lubsan" ./configure --prefix=/usr --enable-shared --enable-static

// Command using afl-clang that compiles a wrapper script for libpng
/home/evan/AFLplusplus/afl-clang -fsanitize=address -fsanitize=undefined -lubsan libpng_test.c -o program -l:libpng.so -L:/usr/lib/

// Initiate fuzzing of libpng
/home/evan/AFLplusplus/afl-fuzz -i ./min_corpus -o fuzz -m none -- ./program @@

---

I have read about how AFL++ does not support argv fuzzing inherently, so you must use an experimental header file, argv-fuzz-inl.h, located in "experimental/argv_fuzzing/" along with the following macro AFL_INIT_ARGV(). Can you tell me if I need this functionality to have better results? I am a little confused.

Is there a way to view the errors of all the crashed inputs so that I don't have to rerun the program manually with crashed inputs? Perhaps in a log file?

What are collisions within the context of fuzzing? What exactly is colliding?

I am looking for best practices within the context of fuzzing these two programs. Given what I have done so far in my own attempts, what should I change or what should I do differently, etc? I do understand that I may, and probably, won't see results. I can deal with that. But, I'd still like advice on how to approach the programs I mentioned above so that I can carry over that knowledge to other fuzzing efforts.

I am interested in restarting my fuzzing efforts on a more powerful AWS server in order to fuzz faster. But, before I do that and wait for days on end to see if my testing generates any fruitful results, I thought it would be best to bring my questions to the attention of you all.

Thank you, Ev

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/afl-users/43fd7b4c-c60c-43fb-a37e-1d5fa91409ben%40googlegroups.com.