SBORPS Random Fact 06

A nice hidden feature of the PSP firmware is the personalised credits screen. Just place any png picture under flash0:/vsh/resource/name_plate.png (important note: filename has to be all lower case) and it’ll show up in the System Settings -> About PSP menu. Make sure the pic is in the correct resolution (480 x 272) otherwise the PSP will stretch the image.

This feature was never documented by Sony but it has existed ever since the very first firmware v1.00. Sony typically used this feature to send personalised PSP’s as gifts to VIP’s. Now you can make your own personalised PSP too.

Posted in Random Facts | 4 Comments »

SBORPS Random Fact 05

SCE make typo’s too.

In the sceRtc lib I noticed an export sceRtc_029CA3B3 that was mapped to the same function that the export sceRtcGetAccumulativeTime was mapped to. Researching some more I noticed that sceRtc_029CA3B3 had existed ever since 1.00 but sceRtcGetAccumulativeTime was only added in 1.50. They are both mapped to the same function. I then realised that the cause of this might be because of a misspelling of the original function and that sceRtcGetAccumulativeTime was the corrected version added in 1.50.

So then, how to crack this NID.

It is not easy to try to guess a misspelling. A per-letter bruteforce would’ve taken too long so I simply tried the most common typo’s and, after many many permutations, I eventually guessed correctly:

• 0×029CA3B3 sceRtcGetAccumlativeTime (it’s missing a ‘u’)

This is not the only typo either. More than once they have spelt “register” as “regitser”.

• 0xDB9D28DD scePowerUnregitserCallback
• 0xDFA8BAF8 scePowerUnregisterCallback

And problems obviously stemming from the fact that the programmers are Japanese:

• 0xB795D2ED sceNandCollectEcc
• 0×88CC9F72 sceNandCorrectEcc

You’ll also notice that the old misspelled entry still exists even though a corrected version was added. The reason for this is for compatibility. Older apps had used the original misspelled function so the NID couldn’t be changed. This is somewhat fixed now that kernel NID’s are randomised in newer firmwares. There will only be one entry for each function now that the NID isn’t derived from the name of the function.

So, sometimes when it seems that an NID is impossible to crack it may simply be because of a stupid SCE typo :p.

Posted in Random Facts | No Comments »

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.

• 0×2DAD213D sceMgrDESEncrypt
• 0xF5DFD97B sceMgrDESDecrypt
• 0×8A916574 sceMgrAESEncrypt
• 0×3054F8F1 sceMgrAESDecrypt

The prototypes are as follows:

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

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 »

SBORPS Random Fact 02

All clocks used by the PSP hardware are derived from a single clock generator IC. It uses a single 27MHz input crystal (there are 2 other crystals, a 4MHz & a 32.768KHz, but is purely for the syscon chip) and can output the following frequencies:
- 37MHz (Spread Spectrum Configurable, used for CPU/PLL freq)
- 48MHz (used for USB freq)
- 27MHz reference (used for video clock on slim)
- 22.5792MHz (used for Lepton clock)
- 22.5792/24.576MHz selectable (used for Audio Codec IC, for audio freq 44.1KHz/48KHz)

The clockgen IC is accessible on the I2C bus on slave address 0xD2. It has 3 registers:
Reg0: Vendor ID/Revision Code Register
Reg1: Output Control Register
Reg2: Spread Spectrum Control Register

Special Note:
Why TA-082/086 motherboards ‘bricked’ on 1.50 was because the clock generator IC was from a different manufacturer on those boards and so had a different Vendor ID/Revision Code than on TA-079/081 boards. The 1.50 IPL doesnt recognise the new Vendor ID/Revision Code so it freezes (which caused the ‘brick’).

The Spread Spectrum Control register is configured depending on the revision, the 1.50 IPL only recognises revisions 0×4 and 0×8 of that IC, the new IC of TA-082 boards had a revision of 0xF. Interestingly, revision 0xF IC’s are supported starting from 2.00 so in all likelyhood TA-082/086 boards could be downgraded to as low as 2.00 without brick. The TA-082/086 boards do NOT ‘blacklist’ firmwares lower than 2.50 like some people have stated. It was NOT designed to ‘block out’ the 1.50 firmware.

So how come the TA-082 downgraders work then? The configuration of the clock generator IC is based on paramaters stored in idstorage key5 (header is “Clkg” – short for Clockgen). If key5 is corrupt the configuration of the clock generator is simple skipped altogether (only the header needs to be modified for the key to appear invalid – ie. if the header is not “Clkg” it is considered corrupt).

So corrupt key5 -> clockgen config is skipped -> 1.50 IPL continues to run.

EDIT: added some extra info on 1.50 downgrader

Posted in Random Facts | 5 Comments »

SBORPS Random Fact 01

I figured because this blog was SilverSpring’s Bunch of Random PSP Stuff, it needs more…well…random PSP stuff.

SBORPS Random Fact 01

SCE uses (intentionally) fake misleading names to protect the most important part of their firmware (ie. everything crypto related). The library & function names for their crypto modules are fake, take for example a library they named “semaphore”. What that library is, is a direct interface to the KIRK crypto engine. Or the function “sceUtilsGetLoadModuleABLength” (not a false nid btw), what it actually does is decrypt kernel prxs.

Posted in Random Facts | No Comments »