Very odd PBP quirk

pdc · Post by **pdc** » Sat Mar 26, 2005 10:05 am

OK so it's not as useful as having cracked the encryption but...

I've been looking at the PBP file tonight, looking at the structure, manually extracting, adding files, etc.
(It's been a long time since I've been into anything technical so I'm enjoying this opportunity to get tinkering and learning again!)

I decided to try messing with the PNG within the PBP.
(This is the preview display picture for the update)
Trying things like removing the IEND tag and duplicating the IHDR tag.
One attempt had a very strange outcome....

The preview does not render the PNG. I must assume it can't.
However, the PSP does not give up;
Rather, it grabs JPEGs from /PSP/PHOTO/ and displays a jumble of those instead, in a strange collage with transparency dividing the squashed JPEGs!
Stranger still, this 'new' preview pic is different when highlighted/unhighlighted if there is more than 1 bootable item on the mem stick and if you have too many JPEGs, the pictures may 'spill' onto the next preview item!

Why the PNG is replaced by a bunch of JPEGs, I don't know...!
It's about the oddest thing I've seen yet though.

I thought it was strange enough to share with you :)

http://pdc.me.uk/psp/odd_pbp/
for the curious.

Also, this is anything but secure - whatever it is trying to do!

Guest · Post by **Guest** » Sat Mar 26, 2005 12:50 pm

I vote this being the coolest psp bug/quirk found so far. ;)

pdc · Post by **pdc** » Sat Mar 26, 2005 6:52 pm

gorim wrote:I vote this being the coolest psp bug/quirk found so far. ;)

I think so!

The PBP handler should be as self-contained as possible and for it to go randomly grabbing pictures off the memory stick is not good!!

I will look more into this later - try putting PNG files with .JPG extensions in /PSP/PHOTO/, etc and also see if the same bug exists if this messed-up PNG is used as ICON0.PNG for a savegame.

Anyway, this just defies all logic.
Can anyone explain why this might happen?

Guest · Post by **Guest** » Sat Mar 26, 2005 7:10 pm

I am told I am good at theories. ;)

I think you said you removed some marker for the end of the image ? I wonder if the PSP uses such low level read routines that they do not pay any attention to any "end of file" marker, and keep on reading into the next contiguous area of data on the memory stick, which naturally could include other files ? Just one possibility, but very cool indeed.

Agntneo · Post by **Agntneo** » Sat Mar 26, 2005 7:14 pm

This is very interesting, why the hell would it suddenly start grabbing JPEG images from PSP/Photos?

Very interesting ,yes this is probably the biggest flaw we've found yet.
I think I will fool a bit around with this myself and see what outcome I get.

Thanks :)

Awhite · Post by **Awhite** » Sat Mar 26, 2005 7:52 pm

Lol that the coolest bug :P

Hey try to remove some of the hex code inside of the PBP file, beause it's not needed if you want to play around only with the PNG file.For god's shake 13mbs are 13mbs :P

You can take a look at my Monkey island "loader" it's only 128kb :P

pdc · Post by **pdc** » Sat Mar 26, 2005 9:45 pm

gorim wrote:I am told I am good at theories. ;)

I think you said you removed some marker for the end of the image ? I wonder if the PSP uses such low level read routines that they do not pay any attention to any "end of file" marker, and keep on reading into the next contiguous area of data on the memory stick, which naturally could include other files ? Just one possibility, but very cool indeed.

No.
The PNG is very early in the PBP file. If it just carried on reading data, it would be reading 'PSP' and 'PSAR' files inside the PBP.

It is looking inside /PSP/PHOTO/
If you rename /PSP/PHOTO --> /PSP/PHOTO2 it will display a blank (transparent) preview.
It will only grab JPEGS from "/PSP/PHOTO/"

What I did, IIRC, is duplicate the IHDR tag (putting the 2nd one in the middle of the PNG) and subtly change a few hex values.
Of course, the 'compare' function is your friend :^)

@Awhite, it's no problem editing a single file within a PBP and it doesn't take much for the PSP to consider the archive 'corrupt'. I expect the PNG is the only file within the PBP which Sony didn't consider needs to have great security. It can just be passed to the PNG decoder.

pdc · Post by **pdc** » Sun Mar 27, 2005 3:51 am

OK, I can confirm that the picture is not a mix from /PSP/PHOTO/
(let's face it, this seemed far too random)
but it is actually being read directly from the PSP's memory.

I imagine the update preview pic is reading from memory where the PNG decoder should have put the icon. Only the PNG decoder did not successfully decode.

The transparent parts must be non-image data in memory.

Also, after playing Ridge Racers, the preview pic reads RR game data.

Edit: Now if we could only get this as a text/data output, it would be quite something!!
Perhaps we need to wait for the PSP web-browser then maybe we can save this data? I can't think how else to retrieve the data at this time.

florinsasu · Post by **florinsasu** » Sun Mar 27, 2005 9:29 am

pdc wrote: I imagine the update preview pic is reading from memory where the PNG decoder should have put the icon. Only the PNG decoder did not successfully decode.

true. if you go to pictures and select one, then back to the dodgy update you'll have a part of the last picture/thumbnail(s) seen. Of course since the width and height do not match you'll have 16 pixels bands displayed wrong. Try see in the photo section only the thumbnails and then go back.
It's obviously that you get displayed the last correctly decoded (jpeg) image area and the png decoder fails.
Also, the png files from saves do not alter the area displayed by the update.

pdc · Post by **pdc** » Sun Mar 27, 2005 9:46 am

florinsasu wrote:
pdc wrote: I imagine the update preview pic is reading from memory where the PNG decoder should have put the icon. Only the PNG decoder did not successfully decode.
true. if you go to pictures and select one, then back to the dodgy update you'll have a part of the last picture/thumbnail(s) seen. Of course since the width and height do not match you'll have 16 pixels bands displayed wrong. Try see in the photo section only the thumbnails and then go back.
It's obviously that you get displayed the last correctly decoded (jpeg) image area and the png decoder fails.
Also, the png files from saves do not alter the area displayed by the update.

Yes, I realise this. This is how I figured out it is reading from memory.
I don't understand why the savegame PNGs do not alter this space in memory though.
Pictures inside MP3 tags do alter it. I'm not sure what format these are in.

Anyway, I am almost out of ideas on how to turn this into a worthwhile exploit.
I tried making the PNG 32MB so that the PSP ran out of RAM but this had no effect.

If we had an official Sony PSP browser then maybe we could use this exploit to pipe PSP memory into the page and then "Save Image As..." to get the memory.

Making the PSP output it's own memory is quite interesting and it's a shame it seems to have hit a brick wall.

florinsasu · Post by **florinsasu** » Mon Mar 28, 2005 6:08 am

anyway, nice work pdc :)
i'm sure that are more bugz and eploits... ready to be discovered.
it's quite hard to protect perfectly such a device. with code written by various ppl and even with external library code.
and, those programmers from sony are not any genius, i can tell you that ;)

Shine · Post by **Shine** » Mon Apr 04, 2005 12:48 am

pdc wrote:If we had an official Sony PSP browser then maybe we could use this exploit to pipe PSP memory into the page and then "Save Image As..." to get the memory.

If it is a monchrome picture, it should be possible to write a program which converts the data from a scanned image. With a 1200 dpi flatbed scanner you can see single pixels:

Perhaps you get better results with better scanners and without the front glass. With a little soldering for the PSP keys and connecting it to the parallel port of a PC and a script it should be possible to automate scanning the whole memory. For 8 MB RAM you need 490 scans, which needs 8 hours with one scan per minute.

Fluff · Post by **Fluff** » Fri Apr 22, 2005 10:08 am

i was messing around with this idea, what i did was move the png header further down the file, and change the content of the png leading up to the new header location, to 00
and now the file has a very specific icon which sort of reminds me of the 1.5 update icon, possibly using a 'default' icon from the psp itself for pbp's that dont have a specific icon image?

anyway heres what it looked like

ChaosKnight · Post by **ChaosKnight** » Fri Apr 22, 2005 11:49 am

I seem to remember someone else having a similar experiance on this board. If memory serves it has to do with the PSP not really validating the the offsets for files in the PBP. Therefore you can do all sorts of fun things like display text in memory or display other graphics which are residing in the graphic memory.

Fun trick though, I've never done it myself, so it's nice to see some screenshots.

pdc · Post by **pdc** » Fri Apr 22, 2005 8:30 pm

@Fluff - that 'default' image just means the PNG was detected to be invalid or missing.

@ChaosKnight, I suspect you are referring to http://forums.ps2dev.org/viewtopic.php?t=1326

Fluff · Post by **Fluff** » Fri Apr 22, 2005 10:59 pm

pdc wrote:@Fluff - that 'default' image just means the PNG was detected to be invalid or missing.

Maybe not for invalid, when the png is invalid or damaged, the image is of diagonal white, lightblue and dark blue lines in a blocky formation but the eboot file still runs, however if the programs totally corrupt the image is of a little X

doesnt really help matters but intresting none the less

th0mas · Post by **th0mas** » Sun Apr 24, 2005 2:06 am

Hi. I'm new here.

Anyways.. just thought I'd share a brainstorm I had while reading this..

does the wipeout browser react the same to malformed PNGs as does the modified PBP file?

(ie, can we inference they're running the same PNG loading library?)

pdc · Post by **pdc** » Sun Apr 24, 2005 4:43 am

th0mas wrote:Hi. I'm new here.

Anyways.. just thought I'd share a brainstorm I had while reading this..

does the wipeout browser react the same to malformed PNGs as does the modified PBP file?

(ie, can we inference they're running the same PNG loading library?)

roto was good enough to test this for me - the PNG displays as an empty box with a red cross inside it (i.e. "invalid PNG").

The PNG library/decoder isn't the problem, but the PBP handler is reading the memory space where the PNG decoder should have written to.

IIRC, using this PNG as a savegame preview simply displays the default 'Invalid/Missing PNG' image.

th0mas · Post by **th0mas** » Sun Apr 24, 2005 8:23 am

ah, so someone forgot to check the PNG decompression call for success and assumed their buffer got filled. interesting.