SBORPS Random Fact 04

SCE media reports have always stated that the PSP has AES capabilities. These are apparently referring to the fact that the UMD format discs are AES encrypted. This means that SPOCK (the crypto engine responsible for UMD decryption) has AES decryption capabilities. KIRK on the other hand (the main crypto engine responsible for prx/eboot decryption) also has a block cipher but is unknown which algorithm it uses, though it is almost certainly AES as well. Currently what is known about the cipher is that it is:

• 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:

Posted in Code Snippets, NID's, Random Facts | 4 Comments »

sceHVAuth_Library

Some new nids:

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

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

Posted in Code Snippets, NID's | 1 Comment »

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 »

3.80 and Pandora

Well it looks like SCE have finally learned and have now removed the functions to read/write to the battery eeprom in 3.80 (they also took out the sceSysconBatteryAuth function too). So you can’t make a magic battery with 3.80, but nevermind, the hardware to do so is still there.

Here’s a compatible replacement:

EDIT:
Finally cracked the real names:

0x68ef0bef sceSysconBatteryReadNVM
0x1165c864 sceSysconBatteryWriteNVM

Posted in Code Snippets | 6 Comments »

Idstorage Keys (0×0004-0×0008) – Generating hash

The idstorage area stores low level info on the PSP. Keys 4-8 are used for config data for various components (the battery, clock generator, LCD, etc.) and are in a different format to all the other keys.

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

Posted in Code Snippets | No Comments »

IPL Decrypt Sample (direct HW access)

Since this place is pretty bare right now here’s a quick sample I wrote up demonstrating how to access the KIRK crypto engine directly to do your decryption. Doing raw hardware access means you dont need to access any of the SCE crypto API’s such as the semaphore lib (memlmd.prx).This is useful for the future since no matter how much SCE change the libs, nids, etc. The HW remains the same so it will work in all future firmwares (until new PSP motherboards are developed). Might be useful to add to PSARDUMPER since PSARDUMPER still rely on the SCE crypto libs and SCE may change the nids in the future and other stupid stuff like that.

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

Posted in Code Snippets | No Comments »