IdStorage keys and their uses + regeneration [TECHNICAL DISCUSSION]

[jas0nuk]

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

NOTE: Slim v1 = TA-085 baryon 22B200, Slim v1.1 = TA-085 baryon 234000, Slim v2 = TA-088, Fat v4 = TA-086

* = 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
* 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:

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)

0x01 - PRX decryption
0x02 - ???
0x03 - ???
0x04 - Scramble, savedata (chnnlsv) [paired with 0x7]
0x05 - Unsigcheck, savedata (chnnlsv) [paired with 0x8]
0x06 - ??? [paired with 0x9]
0x07 - Descramble [paired with 0x4]
0x08 - Sigcheck, savedata (chnnlsv) [paired with 0x5]
0x09 - ??? [paired with 0x6]
0x0A - ???
0x0B - SHA-1
0x0C - ??? (memab)
0x0D - ??? (memab)
0x0E - savedata (chnnlsv), memab, semawm, DbsvrGetData
0x0F - ???
0x10 - ??? (memab)
0x11 - ??? (memab)
0x12 - IdStorage checks

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

[Saben]

I've been thinking about this and it got me wondering how they do the initial burn of idstorage. Is it possible that a standard firmware has a function someplace to setup id storage on a new unit, or do you think the factory jig-kick process does this while installing the IPL and firmware?

[Squirrel]

Originally Posted by Saben

I've been thinking about this and it got me wondering how they do the initial burn of idstorage. Is it possible that a standard firmware has a function someplace to setup id storage on a new unit, or do you think the factory jig-kick process does this while installing the IPL and firmware?

The latter. The Pandora's an awesome great tool but it's been set up from scratch. Sony's magic stick is different and probably includes the code to regenerate IDStorage. But as long as there's no complete dump of it but just the crippled ones floating around the net, chances are few of reversing it. So the other option is solid research and that's what Jas0nuk is proposing.

[AcCeSsDeNiEd]

There's probably some unique ID stored somewhere on the mb (where?). And the jigkick depends on this to create the IDstore keys.

[Chilly Willy]

IdStorage is a special part of the firmware NOT in the normal flash areas. It's composed of "leafs" that contain 512 bytes of data. There can be at most 65520 of these leafs (also called keys by most folks), but Sony only uses about 128 of them currently. They hold various bits of info used by subsytems in the PSP. Things like the WIFI MAC address, levels for the battery, levels for the LCD brightness, etc. There's a thread here that goes into detail on the IdStorage. Read that for more info.

No IdStorage means loss of many functions related to WIFI, USB, and PS3 connectivity. The IdStorage is in every PSP and varies a little by motherboard revision. Each new mobo introduces a few more keys, and some existing keys have new content. So rebuilding the IdStorage will require knowledge about the mobo. Probably at first, the person will have to manually choose the mobo from a list.

Even then, some info cannot be found except by opening the PSP. The WIFI MAC address in key 0x44 is that way.

[Squirrel]

Originally Posted by AcCeSsDeNiEd

There's probably some unique ID stored somewhere on the mb (where?). And the jigkick depends on this to create the IDstore keys.

Yeah, and it's called Kirk. My strong believe is that all IDS keys for a certain type of motherboard are identical with exception of things like MAC and serial, but it's encryption or signing that makes them not work on another PSP.

Originally Posted by Chilly Willy

Even then, some info cannot be found except by opening the PSP. The WIFI MAC address in key 0x44 is that way.

Don't agree, you can also use a wifi router to find the MAC without opening the PSP. The serial is written in the battery bay if some a**hole didn't remove the label (I've seen LOADS of PSP's that for some reason had the label removed, probably because the user expected tons of screws underneath it).

But even more, I think everything can be retrieved from the PSP itself by software, including MAC and serial (the serial must be stored in Kirk in order to create unique encryption keys). I bet it's only readable in factory mode, though.

BTW. Jas0nuk, wouldn't it be wise to move all this "what is IDStorage for" discussions to another thread (maybe the general IDStorage thread)? This thread is only one day old and it's already clogged with posts that do not add anything to the initial discussion.

[jas0nuk]

Thread cleaned up. Please post TECHNICAL info here and questions in the general IdStorage thread which is stickied in this section.

[SilverSpring]

Originally Posted by Chilly Willy

IdStorage is a special part of the firmware NOT in the normal flash areas. It's composed of "leafs" that contain 512 bytes of data. There can be at most 65520 of these leafs (also called keys by most folks), but Sony only uses about 128 of them currently. They hold various bits of info used by subsytems in the PSP. Things like the WIFI MAC address, levels for the battery, levels for the LCD brightness, etc. There's a thread here that goes into detail on the IdStorage. Read that for more info.

No IdStorage means loss of many functions related to WIFI, USB, and PS3 connectivity. The IdStorage is in every PSP and varies a little by motherboard revision. Each new mobo introduces a few more keys, and some existing keys have new content. So rebuilding the IdStorage will require knowledge about the mobo. Probably at first, the person will have to manually choose the mobo from a list.

Even then, some info cannot be found except by opening the PSP. The WIFI MAC address in key 0x44 is that way.

Just to clear some things up, max number of leaf's is only 480 (all that can fit on the nand - without doing some voodoo repartitioning stuffs). Idstorage area is only 256KB (ie. 512pages==16Blocks). Each leaf takes up 1 page (512Bytes), so then why cant you fit 512 leaf's in, because each leaf is mapped to a keyID (0x0044 for example) and these ID's are stored in an index. 2 pages are allocated to the index, so really that only leaves 510 pages left for the leaf's. However, due to another restriction, the index pages can only be stored at the start of a block (ie. the first 2 pages of a block). So really you only have 15Blocks left for actual leaf data (32pages per block and you end up having only 480 pages, hence only 480 maxium leafs).

The leaf's keyID however can be represented by any 16bit digit (from 0x0001-0xFFEF), you can choose to have whatever you wish in that range.

[nknave]

This is defenetly something to look at.

currently have a psp TA-082^ with corrupted keys all the way, once Pandora's Unbricked the flash and ipl, it will not boot up.

The simptoms are similar to a brick, except that the LCD screen is always lighted and the psp never power off.

If anyone here would like to contact me so you can have "certain files" from my psp for research, I will be happy to help out.

THX.

[l_oliveira]

I have a US TA-081, a US TA-082 and a JP TA-086 PSPs in full working state.
I'd like to help with the IDstorage research.

I also have the dump from the failed TA-079 board I posted pictures a few weeks ago...

Jas0nuk, which type of board your PSP has ? It has ID storage problems, right ?