Why we can’t easily find exploits in BMP images
Last week I gave a short introduction on how to use PSPLink for crash analysis in the XMB. Some people have been actively looking for vulnerabilities on the PSP for years now (yes, it’s a fun hobby, trust me), and crashes, as you already know, can lead to exploits (and exploits lead to homebrews, homebrews lead to anger, and…oh wait… different story).
When they don’t lead to exploits, they lead to bug fixes, which is good too, so understand this: crashing your PSP is good for Mankind.
Recently I got a BMP file from Jeerum (you can get the file on his forum). This file crashes the PSP, and the crash looks like it could have been exploitable, except it isn’t. Rather, this example is a hint that exploiting the PSP using BMP files is probably never going to happen.
An interesting crash
Here’s the video. I’m running the XMB through PSPLink, and if you don’t know how to do this you should consider reading my blog more often
I’m doing the usual: going to the “images” section (note that the image doesn’t crash the XMB in thumbnail mode, which is quite rare), attempt to display the image, and the PSP crashes.
Now what’s interesting in this crash? Well as you see, the crash occurs when the PSP tries to Store a Word (MIPS command sw) at an address referenced by register $a1 (sw $t1 8($a1) means: store the value $t1 at $a1+8). And why is it interesting you ask? Well, $a1 is equal to FF414141, and I’m quite convinced that these three “41” come from our BMP file. a value such as FF414141 doesn’t feel “natural” at all, (and that feeling is something you -quickly- get with experience). A quick look at the inside of the BMP file shows us that yes, there’s a bunch of 41’s that were put in there, and it’s quite certain that it’s where the ones we see in the crash come from.
Now what? Well since we can change these 41’s into what we want, it means we can write the value of t1 pretty much wherever we want in memory. It’s not an exploit yet, but it’s extremely promising.
Not so fast…
But wait… what’s that “FF” doing here?
Well that’s the main problem.
To really see where this FF414141 comes from, we can dump the entire contents of the PSP Ram, and check where this comes from.
To dump the Ram to a file, we type the command:
savemem 0x08800000 20000000000 memdump1.bin
the 0x08800000 is the start of what we want to dump. 0x08800000 is not an address I chose randomly, it’s just the address of the beginning of the Ram. The second value is the amount of bytes we want to save. As I’m too lazy to calculate, I just enter an insanely high value to be sure all the Ram will be dumped to a file. PSPLink is clever and will stop when it reaches the end. memdump1.bin is the name of the file I want to save.
We can then open this file with an Hex Editor.
In this screenshot, the addresses I show you are random (because I already investigated this crash a few months ago and I knew what I was looking for), but in reality what you have to do, rather than randomly browsing the memdump, is to understand where the contents of $a1 come from. This is done by disassembling the code around the address of the crash, and understand (through MIPS assembly) where in Ram it read its content. To disassemble code, use the command disasm. I give a few hints on how to do that in my previous articles.
Ok, so the screenshot shows us a bunch of FF414141 in Ram, which is where our value came from. It’s pretty obvious they come from the 41’s we saw in the BMP. These are the contents of the BMP, reinterpreted by the PSP to display pixels on the screen, and this is what we have to deal with if we want to create an exploit.
But wait, we didn’t put thoses “FF”‘s here, only “41”. So where do they come from?
BMP files have no alpha layer
Well to understand this you need some basics in Images on computers. Long story short, pixels on the PSP are represented with 4 bytes, ARGB (alpha, Red, Green, blue). alpha is the transparency of the pixel. Although file formats such as PNG or Tiff have an alpha layer, BMP files don’t. The PSP therefore inserts a “fake” alpha value of “FF” (which means: no transparency) for each pixel.
We’re screwed: whatever we put in the BMP file, every 4 bytes we will get a stupid “FF” inserted as a result in the PSP Ram…
Now it doesn’t mean exploits through BMP files are impossible, but it makes them difficult. Of course, the “original” series of 41’s is maybe stored somewhere else in the Ram, unchanged, but that’s unfortunately not what we deal with in this crash, which makes it useless (if we can’t control all 4 bytes of an address, we’re pretty much screwed).
I don’t think Sony planned this as a security against hackers (they have lots of other tricks against hackers, but this one is probably just the “natural” way of displaying an image with no alpha layer), but it’s still a pretty good security
The conclusion is that if you are looking for vulnerabilities with images on the PSP, you shouldn’t use image formats that have no transparency layer. Forget about BMPs and Gif, and try to focus on PNGs and Tiffs. It worked in the past