Custom mutators with coverage feedback

[evilpan]

Hi guys! I was using AFL++ custom (python) mutator and get confused of the parameters of the fuzz callback def fuzz(buf, add_buf, max_size). According to the examples, buf is The buffer that should be mutated and add_buf is A second buffer that can be used as mutation source.

Does buf and add_buf have the same data? Is the data mutated from our corpus by AFL? If I set AFL_CUSTOM_MUTATOR_ONLY=1, what will buf and add_buf contains in each run?

If I want to perform a structure aware fuzzing, for example, only mutate part of the structure, how can I implment it with AFL++ custom mutator API?

Any enlightment would be appreciated!

[evilpan]

Answering part of my question:

Does buf and add_buf have the same data? Is the data mutated from our corpus by AFL?
No, According to my test, buf is from corpus and add_buf is from what fuzz function return.

[vanhauser-thc]

no that is wrong.

add_buf is a different item from the corpus that can be used for splicing that data in if wished.

buf - the corpus item to be mutated
add_buf - another corpus item that can be used for whatever, totally optional.

[evilpan]

Hi @vanhauser-thc, thanks for your answer!
For example I was fuzzing a QR Code decoder, and I want to mutate the QR Code modules, instead of PNG pixels. So I write something like:

def fuzz(buf, add_buf, max_size):
  qr = random_qrcode()
  mutate(qr.modules)
  return bytearray(qr.toPNG().toBytes())

According to my test, buf is the corpus item, and add_buf is the PNG bytes data, maybe from previous fuzz output. Anyway, this works, but the generated data is totally not affected by AFL++, so I think this will be lack of coverage feedback and run as a blind fuzz?

[vanhauser-thc]

you an do that. if you actually use the queue item (buf) or ignore it is totally up to you.
afl++ still does full coverage analysis.
what you loose is that afl++ will not prefer good mutated input vs. not as good mutated input for the buf data, but that is just how it is with a mutator like that, not uncommon. most grammar mutators have the same issue that they create the new data out of thin air so to say.

and still no - you assumption on add_buf is wrong. it is as I wrote. :)