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

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 720x480 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 480x272, it's because the LCD controller needs to support PSP devkits as well which have VGA output to connect to an external LCD monitor.

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

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?

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.

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.

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

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)

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 0x4 and 0x8 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

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.