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 »

Some very significant NID’s

Here are 2 very important nids found:

• 0x4F46EEDE sceSysregGetFuseId
• 0x8F4F4E96 sceSysregGetFuseConfig

These 2 functions serve quite significant purposes.

And some other not so significant ones:

• 0xBF91FBDA sceSysregMsifQueryConnectIntr
• 0x36A75390 sceSysregMsifAcquireConnectIntr

Edit:

Due to some interest with regard to the above two functions I listed, here is some more info:

These are hardcoded values located in the CPU IC – TACHYON (presumably on an OTP PROM on the die).

The FuseID is a completely unique 48-bit internal ID and as such is referenced quite a bit. Most notably being used as the seed for the idstorage encryption on slim PSP’s as well as the lflash encryption on 3.00+ firmwares. It is probably also widely used for other purposes as well since it is the only one true internal serial number.

The FuseConfig holds hardcoded configuration data for the TACHYON IC. For example, when the PSP is shutdown (or put to sleep) the config data is used to control the TACHYON voltages to power the devices off.

Posted in NID's | 4 Comments »

More NID’s

From sceCtrl_driver lib:

• 0x5E77BC8A sceCtrlGetButtonIntercept
• 0x7CA723DC sceCtrlSetButtonIntercept

These ctrl functions are already in pspsdk – under pspctrl_kernel.h (though with unknown names – labelled Get/Set Button Mask):

From SysMemForKernel lib:

• 0xA262FEF0 sceKernelGetAllowReplaceUmd
• 0xCBB05241 sceKernelSetAllowReplaceUmd

From sceUSB_Stor_Ms_driver lib:

• 0xABE9F2C7 sceUsbstorMsGetApInfo
• 0x576E7F6F sceUsbstorMsSetProductInfo

Posted in NID's | No Comments »

New NAND Flash device support added

Support for new nand IC’s from ST Micro (upto 128MB) have been added to the nand driver in newer firmwares. Previously only Samsung (retail PSP) and Toshiba (devkit PSP) nands were supported.

Posted in Misc | No 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 »

More DevKit NID’s

SysMemForKernel library (from 2.50 fw onwards):

• 0x071d9804 sceKernelApiEvaluationInit
• 0x049CC735 sceKernelApiEvaluationReport
• 0×02786087 sceKernelRegisterApiEvaluation

All these functions just return 0 in the retail sysmem.prx which suggests it’s used in devkits only. Sounds like a reporting tool but no idea what kind of data it will log.

UtilsForKernel library:

• 0x136f2419 sceKernelSetPTRIGMask

PTRIG is some sort of switch on a devkit similar to the dipswitches. Do not know what it controls.

Posted in NID's | No Comments »

Last remaining sceIdStorage nid

The final remaining idstorage nid:

• 0x99ACCB71 sceIdStorageCreateAtomicLeaves

As the name suggests, this function creates multiple leaves as an atomic operation. Because each leaf is only one nand page in size (0×200 Bytes), data requiring more than 0×200 bytes will need more than one leaf. This function allows you to create multiple leaves as a single operation. This saves from having to sceIdStorageCreateLeaf each individual leaf.

A good example of this are the umd keys (0×102-0×106), which hold a single continuous stream of data split over 5 seperate leaves:

That finally completes the idstorage lib !!

Posted in NID's | No Comments »

New 3.95 lib NID’s

Completed 2 libs new in 3.95.

Complete libaac (except for 2 which aren’t really needed anyway since they are just module_start/module_stop aliases):

• 0x6c05813b (module_start alias)
• 0x61aa43c9 (module_stop alias)
• 0xe0c89aca sceAacInit
• 0x33b8c009 sceAacExit
• 0x5cffc57c sceAacInitResource
• 0x23d35cae sceAacTermResource
• 0x7e4cfee4 sceAacDecode
• 0x523347d9 sceAacGetLoopNum
• 0xbbdd6403 sceAacSetLoopNum
• 0xd7c51541 sceAacCheckStreamDataNeeded
• 0xac6dcbe3 sceAacNotifyAddStreamData
• 0x02098c69 sceAacGetInfoToAddStreamData
• 0x6dc7758a sceAacGetMaxOutputSample
• 0x506bf66c sceAacGetSumDecodedSample
• 0xd2da2bba sceAacResetPlayPosition

Completed G.729 lib (new exports added in 3.95):

• 0xaa1e5462 sceG729EncodeInitResource
• 0x94714d50 sceG729EncodeTermResource
• 0x8c87a2ca sceG729EncodeReset
• 0x17c11696 sceG729DecodeInitResource
• 0x890b86ae sceG729DecodeTermResource
• 0x74804d93 sceG729DecodeReset

Posted in NID's | No Comments »

PSP LibDoc update

Finally got around to updating the libdocs (http://silverspring.lan.st/update.html).

Thanks to Insert_Witty_Name for the full sceNetAdhocTransInt_Library nids, and WosRet for some very nice sysmem/kdebug nids:

• 0x24C32559 sceKernelDipsw (devkit dip switch settings)
• 0x39F49610 sceKernelGetPTRIG (I don’t know what these are, more devkit stuff?)
• 0xCE8D3DB3 sceKernelGetQTGP2
• 0x6D8E0CDF sceKernelGetQTGP3

Some nids from brand new modules like the 1seg TV Tuner and the G729 Audio Compression algorithm used for Skype:

• 0xf8e2cedc sceUsb1SegScanCh
• 0x5f62e0b5 sceUsb1SegChangeCh
• 0xcfcd367c sceG729EncodeInit
• 0x55e14f75 sceG729DecodeInit

And an unusual change from the standard naming conventions:

• 0xfa6de6a6 _sce_pspnet_if_up
• 0xedb11cb4 _sce_pspnet_if_down
• 0x701dddc3 _sce_pspnet_if_attach
• 0xd5a03bc0 _sce_pspnet_if_detach

Also added 3.95 firmware (http://silverspring.lan.st/3.95/index.html), not surprisingly nids were changed again from the 3.90/3.93 firmware, but at least there’s some new modules (like libaac).

I will probably only update firmwares 1.50 & 3.52 (as well when a new firmware comes along) from now. !.50 for obvious reasons since 1.50 homebrew is still strong, and 3.52 since that was the last update before SCE started randomising the nids.

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

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 »

SCE’s Battery Emulator (strange NID)

There is a very interesting import used in the 3.90 updater. From a prx called batemu_inst.prx there is a function used, batemu_inst_4E31BC31. The library name batemu_inst is short for Battery Emulator Install, and the nid is:

0x4E31BC31 sceUpdateBatteryEmulator

The function installs a battery emulator. Unforturnately, it seems the prx is used only on a devkit and doesnt seem to be found anywhere in the retail updater itself. Which is a shame, would’ve been nice to see what it does exactly.

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

More SCE Mind Games™…

Have you ever booted up your psp or resumed from sleep and have it appeared bricked (psp freezes then shutoffs)?

Well you can blame SCE for that. You see, if you have corrupt idstorage (keys 4, 5, 6, or 7) there’s an exactly 12.5% chance that on boot the psp will appear bricked. The IPL will check for corrupt keys but will only randomly do so. The check is based on the time, if the current time (in millisecs) is a multiple of (approx.) 8, the IPL will check your idstorage keys and if they are corrupt (ie. if the header for those keys dont match what they should be), the psp will shut itself off.

What is even worse is that this check also occurs during resuming from sleep mode. So one could theoretically boot up the psp fine, sleep, then fail on resume. All of this is to confuse us devs by trying to obscure the problem…very sneaky in my opinion.

Technically, it checks like this:

So, what do people think of this new trick?

Sneaky? Absolutely. Suprised? Well, this is SCE we’re talking about here.

Another day, another mind game…

EDIT: Slight correction, the time is actually in 500ms intervals (0.5second intervals), not milliseconds.

Posted in Misc | 3 Comments »

03g model PSP …revisited…

More proof of the HDD.

Just how the first fat firmware (1.00) was rushed to be released, it seems the first slim firmware (3.60) was also rushed. A certain module that came only on original 3.60 retail slims was (incredibly stupidly) compiled with full debug info intact. Extracted from the debug info was this:

From the debug info, there are ways to stream MagicGate protected video from HDD.

There is a tonne of useful debug info extracted, also noteworthy were references to Skype and the boot mode “app” (other modes “vsh”, “game”, “updater”, “pops”, etc) with which Skype boots into. There seems to be plans to release more of these ‘app’s in the future. Perhaps more towards a full pda…(03g).

Posted in Uncategorized | 2 Comments »