2

I am currently trying to fuzz a PDF viewer with the AFL fuzzer (American Fuzzy Lop).

My problem is quite simple, afl-fuzz expect the application to take an input and close after processing it. But, the PDF viewer is intended to open the document and stay open until closed. The result is that afl-fuzz reach the timeout for all initial inputs and decide to stop here.

...
[*] Validating target binary...
[*] Attempting dry run with 'id:000000,orig:myPDFsample00.pdf'...
[*] Spinning up the fork server...
[+] All right - fork server is up.
[!] WARNING: Test case results in a timeout (skipping)
[*] Attempting dry run with 'id:000001,orig:myPDFsample01.pdf'...
[!] WARNING: Test case results in a timeout (skipping)
[*] Attempting dry run with 'id:000002,orig:myPDFsample02.pdf'...

[-] PROGRAM ABORT : All test cases time out, giving up!
         Location : perform_dry_run(), afl-fuzz.c:2883

I would like to know how to tell AFL to consider that reaching the timeout and get the program terminated is a "normal" behavior for the test case.

perror
  • 7,071
  • 16
  • 58
  • 85

1 Answers1

0

In fact, the usual way to do seems to simply instrument the code of the software you are looking at by adding an exit(0) after the parsing.

It seems quite basic, but I works...

The other way could be to change the meaning of a timeout in the AFL software. But, then, it won't detect 'hangs' when your software might enter a never ending loop.

So, the best way really seems to add an exit(0) (or return 0 if you are in main()) inside your target software just after the parsing is done.

perror
  • 7,071
  • 16
  • 58
  • 85
  • what if you are in Qemu mode and the binary you have, keep waiting for data and you don't have source code for it to edit it and add exit (0) any idea about how you can fuzz that type of binary – zerocool Mar 26 '20 at 23:29
  • Then, you should enlarge the timeout with the `-t` option. – perror Mar 27 '20 at 07:25
  • Could you be more precise, '*it doesn't work*' is not enough... – perror Mar 27 '20 at 07:44
  • because of the nature of the binary, it keeps waiting for input from the terminal, and no matter what how much you increase the time the binary will not exit until you kill it or it crashes and the later will not happen because test cases are just random seeds – zerocool Mar 27 '20 at 08:27
  • Okay, then you may either try to provide some mocks to satisfy the binary or just find another way to fuzz it. Maybe, just a simpler fuzzer that do not require internal instrumentation to operate. – perror Mar 28 '20 at 13:51