OpenJailbreak Project:-
As well as creating the the tools and providing the source, another stream has come from the OpenJailbreak project in the form of education and training. Each and every week a Jailbreak class is run. The goal of the project is for the class to create an untethered jailbreak from the members of the community that contribute to the classes each week. The class is held via Skype & IRC each Saturday at 1pm UTC and usually last around an 1-2 hours.
Each week progress is discussed with individual members contributing their findings and passing on their knowledge to the group. So far this has been tools, crashes or anything they have found that is of interest to jailbreaking in general.
The initial classes discussed the jailbreaking process and what will be required. Since then things have begun to pick up speed and time has been spent looking into fuzzing and creating various tools and wrappers that can automate the fuzzing process. The next step is to investigate the crashes that have been submitted and try to reverse engineer what is happening. Once this done it maybe possible find out if the crash is vulnerable and can be used for an exploit. More information on the classes can be found at the links below:
http://www.reddit.com/r/jailbreak/comments/1nxoq7/openjailbreak_class/
fuzzyDuck automated iOS fuzzing tool:-
As fuzzing was topical I thought I would take a look into it and read the chapter on fuzzing from the iOS hackers handbook. After reading this and listening into some of the discussion on #OpenJailbreak I decided to look into automating the process so that a test case could be fuzzed, tested with MobileSafari and then any crash copied to a directory for later review along with the fuzzed test case. I could then check it out and ensure it was reproducible across platforms and iOS versions.
Web Server
I decided that the best way to do this was probably going to be on the device, the downside of this is you need a Jailbroken device but it does provide you plenty of flexibility in copying the crash.plist and the test case to where you want in order to investigate further. A couple of people were looking at using python as a web server on the device which seemed feasible as you could simply use:
This would create a web server from the directory your in, you can then serve up the test case and run it via MobilSsafari. e.g. simply opening:
After trying this I found that python wasn't the best option, it was causing the .mov file to not play in MobilSafari. Serving the same content to normal desktop Safari from the device was fine and the .mov files seemed to play ok. I don't know why this was happening but decided to look for another httpd daemon to serve up the test cases on the device. It didn't take long to find lighttpd which is a very light weight http server (as the name suggests) and is available from cydia.
When I started the lighttpd daemon this and tried to access a .mov file I had created using the camera on the device it played perfectly via MobileSafari on device. Cool, I grabbed another mov from the Apple Support site and tried to spin that up using lighttpd and MobileSafari on device. This didn't play in mobile safari but did on desktop safari... which I *think* was important. I noticed that if you have a mov file you are going to fuzz it should probably play before it is fuzzed. This isn't necessarily the gospel (just my findings), but if the .mov file your testing with is failing to play before it gets to the interesting bit in the file you have fuzzed, then your fuzzing is going to be useless. I think it is probably safe to say if the mov file plays then it is a good candidate to fuzz with and you will have more chance of crashing.
Fuzzer
Now I had a webserver I needed to create a script that would run, mutating my test case and then launching it in Mobile Safari. If it caused a crash then the crash dump and the mutated test case should be copied to a crashes directory. This is pretty much how the iOS Hackers Handbook does it so I thought I would give it a go. In the book Charlie Miller is using python to write his own fuzzer. After not having much luck with python earlier and reading that it had performance issues running on iOS I thought it would be better to use zzuf. Zzuf had been discussed in the classes and a few others were having luck with it so gave it a go. I'm not sure where it came from but I managed to find a copy of a zzuf that had been built for iOS. I believe it was compiled for ARM by comex so props to him for that!
zzuff takes the original test case mutates it and then outputs it to another file. As well as giving it the input file and output file you can specify a seed and ratio for mutation. The ratio I am using in my script was suggested by compiledEntropy, but if you need to you can play with this and change it around to see what results you get, the more you mess with it the longer it may take to generate a test case. This is the command I use to create test cases:
Testing
After the test case is created I needed a way to test it, iOS Hackers Handbook to the rescue (again)! The simplest way to test this is using a tool called sbopenurl. Simply passing it a URL it will fire MobileSafari and inject the URL to it. This tool is available from the cydia package com.innoying.sbutils. The command is simply:
I know others had tried to create web pages that auto ran the test case but this seemed to fail. Mobile Safari seems to demand input from the user before playing so it wouldn't work in an automated fashion.
Crash Dumps
Now I had a way to serve the test cases (lighttpd), create the test cases (zzuf) and open the test cases (sbopenurl). The final step was to check for crashes and put it into one big loop to run and run! It seems that nearly all test crashes eventually end up in:
Web Server
I decided that the best way to do this was probably going to be on the device, the downside of this is you need a Jailbroken device but it does provide you plenty of flexibility in copying the crash.plist and the test case to where you want in order to investigate further. A couple of people were looking at using python as a web server on the device which seemed feasible as you could simply use:
#python -m SimpleHTTPServer 8080
This would create a web server from the directory your in, you can then serve up the test case and run it via MobilSsafari. e.g. simply opening:
http://localhost:8080/myTestCase.mov
After trying this I found that python wasn't the best option, it was causing the .mov file to not play in MobilSafari. Serving the same content to normal desktop Safari from the device was fine and the .mov files seemed to play ok. I don't know why this was happening but decided to look for another httpd daemon to serve up the test cases on the device. It didn't take long to find lighttpd which is a very light weight http server (as the name suggests) and is available from cydia.
When I started the lighttpd daemon this and tried to access a .mov file I had created using the camera on the device it played perfectly via MobileSafari on device. Cool, I grabbed another mov from the Apple Support site and tried to spin that up using lighttpd and MobileSafari on device. This didn't play in mobile safari but did on desktop safari... which I *think* was important. I noticed that if you have a mov file you are going to fuzz it should probably play before it is fuzzed. This isn't necessarily the gospel (just my findings), but if the .mov file your testing with is failing to play before it gets to the interesting bit in the file you have fuzzed, then your fuzzing is going to be useless. I think it is probably safe to say if the mov file plays then it is a good candidate to fuzz with and you will have more chance of crashing.
Fuzzer
zzuff takes the original test case mutates it and then outputs it to another file. As well as giving it the input file and output file you can specify a seed and ratio for mutation. The ratio I am using in my script was suggested by compiledEntropy, but if you need to you can play with this and change it around to see what results you get, the more you mess with it the longer it may take to generate a test case. This is the command I use to create test cases:
#zzuf -s $RANDOM -r 0.0001:0.001 < originalTestCase.mov > mutatedTestCase.mov
Testing
#sbopenurl http://localhost:3000/mutatedTestCase.mov
I know others had tried to create web pages that auto ran the test case but this seemed to fail. Mobile Safari seems to demand input from the user before playing so it wouldn't work in an automated fashion.
Crash Dumps
Now I had a way to serve the test cases (lighttpd), create the test cases (zzuf) and open the test cases (sbopenurl). The final step was to check for crashes and put it into one big loop to run and run! It seems that nearly all test crashes eventually end up in:
/var/mobile/Library/Logs/CrashReporter/
I'm not entirely sure how they get there though, it seems after a Kernel Panic the kernel panic logs are initially created in the directory below:
/var/logs/CrashReporter/
When you navigate to Settings > General > About > Diagnostics & Usage > Diagnostics & Usage Data on the device the crash logs are copied into the directory previously mentioned:
/var/mobile/Library/Logs/CrashReporter/
I couldn't work out what was doing this, I looked through the preferences app and there seems to be an instance method cleanupTimer that is invoking crash_mover. I tried to run crash_mover manually and by starting the launch daemon (com.apple.crash_mover) but this didn't work. In the end I gave up and decided to just check both directories for logs and copy them out. I would have preferred to aggregate them all in one directory using an 'OEM' supplied method like crash_mover but this will have to do for now.
Recovering
After running my script for a few days I soon realised that I was getting kernel panic, which was good but it meant that my testing stopped until I manually started the script again. I wanted to test all day & night, just checking the results at the end of the day. This wasn't going to be too difficult as I could simply create a launch daemon to run on reboot. The xml below created the launch daemon and it is then installed via fuzzyDuck tool:
House Keeping and Install
I wanted fuzzyDuck to be easy for anyone to use, so it also includes a number of steps to check for required software and install if necessary as well as some fairly verbose output. I think overall it is a fairly useful tool for a beginner to play with. To get fuzzy duck grab it from the github link below:
https://github.com/isa56k/fuzzyDuck
The readme.MD contains the instructions on how to install. Any questions fire them over on twitter or IRC to @isa56k =)
Now to try understand WTF the crash dumps are telling me....