Fuzzing a C library using AFL

[Sandeep Parvatikar]

Hi

I am a newbie to AFL.

I am trying to fuzz a library using afl.
The lib.a is generated via afl-gcc compiler.
When I pass this lib.a as a target to the afl fuzzer....I get the below error.
"Program '/home/testappl/lib/lib.a' not found or not executable.

The command is
"afl-fuzz -i /home/testappl/input / -o /home/testappl/output/ /home/testappl/lib/lib.a ". Can you help me out with the above error?

Can anyone help me?

~ Sandeep

[Hendra Gunadi]

Hi Sandeep,

I think AFL will be able to run any instrumented executables, and a library is not really an executable (you can check by executing /home/testappl/lib/lib.a). In the README file there is a pointer on how you can fuzz a library, in particular:

When testing libraries, you need to find or write a simple program that reads
data from stdin or from a file and passes it to the tested library. In such a
case, it is essential to link this executable against a static version of the
instrumented library, or to make sure that the correct .so file is loaded at
runtime (usually by setting LD_LIBRARY_PATH). The simplest option is a static
build, usually possible via:

$ CC=/path/to/afl/afl-gcc ./configure --disable-shared

- Hendra

[Yann Droneaud]

Hi,

You need a program, a program that is linked with your library, a
program that use your library.

From documentation http://lcamtuf.coredump.cx/afl/README.txt

> When testing libraries, you need to find or write a simple program
> that reads data from stdin or from a file and passes it to the tested
> library.

Regards.

--
Yann Droneaud
OPTEYA

[Sandeep Parvatikar]

Thanks Yann, Hendra!

Now the AFL fuzzer is running.

But the parameter - "Last new path: none yet. (Odd! Check syntax)"
And "Total path: 1"

Any clue here?


~ Sandeep

[Jakub Wilk]

* Sandeep Parvatikar <sandeep.p...@gmail.com>, 2018-05-19, 00:37:

>But the parameter - "Last new path: none yet. (Odd! Check syntax)"

It's actually "(odd, check syntax!)".

>And "Total path: 1"
>
>Any clue here?

docs/status_screen.txt reads:

"[...] if the tool is not finding new paths within several minutes of
starting, you're probably not invoking the target binary correctly and
it never gets to parse the input files we're throwing at it; another
possible explanations are that the default memory limit (-m) is too
restrictive, and the program exits after failing to allocate a buffer
very early on; or that the input files are patently invalid and always
fail a basic header check."

--
Jakub Wilk