search

allyourcodebase / AFLplusplus

Zig build for AFL++
MIT License
4 stars 0 forks source link

Let's make fuzzing stupidly easy #1

Closed kristoff-it closed 1 month ago

kristoff-it commented 2 months ago

See https://github.com/kristoff-it/zig-afl-kit

Thank you so much for working on this!!

tensorush commented 2 months ago

That's cool! I'll see if I can finish off that LLVM support. Cheers!

kristoff-it commented 2 months ago

IMO afl-clang-fast is the most important executable, as jakub's linker doesn't implement LTO at the moment. Another tool that is very important is afl-system-config (required on macos to get shared memory to work). That one should be easy in theory.

tensorush commented 2 months ago

I'm looking at it now and have some off-the-top info:

kristoff-it commented 2 months ago

For (2), yes that makes sense.

For (1), that's unfortunate, the build script hints at the fact that you can get LTO on macos but it always fails with random complaints, turns out if was by design all along. That said their argument is inherently unsound: fork() might be crap on macOS but in persistent mode you only fork on crash, since all tests run in a loop, making macOS perfectly viable if you do that. In our case persistent mode should be considered the main use case.

I can also confirm that I tried to test the same executable both on macOS and NixOS and the performance was perfectly comparable.

If there isn't any special complication in setting it up, I would try to resuscitate LTO on macOS if you can. If it's a pain, feel free to skip it.

tensorush commented 1 month ago

Now able to build with LLVM LTO in a Linux VM. It should work, but I haven't tested it, thought you might want to give it a try on NixOS. It's also set up to build on macOS without LTO, just like the original.

I've kept the executable's original name of afl-cc (all the other names, like afl-clang-fast and afl-clang-fast++, were just sym-links to it in the original build process). You can build LLVM instrumentation alone by running the llvm_exes step.

kristoff-it commented 1 month ago

Here are some issues I'm encountering:

I got past these two problems locally but I'm not yet able to compile successfully. Will update if I make any progress.

kristoff-it commented 1 month ago

BTW I'm trying to fix everything that I'm encountering in a separate branch that I will PR

tensorush commented 1 month ago

I just fixed dynamic_list.txt issue, see: https://github.com/allyourcodebase/AFLplusplus/commit/50b7b45879169e612fc9fbcfff8168e7d16b8aad

tensorush commented 1 month ago

Also, I wasn't getting a glibc error in Ubuntu VM on macOS M1.

tensorush commented 1 month ago

I'm catching up on your stream)

kristoff-it commented 1 month ago

Also, I wasn't getting a glibc error in Ubuntu VM on macOS M1.

On macOS this is not a problem since it has its own libc, on ubuntu maybe glibc is the default? Dunno, nix is weird and without that flag the builit executable failed to open libc.so for some reason.

kristoff-it commented 1 month ago

I was just able to make afl-cc build correctly a program on macOS by adding 

        lib.addLibraryPath(std.Build.LazyPath{ .cwd_relative = llvm_lib_dir });
        lib.linkSystemLibrary("LLVM-18");

to the libs in the for loop that generates all the various dynamic libraries. "LLVM-18" should not be hardcoded, there's a llvm-config flag to get that info.

That said, trying to fuzz the generated file, it dies with SIGTRAP unfortunately.

EDIT: testing the generated executable with an official build of afl-fuzz works, so afl-cc worked correctly! It's afl-fuzz that has the issue.

EDIT2: It's UB in afl-fuzz :^)

kristoff-it commented 1 month ago

See https://github.com/ziglang/zig/wiki/FAQ#why-do-i-get-illegal-instruction-when-using-with-zig-cc-to-build-c-code

kristoff-it commented 1 month ago

https://github.com/kristoff-it/zig-afl-kit now depends on this repo and is able to build the entire toolchain on demand alongside the instrumented executable, success!