PUP: Difference between revisions

From Vita Development Wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 241: Line 241:
The SCEWM file is composed of 3 parts:
The SCEWM file is composed of 3 parts:
* SCEWM header: size 0x20 bytes.
* SCEWM header: size 0x20 bytes.
* RSA2048 signature of the PUP (regardless of the watermark): size 0x100 bytes. ?This part IS NOT ENCRYPTED?. It is verified with and unknown RSA key.
* SCEWM body: size = file_size(usually 0x1000) - header_size(0x20). This part is encrypted.
* SCEWM body (unique data per issue ID): size = file_size(usually 0x1000) - header_size(0x20) - pup_sig_size(0x100). Its size may vary, check file_size in SCEWM header. This part IS ENCRYPTED.


== Body ==
== Body ==
Line 248: 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 data is composed of 2 parts:
After decryption, the data is composed of 3 parts:
* 0xDE0 bytes: plaintext ASCII message
* 0x100 bytes: RSA2048 signature of the PUP (regardless of the watermark). It is verified with an unknown RSA key.
* 0x100 bytes: RSA2048 signature of that message, verified with SCEWM RSA public key.
* 0xDE0 bytes: plaintext ASCII message (unique data per issue ID or build time).
* 0x100 bytes: RSA2048 signature of that message + the PUP signature + the SCEWM header. It is verified with SCEWM RSA public key.


=== Default Watermark Message ===
=== Default Watermark Message ===
Line 293: Line 293:
=== Signature ===
=== Signature ===


It is RSA2048 of the watermark + maybe other data. It is verified with SCEWM RSA public key.
It is RSA2048 of 0xF00 bytes: the header + the decrypted 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 issue ID in SCEWM header
* 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 message


= SCEAS =
= SCEAS =
Line 334: Line 334:
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.


Once decrypted:
Once decrypted, we can usually see 3 parts:
 
*0x100 bytes: RSA2048 signature, certainly of the PUP, verified with SCEAS RSA public key
*0x100 bytes: RSA2048 signature, certainly of the PUP, 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

Revision as of 03:27, 22 March 2020

PUP files are update archives for the PSP, 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

PUP Watermark was added on FW 0.931.000.

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 PUPs is almost always 0x5A, see below why.

Content

The SCEWM file is composed of 3 parts:

  • SCEWM header: size 0x20 bytes.
  • SCEWM body: size = file_size(usually 0x1000) - header_size(0x20). This part is encrypted.

Body

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

After decryption, the data is composed of 3 parts:

  • 0x100 bytes: RSA2048 signature of the PUP (regardless of the watermark). It is verified with an unknown RSA key.
  • 0xDE0 bytes: plaintext ASCII message (unique data per issue ID or build time).
  • 0x100 bytes: RSA2048 signature of that message + the PUP signature + the SCEWM header. It is verified with SCEWM RSA public key.

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

Signature

It is RSA2048 of 0xF00 bytes: the header + the decrypted 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 message

SCEAS

This file contains Additional Signatures (A.S.) necessary for validation of the PUP.

It was added in 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).

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.

Once decrypted, we can usually see 3 parts:

  • 0x100 bytes: RSA2048 signature, certainly of the PUP, 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 the Additional Signature(s), verified with SCEAS RSA public key
Retrieved from "http://wiki.henkaku.xyz/index.php?title=PUP&oldid=13512"