PUP: Difference between revisions
CelesteBlue (talk | contribs) (→SCEWM) |
CelesteBlue (talk | contribs) (Remove Bert naming assumptions.) |
||
(49 intermediate revisions by 2 users not shown) | |||
Line 1: | Line 1: | ||
PUP files are update archives for the Vita. | PUP (Playstation Update Package) files are update archives for the PS3, PS Vita and PS4. | ||
= PUP Structure = | = PUP Structure = | ||
A good resource on the PUP structure can be found [https://www.psdevwiki.com/ps3/Playstation_Update_Package_(PUP) | A good resource on the PUP structure can be found [https://www.psdevwiki.com/ps3/Playstation_Update_Package_(PUP) here]. | ||
= Update .PKG files = | = Update .PKG files = | ||
Line 13: | Line 13: | ||
== Package Header == | == Package Header == | ||
Right after the [[Certified File]] header (usually at offset 0x400) is the update package header that provides information for piecing the component back together. The contents of this header is as follows: | Right after the [[Certified File]] header (usually at offset 0x300 or 0x400) is the update package header that provides information for piecing the component back together. The contents of this header is as follows: | ||
{| class="wikitable sortable" | {| class="wikitable sortable" | ||
Line 19: | Line 19: | ||
! Offset !! Size !! Description | ! Offset !! Size !! Description | ||
|- | |- | ||
| 0x0 || 0x4 || Version | | 0x0 || 0x4 || Version. 4 for PS Vita Update Packages. | ||
|- | |- | ||
| 0x4 || 0x4 || [[PUP#Type | | 0x4 || 0x4 || [[PUP#Type|Type]] | ||
|- | |- | ||
| 0x8 || 0x4 || [[PUP# | | 0x8 || 0x4 || [[PUP#Flag|Flag]] | ||
|- | |- | ||
| 0xC || 0x4 || | | 0xC || 0x4 || Target Hardware Info. For Ernie, Bic, Abby it is [[KBL Param#Hardware Info]], for Grover it is ES revision, for Motion it is some hardware version (6, 7), for Touch it is Touchscreen hardware version (0x800A). | ||
|- | |- | ||
| 0x10 || 0x8 || Update | | 0x10 || 0x8 || Update Version (System Firmware Version or Ernie Update Version). For Bic, Abby, it is <source lang="C">((battery_HWinfo << 0x10) | battery_FWinfo)</source>. | ||
|- | |- | ||
| 0x18 || 0x8 || Final (decompressed) | | 0x18 || 0x8 || Final size (decompressed) | ||
|- | |- | ||
| 0x20 || 0x8 || Decrypted size | | 0x20 || 0x8 || Decrypted size | ||
Line 35: | Line 35: | ||
| 0x28 || 0x4 || Flags requirements: 0 normal, 1 QA flag (sceQafMgrIsAllowQAUpdateForDriver) required, 2 manufacturing mode required | | 0x28 || 0x4 || Flags requirements: 0 normal, 1 QA flag (sceQafMgrIsAllowQAUpdateForDriver) required, 2 manufacturing mode required | ||
|- | |- | ||
| 0x2C || 0x4 || Platform: 0 all platforms accepted, 0x40000000 CEX | | 0x2C || 0x4 || Platform: 0 all platforms accepted, 1 Dolce (PSTV), 0x10000000 Test / Tool, 0x20000000 DEX, 0x40000000 CEX | ||
|- | |- | ||
| 0x30 || 0x4 || | | 0x30 || 0x4 || Downgrade barrier level. Before System Software version 1.692.000, always set to 0. Since System Software version 1.692.000, always set to 1 in os0 and slb2 SPKGs. Since FW 1.692.000 (but not in 1.692.000downversion) a check has been added in update_service_sm for this member. | ||
|- | |- | ||
| 0x34 || 0x4 || ? | | 0x34 || 0x4 || ? | ||
Line 63: | Line 63: | ||
|} | |} | ||
=== | === Flag === | ||
These bitflags indicate which products can install the package. | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
! Flag !! Description | ! Flag !! Description | ||
|- | |- | ||
| 0x10 || | | 0x1 || | ||
|- | |||
| 0x2 || | |||
|- | |||
| 0x4 || | |||
|- | |||
| 0x8 || | |||
|- | |||
| 0x10 || | |||
|- | |||
| 0x20 || | |||
|- | |- | ||
| | | 0x40 || | ||
|- | |- | ||
| | | 0x80 || | ||
|- | |||
| 0x100 || | |||
|- | |||
| 0x200 || | |||
|- | |||
| 0x400 || | |||
|- | |||
| 0x800 || | |||
|- | |||
| 0x4000 || | |||
|- | |||
| 0x8000 || | |||
|} | |} | ||
=== Type | === Type === | ||
The | The Type is used to identify the component of the update. | ||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
! Type | ! Type !! Description | ||
|- | |- | ||
| 0x0 || | | 0x0 || Reserved type. | ||
|- | |- | ||
| 0x1 || | | 0x1 || FAT16 image, <code>os0</code> [[Partitions|partition]] | ||
|- | |- | ||
| 0x2 || | | 0x2 || Error 0x800F0202 in InspectSpackage. | ||
|- | |- | ||
| 0x3 || | | 0x3 || Maybe permissions related to type 0x15. | ||
|- | |- | ||
| 0x4 || | | 0x4 || Permissions related to <code>vs0</code> [[Partitions|partition]] patch update TAR archive (type 0x16) | ||
|- | |- | ||
| 0x5 || | | 0x5 || Error 0x800F0202 in InspectSpackage. | ||
|- | |- | ||
| 0x6 || | | 0x6 || Error 0x800F0202 in InspectSpackage. | ||
|- | |- | ||
| 0x7 || | | 0x7 || Error 0x800F0202 in InspectSpackage. | ||
|- | |- | ||
| 0x8 || | | 0x8 || [[Syscon Update]] (0x9A54 run mode) | ||
|- | |- | ||
| 0x9 || | | 0x9 || [[SLB2]] image, [[Boot Sequence|secure bootloaders]] [[Partitions|partition]] | ||
|- | |- | ||
| 0xA || | | 0xA || FAT16 image, <code>vs0</code> [[Partitions|partition]] | ||
|- | |- | ||
| 0xB || | | 0xB || Cp Firmware | ||
|- | |- | ||
| 0xC || | | 0xC || Motion Firmware | ||
|- | |- | ||
| 0xD || | | 0xD || Bbmc related | ||
|- | |- | ||
| 0xE || | | 0xE || Error 0x800F0202 in InspectSpackage. | ||
|- | |- | ||
| 0xF || | | 0xF || Motion Firmware | ||
|- | |- | ||
| 0x10 || | | 0x10 || Touch Firmware | ||
|- | |- | ||
| 0x11 || | | 0x11 || Touch Config | ||
|- | |- | ||
| 0x12 || | | 0x12 || Bic Firmware (Battery IC) ?for Bic? | ||
|- | |- | ||
| 0x13 || | | 0x13 || Bic Firmware (Battery IC) ?for [[Abby]]? | ||
|- | |- | ||
| 0x14 || | | 0x14 || [[Syscon Update]] (0x3665 run mode) | ||
|- | |- | ||
| 0x15 || | | 0x15 || Maybe TAR archive, maybe patch update for <code>os0</code> [[Partitions|partition]]. | ||
|- | |- | ||
| 0x16 || | | 0x16 || TAR archive, patch update for <code>vs0</code> [[Partitions|partition]] | ||
|- | |- | ||
| 0x17 || | | 0x17 || FAT16 image, <code>sa0</code> [[Partitions|partition]]. For Tool Rev 9, "device stores manufacturing image" according to logs. | ||
|- | |- | ||
| 0x18 || | | 0x18 || <code>pd0</code> [[Partitions|partition]] | ||
|- | |- | ||
| 0x19 || | | 0x19 || [[Syscon Update]] (0xC5E7 run mode) | ||
|- | |- | ||
| 0x1A || | | 0x1A || Error 0x800F0202 in InspectSpackage. | ||
|- | |- | ||
| 0x1B || | | 0x1B || [[PSP Emulator]] lists. This type of SPKG is usually obtained from network and not contained in PUP. | ||
|} | |} | ||
=== | ==== Subroutines ==== | ||
The SPKG Type determines which decryption routine to use in [[SceSblUpdateMgr]]. There is a truth table to determine which ID can be handled by which decryption function. To see how this table is used, check out the [[Updater#Update_Package_Decryption_Code|example code]] for decrypting update packages. | |||
Tables for allowed for each operation. | |||
No to return 0x800F0202. | |||
{| class="wikitable" | {| class="wikitable" | ||
|- | |- | ||
! Type | ! Type !! InspectSpackage !! UpdateSpackage !! ExtractSpackage | ||
|- | |- | ||
| 0x0 || | | 0x0 || No || No || No | ||
|- | |- | ||
| 0x1 || | | 0x1 || Yes || Yes || No | ||
|- | |- | ||
| 0x2 || | | 0x2 || No || No || No | ||
|- | |- | ||
| 0x3 || | | 0x3 || No || No || Yes | ||
|- | |- | ||
| 0x4 || | | 0x4 || No || No || Yes | ||
|- | |- | ||
| 0x5 || | | 0x5 || No || No || No | ||
|- | |- | ||
| 0x6 || | | 0x6 || No || No || No | ||
|- | |- | ||
| 0x7 || | | 0x7 || No || No || No | ||
|- | |- | ||
| 0x8 || | | 0x8 || Yes || Yes || No | ||
|- | |- | ||
| 0x9 || | | 0x9 || Yes || Yes || No | ||
|- | |- | ||
| 0xA || | | 0xA || Yes || Yes || Yes | ||
|- | |- | ||
| 0xB || | | 0xB || Yes || Yes || No | ||
|- | |- | ||
| 0xC || | | 0xC || Yes || Yes || No | ||
|- | |- | ||
| 0xD || | | 0xD || Yes || Yes || No | ||
|- | |- | ||
| 0xE || | | 0xE || No || No || No | ||
|- | |- | ||
| 0xF || | | 0xF || Yes || Yes || No | ||
|- | |- | ||
| 0x10 || | | 0x10 || Yes || Yes || No | ||
|- | |- | ||
| 0x11 || | | 0x11 || Yes || Yes || No | ||
|- | |- | ||
| 0x12 || | | 0x12 || Yes || Yes || No | ||
|- | |- | ||
| 0x13 || | | 0x13 || Yes || Yes || No | ||
|- | |- | ||
| 0x14 || | | 0x14 || Yes || Yes || No | ||
|- | |- | ||
| 0x15 || | | 0x15 || Yes || Yes || Yes | ||
|- | |- | ||
| 0x16 || | | 0x16 || Yes || Yes || Yes | ||
|- | |- | ||
| 0x17 || | | 0x17 || Yes || Yes || Yes | ||
|- | |- | ||
| 0x18 || | | 0x18 || Yes || Yes || No | ||
|- | |- | ||
| 0x19 || | | 0x19 || Yes || Yes || No | ||
|- | |- | ||
| 0x1A || | | 0x1A || No || No || No | ||
|- | |- | ||
| 0x1B || | | 0x1B || No || No || Yes | ||
|} | |} | ||
= SCEWM = | = SCEWM = | ||
PUP Watermark was | SCEWM is a file embedded in the PUP to serve as a watermark. | ||
PUP Watermark is present since at least FW 0.931.010. It was not present on FW 0.902.000. Nevertheless, on FW 0.931.010 the PUP watermark is never verified. | |||
The SCEWM file is composed of 2 parts: | |||
* SCEWM header: size 0x20 bytes. | |||
* SCEWM body: size = file_size(usually 0x1000) - header_size(0x20). This part is encrypted. | |||
== Header == | == Header == | ||
Line 224: | Line 258: | ||
| 0x8 || 0x4 || Unknown (ex: 01 00 00 00) | | 0x8 || 0x4 || Unknown (ex: 01 00 00 00) | ||
|- | |- | ||
| 0xC || 0x4 || | | 0xC || 0x4 || File Size (usually 0x1000) | ||
|- | |- | ||
| 0x10 || 0x4 || | | 0x10 || 0x4 || Message length (ex: 0xD9, 0x5A) | ||
|- | |- | ||
| 0x14 || 0x4 || Unknown (ex: 01 00 00 00) | | 0x14 || 0x4 || Unknown (ex: 01 00 00 00) | ||
Line 235: | Line 269: | ||
|} | |} | ||
The | The message length for prototype/retail PUP is almost always 0x5A, see below why. | ||
== Body == | |||
The body is encrypted using AES128CBC with key and iv from update_service_sm.self. | |||
After decryption, the body is composed of 3 parts: | |||
* 0x100 bytes: RSA2048 signature of SHA256 of the PUP Header Digest. It is verified with SCEWM RSA public key. The PUP Header is independant of the watermark and so is the RSA signature. | |||
* 0xDE0 bytes: plaintext ASCII message (unique message per DevNet issue ID or build time). | |||
* 0x100 bytes: RSA2048 signature of SHA256 of 0xF00 bytes (SCEWM header + decrypted PUP Header Digest signature + decrypted message). It is verified with SCEWM RSA public key. | |||
== | === PUP Header Digest RSA Signature === | ||
It is RSA2048 of SHA256 of the PUP Header Digest. It is verified with SCEWM RSA public key. | |||
=== Watermark Message === | |||
==== Default Watermark Message ==== | |||
For external PUPs not bound to any developer, nor downloaded from DevNet, the watermark has the default message. | |||
Format for System Software versions 0.931.010-3.740.011: | |||
<pre> | |||
desc: default watermark | |||
id: build_team | |||
timestamp: YYYYMMDD_HHmmSS_JST | |||
host: build_machine | |||
</pre> | |||
==== Dummy Watermark Message ==== | |||
For internal PUPs not bound to any developer, nor downloaded from DevNet, the watermark has the dummy message. | |||
Here '??' represents a decimal number starting from '02'. | |||
Format for watermark id 0x71: | |||
<pre> | |||
desc: dummy watermark | |||
id: hoshi | |||
timestamp: DDD MMM DD HH:mm:SS JST YYYY | |||
host: p2bld-l??.build.rd.scei.sony.co.jp | |||
</pre> | |||
Format for watermark id 0x72: | |||
<pre> | |||
desc: dummy watermark | |||
id: hoshi | |||
timestamp: Fri Aug 16 07:36:14 JST 2019 | |||
host: p2bld-vl??.build.rd.scei.sony.co.jp | |||
</pre> | |||
Format for watermark id 0xAC: | |||
<pre> | |||
desc: dummy watermark | |||
HH:mm:SS JST YYYY | |||
host: p2bld-l??.build.rd.scei.sony.co.jp | |||
id: hoshi | |||
timestamp: DDD MMM DD HH:mm:SS JST YYYY | |||
host: p2bld-l??.build.rd.scei.sony.co.jp | |||
</pre> | |||
==== DevNet Watermark Message ==== | |||
For external PUPs bound to a company, downloaded from DevNet, the watermark has the DevNet message. | |||
The message is generated on developer demand by DevNet server. The message syntax has changed with DevNet revisions. | The watermark message is generated on developer's demand by DevNet server, written to the PUP, then the PUP download starts. The message syntax has changed with DevNet revisions. Old message was seen as early as 2011-07-29 and was replaced by a new message at some time between 2016-04-15 and 2018-04-23 after that SilicaAndPina leaked some DevKit/TestKit PS Vita PUP files. | ||
The message is | The watermark message is independant of the PUP. The same PUP (for example PS Vita 0.945.050 PUP) downloaded from DevNet in 2011 and in 2018 has different watermark message syntax but apart from Watermark (and maybe Additional Signature) is identical. | ||
Here 'x' represents an actual character, | Here 'x' represents an actual character, hidden here for confidentiality. | ||
==== Old | ===== Old DevNet Watermark Message ===== | ||
<pre> | <pre> | ||
Line 269: | Line 347: | ||
Org name:xxxxxxxxxxxxxx | Org name:xxxxxxxxxxxxxx | ||
Company name:xxxxxxxxxxxxxxxxxxxxxxxxxxxx | Company name:xxxxxxxxxxxxxxxxxxxxxxxxxxxx | ||
Date PUP downloaded: | Date PUP downloaded:YYYY-MM-DD HH:mm | ||
Host IP address:xxx.xxx.xxx.xxx | Host IP address:xxx.xxx.xxx.xxx | ||
</pre> | </pre> | ||
==== | ===== New DevNet Watermark Message ===== | ||
<pre> | <pre> | ||
Line 281: | Line 359: | ||
</pre> | </pre> | ||
=== Signature === | === SCEWM RSA Signature === | ||
It is RSA2048 of the | It is RSA2048 of SHA256 of 0xF00 bytes: the SCEWM header + the decrypted SCEWM body. It is verified with SCEWM RSA public key. | ||
== Security == | == Security == | ||
When comparing same PUP signed for two different issue IDs, we can notice only 2 differences: | When comparing the same PUP signed for two different issue IDs, we can notice only 2 differences: | ||
* the | * sometimes the message length in SCEWM header | ||
* the SCEWM unique data | * the SCEWM encrypted unique data: the blocks of the message that differ and the RSA signature of the watermark | ||
= SCEAS = | = SCEAS = | ||
This file contains Additional | This file contains Additional Signature(s) (A.S.) necessary for validation of the PUP. | ||
It was added | It was added on FW 0.996, probably for security reasons. This file is missing inside the Prototype DevKit PUP 0.945.040 (and all the pre-0.996 PUPs). | ||
The SCEAS file is composed of 2 parts: | |||
* SCEAS header: size 0x20 bytes. | |||
* SCEAS body: size = file_size(usually 0x1000) - header_size(0x20). This part is encrypted. | |||
== Header == | == Header == | ||
Line 308: | Line 388: | ||
|- | |- | ||
| 0x6 || 0x2 || ?Version? (ex: 00 01) | | 0x6 || 0x2 || ?Version? (ex: 00 01) | ||
|- | |||
| 0x8 || 0x4 || Unknown (ex: 01 00 00 00) | |||
|- | |- | ||
| 0xC || 0x4 || File Size (usually 0x400) | | 0xC || 0x4 || File Size (usually 0x400) | ||
|- | |- | ||
| 0x10 || 0x4 || Unknown | | 0x10 || 0x4 || Unknown (ex: 01 00 00 00) | ||
|- | |- | ||
| 0x14 || 0x4 || Unknown | | 0x14 || 0x4 || Unknown (ex: 01 00 00 00) | ||
|- | |- | ||
| 0x18 || 0x4 || Unknown | | 0x18 || 0x4 || Unknown (ex: 01 00 00 00) | ||
|- | |- | ||
| 0x1C || 0x4 || Certainly padding. | | 0x1C || 0x4 || Certainly padding. (ex: 00 00 00 00) | ||
|} | |} | ||
Line 324: | Line 406: | ||
The body is encrypted using AES128CBC with key and iv from update_service_sm.self. | The body is encrypted using AES128CBC with key and iv from update_service_sm.self. | ||
After decryption, the body is composed of 3 parts: | |||
*0x100 bytes: RSA2048 signature of something unknown (to reverse). It is verified with SCEAS RSA public key. | |||
*0x100 bytes: | *0x1E0 bytes: zeroes, maybe area for more than one signature, or just padding for decryption. | ||
*0x1E0 bytes: zeroes, maybe area for more than one signature | *0x100 bytes: RSA2048 signature of SHA256 of ?0x300 bytes (SCEAS header + decrypted unknown signature)?. It is verified with SCEAS RSA public key. | ||
*0x100 bytes: RSA2048 signature of | |||
[[Category:Formats]] | [[Category:Formats]] |
Latest revision as of 17:40, 6 January 2024
PUP (Playstation Update Package) files are update archives for the PS3, PS Vita and PS4.
PUP Structure
A good resource on the PUP structure can be found here.
Update .PKG files
Most of the files in the update PUP are .pkg files, a sort of Certified File.
Each component of the update is broken up into multiple parts, then optionally compressed, and finally encrypted into the PKG.
Package Header
Right after the Certified File header (usually at offset 0x300 or 0x400) is the update package header that provides information for piecing the component back together. The contents of this header is as follows:
Offset | Size | Description |
---|---|---|
0x0 | 0x4 | Version. 4 for PS Vita Update Packages. |
0x4 | 0x4 | Type |
0x8 | 0x4 | Flag |
0xC | 0x4 | Target Hardware Info. For Ernie, Bic, Abby it is KBL Param#Hardware Info, for Grover it is ES revision, for Motion it is some hardware version (6, 7), for Touch it is Touchscreen hardware version (0x800A). |
0x10 | 0x8 | Update Version (System Firmware Version or Ernie Update Version). For Bic, Abby, it is ((battery_HWinfo << 0x10) | battery_FWinfo). |
0x18 | 0x8 | Final size (decompressed) |
0x20 | 0x8 | Decrypted size |
0x28 | 0x4 | Flags requirements: 0 normal, 1 QA flag (sceQafMgrIsAllowQAUpdateForDriver) required, 2 manufacturing mode required |
0x2C | 0x4 | Platform: 0 all platforms accepted, 1 Dolce (PSTV), 0x10000000 Test / Tool, 0x20000000 DEX, 0x40000000 CEX |
0x30 | 0x4 | Downgrade barrier level. Before System Software version 1.692.000, always set to 0. Since System Software version 1.692.000, always set to 1 in os0 and slb2 SPKGs. Since FW 1.692.000 (but not in 1.692.000downversion) a check has been added in update_service_sm for this member. |
0x34 | 0x4 | ? |
0x38 | 0xC | ? |
0x3C | 0x4 | ? |
0x40 | 0x8 | ? |
0x48 | 0x8 | ? |
0x50 | 0x8 | Offset |
0x58 | 0x8 | Size |
0x60 | 0x8 | Chunk No (part index) |
0x68 | 0x8 | Total Chunks (total parts) |
0x70 | 0x8 | ? |
0x78 | 0x8 | ? |
Flag
These bitflags indicate which products can install the package.
Flag | Description |
---|---|
0x1 | |
0x2 | |
0x4 | |
0x8 | |
0x10 | |
0x20 | |
0x40 | |
0x80 | |
0x100 | |
0x200 | |
0x400 | |
0x800 | |
0x4000 | |
0x8000 |
Type
The Type is used to identify the component of the update.
Type | Description |
---|---|
0x0 | Reserved type. |
0x1 | FAT16 image, os0 partition
|
0x2 | Error 0x800F0202 in InspectSpackage. |
0x3 | Maybe permissions related to type 0x15. |
0x4 | Permissions related to vs0 partition patch update TAR archive (type 0x16)
|
0x5 | Error 0x800F0202 in InspectSpackage. |
0x6 | Error 0x800F0202 in InspectSpackage. |
0x7 | Error 0x800F0202 in InspectSpackage. |
0x8 | Syscon Update (0x9A54 run mode) |
0x9 | SLB2 image, secure bootloaders partition |
0xA | FAT16 image, vs0 partition
|
0xB | Cp Firmware |
0xC | Motion Firmware |
0xD | Bbmc related |
0xE | Error 0x800F0202 in InspectSpackage. |
0xF | Motion Firmware |
0x10 | Touch Firmware |
0x11 | Touch Config |
0x12 | Bic Firmware (Battery IC) ?for Bic? |
0x13 | Bic Firmware (Battery IC) ?for Abby? |
0x14 | Syscon Update (0x3665 run mode) |
0x15 | Maybe TAR archive, maybe patch update for os0 partition.
|
0x16 | TAR archive, patch update for vs0 partition
|
0x17 | FAT16 image, sa0 partition. For Tool Rev 9, "device stores manufacturing image" according to logs.
|
0x18 | pd0 partition
|
0x19 | Syscon Update (0xC5E7 run mode) |
0x1A | Error 0x800F0202 in InspectSpackage. |
0x1B | PSP Emulator lists. This type of SPKG is usually obtained from network and not contained in PUP. |
Subroutines
The SPKG Type determines which decryption routine to use in SceSblUpdateMgr. There is a truth table to determine which ID can be handled by which decryption function. To see how this table is used, check out the example code for decrypting update packages.
Tables for allowed for each operation.
No to return 0x800F0202.
Type | InspectSpackage | UpdateSpackage | ExtractSpackage |
---|---|---|---|
0x0 | No | No | No |
0x1 | Yes | Yes | No |
0x2 | No | No | No |
0x3 | No | No | Yes |
0x4 | No | No | Yes |
0x5 | No | No | No |
0x6 | No | No | No |
0x7 | No | No | No |
0x8 | Yes | Yes | No |
0x9 | Yes | Yes | No |
0xA | Yes | Yes | Yes |
0xB | Yes | Yes | No |
0xC | Yes | Yes | No |
0xD | Yes | Yes | No |
0xE | No | No | No |
0xF | Yes | Yes | No |
0x10 | Yes | Yes | No |
0x11 | Yes | Yes | No |
0x12 | Yes | Yes | No |
0x13 | Yes | Yes | No |
0x14 | Yes | Yes | No |
0x15 | Yes | Yes | Yes |
0x16 | Yes | Yes | Yes |
0x17 | Yes | Yes | Yes |
0x18 | Yes | Yes | No |
0x19 | Yes | Yes | No |
0x1A | No | No | No |
0x1B | No | No | Yes |
SCEWM
SCEWM is a file embedded in the PUP to serve as a watermark.
PUP Watermark is present since at least FW 0.931.010. It was not present on FW 0.902.000. Nevertheless, on FW 0.931.010 the PUP watermark is never verified.
The SCEWM file is composed of 2 parts:
- SCEWM header: size 0x20 bytes.
- SCEWM body: size = file_size(usually 0x1000) - header_size(0x20). This part is encrypted.
Header
This is a watermark for PUPs. For development PUPs, the Issue ID is unique to the company/organization the PUP is issued to.
Offset | Size | Description |
---|---|---|
0x0 | 0x6 | Magic ('SCEWM\0') |
0x6 | 0x2 | ?Version? (ex: 00 01) |
0x8 | 0x4 | Unknown (ex: 01 00 00 00) |
0xC | 0x4 | File Size (usually 0x1000) |
0x10 | 0x4 | Message length (ex: 0xD9, 0x5A) |
0x14 | 0x4 | Unknown (ex: 01 00 00 00) |
0x18 | 0x4 | Unknown (ex: 01 00 00 00) |
0x1C | 0x4 | Unknown (ex: 01 00 00 00) |
The message length for prototype/retail PUP is almost always 0x5A, see below why.
Body
The body is encrypted using AES128CBC with key and iv from update_service_sm.self.
After decryption, the body is composed of 3 parts:
- 0x100 bytes: RSA2048 signature of SHA256 of the PUP Header Digest. It is verified with SCEWM RSA public key. The PUP Header is independant of the watermark and so is the RSA signature.
- 0xDE0 bytes: plaintext ASCII message (unique message per DevNet issue ID or build time).
- 0x100 bytes: RSA2048 signature of SHA256 of 0xF00 bytes (SCEWM header + decrypted PUP Header Digest signature + decrypted message). It is verified with SCEWM RSA public key.
PUP Header Digest RSA Signature
It is RSA2048 of SHA256 of the PUP Header Digest. It is verified with SCEWM RSA public key.
Watermark Message
Default Watermark Message
For external PUPs not bound to any developer, nor downloaded from DevNet, the watermark has the default message.
Format for System Software versions 0.931.010-3.740.011:
desc: default watermark id: build_team timestamp: YYYYMMDD_HHmmSS_JST host: build_machine
Dummy Watermark Message
For internal PUPs not bound to any developer, nor downloaded from DevNet, the watermark has the dummy message.
Here '??' represents a decimal number starting from '02'.
Format for watermark id 0x71:
desc: dummy watermark id: hoshi timestamp: DDD MMM DD HH:mm:SS JST YYYY host: p2bld-l??.build.rd.scei.sony.co.jp
Format for watermark id 0x72:
desc: dummy watermark id: hoshi timestamp: Fri Aug 16 07:36:14 JST 2019 host: p2bld-vl??.build.rd.scei.sony.co.jp
Format for watermark id 0xAC:
desc: dummy watermark HH:mm:SS JST YYYY host: p2bld-l??.build.rd.scei.sony.co.jp id: hoshi timestamp: DDD MMM DD HH:mm:SS JST YYYY host: p2bld-l??.build.rd.scei.sony.co.jp
DevNet Watermark Message
For external PUPs bound to a company, downloaded from DevNet, the watermark has the DevNet message.
The watermark message is generated on developer's demand by DevNet server, written to the PUP, then the PUP download starts. The message syntax has changed with DevNet revisions. Old message was seen as early as 2011-07-29 and was replaced by a new message at some time between 2016-04-15 and 2018-04-23 after that SilicaAndPina leaked some DevKit/TestKit PS Vita PUP files.
The watermark message is independant of the PUP. The same PUP (for example PS Vita 0.945.050 PUP) downloaded from DevNet in 2011 and in 2018 has different watermark message syntax but apart from Watermark (and maybe Additional Signature) is identical.
Here 'x' represents an actual character, hidden here for confidentiality.
Old DevNet Watermark Message
# PUP watermark data that contain DevNet user id, org name, company name, date of PUP downloaded and host IP address User id:xxxxxx Org name:xxxxxxxxxxxxxx Company name:xxxxxxxxxxxxxxxxxxxxxxxxxxxx Date PUP downloaded:YYYY-MM-DD HH:mm Host IP address:xxx.xxx.xxx.xxx
New DevNet Watermark Message
# PUP watermark data contain a serial_number that associates with the user who download this PUP # Provide the serial number below to the DevNet development team to get user and org details. PUP serial number:xxxxxxxx
SCEWM RSA Signature
It is RSA2048 of SHA256 of 0xF00 bytes: the SCEWM header + the decrypted SCEWM body. It is verified with SCEWM RSA public key.
Security
When comparing the same PUP signed for two different issue IDs, we can notice only 2 differences:
- sometimes the message length in SCEWM header
- the SCEWM encrypted unique data: the blocks of the message that differ and the RSA signature of the watermark
SCEAS
This file contains Additional Signature(s) (A.S.) necessary for validation of the PUP.
It was added on FW 0.996, probably for security reasons. This file is missing inside the Prototype DevKit PUP 0.945.040 (and all the pre-0.996 PUPs).
The SCEAS file is composed of 2 parts:
- SCEAS header: size 0x20 bytes.
- SCEAS body: size = file_size(usually 0x1000) - header_size(0x20). This part is encrypted.
Header
Offset | Size | Description |
---|---|---|
0x0 | 0x6 | Magic ('SCEAS\0') |
0x6 | 0x2 | ?Version? (ex: 00 01) |
0x8 | 0x4 | Unknown (ex: 01 00 00 00) |
0xC | 0x4 | File Size (usually 0x400) |
0x10 | 0x4 | Unknown (ex: 01 00 00 00) |
0x14 | 0x4 | Unknown (ex: 01 00 00 00) |
0x18 | 0x4 | Unknown (ex: 01 00 00 00) |
0x1C | 0x4 | Certainly padding. (ex: 00 00 00 00) |
Body
The body is encrypted using AES128CBC with key and iv from update_service_sm.self.
After decryption, the body is composed of 3 parts:
- 0x100 bytes: RSA2048 signature of something unknown (to reverse). It is verified with SCEAS RSA public key.
- 0x1E0 bytes: zeroes, maybe area for more than one signature, or just padding for decryption.
- 0x100 bytes: RSA2048 signature of SHA256 of ?0x300 bytes (SCEAS header + decrypted unknown signature)?. It is verified with SCEAS RSA public key.