IDStorage
IDStorage is located after the IPL on the nand at 0xC0000, and is used to store low-level information on the PSP, such as the serial, MAC address, UMD, WLAN and region. Most idstorage keys have a pair, although some do not (explained later.) Idstorage keys are 512(+16) bytes and are stored in an index of two nand pages (512 bytes.) Nand pages are also 515(+16 spare area) bytes. The index of idstorage is identified by byte 6 of the spare (0x73), byte 7 is the idstorage version, byte is either 1 or 0; depending on whether the idstorage has been formatted or not (???), and finally byte 9 indicates if the idstorage is read-only or not.
Idstorage keys are 16 bit integers and are stored in the corresponding user areas. For example, a key appearing at position 27 (byte 54) in the index would find its associated data at the location:0xc0000 + (27 * 512) = 0xC3600
Importance to PSP Functions
As major functions such as UMD Decryption, Ad Hoc and DNAS Authentication rely on IDStorage keys, the loss or corruption of keys can be crippling to the usability of the PSP. Users are strongly recommended to take a NAND Backup, giving them the opportunity to restore their IDStorage using a tool such as NandTool.
Generation
Most of the idstorage generation process is detailed in Despertar Del Cementerio (sources available here: https://github.com/mathieulh/Despertar-Del-Cementerio).
- some PSP JigKick files contain information on how to (re)generate idstorage leaves
- DespertarDelCementerio v7 also contains information about idstorage (re)generation.
- the most significant module used by DCv7 used to do this is idsregeneration.prx
(see DCv7 src code https://github.com/mathieulh/Despertar-Del-Cementerio/tree/master/idsregeneration).
- you can see a plethora of "templates" which are used for the generation of the idstorage sections.
- the idstorage regeneration requires 2, probably more parameters -> Region, MAC Address, and likely a timestamp of sorts.
- on ps3 the generation method wasn't found on the JigKick firmware files (and selfs). however, it seems that factory still does this, but by accessing a server, so the information cannot be deduced anymore unless there's access to the server.
- together with the idps (called PSID on PSP), the openPSID is also generated on PSP (written to IdStorage).
- there are 12 sections on PSP, unlike the 11 ones on PS3 EID0.
Uses
IPL
The Stage 2 IPL (main.bin) reads 3 keys from the idstorage, 0x004, 0x005 and 0x006. These keys play a significant part in the PSP as they are related to power. In TA-082 and TA-086 PSP's, these keys are at different locations, causing a brick with the 1.50 IPL.
0x004
0000000000 6E 79 72 42 01 00 00 00-10 00 00 00 BB 01 AB 1F nyrB............ 0000000016 D8 00 24 00 14 31 14 00-94 01 48 00 D8 00 00 00 ..$..1....H.....
0x005
0000000000 67 68 6C 43 01 00 00 00-01 00 00 00 CA D9 E3 9B ghlC............ 0000000016 0A 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 ................
0x006
0000000000 72 64 44 4D 01 00 00 00-07 00 00 00 85 BD 2C 75 rdDM..........,u 0000000016 00 00 00 85 83 81 80 00-00 00 00 00 00 00 00 00 ................
Chkreg.prx
sceChkregGetPsCode
Chkreg (chkreg.prx) reads 2 keys... 0x100 and 0x102 or 0x120 and 0x122 all contain the return of sceChkregGetPsCode 3 times. exempl of PsCode: 0x00 0x00 0x00 0x01 0x00 0x03 0x00 0x01
openpsid.prx
sceOpenPSIDGetPSID
0000000048 00 00 00 01 00 03 00 01 ........ 0000000240 00 00 00 01 00 03 00 01 ........ 0000000416 00 00 00 01 00 03 00 01 ........
(Highlighted Byte - 01 for Development Tool, 02 for Testing Tool, 03 for Japan, 04 for USA, 05 for Europe/Africa, 06 for Korea, 09 for Australia/New Zealand, 0A for Hong Kong and Singapore, 0E for DTP-L1500)
The rest of key is filled with random data, which is unique to each PSP. If this data is changed, sceChkregGetPsCode will return: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00, meaning an invalid region. The data above is also the return of getpscode inside vshbridge.prx and chkreg.prx. The return from sceChkregGetPsCode is determined to be valid or invalid via sceUtilsBufferCopyWithRange and OpenPSID... sceOpenPSIDGetPSID first reads 0x100 or 0x120 into a buffer, this buffer is then sent to sceUtilsBufferCopyWithRange (the same as OpenPSID) with the following args:
sceUtilsBufferCopyWithRange(0, 0, scrambled_buf, 0xB8, 0x12);
Arg 1 - Destination. ?? Arg 2 - size. ?? Arg 3 - Buffer 0x100 or 0x120 was read into and is 512 bytes. Arg 4 - Length. ?? Arg 5 - KIRK key
It sends data to 2 modules, these are OpenPSID and memab. Once the scrambled buffer has been sent, "some check" is performed. If sceUtilsBufferCopyWithRange is sucessful, this part of sceChkregGetPsCode returns 0, else it returns 0x80000108.
sceOpenPSIDGetPSID reads 0x120 using sceIdStorageLookup with the following args:
sceIdStorageLookup(0x120, 0x38, scrambled_buf, 0xB8); Arg 1 - Idstorage key. Arg 2 - Offset within the 512 byte leaf. The 1st occurrence of the region (sceChkregGetPsCode) is at 0x38, the second at 0xF0 and the third at 0x1A8. Each occurrence is 0xAF (175 bytes) apart. Arg 3 - Buffer. Arg 4 - Length.
sceOpenPSIDGetOpenPSID
OpenPSID (openpsid.prx) reads 2 keys, both relating to the region: 0x101 or 0x121 and 0x102 or 0x122. The OpenPSID is calculated via the above keys and sceUtilsBufferCopyWithRange. It first reads 0x101 or 0x121 into a buffer, if this fails it returns 0xC0520001 and reads 0x102 or 0x122 into the buffer, if thisfails again, it returns 0xC0520002. This is then passed to sceUtilsBufferCopyWithRange with the following args:
sceUtilsBufferCopyWithRange(0, 0, buf, 0xB8, 0x12);
The args are explained above. If the function returns 1, OpenPSID returns 0x0xC0520001, else it returns 0.
Memab
Memab (memab.prx) reads 1 key... once again being 0x100 or 0x120.
Mgr (mgr.prx) reads 2 keys.
0x040
00000001E0 03 86 00 20 F8 47 90 88-58 99 2E 88 F8 47 90 88 ... .G..X....G.. 00000001F0 25 00 00 00 64 99 2E 88-01 00 00 00 D0 99 2E 88 %...d...........
Another unknown key.
Power
Power (power.prx) reads 1 key, 0x0004. This key is related to power and is also read by the IPL.
Umdman
Umdman (umdman.prx) reads 1 key, 0x102. This key is related to the region, and is probably used to determine what UMD video's can be read on the PSP.
USB
usb.prx
USB (usb.prx) reads 1 key, 0x041. This key has information on the USB types.
0x041
0000000000 4C 05 00 00 0A 03 53 00-6F 00 6E 00 79 00 00 00 L.....S.o.n.y... 0000000064 00 00 00 00 05 00 00 00-C8 01 00 00 16 03 50 00 ..............P. 0000000080 53 00 50 00 20 00 54 00-79 00 70 00 65 00 20 00 S.P. .T.y.p.e. . 0000000096 41 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 A............... 0000000128 00 00 00 00 00 00 00 00-00 00 00 00 C9 01 00 00 ................ 0000000144 16 03 50 00 53 00 50 00-20 00 54 00 79 00 70 00 ..P.S.P. .T.y.p. 0000000160 65 00 20 00 42 00 00 00-00 00 00 00 00 00 00 00 e. .B........... 0000000208 CA 01 00 00 16 03 50 00-53 00 50 00 20 00 54 00 ......P.S.P. .T. 0000000224 79 00 70 00 65 00 20 00-43 00 00 00 00 00 00 00 y.p.e. .C....... 0000000272 00 00 00 00 CB 01 00 00-16 03 50 00 53 00 50 00 ..........P.S.P. 0000000288 20 00 54 00 79 00 70 00-65 00 20 00 44 00 00 00 .T.y.p.e. .D... 0000000336 00 00 00 00 00 00 00 00-CC 01 00 00 16 03 50 00 ..............P. 0000000352 53 00 50 00 20 00 54 00-79 00 70 00 65 00 20 00 S.P. .T.y.p.e. . 0000000368 45 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 E...............
Offset Description Data
0x0000 idVendor 0x4C 0x05
0x0002 ??? 0x00 0x00
0x0004 bLength 0x0A
0x0005 ??? 0x03
0x0006 iManufacturer String 0x53 0x00 0x6F 0x00 0x6E 0x00 0x79
0x0044 ? bNum 0x05
0x0045 ??? 0x00 0x00 0x00
0x0048 idProduct 0xC8 0x01
0x004A ??? 0x00 0x00
0x004C bLength 0x16
0x004D ? bDescriptorType 0x03
0x004E iProduct String 0x50 0x00 0x53 0x00 0x50 0x00 0x20
0x00 0x54 0x00 0x79 0x00 0x70 0x00
0x65 0x00 0x20 0x00 0x41
0x008C idProduct 0xC9 0x01
0x008E ??? 0x00 0x00
0x0090 bLength 0x16
0x0091 ? bDescriptorType 0x03
0x0092 iProduct String 0x50 0x00 0x53 0x00 0x50 0x00 0x20
0x00 0x54 0x00 0x79 0x00 0x70 0x00
0x65 0x00 0x20 0x00 0x42
0x00D0 idProduct 0xCA 0x01
0x00D2 ??? 0x00 0x00
0x00D4 bLength 0x16
0x00D5 ? bDescriptorType 0x03
0x00D6 iProduct String 0x50 0x00 0x53 0x00 0x50 0x00 0x20
0x00 0x54 0x00 0x79 0x00 0x70 0x00
0x65 0x00 0x20 0x00 0x43
0x0114 idProduct 0xCB 0x01
0x0116 ??? 0x00 0x00
0x0118 bLength 0x16
0x0119 ? bDescriptorType 0x03
0x011A iProduct String 0x50 0x00 0x53 0x00 0x50 0x00 0x20
0x00 0x54 0x00 0x79 0x00 0x70 0x00
0x65 0x00 0x20 0x00 0x44
0x0158 idProduct 0xCC 0x01
0x015A ??? 0x00 0x00
0x015C bLength 0x16
0x015D ? bDescriptorType 0x03
0x015E iProduct String 0x50 0x00 0x53 0x00 0x50 0x00 0x20
0x00 0x54 0x00 0x79 0x00 0x70 0x00
0x65 0x00 0x20 0x00 0x45
usbstor.prx
USBstor (usbstor.prx) reads 1 key, 0x043.
0x040
0000000000 55 73 74 72 53 6F 6E 79-20 20 20 20 50 53 50 20 UstrSony PSP 0000000016 20 20 20 20 20 20 20 20-20 20 20 20 31 2E 30 30 1.00 0000000032 50 00 53 00 50 00 00 00-00 00 00 00 00 00 00 00 P.S.P...........
WLAN
WLAN (wlan.prx) reads 2 keys, 0x044 and 0x045.
0x044
0000000000 00 16 FE 86 FA 28 .....(
0x045
0000000000 03 00 01 ...
This key contains the MAC address of the PSP. This can be changed, but does not effect the hardware, only the address displayed under System Information.
Sysconf_plugin
Sysconf_plugin (sysconf_plugin.prx) reads 1 key, 0x044. This is probably why the VSH displays a different MAC address when 0x044 is changed.
Vshmain
Vshmain (vshmain.prx) reads 1 key, 0x046.
0x046
Empty, however vshmain uses the first byte of this key to set a param for vshImposeSetParam.
Legality of Distribution
There is question as to whether Sony are able to take legal action against those found to be distributing IDStorage keys among the community, for research, repair, or otherwise. The worry is that the keys are proprietary data (particularly UMD Decryption keys).