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 0×08800000 20000000000 memdump1.bin

the 0×08800000 is the start of what we want to dump. 0×08800000 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 ;)

  1. eric’s avatar

    failure can make success.


  2. Darren cola’s avatar

    hey look i am a noob and i accedently found a way to crash the psp using the BMP file without Clicking on!! i was hoping it might help you hack the psp version 6.10 faster first download these to files at http://www.sendspace.com/file/6lg0d0 then uncompress the .rar file and put both files into the psp\photo on the psp. after that go to crash exploit let all of the chickhen.gif photos run then go to chickhend.gif and click on it, let it oad then exit out and go to exploit101 and click on it and wait for 4 sec. then the psp should crash after it loads all of the chickhen files plus the crash it.bmp file. i dont know why it does this but it just does…. so i hope it will help you hack the psp faster. and maybe you can show the chickhen team and they can use it to hack the psp faster since it uses there files to do it!!


  3. Darren cola’s avatar

    please comment if you read the comment above and tell me how you feel!!!


  4. Darren cola’s avatar

    oh yea and it wont work if all of the pictures are already loaded


  5. Darren cola’s avatar

    here are some other crashes i have created maybe you guys can use these to hack the psp.http://www.sendspace.com/file/2xvv0d and alsohttp://www.sendspace.com/file/tn6flf i dont know it the crash is the same or not tho. but just do the same thing i told you earlier


  6. Doublehawk’s avatar

    Hey wololo, malloxis has yet again found something interesting. I have no idea if its exploitable or not (its a tiff file again) Could you check it out?
    Thanks in advance, and your website is just awesome btw.


  7. wololo’s avatar

    Yep, he contacted me already, I’ll have a look at his files


  8. wololo’s avatar

    I checked, the file that causes the crash in malloxis’ files is a BMP renamed as a TIFF, with extra crap in the headers. It won’t lead to an exploit for the reasons explained in this page


  9. n00b81’s avatar

    Looks like Malloxis watches this blog closely. Once you put up this post, he came up with his nice fake exploit.

    Jeerum’s BMP simply renamed as TIFF….




  10. wololo’s avatar

    Yeah, this is sad…


  11. jeerum’s avatar

    :D i like wololo blog!
    sad that malloxis have made fake file – i have trusted him :C
    but wololo have you tested this image pack?
    Maybe its same crash as play mp3 and open bmp, but different way.


  12. H@lo World’s avatar

    It´s very difficult to find an tiff exploit
    Sony have done good work…


  13. H@lo World’s avatar

    Has someone ideas for a new tiff exploit?


  14. jeerum’s avatar

    we have done good work, not sony :)


  15. Yoshihiro’s avatar

    Heyy wololo the a1 code from the .bmp of jeerum start at the offset 0x8A in the BMP if that can help ya cya


  16. wololo’s avatar

    You love enigmas :D
    I’ll have a look


  17. Rios’s avatar

    Hello Wololo, I am an Italian boy, I read your article entitled “Looking for vulnerabilities in the PSP Firmware”, “Finding gamesaves exploits on the PSP” and “Why We Can’t easily find exploits in BMP images”.
    I found these very interesting and I thought that if you give me permission, I might be translated into Italian and published on PSPrl.it in order to bring Italian users to an argument that in our native language is superficial.

    Sorry for my bad English, and thank ‘s for the attention.


  18. wololo’s avatar

    @Rios: no problem at all as long as there is a link to the original articles in your translation :)


  19. Rios’s avatar

    Obviously, it will be the source and the author, thanks for the availability and the permission.


  20. RoxFox64’s avatar

    Well, what about the general vulnerability with the BMP format to begin with?
    If you take a look at the BMP documentation the actual reading of the image data STARTS at an offset specified at the beginning of the file. Couldn’t you insert some code in before the image data and work from it?


  21. Protoph’s avatar

    I don’t know if this is a PSP difference (as, I don’t have one) but I’m fairly certain that bmp files can have an alpha channel. I needed to do some simple pattern matching with .jpg files and did so by converting them to .bmp and I remember having to ignore the alpha channel and skipping to next pixel by adding 4h.

    Wikipedia page on .bmp files says that the alpha channel is present on bitmaps with the (win95 or newer) ‘BITMAPV4HEADER’ header.


  22. EdrickV’s avatar

    16-bit and 32-bit BMP files can contain alpha channel values. And the PSP can view a 32-bit BMP file that has alpha channel info.

    Whether it actually uses the alpha channel info or not is another story. (It might just insert FF’s instead since transparent bitmaps aren’t something it officially supports.)



Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>