I’ve said it numerous times, finding crashes is the first step to finding exploits on the PSP (and on other devices as well, by the way. It is just easier on the PSP since we already have lots of tools to help us).

Crashes are usually the result of luck (bad luck if you were playing a game and forgot to save), but there are ways to “force” your luck. One of them is called Fuzzing. I recently found an MP3 crash (which happened to be non exploitable) through this technique, and I was actually very proud of this “revolutionary” method of finding crashes, until I was told that this was a known technique in software testing :P.

Wikipedia tells us:



Fuzz testing or fuzzing is a software testing technique that provides invalid, unexpected, or random data to the inputs of a program.

Well that’s pretty clear. The idea is to feed our program with random data and see if it crashes. In my case, the “program” was the PSP mp3 Player, and the random data was a series of broken mp3 files.

This is all very good, but the main issue is that you’d need to be extremely lucky in order to find a crash this way. Except… that the PSP mp3 player allows us to test thousands of files extremely quickly with the usage of playlists.

Here’s what I did for the mp3 file: I first created a very short mp3 file with Audacity. I use audacity because it’s open source, but any audio manipulation software will do. I then created thousands of copies of this file, with only one bit changed for each of those files. I of course didn’t do this by hand, I used a script. I went with ruby, but here again, any scripting language will do (perl, php, python…I’m sure you can do it in Linux shell, or even in C/C++ if you like pain). Here’s what my script looks like (fe4r my Ruby skillz):

What this script tells is the following: open the file “a.mp3” (my “source” regular mp3 created with audacity), and for i in 0..200, change the byte at position i with a value j, j varying between 0 and 255. In other words, I’m trying all the possible values for each single byte in the file. This generates thousands of files. For each value of i, I’m creating a new directory, so each folder will have 255 files. Note that I’m only doing this with the 200 first bytes because my 1GB memory stick got filled with those files, but nothing prevents us to actually create more (although I’d need to check if the mp3 player allows to have more than 255 subfolders in the mp3 directory). What I ended up doing is “sessions of 200”. I first tested the 200 first bytes, then 201 to 400, etc…

Once this was done, I copied all the generated files (still in their respective folders, the psp mp3 player doesn’t allow more than 999 mp3 files per folder anyways) on my psp, and started playing everything.

This takes time, but not mine: I don’t need to be around when the psp plays the mp3 files. if, when I come back, the PSP is off, it means a crash occured. I can then remove half of the files and try again, until I find the “culprit” through dichotomy.

That’s pretty much all there is to know about this technique. It worked for mp3s, and it would work for video files, as well as image files (through the slideshow feature), although I’m not sure how these two applications deal with playlists (let me know the outcome if you try it!). The whole point of this technique is to be able to test a very large number of files in a short amount of time. Even by testing thousands of files (my mp3 was 2048btes long, so thats 2048×255 = half a million files), we only test a very small percentage of all the combinations that could be fed to the software (what if I start changing 2bytes instead of 1 in my file? What if I use a different audio file as my source ? A wma maybe ? etc…). Well it’s good because everyone can try different combinations, but of course don’t expect too much results if the player only allows you to play 10 files in a row or something like that.

There are of course lots of other techniques to look for exploits in a system, but this one has several good points (when it is applicable!): it doesn’t require to be too clever (al you need is a little script, no specific knowledge about MP3s was required for my crash, at least for the first steps), and it takes very little time (as long as the system is nice enough to allow you to feed it thousands of inputs very fast).

I’m actually surprised I found a bug in the mp3 library of the PSP through this technique…One would think Sony use that kind of testing method on their firmwares.

I hope this will give inspiration to both people trying to secure their software, and those trying to free the world from the evil forces of DRMs 🙂 Have fun hacking!