SBORPS Random Fact 10

Support for NAND flash IC’s from Hynix has been added to the NAND driver. Specifically, three extra models from 1.8V family:

These are probably used for PSP GO models. The PSP now supports NAND’s from Samsung, Toshiba, ST Micro, and Hynix.

Posted in Random Facts | No Comments »

SBORPS Random Fact 09

Been awhile since my last post, been quite busy with other stuff (read ‘real life’). I’ll be posting more stuff from now though.

After searching for any new supported resolutions for the LCD controller I found a strange one (added in 6.xx):

Don’t know why it is missing one single row from the usual 720×480 resolution.

Here’s the full list of supported resolutions:

If you are wondering how the PSP can support resolutions higher than it’s native screen resolution of 480×272, it’s because the LCD controller needs to support PSP devkits as well which have VGA output to connect to an external LCD monitor.

Posted in Random Facts | No Comments »

SBORPS Random Fact 08

To find out the PSP model your code is running on you can call the function sceKernelGetModel(). People have been using it in homebrew to differentiate between 01g and 02g machines (fat and slim) to determine what their app will do depending on the model the user is running.

However, the sceKernelGetModel function can do a lot more than just determining whether you’re running fat or slim PSP, it can return values for:

That’s three more models after the PSP GO! As well as a 4000 model after 3000.

The fw for 04g models is already out, it’s included with normal fw updaters (6.xx) and can be decrypted using the 3K keys. There’s also code already in the fw supporting 06g and 08g models (which seem to be GO-like models).

So for people thinking the PSP GO was a waste of a update or there wouldn’t be any more updates, prepare for three more models…

Posted in Random Facts | 6 Comments »

SBORPS Random Fact 07

Beware of future fw updates, SCE are starting to make activity logs.

New registry categories/keys stored in flash1 registry (6.xx fw):

These new registry keys can still be accessed via the sceReg API, sceRegOpenCategory/sceRegGetKeyValue etc.

What other things will they be tracking in future updates? Maybe logging ISO games? Secretly ‘phoning-home’ with this info? Was any of this mentioned in the EULA?

Posted in Random Facts | 3 Comments »

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:

• 0x029CA3B3 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
• 0x88CC9F72 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.

• 0x2DAD213D sceMgrDESEncrypt
• 0xF5DFD97B sceMgrDESDecrypt
• 0x8A916574 sceMgrAESEncrypt
• 0x3054F8F1 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 »