IDStorage: Difference between revisions

From PSP Developer wiki
Jump to navigation Jump to search
mNo edit summary
(→‎Key 0x054 Byte 3 Color Table: Added Radiant Red along with guesses at missing colors)
 
(6 intermediate revisions by 4 users not shown)
Line 45: Line 45:
= IDStorage certified sections =
= IDStorage certified sections =


IDStorage certified sections are a security measure for critical information. For example PSID and OpenPSID are certified (leaves 0x100, 0x101, 0x120, 0x121).
IDStorage certified sections are a security measure for critical information. For example PSID and OpenPSID are certified (leaves 0x100, 0x101, 0x120, 0x121). For PSPemu on PS3 and PS Vita, the same sort of certificates are contained in PS3 eEID and PS Vita ID Storage, and Kirk commands are implemented to handle them. Moreover, PS3 eEID certificates use almost the same structure and algorithms, whilst PS Vita extends block sizes from 128 to 192 and 256 bits.


KIRK command 0x12 is used to verify IDStorage certificates.
Kirk command 0x12 is used to verify IDStorage certificates.


== Structure ==
== Structure ==
Some of the leaves contain certificates similar in PSP, PS3 and PSVita.
Size is 0xB8 bytes: 0x10 bytes of data and 0xA8 bytes of certificate.


{|class="wikitable"
{|class="wikitable"
Line 73: Line 69:
| omac/cmac1 || 0x10 || hash of the previous information in CMAC1/OMAC mode
| omac/cmac1 || 0x10 || hash of the previous information in CMAC1/OMAC mode
|}
|}
<source lang="C">
typedef struct ECDSA160_signature { // size is 0x28
  unsigned char r[0x14];
  unsigned char s[0x14];
} ECDSA160_signature;
typedef struct ids_cert_main_psp { // size is 0xA8
char data[0x10];
char pub_key[0x28]; // ?generated using Kirk command 0xC? sent to Kirk command 0x11 for verification
ECDSA160_signature signature;
char constant_pub_key[0x28]; // hardcoded constant, same in all PSP consoles but depends on the certificate index in ID Storage
char enc_priv_key[0x20]; // decrypted and verified by Kirk command 0x10
} ids_cert_main_psp;
typedef struct ids_cert_psp { // size is 0xB8
ids_cert_main_psp cert_data; // data input for generating enc_aes_cmac_hash
char aes_cmac[0x10]; // verified by Kirk command 0x12
} ids_cert_psp;
</source>


= Content =
= Content =
 
{| class="wikitable"
!Key
!Information
!Unique?
|-
|0x4
|Baryon settings/information + extra data since TA-085v1
|Same per model
|-
|0x5
|Clockgen/I2C setup commands
|Same per model
|-
|0x6
|Battery, CPU frequency and general power settings + extra data since TA-085v1
|Same per model
|-
|0x7
|Unknown (exists since TA-085v1/TA-086, changed in TA-088)
|Yes
|-
|0x8
|Brightness hardware control (exists since TA-085v1/TA-086, changed in TA-085v2 and TA-088)
|Same per model
|-
|0x10
|MagicGate
|Yes
|-
|0x11
|MagicGate
|Yes
|-
|0x12
|MagicGate
|Same per model
|-
|0x13
|MagicGate
|Yes
|-
|0x40
|Contains the 0x5 bytes at 0x88 from key 0x10
|Yes
|-
|0x41
|USB (Driver type identifier) (slightly different since TA-085v1)
|Same per model
|-
|0x43
|USB (Device ID) (slightly different since TA-085v1)
|Same per model
|-
|0x44
|WLAN MAC Address (can be rebuilt using Noobz MAC Address Fixer)
|Yes
|-
|0x45
|WLAN Region (can be rebuilt using KeyCleaner)
|Partially
|-
|0x47
|Default parental lock level (first byte is 0x09, rest is empty)
|Same per model
|-
|0x50
|Serial number (not used since TA-082)
|Yes
|-
|0x51
|Firmware the PSP shipped with, and unknown unique data (exists since TA-085v1/TA-086)
|Yes
|-
|0x52
|Unused by PSP - Mostly the same per PSP except for slight variations, could be manufacturing info (exists since TA-085v1)
|Partially
|-
|0x54
|Default XMB background colour and original shell colour (exists since TA-085v1), see section below for more info
|Partially
|-
|0x100
|DNAS, VSH & Internet browser region, ad-hoc region (if missing, official updaters cannot run - error CTA80000025)
|Yes
|-
|0x101
|OpenPSID (non-indexed duplicate at [location of original + 0x8000])
|Yes
|-
|0x102
|UMD (non-indexed duplicate at [location of original + 0x8000])
|Yes
|-
|0x103
|UMD (non-indexed duplicate at [location of original + 0x8000])
|Yes
|-
|0x104
|UMD (non-indexed duplicate at [location of original + 0x8000])
|Yes
|-
|0x105
|UMD (non-indexed duplicate at [location of original + 0x8000])
|Yes
|-
|0x106
|UMD (non-indexed duplicate at [location of original + 0x8000])
|Yes
|-
|0x120-0x126
|Backup of respective 0x0100-106 key
|Yes
|-
|0x140
|Unknown unique data
|Yes
|}
* Leaves 0x100-0x11F are identical to their backup leaves 0x120-0x13F
* Leaves 0x100-0x11F are identical to their backup leaves 0x120-0x13F
* Old PSP revision haven't leaves 0x046, 0x047
* Old PSP revision haven't leaves 0x046, 0x047
* Very old PSP revisions haven't leaf 0x140
* Very old PSP revisions haven't leaf 0x140
* Leaf 0x50 is maybe Serial Number


= Uses =
= Uses =
Line 157: Line 288:
== Umdman ==
== Umdman ==


Umdman (umdman.prx) reads 1 leaf, 0x102. This leaf is related to the region, and is probably used to determine what UMD video's can be read on the PSP.
Umdman (umdman.prx) reads 5 leafs, 0x102, 0x103, 0x104, 0x105, 0x106, 0x107. The leaf 0x102 is related to the region, and is probably used to determine what UMD video's can be read on the PSP.


== USB ==
== USB ==
Line 256: Line 387:
0x046
0x046
  Empty, however vshmain uses the first byte of this leaf to set a param for vshImposeSetParam.  
  Empty, however vshmain uses the first byte of this leaf to set a param for vshImposeSetParam.  
== Key 0x054 ==
This key controls what the default background color is set to on initial setup and also denotes what color of shell the board shipped with. It was introduced with 02g and consists of 3 bytes on every retail model except 01g (non-existent) and 05g (4 bytes, needs more research). The first byte has 3 options: 00 sets the default color to the "By Month" option, 01 (or any other byte 1 value that's not 00 or 02) will set the color in hexadecimal order from 1-12.bmp or 13-27.bmp that matches byte 2, 02 (only found on 02g so far) will set the default color to a specified color depending on the value of byte 3 if byte 3 is between 00 and 06 (if byte 3 is 07 or higher, then functionality is the same as setting byte 1 to anything other than 00 or 02). Byte 2 can be any hexadecimal number between 00 and 21, anything higher than 21 will result in a default background of solid white with no visible wave. Byte 3 seems to be linked to the color of the original shell and increments chronologically as more colors were released.
A key 0x054 value of 020002 would be a 02g in Ice Silver with a default background color of 26 (middle dark gray/black option), a value of 010410 would be a Spirited Green system with a default background color of 5 (dark green), and a value of 00001D would be a Charcoal Black system that defaults to the "By Month" color option.
==== Key 0x054 Byte 3 Color Table ====
{| class="wikitable mw-collapsible mw-collapsed"
|+
!Byte 3
!Shell Color
!Special Color
(Byte 1 = 02)
!First Release (02g+)
|-
|00
|Piano Black
|26
|September 20th, 2007
|-
|01
|?Ceramic White?
|26
|September 20th, 2007
|-
|02
|Ice Silver
|26
|September 20th, 2007
|-
|03
|?Rose Pink?
|14
|September 20th, 2007
|-
|04
|?Lavender Purple?
|17
|September 20th, 2007
|-
|05
|Felicia Blue
|20
|September 20th, 2007
|-
|06
|?Mint Green?
|23
|February 28th, 2008
|-
|07
|?Deep Red?
|N/A
|December 13th, 2007
|-
|08
|?Matte Bronze?
|N/A
|April 24th, 2008
|-
|09
|
|N/A
|
|-
|0A
|
|N/A
|
|-
|0B
|Metallic Blue
|N/A
|July 17th, 2008
|-
|0C
|Pearl White
|N/A
|October 15th, 2008
|-
|0D
|Mystic Silver
|N/A
|October 14th, 2008
|-
|0E
|Vibrant Blue
|N/A
|March 5th, 2009
|-
|0F
|Radiant Red
|N/A
|March 5th, 2009
|-
|10
|Spirited Green
|N/A
|March 19th, 2009
|-
|11
|?Bright Yellow?
|N/A
|March 19th, 2009
|-
|12
|?Lilac Purple?
|N/A
|October 2009
|-
|13
|Turquoise Green
|N/A
|November 2009
|-
|14
|
|N/A
|
|-
|15
|Blossom Pink
|N/A
|November 2009
|-
|16
|
|N/A
|
|-
|17
|
|N/A
|
|-
|18
|?Black/Red?
|N/A
|February 10, 2011
|-
|19
|?White/Blue?
|N/A
|February 10, 2011
|-
|1A
|Monster Hunter Portable 3rd Hunters Lm. Ed. (3000MHB)
|N/A
|December 1, 2010
|-
|1B
|Camouflage (MGS Peace Walker 3000)
|N/A
|March 18, 2011
|-
|1C
|
|N/A
|
|-
|1D
|Charcoal Black
|N/A
|October 26, 2011
|-
|1E
|Red/Black
|N/A
|November 17, 2011
|-
|1F
|?Sky Blue/Marine Blue?
|N/A
|April 26, 2012
|-
|20
|Ice White
|N/A
|July 2012
|}
<nowiki>*</nowiki>Shell color entries with question marks are guesses based on release date and special color value and need to be verified.


= Legality of distribution =
= Legality of distribution =

Latest revision as of 00:08, 2 December 2024

Location[edit | edit source]

PSP[edit | edit source]

IDStorage area is located after the IPL on the NAND at offset 0xC0000.

Description[edit | edit source]

It is used to store low-level information, such as the serial, MAC address, UMD, WLAN and region.

The IDStorage area is an associative array and information is stored using key/value pairs (index/leaf). The IDStorage seems a little coupled to the physical storage as each leaf is mapped to an area of 512-byte, which is equal to the pagesize of the PSP standard NAND flash, and it seems 512-byte page operations are intended.

Structure[edit | edit source]

Idstorage leaves are all 512 bytes. Most IDStorage leaves have a pair, although some do not.

Idstorage leaves indexes are 16-bit integers and are stored in an index table of two NAND pages of 512 bytes.

  • The index is identified by byte 6 of the spare area (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.

For example, an index appearing at position 27 (byte 54) in the index table would find its associated data at the NAND offset: 0xC0000 + (27 * 512) = 0xC3600.

Importance in OS[edit | edit source]

As major functions such as UMD decryption, Ad Hoc and DNAS Authentication rely on IDStorage leaves, the loss or corruption of leaves 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.

The firmware provides a driver to facilitate manipulations. In PSP: idstorage.prx. In PSVita: idstorage.skprx.

Generation[edit | edit source]

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.

IDStorage certified sections[edit | edit source]

IDStorage certified sections are a security measure for critical information. For example PSID and OpenPSID are certified (leaves 0x100, 0x101, 0x120, 0x121). For PSPemu on PS3 and PS Vita, the same sort of certificates are contained in PS3 eEID and PS Vita ID Storage, and Kirk commands are implemented to handle them. Moreover, PS3 eEID certificates use almost the same structure and algorithms, whilst PS Vita extends block sizes from 128 to 192 and 256 bits.

Kirk command 0x12 is used to verify IDStorage certificates.

Structure[edit | edit source]

Name Size Description
Data 0x10 contains the actual data (either PSID or OpenPSID)
plaintext public key 0x28 contains the certificate's public key (without padding)
R 0x14 part of the ECDSA signature pair (R, S)
S 0x14 part of the ECDSA signature pair (R, S)
public key 0x28 ECDSA public key (unknown what this is doing here)
encrypted private key 0x20 encrypted blob that contains the certificate's private key (with padding)
omac/cmac1 0x10 hash of the previous information in CMAC1/OMAC mode 
typedef struct ECDSA160_signature { // size is 0x28
   unsigned char r[0x14];
   unsigned char s[0x14];
} ECDSA160_signature;

typedef struct ids_cert_main_psp { // size is 0xA8
char data[0x10];
char pub_key[0x28]; // ?generated using Kirk command 0xC? sent to Kirk command 0x11 for verification
ECDSA160_signature signature;
char constant_pub_key[0x28]; // hardcoded constant, same in all PSP consoles but depends on the certificate index in ID Storage
char enc_priv_key[0x20]; // decrypted and verified by Kirk command 0x10
} ids_cert_main_psp;

typedef struct ids_cert_psp { // size is 0xB8
ids_cert_main_psp cert_data; // data input for generating enc_aes_cmac_hash
char aes_cmac[0x10]; // verified by Kirk command 0x12
} ids_cert_psp;

Content[edit | edit source]

Key Information Unique?
0x4 Baryon settings/information + extra data since TA-085v1 Same per model
0x5 Clockgen/I2C setup commands Same per model
0x6 Battery, CPU frequency and general power settings + extra data since TA-085v1 Same per model
0x7 Unknown (exists since TA-085v1/TA-086, changed in TA-088) Yes
0x8 Brightness hardware control (exists since TA-085v1/TA-086, changed in TA-085v2 and TA-088) Same per model
0x10 MagicGate Yes
0x11 MagicGate Yes
0x12 MagicGate Same per model
0x13 MagicGate Yes
0x40 Contains the 0x5 bytes at 0x88 from key 0x10 Yes
0x41 USB (Driver type identifier) (slightly different since TA-085v1) Same per model
0x43 USB (Device ID) (slightly different since TA-085v1) Same per model
0x44 WLAN MAC Address (can be rebuilt using Noobz MAC Address Fixer) Yes
0x45 WLAN Region (can be rebuilt using KeyCleaner) Partially
0x47 Default parental lock level (first byte is 0x09, rest is empty) Same per model
0x50 Serial number (not used since TA-082) Yes
0x51 Firmware the PSP shipped with, and unknown unique data (exists since TA-085v1/TA-086) Yes
0x52 Unused by PSP - Mostly the same per PSP except for slight variations, could be manufacturing info (exists since TA-085v1) Partially
0x54 Default XMB background colour and original shell colour (exists since TA-085v1), see section below for more info Partially
0x100 DNAS, VSH & Internet browser region, ad-hoc region (if missing, official updaters cannot run - error CTA80000025) Yes
0x101 OpenPSID (non-indexed duplicate at [location of original + 0x8000]) Yes
0x102 UMD (non-indexed duplicate at [location of original + 0x8000]) Yes
0x103 UMD (non-indexed duplicate at [location of original + 0x8000]) Yes
0x104 UMD (non-indexed duplicate at [location of original + 0x8000]) Yes
0x105 UMD (non-indexed duplicate at [location of original + 0x8000]) Yes
0x106 UMD (non-indexed duplicate at [location of original + 0x8000]) Yes
0x120-0x126 Backup of respective 0x0100-106 key Yes
0x140 Unknown unique data Yes
  • Leaves 0x100-0x11F are identical to their backup leaves 0x120-0x13F
  • Old PSP revision haven't leaves 0x046, 0x047
  • Very old PSP revisions haven't leaf 0x140

Uses[edit | edit source]

IPL[edit | edit source]

The Stage 2 IPL (main.bin) reads 3 leaves, 0x004, 0x005 and 0x006. These leaves play a significant part in the PSP as they are related to power. In TA-082 and TA-086 PSP's, these leaves 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[edit | edit source]

sceChkregGetPsCode[edit | edit source]

Chkreg (chkreg.prx) reads 2 leaves, 0x100 and 0x102 or 0x120 and 0x122.

It gets PSID from the IdStorage and convert it to PsCode.

Example of PSP PsCode: 00 00 00 01 00 03 00 01

The return from sceChkregGetPsCode is determined to be valid or invalid via KIRK command 0x12, just like other functions using leaves 0x100, 0x120.

openpsid.prx[edit | edit source]

sceOpenPSIDGetPSID[edit | edit source]

sceOpenPSIDGetPSID first reads leaf 0x100 or 0x120 into a buffer using sceIdStorageLookup with the following args: 

sceIdStorageLookup(0x120, 0x38, buf, 0xB8); // ???offset to check???

The buffer is then sent to KIRK using sceUtilsBufferCopyWithRange with the following args: 

sceUtilsBufferCopyWithRange(0, 0, buf, 0xB8, 0x12);

It sends data to 2 modules: 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.

sceOpenPSIDGetOpenPSID[edit | edit source]

OpenPSID (openpsid.prx) reads 2 leaves, both relating to the region: 0x101 or 0x121 and 0x102 or 0x122. The OpenPSID is calculated via the above leaves 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 it fails again, it returns 0xC0520002.

The buffer is then passed to sceUtilsBufferCopyWithRange with the following args: 

sceUtilsBufferCopyWithRange(0, 0, buf, 0xB8, 0x12);

If the sceUtilsBufferCopyWithRange returns 1, OpenPSID returns 0xC0520001, else it returns 0.

Memab[edit | edit source]

Memab (memab.prx) reads 1 leaf, 0x100 or 0x120.

Mgr (mgr.prx) reads 2 leaves, 0x040 and another unknown leaf.

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

Power[edit | edit source]

Power (power.prx) reads 1 leaf, 0x0004. This leaf is related to power and is also read by the IPL.

Umdman[edit | edit source]

Umdman (umdman.prx) reads 5 leafs, 0x102, 0x103, 0x104, 0x105, 0x106, 0x107. The leaf 0x102 is related to the region, and is probably used to determine what UMD video's can be read on the PSP.

USB[edit | edit source]

usb.prx[edit | edit source]

USB (usb.prx) reads 1 leaf, 0x041. This leaf 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[edit | edit source]

USBstor (usbstor.prx) reads 1 leaf, ?0x040 or 0x043?.

?0x040 or 0x043? 

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[edit | edit source]

WLAN (wlan.prx) reads 2 leaves, 0x044 and 0x045.

0x044 

0000000000  00 16 FE 86 FA 28                                .....(

0x045 

0000000000  03 00 01                                         ...

These leaves 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[edit | edit source]

Sysconf_plugin (sysconf_plugin.prx) reads 1 leaf, 0x044. This is probably why the VSH displays a different MAC address when leaves 0x044/0x045 are changed.

Vshmain[edit | edit source]

Vshmain (vshmain.prx) reads 1 leaf, 0x046.

0x046 

Empty, however vshmain uses the first byte of this leaf to set a param for vshImposeSetParam.

Key 0x054[edit | edit source]

This key controls what the default background color is set to on initial setup and also denotes what color of shell the board shipped with. It was introduced with 02g and consists of 3 bytes on every retail model except 01g (non-existent) and 05g (4 bytes, needs more research). The first byte has 3 options: 00 sets the default color to the "By Month" option, 01 (or any other byte 1 value that's not 00 or 02) will set the color in hexadecimal order from 1-12.bmp or 13-27.bmp that matches byte 2, 02 (only found on 02g so far) will set the default color to a specified color depending on the value of byte 3 if byte 3 is between 00 and 06 (if byte 3 is 07 or higher, then functionality is the same as setting byte 1 to anything other than 00 or 02). Byte 2 can be any hexadecimal number between 00 and 21, anything higher than 21 will result in a default background of solid white with no visible wave. Byte 3 seems to be linked to the color of the original shell and increments chronologically as more colors were released.

A key 0x054 value of 020002 would be a 02g in Ice Silver with a default background color of 26 (middle dark gray/black option), a value of 010410 would be a Spirited Green system with a default background color of 5 (dark green), and a value of 00001D would be a Charcoal Black system that defaults to the "By Month" color option.

Key 0x054 Byte 3 Color Table[edit | edit source]

Byte 3 Shell Color Special Color

(Byte 1 = 02)

First Release (02g+)
00 Piano Black 26 September 20th, 2007
01 ?Ceramic White? 26 September 20th, 2007
02 Ice Silver 26 September 20th, 2007
03 ?Rose Pink? 14 September 20th, 2007
04 ?Lavender Purple? 17 September 20th, 2007
05 Felicia Blue 20 September 20th, 2007
06 ?Mint Green? 23 February 28th, 2008
07 ?Deep Red? N/A December 13th, 2007
08 ?Matte Bronze? N/A April 24th, 2008
09 N/A
0A N/A
0B Metallic Blue N/A July 17th, 2008
0C Pearl White N/A October 15th, 2008
0D Mystic Silver N/A October 14th, 2008
0E Vibrant Blue N/A March 5th, 2009
0F Radiant Red N/A March 5th, 2009
10 Spirited Green N/A March 19th, 2009
11 ?Bright Yellow? N/A March 19th, 2009
12 ?Lilac Purple? N/A October 2009
13 Turquoise Green N/A November 2009
14 N/A
15 Blossom Pink N/A November 2009
16 N/A
17 N/A
18 ?Black/Red? N/A February 10, 2011
19 ?White/Blue? N/A February 10, 2011
1A Monster Hunter Portable 3rd Hunters Lm. Ed. (3000MHB) N/A December 1, 2010
1B Camouflage (MGS Peace Walker 3000) N/A March 18, 2011
1C N/A
1D Charcoal Black N/A October 26, 2011
1E Red/Black N/A November 17, 2011
1F ?Sky Blue/Marine Blue? N/A April 26, 2012
20 Ice White N/A July 2012

*Shell color entries with question marks are guesses based on release date and special color value and need to be verified.

Legality of distribution[edit | edit source]

There is question as to whether Sony are able to take legal action against those found to be distributing IDStorage leaves among the community, for research, repair, or otherwise. The worry is that the leaves are proprietary data (particularly UMD decryption leaves).

Useful links[edit | edit source]

Retrieved from "http://www.psdevwiki.com/psp/index.php?title=IDStorage&oldid=12759"