SBORPS Random Fact 03

Why doesnt PSAR Dumper dump the IPL in 1.xx updaters?

Simple, the IPL was not stored in the PSAR. In 1.50/1.51/1.52 updater EBOOT’s, the IPL is stored embedded in the ipl_update.prx which is encrypted and embedded in the updater app itself (DATA.PSP) which is also encrypted.

Starting from 2.00 the IPL was taken out of the ipl_update.prx and stored inside the DATA.PSAR along with the rest of the firmware which PSAR Dumper can then extract.

Then what about IPL’s from 2.60+ updaters which PSAR Dumper can extract but cannot decrypt? Well starting from 2.60 an extra step was added to the IPL decryption process which used the PSP’s preipl as a decryption seed. The preipl is unavailable to apps by the time the firmware has booted so it cannot be accessed while PSAR Dumper is running to complete the decryption of the IPL, and including the preipl binary in the release of PSAR Dumper would be a big no-no.

So PSAR Dumper can really only dump & decrypt the IPL from three updates: 2.00, 2.01, & 2.50.

Related to this topic is the bogus 1.00 updater which was accidently made available to the public on SCE servers when they were testing out the Network Update feature. Because this update was not a retail update and only for devkits, running this updater on a retail PSP resulted in a brick. The reason is, devkits do not boot the IPL off the nand so this updater did not include an IPL (there is no ipl_update.prx)

Posted in Random Facts | No Comments »

NAND set_encryption_seed NID (last remaining sceNand nid)

Sometimes it’s the most obvious names that are the hardest to guess (as was also the case with sceSysconBatteryReadNVM):

0x0BEE8F36 sceNandSetScramble

That finally completes the sceNand lib !!

This is used to set the encryption seed for lfat decryption (on 3.00+) and for idstorage (on slim). After correctly setting the seed, all (per-page) reads to the nand will be read decrypted (otherwise raw reads to the nand will just return rubbish).

So, how to calculate the correct seed? For slim idstorage area it is pretty straightforward:

The 64bits stored at hardware register 0xBC100090 is unique for every psp (it is some sort of id or serial). Hence why nand dumps are also unique between psps (for 3.00 onwards).

For lfat area, things get slightly more complicated to derive the correct seed however is still based on the unique 0xBC100090 register. Maybe will come later then we’ll finally have a logical restore for slims (instead of a relatively dangerous physical restore).

Posted in Code Snippets, NID's | No Comments »

UMD Firmware Version checker

Here’s a quick & dirty sample to dump some info regarding your UMD Firmware.

http://silverspring.lan.st/umd_ver_check.rar

It’s a 3.xx app (source included), works on both slim & fat.

Will dump a file called umd.bin into root of MS.

In it will say something like:

SCEI UMD ROM DRIVE 1.090 Oct18 ,2004

Your UMD FW version will be at least 1.090 or above unless you have an early batch 1.00 JP model AND you have never used an official SCE updater (note: downgrading your normal psp fw version wont downgrade the umd fw version – so downgrading back to 1.00 wont work).

For another reference, here is one from pretty recent JP slim (came with 3.72):

SCEI UMD ROM DRIVE 1.240 Nov10 ,2006

Also there are a few numbers before this string appears but I couldnt figure out what they represented.

EDIT:

Ok, so the data is just in the standard ATAPI INQUIRY data format.

So:
- the drive reports to the host as a “CDROM Device” (0×5 in the Device Type field).
- that the medium is removable (RMB bit set to 1).
- is not standard in either ANSI/ECMA/ISO (all set to 0)
- Response Data Format (2)
- ATAPI Transport Version (3)
- Vendor ID is “SCEI”
- Product ID is “UMD ROM DRIVE”
- a blank Product Revision Level
- Vendor Specific info “1.240 Nov10 ,2006″

Posted in Code Snippets | No Comments »