NAND set_encryption_seed NID (last remaining sceNand nid)

April 11th, 2008 silverspring

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:

  1. u32 magic;
  2. u32 buf[4];
  3. u32 sha[5];
  5. buf[0] = *(vu32*)(0xBC100090);
  6. buf[1] = *(vu32*)(0xBC100094);
  7. buf[2] = *(vu32*)(0xBC100090)<<1;
  8. buf[3] = 0xD41D8CD9;
  10. sceKernelUtilsSha1Digest((u8*)buf, sizeof(buf), (u8*)sha);
  12. magic = (sha[0] ^ sha[3]) + sha[2];
  14. sceNandSetScramble(magic);

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

SCE’s Battery Emulator (strange NID)

February 23rd, 2008 silverspring

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.

03g model PSP?

December 19th, 2007 silverspring

A new device has been found in syscon that only exists in 3.80 firmware. The nids have been randomised so there’s no chance of cracking the real name like was done with GSensor, HDD, & Bluetooth.

The actual function is sceSyscon_driver_4AB44BFC (which should be called sceSysconSet__Callback).

  1. enum PspSysconCallbacks
  2. {
  18.     SYSCON_UNK_DEV_CB // in 3.80 only – PSP 03g?
  19. };

Since it only exists in 3.80 and not 3.7x and earlier, it would seem it’s a 03g only device. What other devices are SCE planning to add in 03g?? The waiting game begins…

The PSP Slim could’ve been a gamer’s dream handheld…

November 16th, 2007 silverspring

Cracked a few very interesting nids the other day. More proof that the HDD wasnt just a rumour.

  • 0xc68f1573 sceSysconCtrlGSensor
  • 0x3ab3aeef sceSysconReadGSensorReg
  • 0x07a0c260 sceSysconWriteGSensorReg
  • 0x72eda9af sceSysconGetGSensorVersion
  • 0x58531e69 sceSysconSetGSensorCallback

The G-Sensor is already used on Sony’s Vaio laptop and also their HDD based Walkman’s. To quote Sony:

The innovative G-Sensor system automatically and instantly reacts to changes in gravity and velocity by releasing the recording head. This helps protect the hard disk surface, preventing crashes and loss of data, ultimately improving long term reliability.

These new nids along with the new HDD nids cracked just last week provides pretty conclusive proof that the PSP Slim does in fact natively support a HDD.

  • 0x8b95c17f sceSysregAtahddIoEnable
  • 0xccf911c0 sceSysregAtahddIoDisable
  • 0xa23bc2c4 sceSysregAtahddResetEnable
  • 0xf5ea8570 sceSysregAtahddResetDisable
  • 0x8ce2f97a sceSysregAtahddClkSelect
  • 0xb59db832 sceSysregAtahddClkEnable
  • 0x9155812C sceSysregAtahddClkDisable
  • 0xe45bed6a sceSysregAtahddBusClockEnable
  • 0x681b35c4 sceSysregAtahddBusClockDisable
  • 0xa975f224 sceSysconCtrlHddPower
  • 0x051186F3 sceSysconGetHddPowerCtrl
  • 0xF9FDAFA5 sceSysconGetHddPowerStatus
  • 0x04EEFD03 sceSysconSetHddPowerCallback

This along with the (also missing) Bluetooth features (sceSysconCtrlBtPower etc.) could’ve made the PSP Slim a very attractive handheld indeed. What you are left with instead is a slightly ‘slimmer’, ‘lighter’ model with very ordinary additions (TV out, USB charge, UMD cache, larger flash space etc).

So why did Sony decide in the end to skimp on these features (Im sure there’s a few more features still hidden – there’s still about 20 more syscon nids that havent been cracked yet). Well the two main factors are a) battery life (the slim battery is already at a lower capacity than the fat) and b) cost (the slim was released at the same price as the current fat).

So even though these are dream features to have on a PSP (and in fact these features are still supported natively on a HW level – just need to connect the HDD and write the drivers for it) could you justify the sacrifice in battery life and increase in purchase price to have these features?


November 7th, 2007 silverspring

0xb4560c45 sceSysregPllGetOutSelect
0xdca57573 sceSysregPllSetOutSelect

I’ve been trying to crack these 2 nids for awhile. These are used to get/set the PLL index that multiplies with the base frequency to change the PLL freq (to change cpu & bus freq). The index is as follows:

  1. const float pll_table[0×10] =
  2. {
  3.     1/9.0,    // 0.1…
  4.     4/9.0,    // 0.4…
  5.     4/7.0,    // 0.571428…
  6.     6/9.0,    // 0.6…
  7.     4/5.0,    // 0.8
  8.     9/9.0,    // 1.0
  9.     0.0,
  10.     0.0,
  12.     1/18.0,   // 0.05…
  13.     4/18.0,   // 0.2…
  14.     4/14.0,   // 0.285714…
  15.     6/18.0,   // 0.3…
  16.     4/10.0,   // 0.4
  17.     9/18.0,   // 0.5
  18.     0.0,
  19.     0.0
  20. };

Although the index is from 0-15, sceSysregPllSetOutSelect limits it to 0-5 only. The default is 3 (ie. 0.666666…). So default PLL freq is (multiplier*BASE_FREQ) * pll_table[index] = 9*37 * 0.66666 = 222MHz. To set to 333MHz just call sceSysregPllSetOutSelect(5) (which will also make the cpu freq 333MHz).

EDIT: For completeness, here’s what I had originally written about it: