PUP: Difference between revisions

From Vita Development Wiki
Jump to navigation Jump to search
(Remove Bert naming assumptions.)
 
(62 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 Header ==
= PUP Structure =
A good resource on the PUP header can be found [https://playstationdev.wiki/psvitadevwiki/index.php?title=Playstation_Update_Package_(PUP) HERE].


=== Filename IDs ===
A good resource on the PUP structure can be found [https://www.psdevwiki.com/ps3/Playstation_Update_Package_(PUP) here].
It is a mistake to try to connect a file entry ID to any specific file. A better way of organizing the update contents is through the extracted [[SCE]] encrypted file header. Nevertheless, there are certain file entry IDs that have been linked with the same data throughout all observed update packages.


{| class="wikitable sortable"
= Update .PKG files =
! File Entry ID !! Description
 
|-
Most of the files in the update PUP are .pkg files, a sort of [[Certified File]].
| 0x100 || Version string
 
|-
Each component of the update is broken up into multiple parts, then optionally compressed, and finally encrypted into the PKG.
| 0x101 || License XML
 
|-
== Package Header ==
| 0x200 || <code>psp2swu.self</code>, main [[Updater|updater]]
 
|-
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:
| 0x204 || <code>cui_setupper.self</code>, development [[Updater|updater]] initializer
|-
| 0x400 || Watermark. Same ID for retail PUPs. Different IDs for dev PUPs for each developer.
|-
| 0x401 || Unknown SCEAS magic file
|-
| 0x2005 || CP firmware in early debug updates only
|-
| 0x2006 || CP firmware in debug updates only
|}


== Package Headers ==
Most of the files in the update PUP are [[SCE]] encrypted. Each component of the update is broken up into multiple parts, then optionally compressed, and finally encrypted into the SCE file. Right after the SCE header (usually offset 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"
|-
|-
! Offset !! Size !! Description
! Offset !! Size !! Description
|-
|-
| 0x0 || 0x4 || Version (0x4)
| 0x0 || 0x4 || Version. 4 for PS Vita Update Packages.
|-
|-
| 0x4 || 0x4 || [[PUP#Type ID|Type ID]]
| 0x4 || 0x4 || [[PUP#Type|Type]]
|-
|-
| 0x8 || 0x4 || [[PUP#Flags|Flags]]
| 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 FW Version
| 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) size
| 0x18 || 0x8 || Final size (decompressed)
|-
|-
| 0x20 || 0x8 || Decrypted size
| 0x20 || 0x8 || Decrypted size
|-
|-
| 0x28 || 0x8 || ?
| 0x28 || 0x4 || Flags requirements: 0 normal, 1 QA flag (sceQafMgrIsAllowQAUpdateForDriver) required, 2 manufacturing mode required
|-
|-
| 0x30 || 0x4 || ?
| 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 || ?
| 0x34 || 0x4 || ?
Line 65: Line 53:
| 0x58 || 0x8 || Size
| 0x58 || 0x8 || Size
|-
|-
| 0x60 || 0x8 || Part Index
| 0x60 || 0x8 || Chunk No (part index)
|-
|-
| 0x68 || 0x8 || Total Parts
| 0x68 || 0x8 || Total Chunks (total parts)
|-
|-
| 0x70 || 0x8 || ?
| 0x70 || 0x8 || ?
Line 74: Line 62:
|-
|-
|}
|}
=== Flags ===
 
There are flags that are set in the package header. Some potential ones are listed here.
=== Flag ===
 
These bitflags indicate which products can install the package.
 
{| class="wikitable"
{| class="wikitable"
|-
|-
! Flag !! Description
! Flag !! Description
|-
|-
| 0x10 || Set when compressed
| 0x1 ||  
|-
|-
| 0x2 || Has multiple parts
| 0x2 ||  
|-
|-
| 0x1 || Set when compressed
| 0x4 ||  
|-
|-
| 0x8 ||
|-
| 0x10 ||
|-
| 0x20 ||
|-
| 0x40 ||
|-
| 0x80 ||
|-
| 0x100 ||
|-
| 0x200 ||
|-
| 0x400 ||
|-
| 0x800 ||
|-
| 0x4000 ||
|-
| 0x8000 ||
|}
|}


=== Type ID ===
=== Type ===
The type id determines which decryption routine to use in [[SceSblSsUpdateMgr]]. 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|example code]] for decrypting packages.
 
The Type is used to identify the component of the update.
 
{| class="wikitable"
{| class="wikitable"
|-
|-
! Type ID !! Func 1? !! Func 2? !! Func 3?
! Type !! Description
|-
| 0x0 || Reserved type.
|-
| 0x1 || FAT16 image, <code>os0</code> [[Partitions|partition]]
|-
| 0x2 || Error 0x800F0202 in InspectSpackage.
|-
| 0x3 || Maybe permissions related to type 0x15.
|-
| 0x4 || Permissions related to <code>vs0</code> [[Partitions|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, [[Boot Sequence|secure bootloaders]] [[Partitions|partition]]
|-
| 0xA || FAT16 image, <code>vs0</code> [[Partitions|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 <code>os0</code> [[Partitions|partition]].
|-
| 0x16 || TAR archive, patch update for <code>vs0</code> [[Partitions|partition]]
|-
| 0x17 || FAT16 image, <code>sa0</code> [[Partitions|partition]]. For Tool Rev 9, "device stores manufacturing image" according to logs.
|-
| 0x18 || <code>pd0</code> [[Partitions|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 [[Updater#Update_Package_Decryption_Code|example code]] for decrypting update packages.
 
Tables for allowed for each operation.
 
No to return 0x800F0202.
 
{| class="wikitable"
|-
! Type !! InspectSpackage !! UpdateSpackage !! ExtractSpackage
|-
|-
| 0x0 || No || No || No
| 0x0 || No || No || No
Line 149: Line 232:
|-
|-
| 0x1B || No || No || Yes
| 0x1B || No || No || Yes
|}  
|}
 
= SCEWM =
 
SCEWM is a file embedded in the PUP to serve as a watermark.


=== Type ID (Identifier) ===
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 type ID is also used to identify the component of the update.
 
{| class="wikitable"
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.
 
{| class="wikitable sortable"
|-
|-
! Type ID !! Note
! Offset !! Size !! Description
|-
|-
| 0x0 ||  
| 0x0 || 0x6 || Magic ('SCEWM\0')
|-
|-
| 0x1 || <code>os0</code> [[Partitions|partition]]
| 0x6 || 0x2 || ?Version? (ex: 00 01)
|-
|-
| 0x2 ||  
| 0x8 || 0x4 || Unknown (ex: 01 00 00 00)
|-
|-
| 0x3 ||  
| 0xC || 0x4 || File Size (usually 0x1000)
|-
|-
| 0x4 || Permissions related to TAR archives of type 0x16
| 0x10 || 0x4 || Message length (ex: 0xD9, 0x5A)
|-
|-
| 0x5 ||  
| 0x14 || 0x4 || Unknown (ex: 01 00 00 00)
|-
|-
| 0x6 ||  
| 0x18 || 0x4 || Unknown (ex: 01 00 00 00)
|-
|-
| 0x7 ||  
| 0x1C || 0x4 || Unknown (ex: 01 00 00 00)
|-
| 0x8 || [[Syscon Update]] (0x9A54 type)
|-
| 0x9 || [[SLB2]] [[Boot Sequence|bootloaders]]
|-
| 0xA || <code>vs0</code> [[Partitions|partition]]
|-
| 0xB || Development CP firmware (same file as PUP entry 0x2006)
|-
| 0xC || Motion related
|-
| 0xD || Bbmc related
|-
| 0xE ||
|-
| 0xF || Motion related
|-
| 0x10 || Touch/Syscon related
|-
| 0x11 || Touch related
|-
| 0x12 || Syscon related
|-
| 0x13 || Syscon related
|-
| 0x14 || [[Syscon Update]] (0x3665 type)
|-
| 0x15 ||
|-
| 0x16 || TAR archive, patch update for <code>vs0</code>
|-
| 0x17 || <code>sa0</code> [[Partitions|partition]]
|-
| 0x18 || <code>pd0</code> [[Partitions|partition]]
|-
| 0x19 || [[Syscon Update]] (0xC5E7 type)
|-
| 0x1A ||
|-
| 0x1B || [[PSP Emulator]] lists
|}
|}


=== PUP Update Contents ===
The message length for prototype/retail PUP is almost always 0x5A, see below why.
Each PUP contain updates for different partitions of the system. Most packages, once decrypted, decompressed, and pieced together are an raw disk image for the partition to update. Sometimes a TAR archive patch is also used along with the disk images but not as often. Sony usually releases three kinds of update files, each to update different components.
 
==== full ====
== Body ==
This contains the actual system files. The main components are <code>os0</code>, <code>vs0</code>, and the [[Boot Sequence|bootloader partition]].
 
==== systemdata ====
The body is encrypted using AES128CBC with key and iv from update_service_sm.self.
Systemdata PUPs only update the <code>sa0</code> [[Partitions|partition]]. It is likely separated from the main update due to it not regularly needing updates and size concerns.
 
==== preinst ====
After decryption, the body is composed of 3 parts:
Preinst PUPs only update the <code>pd0</code> [[Partitions|partition]]. This is the [[Welcome Park]] application and the initial setup movie. It is likely separated from the main update because of the size.
* 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.
==== com ====
* 0xDE0 bytes: plaintext ASCII message (unique message per DevNet issue ID or build time).
Unknown.
* 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.
==== modeldiff ====
 
Unknown.
=== PUP Header Digest RSA Signature ===
==== Debug ====
 
Debug updates for [[PTEL-XXXX]] and [[PDEL-XXXX]] do not separate into different PUPs. A single PUP will update all components. Additionally updates for PDEL units contains updates for the CP and probably other development unit specific components.
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 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 =====
 
<pre>
# 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
</pre>
 
===== New DevNet Watermark Message =====
 
<pre>
# 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
</pre>
 
=== 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


== SCEWM ==
= SCEAS =


=== SCEWM Header ===
This file contains Additional Signature(s) (A.S.) necessary for validation of the PUP.


This is a watermark for PUPs. For development PUPs, the Issue ID is unique to the company/organization the PUP is issued to.
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 ==


{| class="wikitable sortable"
{| class="wikitable sortable"
Line 239: Line 385:
! Offset !! Size !! Description
! Offset !! Size !! Description
|-
|-
| 0x0 || 0x6 || Magic "SCEWM\0"
| 0x0 || 0x6 || Magic ('SCEAS\0')
|-
|-
| 0x6 || 0x2 || ?Version? (ex: 00 01)
| 0x6 || 0x2 || ?Version? (ex: 00 01)
Line 245: Line 391:
| 0x8 || 0x4 || Unknown (ex: 01 00 00 00)
| 0x8 || 0x4 || Unknown (ex: 01 00 00 00)
|-
|-
| 0xC || 0x4 || Content size including RSA area (ex: 0x1000)
| 0xC || 0x4 || File Size (usually 0x400)
|-
|-
| 0x10 || 0x4 || Issue ID (ex: 0xD9)
| 0x10 || 0x4 || Unknown (ex: 01 00 00 00)
|-
|-
| 0x14 || 0x4 || Unknown (ex: 01 00 00 00)
| 0x14 || 0x4 || Unknown (ex: 01 00 00 00)
Line 253: Line 399:
| 0x18 || 0x4 || Unknown (ex: 01 00 00 00)
| 0x18 || 0x4 || Unknown (ex: 01 00 00 00)
|-
|-
| 0x1C || 0x4 || Unknown (ex: 01 00 00 00)
| 0x1C || 0x4 || Certainly padding. (ex: 00 00 00 00)
|}
|}


The Issue ID for SCE/retail PUPs seems to be 0x5A.
== Body ==
 
=== SCEWM Content ===
 
The encrypted SCEWM file is composed of 3 parts:
 
* SCEWM header: size 0x20 bytes.
* RSA signature of the PUP regardless of the watermark: size 0x100 bytes.
* SCEWM unique data per issue ID: size 0x900 bytes (may vary, check SCEWM header).


=== SCEWM Security ===
The body is encrypted using AES128CBC with key and iv from update_service_sm.self.


When comparing same PUP signed for two different issue IDs, we can notice only 2 differences:
After decryption, the body is composed of 3 parts:
* the issue ID in SCEWM header
*0x100 bytes: RSA2048 signature of something unknown (to reverse). It is verified with SCEAS RSA public key.
* the SCEWM unique data
*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.




[[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.
Retrieved from "http://wiki.henkaku.xyz/index.php?title=PUP&oldid=20933"