View parts of memory on PSP

[VeggieGames]

I was playing with the .SFO files and noticed that they do not do range checking on the offsets for the variable values. If you set the offset for the TITLE variable to a number beyond the end of the file it will display whatever is in memory at that address on the screen in the game browser (as a null-terminated string). If the memory access causes a fault the system will power off (no harm done).

I don't know how useful this will prove as it displays a maximum of 20 characters and there is no address consistency as the addresses you enter are offsets from wherever in memory the data happened to be loaded. It might be good for some memory sniffing though.

The specific place in EBOOT.PBP that you would change is the 4 bytes at position 0x98 (the original value is 0x00000018, change it to anything). To make the PBP file a more managable size for this purpose you can crop it at offset 0x3251 (where it says "~PSP"... don't need the executable because it won't be executed). Put the file on the PSP memory card in \PSP\GAME\UPDATE, then go to Game -> Memory Stick in the PSP menu and press X. Right there as the title you will see the memory contents... if there is no title that means the data at that address is zero.

[ooPo]

Hey, that's kinda nifty. Good find. :)

[charlie]

Hello. I'm fairly new to these boards, and to reverse engineering. Reading Hacking the Xbox and browsing these forums to learn. From what I have gathered, the firmware update is downloaded to MS, where it is decrypted and put into memory to be run when the actual flashing takes place, right? Then with this memory sniffing technique, couldn't one or maybe a lot of people collaborate together to piece together the program that updates the firmware while it is in RAM?

[TerryMathews]

If someone can make this hack read out the contents of the memory @ address 0, we might be able to start disassembling forward...

[Shine]

From what I have gathered, the firmware update is downloaded to MS, where it is decrypted and put into memory to be run when the actual flashing takes place, right?

You are assuming that the firmware is saved unencrypted in the flash. Looks like the PSP has an AES encryption hardware built-in:

http://pc.watch.impress.co.jp/docs/2003 ... aigai1.pdf

This is used at least for communication with UMD. And if I were Sony, I would use it for the boot process, too. Perhaps it looks like this: The main CPU has some embedded flash for the AES keys and for a small boot loader, which loads and decrypts an initialization program from flash (this could be even more plausible, if the access to the NAND flash requires setting up some command registers before reading, like in Intel NAND flashs). The rest can work like in PS2: In the flash are libraries in ELF format, which are loaded when needed, but anything is encrypted on flash. I don't think that the DRAM is encrypted, because this would be too slow for random access, but loading libraries and other streams could be encrypted without slowing down the system.

Then with this memory sniffing technique, couldn't one or maybe a lot of people collaborate together to piece together the program that updates the firmware while it is in RAM?

With the memory sniffing technique you can read memory and perhaps even address 0, if the offsets are 32 bit and wrapped-around (perhaps could be tested with binary search for some large offsets until it doesn't crash, which means it has accessed real memory instead of producing an memory access failure). But how can you write something to the memory with this technique? If it is real secure, reading memory may help to understand the hardware a bit better, but if there are some private/public key algorithms implemented, it doesn't help in creating own encrypted PSP files, even if you can read the public key for decrypting the flash. Then only Sony can create encrypted program files (save-game files and wireless transfers could use other private/public keys for encryption). But it may help to have an unencrypted flash for writing programs, which can be executed by a buffer overflow or something similar.

[XenuPSP]

I was playing with the .SFO files and noticed that they do not do range checking on the offsets for the variable values. If you set the offset for the TITLE variable to a number beyond the end of the file it will display whatever is in memory at that address on the screen in the game browser (as a null-terminated string). If the memory access causes a fault the system will power off (no harm done).

What game / how are you doing this? When I muck around with a PARAM.SFO file for Untold Legends, it comes up as "Corrupted Data" when I go to Game -> Saved Data Utility.

[mrbrown]

If someone can make this hack read out the contents of the memory @ address 0, we might be able to start disassembling forward...

If the kernel/browser is setup anything like the PS2, then the browser runs in user mode and can't access address 0.

[nanoscopic]

I fiddled around with this... and it is interesting but not really useful, because the PSP does not render much of the characters. Most characters aren't even show at all. (as stated by Darkfader in chat)(also a problem that should be obvious)

So, I figured I would try to map out what bytes ARE mapped to something. In the process of doing that I noticed something sort of interesting... there is in fact an 'escape' character. Well, there seem to be too. Both 0xE2 and 0xE3 both seem to be escape characters to map to ?unicode?. That is how the TM characters is created as well as the japanese letters.

What I don't understand is why the system only reads in 20 characters. Looking at the file, it is clear about 60 or so bytes or provided for each language...

I also realized you can make as many folders under the game folder as you want, named whatever, and they will all list in the psp. Anyways; that is my two bits for now.

[mc]

I noticed something sort of interesting... there is in fact an 'escape' character. Well, there seem to be too. Both 0xE2 and 0xE3 both seem to be escape characters to map to ?unicode?. That is how the TM characters is created as well as the japanese letters.

RTFM UTF-8. :-)

What I don't understand is why the system only reads in 20 characters. Looking at the file, it is clear about 60 or so bytes or provided for each language...

Presumably they figured that 20 was about how many that would fit on the screen without making it multiple lines.

[nanoscopic]

Ok, so I didn't RTFM on UTF.... whatever.

Presumably they figured that 20 was about how many that would fit on the screen without making it multiple lines.

Only 0x0A (normal old LF) makes multiple lines just fine.