Before we can start porting, you will need to grab a copy of the Radamsa fuzzer; here's how you do that:

To cross-compile Radamsa for Android, you should do the following:

And that's it! Radamsa is up and running on Android. The next section talks about setting up a simple fuzzing script and pointing it at dexdump to try and generate some crashes and hopefully find some exploitable vulnerabilities.

If you're going to be doing some fuzzing, you will eventually need to do some bash scripting to hone Radamsa at the right targets and autonomously report input data that causes interesting behavior. Unfortunately, Android platforms don't come packaged with all the utilities that make bash scripting powerful; they don't even come with a bash shell application, mostly because it's not needed.

We could use the sh shell do to our scripting, but bash is a little more powerful and robust and generally most people are more accustomed to bash scripting. Because of this, the following section of this recipe explains how to get Busybox running on an Android platform.

In the first part of the How to do it… section of this recipe, we covered cross-compiling a popular fuzz test generator called Radamsa. Most of what we did is already explained in the Cross-compiling native executables recipe. Things get interesting when the NDK build script fails to compile Radamsa because of a type definition; here's what it looked like:

typedef unsigned long in_addr_t;

This causes the build script to fail because the GCC compiler used by the NDK build script—namely one that was built to support the ARM Application Binary Interface—failed to recognize the effect of the type definition.

Once this issue was resolved, Radamsa could compile successfully and be deployed to an Android device.

Then we wrote a makeshift fuzzing script to the target dexdump. To make sure you guys understand exactly what you're doing in this recipe, it's important we detail what the bash script does.

The first few instructions make sure we have some useful mnemonics to help us refer to the arguments passed to the script. These instructions—appearing after the #!/bin/bash instruction—simply assign values to some variable names.

After assigning these values, the script steps into a for loop with a sentinel value—the value that limits the number of times the for loop iterates—which will cause the script to iterate forever unless explicitly stopped by the user or the operating system.

Inside the for loop, we see the following line:

cat $ROOT | radamsa -m bf,br,sr -p bu > fuzz.dex

All this does is grab the file pointed to by the ROOT variable and feeds it to Radamsa. Radamsa then applies some randomized transformations to the file.

After making the requested random transformations to the DEX file, Radamsa redirects the output to a file called fuzz.dex, which is the "fuzzed" version of the sample DEX file.

Then dexdump is invoked with the fuzzed DEX file as an argument; here's what it looks like:

$TARGET -d fuzz.dex 2>&1 > /dev/null

And all output is redirected to /dev/null, since we probably won't be interested in it. This line of code also redirects all the output from STDIN (the standard output file) to the STDERR file (the standard error output file). This allows all the output generated by the program—any that would likely clutter the screen—to be redirected to /dev/null.

The next instruction looks like this:

RET_CODE=$?

This records the exit code of whatever the last command was; in this case, it was dexdump.

The script does this because it will reveal information about how dexdump exited. If dexdump exited execution normally, the return code will be 0; should anything have happened that caused dexdump to exit or halt abnormally—say, like a fault due to corrupted input—the exit code will be nonzero.

And even more interestingly, if the fault required the operating system to halt dexdump via the use of inter-process signaling, the return code will be greater than 127. These return codes are the ones we are interested in generating since they give us a strong indication that a relatively serious flaw was exposed due to the given dexdump input. Errors like segmentation faults, which usually happen when an invalid portion of memory is used in an incorrect manner, always generate return codes higher than 127. For more detail on how exit codes or rather exit statuses work, see the Work the Shell - Understanding Exit Codes link in the See also section.

Moving on, the rest of the code looks like this:

echo "[$c] {$RET_CODE} ($WINS)"
test $RET_CODE -gt 127 && cp fuzz.dex win-dexdump_$ITER"_"$c.dex && WINS=`expr $WINS + 1

The first instruction of this portion of the code simply helps us keep track of which iteration the script is currently executing—by printing the $c value. It also prints out the return code of the previous run of dexdump and how many notable halts have occurred.

After printing out the mentioned "status indicators", the script compares the value saved in the RET_CODE variable's value to 127; if this value is greater, it makes a copy of the sample input that caused this error and increments the WINS variable by 1 to reflect that another notable error was generated.