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

view plain
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…

Posted in NID's | 2 Comments »

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:

view plain
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

Posted in Code Snippets | 6 Comments »

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.

Posted in Uncategorized | 1 Comment »

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……

Posted in Misc, Uncategorized | No Comments »

The (New) PSP Tech Docs – Article01

November 22nd, 2007 silverspring

This is just the first draft just to give you an idea of what these “tech docs” are going to be like. It’s on the PSP Boot Sequence.

And to quote before:

“It will be fairly technical but it is aimed at the general psp user and explained in a way that everyone can understand while at the same time trying to be as detailed as possible. Though I will assume that the reader has a general knowledge of terms like ‘Nand’, ‘IPL’, ‘Idstorage’, etc.

Hopefully, this will be useful for not only general users wanting to gain a better understanding of the PSP, but also devs looking for some detailed reference material.”

http://silverspring.lan.st/NPSPTD_01.txt

EDIT: First drafts of Articles 02 & 03 will be posted soon. Topic will be “2.60+ IPL Encryption” & “3.00+ Nand Encryption” respectively. Future articles I’m planning to write will include Idstorage Keys, the KIRK crypto engine, and that “other secret” crypto engine.

Posted in Tech Docs | 5 Comments »

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?

Posted in NID's | 6 Comments »

Finally…

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:

view plain
C:
  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,
  11.  
  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: http://lan.st/showthread.php?t=854

Posted in NID's | No Comments »

The (New) PSP Technical Docs

November 5th, 2007 silverspring

Because there is a general lack of detailed PSP System documentation available (YAPSPD is excellent and is the definitve PSP HW docs http://hitmen.c02.at/files/yapspd/psp_doc/frames.html, but unfortunately is no longer updated), I’ll be writing up some technical articles for the general public. Topics will vary but will generally be detailed low level information that isnt publically available anywhere else.

It will be fairly technical but it is aimed at the general psp user and explained in a way that everyone can understand while at the same time trying to be as detailed as possible. Though I will assume that the reader has a general knowledge of terms like ‘Nand’, ‘IPL’, ‘Idstorage’, etc.

Hopefully, this will be useful for not only general users wanting to gain a better understanding of the PSP, but also devs looking for some detailed reference material.

Posted in Tech Docs | 1 Comment »

Idstorage Keys (0×0004-0×0008) – Generating hash

November 5th, 2007 silverspring

The idstorage area stores low level info on the PSP. Keys 4-8 are used for config data for various components (the battery, clock generator, LCD, etc.) and are in a different format to all the other keys.

Here is the code to generate the hash for these particular keys:

view plain
C:
  1. /*
  2. Idstorage Leaf Hash Gen Sample – SilverSpring 2007
  3.  
  4. The idstorage area stores low level info on the PSP.
  5. Keys 4-8 are used for config data for various components
  6. (the battery, clock generator, LCD, etc.)
  7. and are in a different format to all the other keys.
  8.  
  9. Specifically the format is as follows:
  10.  
  11. typedef struct
  12. {
  13.     u32 signature;
  14.     int type;
  15.     int datalen;
  16.     u32 hash;
  17.     u8 databuf[0x1F0];
  18.  
  19. } SceIdStorageLeaf;
  20.  
  21. Here’s the code to regenerate the hash for those keys.
  22. */
  23.  
  24. #include <stdio.h>
  25.  
  26. #define POLY (0xEDB88320)
  27.  
  28. #define LEAF_0x0004_HASH    (0x1FAB01BB)
  29. #define LEAF_DATA_SIZE  (0x1F0)
  30.  
  31. unsigned int gen_hash(unsigned int seed, unsigned char buf[], int size);
  32. void gen_table(void);
  33.  
  34.  
  35. unsigned int table[256];
  36.  
  37.  
  38. unsigned char leaf_0x0004_data[LEAF_DATA_SIZE] =
  39. {
  40.     0xD8, 0×00, 0×24, 0×00, 0×14, 0×31, 0×14, 0×00, 0×94, 0×01, 0×48, 0×00, 0xD8, 0×00, 0×00, 0×00,
  41.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  42.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  43.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  44.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  45.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  46.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  47.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  48.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  49.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  50.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  51.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  52.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  53.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  54.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  55.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  56.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  57.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  58.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  59.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  60.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  61.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  62.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  63.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  64.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  65.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  66.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  67.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  68.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  69.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  70.     0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00, 0×00,
  71. };
  72.  
  73.  
  74. int main()
  75. {
  76.     unsigned int hash;
  77.  
  78.     gen_table();
  79.     hash = gen_hash(0xFFFFFFFF, leaf_0x0004_data, LEAF_DATA_SIZE);
  80.  
  81.     if (hash != LEAF_0x0004_HASH)
  82.         printf("error: hash not match \n");
  83.  
  84.     printf("leaf_0x0004 hash: 0x%08X", hash);
  85.  
  86.     return 0;
  87. }
  88.  
  89.  
  90. unsigned int gen_hash(unsigned int seed, unsigned char buf[], int size)
  91. {
  92.     unsigned int hash = ~seed;
  93.     unsigned char index;
  94.     int i;
  95.  
  96.     for (i=0; i!=size; i++)
  97.     {
  98.         index = buf[i] ^ hash;
  99.         hash>>= 8;
  100.         hash ^= table[index];
  101.     }
  102.  
  103.     return(~hash);
  104. }
  105.  
  106. void gen_table(void)
  107. {
  108.     unsigned int i, j, x;
  109.  
  110.     for (i=0; i<256; i++)
  111.     {
  112.         x = i;
  113.  
  114.         for (j=0; j<8; j++)
  115.         {
  116.             if (x & 1)
  117.                 x = (x>>1) ^ POLY;
  118.             else
  119.                 x = (x>>1);
  120.         }
  121.  
  122.         table[i] = x;
  123.     }
  124. }

Note: this is a PC app (though you could run it on the PSP as well if you wanted).

Posted in Code Snippets | No Comments »

IPL Decrypt Sample (direct HW access)

October 9th, 2007 silverspring

Since this place is pretty bare right now here’s a quick sample I wrote up demonstrating how to access the KIRK crypto engine directly to do your decryption. Doing raw hardware access means you dont need to access any of the SCE crypto API’s such as the semaphore lib (memlmd.prx).This is useful for the future since no matter how much SCE change the libs, nids, etc. The HW remains the same so it will work in all future firmwares (until new PSP motherboards are developed). Might be useful to add to PSARDUMPER since PSARDUMPER still rely on the SCE crypto libs and SCE may change the nids in the future and other stupid stuff like that.

To use just place an encrypted IPL as enc_ipl.bin in the MS root. It’ll decrypt it and save as it dec_ipl.bin.

NOTE: the same decryption routine can also decrypt prx’s, though they need to be setup first before being passed to the crypto engine (ie. the prx header needs to be descrambled with its decryption key first). I might write up a quick sample to do that later.

Anyway, enjoy and I hope you’ll find this useful…

EDIT: this is for 1.50 Kernel

Download link: IPL Decrypt Sample (direct HW access)


Admin note: The issue with the captcha not working has been fixed. Sorry for any inconvenience caused. -EvilSeph

Posted in Code Snippets | No Comments »

Welcome…

October 9th, 2007 silverspring

Welcome to SilverSpring’s bunch of random PSP stuff. There wont be much happening here, it’ll just be a bunch of…err…random PSP stuff!

Anyway, enjoy your stay here.

Posted in Uncategorized | No Comments »

Next Entries »