PUP: Difference between revisions
CelesteBlue (talk | contribs) No edit summary |
CelesteBlue (talk | contribs) No edit summary |
||
Line 211: | Line 211: | ||
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 OS the PUP watermark is never verified. | 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 OS 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 238: | Line 242: | ||
The message length for prototype/retail PUP is almost always 0x5A, see below why. | The message length for prototype/retail PUP is almost always 0x5A, see below why. | ||
== Body == | == Body == | ||
Line 249: | Line 247: | ||
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 | After decryption, the body is composed of 3 parts: | ||
* 0x100 bytes: RSA2048 signature of SHA256 of the PUP | * 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). | * 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 | * 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 | === PUP Header Digest RSA Signature === | ||
It is RSA2048 of SHA256 of the PUP | It is RSA2048 of SHA256 of the PUP Header Digest. It is verified with SCEWM RSA public key. | ||
=== Message === | === Message === | ||
Line 301: | Line 299: | ||
=== SCEWM RSA Signature === | === SCEWM RSA Signature === | ||
It is RSA2048 of SHA256 of 0xF00 bytes: the header + the decrypted body. It is verified with SCEWM RSA public key. | 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 == | ||
Line 314: | Line 312: | ||
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). | 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 342: | Line 344: | ||
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: 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. | *0x1E0 bytes: zeroes, maybe area for more than one signature, or just padding for decryption. | ||
*0x100 bytes: RSA2048 signature of SHA256 of | *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]] |
Revision as of 14:40, 26 March 2020
PUP (Playstation Update Package) files are update archives for the PS3, PSVita 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 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 (0x4) |
0x4 | 0x4 | Type ID |
0x8 | 0x4 | Flags |
0xC | 0x4 | ? |
0x10 | 0x8 | Update FW Version |
0x18 | 0x8 | Final (decompressed) size |
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, 0x40000000 CEX, 0x10000000 Devtool |
0x30 | 0x4 | ? |
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 | ? |
Flags
There are flags that are set in the package header. Some potential ones are listed here.
Flag | Description |
---|---|
0x10 | Set when compressed |
0x2 | Has multiple parts |
0x1 | Set when compressed |
Type ID
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 example code for decrypting packages.
Type ID | Func 1? | Func 2? | Func 3? |
---|---|---|---|
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 |
Type ID (Identifier)
The type ID is also used to identify the component of the update.
Type ID | Note |
---|---|
0x0 | |
0x1 | os0 partition
|
0x2 | |
0x3 | |
0x4 | Permissions related to TAR archives of type 0x16 |
0x5 | |
0x6 | |
0x7 | |
0x8 | Syscon Firmware (0x9A54 run mode) Syscon Update |
0x9 | SLB2 bootloaders |
0xA | vs0 partition
|
0xB | Cp Firmware (same file as PUP entry 0x2006) |
0xC | Motion Firmware |
0xD | Bbmc related |
0xE | |
0xF | Motion Firmware |
0x10 | Touch Firmware |
0x11 | Touch Config |
0x12 | Bic Firmware |
0x13 | Bic Firmware |
0x14 | Syscon Update (0x3665 run mode) |
0x15 | |
0x16 | TAR archive, patch update for vs0
|
0x17 | sa0 partition
|
0x18 | pd0 partition
|
0x19 | Syscon Update (0xC5E7 run mode) |
0x1A | |
0x1B | PSP Emulator lists |
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 OS 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.
Message
Default Watermark Message
For PUP not bound to a developer, not downloaded on DevNet, such as prototype and retail PUP, the watermark has a default message.
0.931-3.73:
desc: default watermark id: build_team timestamp: YYYYMMDD_HHmmSS_JST host: build_machine
DevNet Watermark Message
The 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.
The message is totally independant of the PUP. The same PUP (for example PSVita FW 0.945 PUP) downloaded from DevNet in 2011 and in 2018 has different message syntax.
Here 'x' represents an actual character, which I hide for confidentiality.
Old message (2011-02)
# 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
Recent message (2018-04)
# 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.