PSP LibDoc update

Another large update to the libdocs: http://silverspring.lan.st/update.html

Finally added the 4.05 firmware and updates to 1.50 and 3.52 only.

Some of the more noteworthy NID’s include:

• 0x96cfac38 sceDisplayGetBacklightSel
• 0xe55f0d50 sceDisplaySetBacklightSel

Newer method to get/set the brightness levels.

• 0x42f954d4 sceIoAddHook

This is the function used to implement the CipherIO system (the cphio pseudo IO driver) used by things such as the DNAS IO lib as well as other DRM libs. It hooks the IO functions to be able to implement cipher routines which can then used by simply calling ioctls of this pseudo IO driver.

• 0x19d579f0 sceOpenPSIDGetPSID

Note, this is NOT the same as sceOpenPSIDGetOpenPSID, plus this is a kernel-only export.

• 0xe7735df4 sceUsb1SegEEPROMParamRead
• 0xa68a6c72 sceUsb1SegEEPROMParamWrite

Access to the EEPROM of the 1Seg TV Tuner.

• 0xc72ed6d3 sceUsbCamEnterFwUpdateMode

Updating the USB Camera firmware.

• 0xf9ecfddd scePcactAuth1BB
• 0x08bb9677 scePcactAuth2BB
• 0x8523e178 sceMlnpsnlAuth1BB
• 0x6885f392 sceMlnpsnlAuth2BB

Yes another DRM api.

There are plenty more NID’s of various usefulness as well. In general, this was quite a good update, lot’s of great NID’s were cracked.

Posted in NID's | 3 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 »

PSP-3000 (03g) a step closer to reality

The new PSP-3001 model (03g PSP) has been submitted to the FCC for testing:

https://fjallfoss.fcc.gov/oetcf/eas/reports/ViewExhibitReport.cfm?mode=Exhibits&RequestTimeout=500&calledFromFrame=N&application_id=290118&fcc_id=’AK8PSP3001

This means the new PSP-3000 model should hit retail shelves soon. Though there have been plenty of clues for months & months now, from unused nids referencing new hardware devices, a reference to a “03g” model in the IPL, that “3000″ graphic on the official Sony site, and most recently, alleged pics of a prototype.

Now it’s just a matter of waiting for the official announcement and the official list of changes. Hopefully some of the rumours that have been floating around turn out to be true (the hard disk drive comes to mind).

With the new PSP-2000 TA-088v3 model that is out now that is completely Pandora-proof you can bet the PSP-3000 will also be completely Pandora-proof. Im sure there would be plenty of people who would only want to buy a hackable PSP-3000. Though you can be sure that when this new model gets here we will all be looking thoroughly for new hacks for it.

[Waits patiently for the PSP-3000...]

Thanks to Poison for tip.

EDIT: 21st August 2008

Well it seems it has been officially announced now and the current official changelist really is disappointing. Let’s hope there are still more changes yet to be announced. Otherwise, it’s quite a disappointing model (and no doubt Pandora-proof as well). Oh well, won’t stop us from trying to hack it still .

EDIT: 15th October 2008

Now that the PSP-3000 has been released it has unfortunately been confirmed that this model is indeed Pandora-proof (as expected). No extra features apart from what had already been announced. So no HDD, GSensor, Bluetooth, or USB Host on this model (even though these features are supported by the firmware). May have to wait for a PSP-4000 then…

[Waits patiently for the PSP-4000...]

Posted in Uncategorized | 5 Comments »

NID’s – SCE trickery & fake names

In a previous post http://my.malloc.us/silverspring/2008/02/18/sborps-random-fact-01/ I wrote about SCE using fake names for their functions especially for their crypto libraries.

Here is another classic example, from the sceChnnlsv lib – the savegame encryption library (chnnlsv is also a meaningless jumble of letters just like the names of the other crypt libs):

• 0xe7833020 sceSdSetIndex
• 0xf21a1fca sceSdRemoveValue
• 0xc4c494f8 sceSdGetLastIndex
• 0xabfdfc8b sceSdCreateList
• 0x850a7fa1 sceSdSetMember
• 0x21be78b4 sceChnnlsv_21BE78B4 (not yet cracked)

The names have nothing to do with what the actual functions do and actually should be named something like this:

• sceSdSetIndex – sceSdCipherInit
• sceSdRemoveValue – sceSdCipherUpdate
• sceSdGetLastIndex – sceSdCipherFinal
• sceSdCreateList – sceSdMacInit
• sceSdSetMember – sceSdMacUpdate
• sceChnnlsv_21BE78B4 – sceSdMacFinal

The sceChnnlsv lib is already in the PSPSDK and the prototypes worked out. Now we have the correct names for them; however they are intentionally fake (I suspect in the SCESDK they may use more meaningful names in their code which their toolchain later converts to these fake names that you see in the exports table).

Almost every crypto lib uses fake function names. Which is why the nids for them are so much more difficult to crack. There are several crypto libs still with completely unknown names: sceMcctrl, sceMemab, sceMemlmd, sceMesgLed, sceSemawm.

Posted in NID's | No Comments »

Clarification of new TA-088 motherboards

There has been news recently about a Pandora-proof PSP with TA-088 motherboard. There has been a lot of speculation and misinformation being spread around.

There is a Pandora-proof model out now and it is of a TA-088 motherboard. However, that is not to imply that all TA-088 boards are Pandora-proof. There are currently (AFAIK) three different TA-088 models:

TA-088v1: These were the first TA-088 models which came with 3.71 firmware. They are similar to TA-085v2 in that it has disabled writing to the battery eeprom so that Pandora batteries cannot be created with these boards. However, like the TA-085v2, Pandora still worked perfectly fine so cfw can still be installed normally like any other PSP.

TA-088v2: These are newer TA-088 boards which came with 3.90 firmware and had a slight hardware change in the TACHYON IC (the cpu chip). At first, Pandora could not run so it was speculated that the exploit that allows Pandora to work was patched. However, after more research it was found that this was not the case but simply there was a hardware change that made it incompatible with the DDC kernel. Custom IPL’s could still be run so cfw still worked on these models, however they will be unable to be installed with the current versions of DDC. A new DDC version will be needed for these models. (EDIT: DC6 has now been released to fix this problem, DC5 and earlier versions still will not work on these boards)

TA-088v3: These are the newest TA-088 boards that seem to be completely Pandora-proof (as far as I can tell). It has a new TACHYON IC part number – CXD2988GG with a copyright year of 2008 (previous TA-088 models had a CXD2975GG part number with a 2007 copyright year). This PSP looks like to be the real Pandora-proof model, one that has patched the ‘preipl’ exploit that allows Pandora to run. If this is the case (and the exploit was properly patched) there would be no workaround or ‘fix’ to get Pandora to run (unless we find a way to ‘properly sign’ our own IPL).

I hope this clears up some of the confusion surrounding the new TA-088 motherboards and the rumours surrounding this new Pandora-proof PSP.

EDIT:

There’s some confusion with regards to the relationship between the firmware version and the motherboard. There isn’t a one-to-one correlation between the motherboard version and the firmware version. That is, if you have a TA-088v2 board then you have (at least) a 3.90 firmware. However the inverse is not true, that is, it doesn’t necessarily mean that if you have a 3.90 firmware then you have a TA-088v2 board (you may have a TA-088v1 board or maybe a TA-085v2 board).

It’s just the TA-088v2 boards first started appearing with 3.90 firmware. But you may also still have TA-088v1 boards or TA-085v2 boards being produced with 3.90 firmware too. Especially depending on the region. The firmware versions listed above are the earliest firmwares seen with these boards. These boards were released in Asia first so the firmware version may be earlier than on US or Europe models.

Basically, you cannot tell what board you have just based on the firmware version (though you can make an educated guess), however if you have a certain board then you will know at least the earliest firmware it will have.

EDIT2:

The new TA-088v3 boards only come in 4.xx and above. The new pre-IPL in these boards can only boot the 4.xx IPL’s, it cannot boot older IPL’s from 3.xx. So as long as the PSP doesnt come with 4.xx fw you know it won’t be a v3 board. Just remember, v3 boards cannot run firmwares under 4.xx.

Posted in Uncategorized | 39 Comments »