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


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

  1. u64 sceSysregGetFuseId();
  2. u32 sceSysregGetFuseConfig();

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.

4 Responses to “Some very significant NID’s”

  1. Fuses as in CPU die fuses, or something completely unrelated to that line of thought?

  2. silverspring Says:
    July 25th, 2008 at 12:52 pm

    Yes, I presume it’s referring to an OTP PROM on the die. Something that is programmed at the factory, the ID being a completely unique serial. It might also suggest that the ‘preipl’ is stored on an OTP PROM as well and not a mask ROM.

  3. I’m thinking preipl is in Mask ROM, at least on older PSP CPUs.
    As seen here, TA-088 V2 has a new Pandora-proof (C) 2007 CPU.
    Since clearly Sony really did want to lockout/defeat Pandora, badly enough to push a new CPU, I think that had preipl been in OTP PROM on the older PSP models they would have pushed an update to manufacturing and we would have seen Pandora-proof PSPs much sooner.
    Maybe it’s in OTP PROM now though, interesting thought…

  4. silverspring Says:
    July 26th, 2008 at 4:49 pm

    Well regarding that new model, it seems they hadn’t fixed the preipl exploit. The problem lie elsewhere (something else in that IC changed but not the preipl). Though on newer slim IPL’s there is a SYSCON-based challenge-response setup that’s used to generate keys which might be timing critical and may depend on certain paramaters within the CPU IC. This might have something to do with it. But more tests need to be done on these new models to see what exactly it is that changed within that IC (so far it doesn’t seem to be the preipl).

Leave a Reply