Now to try this with midi...
But what to feed it into? I could make some musical analysis stuff, but do I need to write it in C to avoid accidentally fuzzing my interpreter?
Pulling JPEGs out of thin air
41–50 of 86 posts
Re: Pulling JPEGs out of thin air
#42Earlier quoted context omitted.
It starts with an invalid .jpg (literally a text file containing "hello"), and by trying over and over, changing random bytes and tracing the execution of the decoder program as it is fed the corrupted input, it will drill deeper and deeper into the program until it has gotten far enough that the input is actually a valid .jpg, without any human input. Fuzzing like this is a very effective technique for finding (secu…
Why does it use fuzzed input in the first place? Couldn’t one just use random input from the beginning instead? It would be effectively equivalent but fuzzing of a "hello" string seems to be roundabout.
From the article: it works without any special preparation: there is nothing special about the "hello" string.
Re: Pulling JPEGs out of thin air
#43You can throw afl-fuzz at many other types of parsers with similar results: with bash, it will write valid scripts;
^ that seems fun, I just don't think I would run it on my machine for fear of what it might create (oh.. rm -rf * ok!)
Re: Pulling JPEGs out of thin air
#44I'm not familiar with how the fuzzer was monitoring the executed code path. Would this be thwarted by address space layout randomization?
You build the target binary using a special version of gcc:
3) Instrumenting programs for use with AFL
------------------------------------------
Instrumentation is injected by a companion tool called afl-gcc. It is meant to
be used as a drop-in replacement for GCC, directly pluggable into the standard
build process for any third-party code.
[...]
The correct way to recompile the target program will vary depending on the
specifics of the build process, but a common approach may be:
$ CC=/path/to/afl/afl-gcc ./configure
$ make clean all
[...]Re: Pulling JPEGs out of thin air
#45At the risk of sounding really stupid. Can someone ELI5 what's going on here and why everyone thinks its so amazing?
This is how I understand it: 1) JPEG file structure is complex (much more so than a BMP file for example). 2) Imagine you didn't know what it looked, but had a tool that could "read" them. djpeg in this case 3) What the fuzzer does is "peek" at how the djpeg tool reacts to random "fuzzed" data. It's smart about it, understanding when a bit of data makes the tool do something new (code path) 4) After millions of itera…
It doesn't do #4; it just finds one input that makes the program exit with exit code zero (for success)
It is better to look at it as a maze solver that tries to generate instructions for a robot that will lead that robot through the maze, while that robot has its own weird way of interpreting the instructions. It it generates) makes
Re: Pulling JPEGs out of thin air
#46Regarding >if (strcmp(header.magic_password, "h4ck3d by p1gZ")) goto terminate_now; How impossible would it be to look at the branching instruction, perform a taint analysis on its input and see if there is any part of the input we can tweak to make it branch/not branch. Like, we jumped because the zero flag was set. And the zero flags was set because these two bytes were equal. Hmm that byte is hardcoded. This other…
https://en.wikipedia.org/wiki/Symbolic_execution Quite possible. More commonly done with higher-level languages rather than machine code, but certainly possible with machine code. A good fuzzer could do this too. The fuzzer from the article, american-fuzzy-lop ( https://code.google.com/p/american-fuzzy-lop/ ), does something similar to this as it moves forward in execution, trying to find interesting inputs that caus…
I'm no expert but perhaps this symbolic engine could be something to build as a valgrind module.
Re: Pulling JPEGs out of thin air
#47Regarding >if (strcmp(header.magic_password, "h4ck3d by p1gZ")) goto terminate_now; How impossible would it be to look at the branching instruction, perform a taint analysis on its input and see if there is any part of the input we can tweak to make it branch/not branch. Like, we jumped because the zero flag was set. And the zero flags was set because these two bytes were equal. Hmm that byte is hardcoded. This other…
https://en.wikipedia.org/wiki/Symbolic_execution Quite possible. More commonly done with higher-level languages rather than machine code, but certainly possible with machine code. A good fuzzer could do this too. The fuzzer from the article, american-fuzzy-lop ( https://code.google.com/p/american-fuzzy-lop/ ), does something similar to this as it moves forward in execution, trying to find interesting inputs that caus…
Yea I thought of hashes too. Because there are hashes proven (?) to be secure, it follows that it's impossible to make a universally efficient fuzzer (i.e. one that necessarily spends much less than ~exp(parser size) time).
Re: Pulling JPEGs out of thin air
#48Now to try this with midi... But what to feed it into? I could make some musical analysis stuff, but do I need to write it in C to avoid accidentally fuzzing my interpreter?
Clojure repl + Overtone?
Re: Pulling JPEGs out of thin air
#49Potential instructions for trying this on Mac (I was unable to make it work, perhaps we can build upon this):
curl -LO http://lcamtuf.coredump.cx/afl.tgz
tar zxvf afl.tgz
rm afl.tgz
cd afl*
make afl-gcc
make afl-fuzz
mkdir in_dir
echo 'hello' >in_dir/hello
# there is a glitch with the libjpeg-turbo-1.3.1 configure file that makes it difficult to compile on Mac, so I tried regular libjpeg:
curl -LO http://www.ijg.org/files/jpegsrc.v8c.tar.gz
tar zxvf jpegsrc.v8c.tar.gz
cd jpeg-8c/
CC=../afl-gcc ./configure
make
# error: C compiler cannot create executables
# if the above command worked to build an instrumented djpeg, then this should work
cd ..
./afl-fuzz -i in_dir -o out_dir ./jpeg-8c/djpeg
Re: Pulling JPEGs out of thin air
#50I like to imagine that given enough time it eventually generates the Lenna [1] jpeg and exits