• a block cipher operating in CBC mode
• an all zero 128-bit initialization vector
• 128-bit block and key sizes
• cmd4/7 uses a static key that is identical in all PSP's
• cmd5/8 uses a key based off the fuseID making all operations unique per PSP
• cmd6/9 uses a user-defined 128-bit key
• cmd1/2/3 uses the block cipher but also signature algorithms
• the remaining KIRK cmd's do not use the block cipher (sig, hash, & prng algo's)

Interfacing with KIRK for general-purpose encryption is cumbersome and using a software-based lib is both slow and memory-consuming. Fortunately, there is another method: using the MagicGate hardware. The API provides both standard DES and AES algorithms.

• 0x2DAD213D sceMgrDESEncrypt
• 0xF5DFD97B sceMgrDESDecrypt
• 0x8A916574 sceMgrAESEncrypt
• 0x3054F8F1 sceMgrAESDecrypt

The prototypes are as follows:

• 0x5e335df6 sceHVAuthOpen
• 0x816a5f92 sceHVAuthAuth
• 0x9db7de7c sceHVAuthClose

The sceHVAuth lib seems to be used for proxy config settings for the Html Viewer.

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).

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" (0x5 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"

Here's a compatible replacement:

EDIT:
Finally cracked the real names:

0x68ef0bef sceSysconBatteryReadNVM
0x1165c864 sceSysconBatteryWriteNVM

Here is the code to generate the hash for these particular keys:

Note: this is a PC app (though you could run it on the PSP as well if you wanted).

To use just place an encrypted IPL as enc_ipl.bin in the MS root. It'll decrypt it and save as it dec_ipl.bin.

NOTE: the same decryption routine can also decrypt prx's, though they need to be setup first before being passed to the crypto engine (ie. the prx header needs to be descrambled with its decryption key first). I might write up a quick sample to do that later.

Anyway, enjoy and I hope you'll find this useful...

EDIT: this is for 1.50 Kernel

Download link: IPL Decrypt Sample (direct HW access)

Admin note: The issue with the captcha not working has been fixed. Sorry for any inconvenience caused. -EvilSeph