Busybox no coverage

[Sony Bavaria]

Hi, 

I am trying to fuzz specific version of busybox but it seems like AFL++ only finds 1-3 paths within the applets and immediately start cycling after few seconds. 

The busybox is compiled with afl-gcc-fast and afl-g++-fast with ASAN build enabled. 

As mentioned earlier depending on applet I get 1 to 3 paths. For example for gunzip/gzip applet I get three path only. I am not using QEMU mode (as others who were fuzzing busybox were). 

I am using busybox for x86 v 1.30.1 (manually patched to fix time syscall issue which is known problem). 

afl-showmap shows different bitmap for each applet or within same applet with different files. strace does not show any usage of forking/execve within busybox. All seems normal situation. 

I am sure there is something wrong here but I can not pinpoint it. 

Any idea?

my command:

afl-fuzz -i corpus/ -o outdir/ ./busybox gzip @@

[Jonathan Neuschäfer]

On Fri, Aug 27, 2021 at 03:36:31AM -0700, Sony Bavaria wrote:
[...]

> As mentioned earlier depending on applet I get 1 to 3 paths. For example
> for gunzip/gzip applet I get three path only. I am not using QEMU mode (as
> others who were fuzzing busybox were).

[...]
> my command:
>
> *afl-fuzz -i corpus/ -o outdir/ ./busybox gzip @@*

With "busybox gzip @@" as the command line, you'll test compression, not
decompression. I'd expect it to be relatively difficult to hit interesting
cases this way, as the input data is more or less treated as opaque and
will not be parsed.

Decompression (gzip -d or gunzip) seems more likely to evoke interesting
behavior.

Also, what's in your corpus directory?


Best regards.