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

C:
  1. enum PspSysconCallbacks
  2. {
  3.     SYSCON_LOW_BATTERY_CB = 0,
  4.     SYSCON_POWER_SWITCH_CB,
  5.     SYSCON_ALARM_CB,
  6.     SYSCON_AC_SUPPLY_CB,
  7.     SYSCON_HP_CONNECT_CB,
  8.     SYSCON_WLAN_SWITCH_CB,
  9.     SYSCON_HOLD_SWITCH_CB,
  10.     SYSCON_UMD_SWITCH_CB,
  11.     SYSCON_HR_POWER_CB,
  12.     SYSCON_WLAN_POWER_CB,
  13.     SYSCON_GSENSOR_CB,
  14.     SYSCON_HDD_POWER_CB,
  15.     SYSCON_BT_POWER_CB,
  16.     SYSCON_BT_SWITCH_CB,
  17.     SYSCON_HR_WAKEUP_CB,
  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…

3.80 and Pandora

December 19th, 2007 silverspring

Well it looks like SCE have finally learned and have now removed the functions to read/write to the battery eeprom in 3.80 (they also took out the sceSysconBatteryAuth function too). So you can’t make a magic battery with 3.80, but nevermind, the hardware to do so is still there.

Here’s a compatible replacement:

C:
  1. int write_eeprom(u8 addr, u16 data)
  2. {
  3.     int res;
  4.     u8 param[0×60];
  5.  
  6.     if (addr>0x7F)
  7.         return(0×80000102);
  8.  
  9.     param[0x0C] = 0×73; // write battery eeprom command
  10.     param[0x0D] = 5; // tx packet length
  11.  
  12.     // tx data
  13.     param[0x0E] = addr;
  14.     param[0x0F] = data;
  15.     param[0×10] = data>>8;
  16.  
  17.     res = sceSysconCmdExec(param, 0);
  18.  
  19.     if (res<0)
  20.         return(res);
  21.  
  22.     return 0;
  23. }
  24.  
  25. int read_eeprom(u8 addr)
  26. {
  27.     int res;
  28.     u8 param[0×60];
  29.  
  30.     if (addr>0x7F)
  31.         return(0×80000102);
  32.  
  33.     param[0x0C] = 0×74; // read battery eeprom command
  34.     param[0x0D] = 3; // tx packet length
  35.  
  36.     // tx data
  37.     param[0x0E] = addr;
  38.  
  39.     res = sceSysconCmdExec(param, 0);
  40.  
  41.     if (res<0)
  42.         return(res);
  43.  
  44.     // rx data
  45.     return((param[0×21]<<8) | param[0×20]);
  46. }

EDIT:
Finally cracked the real names:

0x68ef0bef sceSysconBatteryReadNVM
0x1165c864 sceSysconBatteryWriteNVM

Updater versions

December 14th, 2007 silverspring

Contrary to what people say about all updaters being the same, it is not true. There have been several instances of multiple releases of a firmware update. It occured with earlier updaters though recent releases have generally been identical.

Here’s a quick list, but because most sites only post a single version of an update I’ve been unable to find the alternate versions. Though I have both 2.00 updaters as you see in the list.

Im still looking for the others so if you have an eboot that does not match the following hashes let me know, specifically:

1.52 (MD5: B976783070C12C4ED81CC27785222491)

2.60 (MD5: A69A022FCE43B614A8CB305786F59855)

1.50
release:1.00:
build:89,0,3,1,0:root@psp-vsh
system:17756@release_103a,0×01000300:
vsh:p4231@updater_for_day1,v11488@updater_for_day1,20050304:

1.51
release:1.00:
build:91,0,3,1,0:root@psp-vsh
system:17756@release_103a,0×01000300:
vsh:p4389@updater_151,v12880@updater_151,20050507:

1.52
release:1.00:
build:114,0,3,1,0:root@psp-vsh
system:17756@release_103a,0×01000300:
vsh:p4505@updater_152,v13669@NA,20050602:

2.00a
release:1.00:
build:134,0,3,1,0:root@psp-vsh
system:17756@release_103a,0×01000300:
vsh:p4689@updater_200,v15800@updater_200,20050722:

2.00b
release:1.00:
build:139,0,3,1,0:root@psp-vsh
system:17756@release_103a,0×01000300:
vsh:p4689@updater_200,v16630@updater_200,20050819:

2.01
release:1.00:
build:150,0,3,1,0:root@vsh-build
system:17756@release_103a,0×01000300:
vsh:p4798@updater_201,v18571@updater_201,20050929:

2.50
release:1.00:
build:157,0,3,1,0:root@vsh-build
system:17756@release_103a,0×01000300:
vsh:p4801@updater_250,v19017@updater_250,20051011:

2.60
release:1.00:
build:170,0,3,1,0:root@vsh-build
system:17756@release_103a,0×01000300:
vsh:p4954@updater_trunk,v20338@updater_trunk,20051122:

2.70
release:1.00:
build:190,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5181@updater_270,v22592@updater_270,20060420:

2.71
release:1.00:
build:203,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5220@updater_271,v22936@updater_271,20060530:

2.80
release:1.00:
build:214,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5271@updater_280,v24380@updater_280,20060721:

2.81
release:1.00:
build:215,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5280@updater_281,v24651@updater_281,20060814:

2.82
release:1.00:
build:218,0,3,1,0:hoshi@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5353@updater_282,v25795@updater_282,20061003:

3.00
release:1.00:
build:230,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5382@updater_300,v27165@updater_300,20061120:

3.01
release:1.00:
build:231,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5404@updater_301,v27257@updater_301,20061121:

3.02
release:1.00:
build:233,0,3,1,0:builder@vsh-build2
system:17756@release_103a,0×01000300:
vsh:p5414@updater_302,v27411@updater_302,20061204:

3.03
release:1.00:
build:238,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5426@updater_303,v27632@updater_303,20061216:

3.10
release:1.00:
build:247,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5471@updater_310,v28276@updater_310,20070119:

3.11
release:1.00:
build:250,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5476@updater_311,v28775@updater_311,20070206:

3.30
release:1.00:
build:259,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5531@updater_330,v30241@updater_330,20070326:

3.40
release:1.00:
build:261,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5576@updater_340,v30701@updater_340,20070406:

3.50
release:1.00:
build:275,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5662@updater_350,v32514@updater_350,20070522:

3.51
release:1.00:
build:278,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5724@updater_351,v33285@updater_351,20070628:

3.52
release:1.00:
build:279,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5742@updater_352,v33536@updater_352,20070710:

3.70
release:1.00:
build:290,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5840@updater_370,v35316@updater_370,20070831:

3.71
release:1.00:
build:291,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5864@updater_371,v35671@updater_371,20070912:

3.72
release:1.00:
build:295,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5876@updater_372,v36347@updater_372,20071015:

3.73
release:1.00:
build:298,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5928@updater_373,v37903@updater_373,20071121:

3.80
release:1.00:
build:303,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5933@updater_380,v38389@updater_380,20071210:

3.90
release:1.00:
build:310,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5940@updater_390,v38984@updater_390,20080125:

3.93
release:1.00:
build:313,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p5989@updater_393,v39469@updater_393,20080215:

3.95
release:1.00:
build:318,0,3,1,0:builder@vsh-build5
system:17756@release_103a,0×01000300:
vsh:p6004@updater_395,v40308@updater_395,20080328:

EDIT: added 3.80, added 3.90, added 3.93, added 3.95

Note: there were two releases of the 3.93 EBOOT however the app itself stayed the same so there’s only one version listed. There were only minor changes to the packaging of the EBOOT, an extra 0×1000 null bytes for the PBP Header, and an extra 0×10 byte hash added to the end of the PSAR. Strangely enough, the extra 0×1000 bytes were taken out again for 3.95.

The mind games SCE play…

December 2nd, 2007 silverspring

We are all familiar with the various tricks SCE use to fool devs, though I recently came across one that has annoyed me the most.

When 3.40 was released, a ‘special’ prx was flashed with the rest of the firmware that didnt seem to be used at all. It was special in that not only was it not used nor referred to once in the entire firmware, it also could NOT be decrypted (the keys to decrypt it simply did not exist in the firmware). Because of this and the fact that the prx was promptly removed from all future firmware (it only exists in 3.40) it was assumed to be a remnant of a debug prx used during testing and they had simply forgot to remove it. Or was it?

The prx was “idcheck.prx”. The module name sounded interesting and on first glance it was assumed to be the debug version of the embedded prx SCE hid in 3.30+ updaters to check for corrupt idstorage in their updaters (the one that refuses to update the PSP if either your keys 4, 5, 6, 7 & 8 were corrupt).

Long story short, the prx has been decrypted and the result was far from expected. It seems that the original module has been taken out and replaced with a dummy instead. The only remains left of the original module was the module name “sceIdCheck” and the data segment, which included the strings “Illegal idstoarge” (SCE always misspell ‘idstorage’), “flash is corrupted”, and “cannot restore PSP system”. The rest of the module (including all the code) had been dummied with another module from the firmware.

Now why would SCE do this? If it were a debug prx that was accidently left in, why would they bother going to the trouble of dummying the code?

Some accidental mistake on their part, or more of their ridiculous mind games at play……