Disclaimer: We have given up on jumping into VRAM at this time due to the belief that the alpha bits in VRAM are always 0, or something else funky that is beyond our control. So when I am talking about images and memory in this post, I am referring to regular old application memory space, not VRAM.
System Settings -> About PSP
Notice the last screen... libtiff is being used for TIFF functionality in the Photo Viewer (the browser will not display TIFF).
Notice this, a confirmed overflow in libtiff:
"The libTIFF library is vulnerable to a buffer overflow, potentially resulting in the execution of arbitrary code."
Yay. Follow the LIBTIFF BUG#863 link at the bottom to get to a page that hosts the problem TIFF file.
Save and download the TIFF to PSP/PHOTO, and view it. It crashes. Probably the vulnerable version of libtiff!
Thanks to a certain someone on IRC who pointed this out (he didn't care to receive any "street cred" -- good for him).
Now. I have found that very large (like over 5 MB, maybe even much more -- test) UNCOMPRESSED (this is important for preserving our machine code) TIFFs are able to be loaded into the photo viewer. This got me very excited as the image lies somewhere between 0x08800000 and 0x09ffffff user space memory (24 MB). Hitting somewhere near the beginning of a crafted TIFF that large sitting in user space memory full of noops with the machine code (which draws a bunch of pixels on the screen) referenced at
at the end via buffer overflow shouldn't be that hard (should only take ~ (24 MB / ~ 5 MB tries)) if the vulnerability exists (certainly appears to... but as I've found with pursuing these things thus far... appearances can be decieving).
Now let's talk about the challenges:
1. The image data in the Photo Viewer appears to be managed in a very peculiar way. Even when viewing small files, the memory card is accessed when scaling/scrolling. Why? Any guesses (let us know)? When you rotate large images, regisions at the edge appear to be lower quality. I think all of this is indicative of the fact that all of the image data is not in memory at once, but rather being loaded in and out of system memory all the time. Maybe this is just some property of the graphical calculations they are doing? For example... when you open an uncompressed image, why does it appear to have a "2-phase" load? If large images were to be stored contiguously in memory the hack (if the vulnerability exists) just becomes easier to pull off. What do you guys think about the strange behaviour of the Photo Viewer?
Worst case, I'm pretty sure loaded a natively sized 480x272 image does result in a normal image buffer somewhere in memory (unless Sony did some crazyness and thought of all of this ahead, and uses two buffers or something. In that case the hack should still be workable if it's the vulnerable version of libTIFF if we come to an understanding of how the image data resides in memory. The libpng bug was reported in May, so it's possible Sony did something quick to patch it -- but the fact that it crashes the PSP would suggest otherwise).
2. Someone should write a program that will take as input a file (this could be an image, an eboot, whatever), a directory_name (PSP/PHOTO), an offset, 4 values (decimal or hex representing the address we want to override the return address on the stack with), and a num_times value representing the number of times to write the sequence of 4 bytes to the file. The program would then spit out the modified file (prob. an eboot or image) to directory 0/directory_name/. The program could then loop and dump the same file, except that the address we would use for this one would be [the desired RA given before - sizeof(file's payload -- excuse me... this would be another parameter)] to 1/directory_name/. So forth and so on until the RA argument reaches the bottom of user space (0x08800000). This was written quickly... but the idea is to generate the dir. tree (with a bunch of diff. generated files) up front (test files) so that testing can be more manageable/it will be less likely we will miss something. Then you just have to choose a decent starting address value and you can spend some time testing if you land in the image.
Also note that to get the PSP to crash at the right time (as in, with another image in memory with our machine code in it because I'm not sure if the image that crashes' image data gets loaded in before the crash just from previewing alone (which will crash)) with the image from the Bugzilla site you have to write it to the memory card FIRST (it will then be processed last by the viewer preview menu), then write a bunch of legit images to the card, and then the image with the exploit code in it (this image can actually be whatever format you want... uncompressed PNG or uncompressed BMP or uncompressed TIFF). So you put enough on there that it won't crash during preview... you open the image with the custom code in it... you choose slideshow... and it will parse a bunch of images (including the overflow one, and crash). Because you did it this way, the image with the custom code (diff. than the one that causes the overflow) should be in memory and have preserved byte code (if you made a 480 x 272 image that goes into one big memory block).
3. I don't know if the historyi.dat extension thing is an overflow (very well could be though!). Looks like one (visually), but then so have a lot of things so far. I was pursuing this before I was informed of the libTIFF bug. The nice thing about crashing the browser with that historyi file is that if its an overflow, the browser does grab large blocks of contiguous memory for large images (I don't think Photo Viewer does), which makes it easier to guess where to jump in user space memory to land in the image buffer. To get it to crash with your image in memory, put the massive historyi file on your memory card. load the browser with the memory card OUT. load the image from memory card. put in memory card. open address pane, go to history. kaboom.