Allow only `custom_post_process` outputs to queue
bendrissou opened this issue · comments
Hi,
I am using the custom_post_process function. The post process function performs some repairs on the fuzzed input. The function is working fine. However, I noticed that AFL occasionally adds to the queue some inputs that did not undergo my post_process transformation. Is there a way to enforce AFL to only save post_process outputs to the queue?
Note that I am not using any other custom mutation functions.
Thanks.
this can only happen from seeds (-i dir, -F dir and parallel instances that you are not running with the post processor).
is that possible? you can easily see from the filenames of such queue entries where they come from (orig:...).
Some valid queue entires are:
id:000006,src:000000,time:1018,execs:71,op:havoc,rep:3,+cov
id:000015,src:000000,time:5273,execs:298,op:havoc,rep:3
id:000045,src:000000+000014,time:58154,execs:2933,op:splice,rep:1
Some queue entries that not post processed:
id:000036,src:000000+000014,time:19142,execs:1080,op:splice,rep:2
id:000057,src:000000+000014,time:185644,execs:9202,op:splice,rep:2
Initially all inputs in queue were post-processed, then occasionally some are not.
To help me debug this, is there a way to intercept an entry (in AFL source code) before being added to the queue?
Thank you.
Weird. Yes there is a custom mutator hook when a new item is found
Thank you for your answer.
I have found out that some files in the queue were being occasionally overwritten. Is is possible to AFL to overwrite some older queue entries? Or it's not a normal behavior?
This happens due trimming. Likely after trimming we have to implement a post process call … will do that today or tomorrow
Thanks for the swift answer.
I notice that the contents of some queue entries are being truncated e.g. [1,2] becomes [1,2
I agree that its a good idea for post-processing to be the last operation (after trimming). If that is not feasible, it would be nice to have an option to disable trimming.
I don't think its a good idea to overwrite existing queue entries. If some new interesting inputs were discovered, then they should be added to the queue as new entries. Otherwise, we will have mismatches between the timestamp in the filename and the actual timestamp.
See example below:
-rw------- 1 root root 13 May 13 11:18 id:000001,src:000000,time:18,execs:15,op:inf,pos:0,+cov
-rw------- 1 root root 10 May 13 11:18 id:000002,src:000000,time:44,execs:23,op:quick,pos:0
-rw------- 1 root root 1 May 13 11:18 id:000003,src:000000+000001,time:96,execs:40,op:havoc,rep:3,+cov
-rw------- 1 root root 12 May 13 11:24 id:000004,src:000000+000001,time:116,execs:50,op:havoc,rep:1,+cov
-rw------- 1 root root 4 May 13 11:18 id:000005,src:000000+000001,time:169,execs:75,op:havoc,rep:2,+cov
-rw------- 1 root root 21 May 13 11:18 id:000006,src:000000+000001,time:197,execs:89,op:havoc,rep:1
Entry id:000004 was added earlier than id:000005, but has a newer unix timestamp 11:24!
Trimming keeps the same coverage so it is fine.
There is an env to disable it
I pushed a commit to dev that calls post_process after trimming. I am at an airport and cannot test it really now :) can you please check it works and nothing crashes?
I don't think its working. See example below:
-rw------- 1 root root 43 May 13 14:51 id:000040,src:000024+000013,time:16673,execs:3078,op:havoc,rep:6
-rw------- 1 root root 10 May 13 14:57 id:000041,src:000024+000013,time:17019,execs:3124,op:havoc,rep:2,+cov
-rw------- 1 root root 9 May 13 14:51 id:000042,src:000024+000013,time:19841,execs:3427,op:havoc,rep:3
How would I see this there?
Run the fuzzer for a few minutes, then list the queue and inspect the timestamps for any inconsistencies.
ls -lh findings/default/queue
The last dev commit 0892a22 seems to work. No overwrites observed.
I do not understand you. is the dev state working for you, so are all items in the queue valid or not
Yes, its working. All of the queue is valid.