PUP

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, Bert, 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 Bert, 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
0x1	os0 partition
0x2
0x3
0x4	Permissions related to vs0 partition patch update TAR archive (type 0x16)
0x5
0x6
0x7
0x8	Syscon Update (0x9A54 run mode)
0x9	SLB2 bootloaders
0xA	vs0 partition
0xB	Cp Firmware
0xC	Motion Firmware
0xD	Bbmc related
0xE
0xF	Motion Firmware
0x10	Touch Firmware
0x11	Touch Config
0x12	Bic Firmware (Battery IC) ?for Bert?
0x13	Bic Firmware (Battery IC) ?for Abby?
0x14	Syscon Update (0x3665 run mode)
0x15
0x16	TAR archive, patch update for vs0 partition
0x17	sa0 partition. For Tool Rev 9, "device stores manufacturing image" according to logs.
0x18	pd0 partition
0x19	Syscon Update (0xC5E7 run mode)
0x1A
0x1B	PSP Emulator lists

Subroutines

The SPKG Type 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	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

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.

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.