
American fuzzy lop - jcr
http://lcamtuf.coredump.cx/afl/
======
petercooper
ICYMI, there was an article that was popular on here a week or two ago about
using afl to 'generate' JPEGs out of thin air:
[http://lcamtuf.blogspot.co.uk/2014/11/pulling-jpegs-out-
of-t...](http://lcamtuf.blogspot.co.uk/2014/11/pulling-jpegs-out-of-thin-
air.html)

~~~
Luc
ICYMI: In Case You Missed It.

------
jcr
I probably shouldn't ruin the fun, but for those that missed the joke, the
name "American Fuzzy Lop" is actually a breed of extremely fuzzy rabbits.

[http://en.wikipedia.org/wiki/American_Fuzzy_Lop](http://en.wikipedia.org/wiki/American_Fuzzy_Lop)

------
yzzxy
Enjoying the recent spatter of articles on fuzzing, it's an interesting topic
to read about and file for future use.

This page brings me back to a question that I've been having a lot recently:
how does one get really good at *nix in this day and age?

It seems like the era of learning on a college mainframe computer is over, and
"sysadmining" for hobby and SaaS nowadays projects often totally abstracts the
nitty-gritty bits of the OS. Yet these systems still power our computers and
servers, and there appears to be a real utility in understanding them well. I
run Debian as my daily driver, with a fairly "hardcore" setup without a fancy
GUI, but I still feel like I haven't even scratched the surface of my OS. I
don't really understand how library linking or process messaging or anything
like that works, and I'm not sure how to start learning.

~~~
jcr
Learning C is essentially required to become _really good_ with UNIX. For
example, the answer to your library linking question only "correctly" makes
sense when you understand C since you need to understand C to really
understand how the underlying C code works with all the compilers, linkers,
loaders, object files, executable file formats, and such.

The good folks Debian build and maintain a solid linux disto, but you need to
realize how a linux distro will only teach you the "linux way" of doing
things. There are other ways, and of course, other systems. The various BSD
operating systems like OpenBSD, FreeBSD, NetBSD, DragonFlyBSD, ArchBSD,
BitRig, and so forth all tend to stick a bit more closely to the classic or
historic "UNIX way" of doing things.

If the goal is to learn C so you can learn the underlying system code, my
choice would be OpenBSD. It's simple, solid, and secure, but the best reason
to pick it would be the quality of the code and documentation. It really helps
to have reliable code and docs when you're trying to learn, and like all
active projects, they keep trying to improve both.

The only reason why I know about the AFL fuzzer is due to the never ending
auditing of OpenBSD since some of the OpenBSD developers, like Damien Miller
[1] and Jonathan Gray [2], have recently been using AFL to discover and fix
bugs.

[1]
[https://twitter.com/damienmiller/status/534156368391831552](https://twitter.com/damienmiller/status/534156368391831552)

[2] [https://www.marc.info/?l=openbsd-
cvs&m=141646270127039&w=2](https://www.marc.info/?l=openbsd-
cvs&m=141646270127039&w=2)

~~~
yzzxy
Thanks for the advice... I will be bookmarking this and I think I'll load up a
FreeBSD install on a Raspberry Pi or something[0]. I know C, but I don't
_know_ C, and it think learning about compilers and such would be super
interesting.

[0] More driver problems are probably _good_ , right? :)

------
anon4
A word of warning: the links on the demo page
[http://lcamtuf.coredump.cx/afl/demo/](http://lcamtuf.coredump.cx/afl/demo/)
lead to pages with images that can make your browser use up all your memory
and your system will be unresponsive until the OOM killer kicks in. I admit
that it's my fault for not reading the warning on the very page I'm linking,
but I imagine there are others like me, so here.

WARNING: some of the demo pages will crash your browser.

------
unbelievr
I have wanted to apply some amount of fuzzing for embedded development, but
have not yet stumbled over any tools or strategies for this. Is there anyone
who have some experience with this?

More specifically, I want to test against a stack with an API written in C,
but the problem is that it is only accessible through code. Code that needs to
be flashed to physical hardware before running. A crash in the stack leads to
some trigger that can give output, so it's easy to identify a crash. For now,
I have made a serialization layer for the API functions, but feel like any
fuzzing methodologies would mainly test the serialization instead of the
underlying stack.

Is there any tools out there that can do this, or what AFL-fuzz does but on
ARM Cortex M running with a debugger?

------
vishaldpatel
So, what's a "fuzzer"? =/

~~~
charleslmunger
A fuzzer is a tool that generates malformed input to try and trigger crashes
in parsers, usually with the hope of finding a bug that can be turned into a
security exploit.

~~~
zurn
Parsing bugs is one category of tickled bugs, another is correctly encoded
values that confuse the deeper logic layers. Eg heartbleed was the latter.

------
chris_wot
Awesome! However... could you change the instruction to "login as root" to
also suggest:

    
    
      echo core | sudo tee /proc/sys/kernel/core_pattern

------
unsigner
Is there a good fuzzer for Windows command-line executables? I looked around a
day or two ago and everything "advanced" was Linux-only.

------
krakensden
From the Makefile:

    
    
      ifneq "$(shell echo $$HOSTNAME)" "raccoon"
        CFLAGS   += -Wno-format
      endif

------
com2kid
I'd kill for good fuzzing tools that ran on embedded systems that lack a real
OS.

The embedded world really needs some better tooling.

