If this is your first visit, be sure to check out the FAQ by clicking the link above.
You may have to register before you can post: click the register link above to proceed.
To start viewing messages, select the forum that you want to visit from the selection below.
Very little is known about the IDStorage generation process, except that it occurs onboard the PSP, leading speculators to believe Sony may use Jigkick Batteries to start the process on the PSP during manufacture.
It is believed IDStorage cannot be restored even by Sony technicians after the manufacture process.
Meaning it can't be restored without a NAND Back-up, and only a Few Keys can be fixed with programs such as KeyCleaner and IdStorage Manager by Chilly Willy
Info below compiled from various sources, including: adrahil, Chilly Willy, FreePlay, harleyg, jas0nuk, l_oliveira, Mathieulh, Saben, SilverSpring, Squirrel, vb_master
The following keys are backed up separately from the IdStorage, non-indexed: 4, 5, 6, F, 30-3F, 40-46, 50, 140
* = key is the same per model, but not necessarily the same in every PSP
* = key is unique to each PSP
* = key is partially unique (e.g. WLAN region are all similar but with a few bytes changed for different regions)
General info on each key
Quote:
* 0x4 - Baryon settings/information - extra data added since Slim v1 * 0x5 - Clockgen/I2C setup commands - invalidating the first four bytes enables 1.50 to boot on TA-082+ by preventing an IPL crash due to unsupported hardware * 0x6 - Battery, CPU frequency and general power settings - extra data added since Slim v1
* 0x7 - Unknown usage (exists since Fat v4/Slim v1) - changed in Slim v2 * 0x8 - Brightness hardware control (exists since Fat v4/Slim v1) - changed in Slim v1.1 and again in Slim v2 - if this is detected, the data in them is used to control the brightness levels. If not, the board acts as a TA-079 which causes brightness level issues with the new hardware.
* 0x10 - MagicGate
* 0x11 - MagicGate * 0x12 - MagicGate
* 0x13 - MagicGate
* 0x40 - Contains the 0x5 bytes at 0x88 from key 0x10 All of the above are required for MagicGate to work
* 0x41 - USB (Driver type identifier) - slightly different since Slim v1 * 0x43 - USB (Device ID) - slightly different since Slim v1
* 0x44 - WLAN MAC Address (can be rebuilt using Noobz MAC Address Fixer)
* 0x45 - WLAN Region (can be rebuilt using KeyCleaner)
* 0x47 - Default parental lock level (first byte is 0x09, rest is empty)
* 0x50 - Serial number (not used since TA-082)
* 0x51 - Firmware the PSP shipped with, and unknown unique data (exists since Fat v4/Slim v1)
* 0x52 - Unused by PSP - Mostly the same per PSP except for slight variations - could be manufacturing info (exists since Slim v1)
* 0x54 - Default XMB background colour - first 3 bytes: 02 00 02 in PSP-200X IS, 02 00 00 in PSP-200X PB (exists since Slim v1)
* 0x100 - DNAS, VSH & Internet browser region, ad-hoc region (if missing, official updaters cannot run - error CTA80000025)
* 0x101 - OpenPSID (non-indexed duplicate at [location of original + 0x8000])
* 0x102 - UMD (non-indexed duplicate at [location of original + 0x8000])
* 0x103 - UMD (non-indexed duplicate at [location of original + 0x8000])
* 0x104 - UMD (non-indexed duplicate at [location of original + 0x8000])
* 0x105 - UMD (non-indexed duplicate at [location of original + 0x8000])
* 0x106 - UMD (non-indexed duplicate at [location of original + 0x8000]) 102-106 is a continuous key which the UMD drive uses. Any invalid ones (missing, edited, or from another PSP) will prevent the UMD sectors being decrypted, resulting in a Disc Read Error
* 0x120-0x126 - backup of respective 0x0100-106 key
* 0x140 - Unknown unique data
More info on keys 4-8
Keys 4-8 are setup data for various devices. Their structure is as follows:
typedef struct {
u32 signature; // "Clkg", "Bryn", etc
int type; // always 00000001 so far
int datalen; // length of data starting at 0x10
u32 hash; // hash of data from 0x10 to 0x10+datalen
u8 databuf[0x1F0]; // data used for hardware init/control
} SceIdStorageLeaf;
Since official updater 3.30, every updater has a hidden module called sceChkDegeneration which checks the signatures of these keys and produces an error if the signature is incorrect:
Quote:
DRNFFFFFFD8 = key 0x4 missing
DRNFFFFFFD7 = key 0x4 header is not "n y r B" (in hex: 6E 79 72 42)
DRNFFFFFFCE = key 0x5 missing
DRNFFFFFFCD = key 0x5 header is not "g k l C" (in hex: 67 6B 6C 43)
DRNFFFFFFC4 = key 0x6 missing
DRNFFFFFFC3 = key 0x6 header is not "r d D M" (in hex: 72 64 44 4D)
Additional checks in TA-086:
DRNFFFFFFB9 = key 0x7 header is not "D a P A" (in hex: 44 61 50 41)
DRNFFFFFFB0 = key 0x8 missing
DRNFFFFFFAF = key 0x8 header is not "p D C L" (in hex: 70 44 43 4C) - for this error, creating a fake key 8 is not enough as this will result in the brightness not working at all, a real key must be used.
KIRK commands
IdStorage keys are created by one of the KIRK commands, so we need to get as much information as we can about KIRK (aka semaphore hardware decryption)
GetPsCode (0x100 region key) return codes
List compiled by harleyg/Slash
Region code is returned from sceChkregGetPsCode, in the format 01 00 XX 00 01
Model Country Region GetPsCode Comments
--------------------------------------------------------------------------
PSP-1000 Japan 2 0x03 Standard Pack
PSP-1000CW Japan 2 0x03 White Giga Pack
PSP-1000K Japan 2 0x03 Value Pack
PSP-1000KCW Japan 2 0x03 White Value Pack
PSP-1000G1 Japan 2 0x03 Giga Pack
PSP-1000G1CW Japan 2 0x03 White Giga Pack
PSP-1001K North America 1 0x04 Value Pack
PSP-1001G1 North America 1 0x04 Giga Pack
PSP-1002K Australia/New Zealand 4 0x09 Value Pack
PSP-1002G1 Australia/New Zealand 4 0x09 Giga Pack
PSP-1003K UK 2 0x05 Value Pack
PSP-1003G1 UK 2 0x05 Giga Pack
PSP-1004K Europe 2 0x05 Value Pack
PSP-1004G1 Europe 2 0x05 Giga Pack
PSP-1005K Korea 5 0x06 Value Pack
PSP-1005G1 Korea 5 0x06 Giga Pack
PSP-1006CW Hong Kong/Singapore 5 0x0A White Giga Pack
PSP-1006K Hong Kong/Singapore 3 0x0A Value Pack
PSP-1006G1 Hong Kong/Singapore 3 0x0A Giga Pack
PSP-1007K Taiwan 3 0x0B Value Pack
PSP-1007G1 Taiwan 3 0x0B Giga Pack
PSP-1008K Russia 5 0x0C Value Pack
PSP-1008G1 Russia 5 0x0C Giga Pack
PSP-1009K China 6 0x0D Value Pack
PSP-1009G1 China 6 0x0D Giga Pack
It's a 3.xx app (src included), should work on all psps (tested on 3.52 fat and 3.90 slim).
If you modify any part of those keys, you'll see the app fail the check for that section. But you can modify any section apart from section0 & section5 (pscode & openPSID) and all features of the psp will still work fine, even though the app will fail the verify. Modify section0 (pscode) and you'll get region errors, modify section5 (openPSID) and you'll get adhoc/dnas errors.
Here are the offsets of each section in the idstorage key:
section0: 0xB8 Bytes from offset 0x038 of key 0x100 (this is the pscode)
section1: 0xB8 Bytes from offset 0x0F0 of key 0x100
section2: 0xB8 Bytes from offset 0x1A8 of key 0x100 (continues onto key 0x101)
section3: 0xB8 Bytes from offset 0x060 of key 0x101
section4: 0xB8 Bytes from offset 0x118 of key 0x101
section5: 0xB8 Bytes from offset 0x1D0 of key 0x101 (continues onto key 0x102) (this is the openPSID)
Only section 0 & 5 are used in the fw so that's why modifying any other section doesnt affect the psp's functionality.
Little is known about the format of these 0xB8 Byte sections and how they are generated, though it's constantly being researched. It doesnt seem to be one single stream of data but composed of seperate parts.
__________________
Last edited by karothacker; 08-20-2008 at 02:08 AM.
I just restored my slim after a nice brick and used Keycleaner to clean up. I had 5 bad keys and luckily i could fix them ,thanx to your guide I know just what they 're for . thanx KAROTHACKER
I just restored my slim after a nice brick and used Keycleaner to clean up. I had 5 bad keys and luckily i could fix them ,thanx to your guide I know just what they 're for . thanx KAROTHACKER