Communication Processor Update Package: Difference between revisions
CelesteBlue (talk | contribs) Tag: Undo |
|||
(2 intermediate revisions by the same user not shown) | |||
Line 103: | Line 103: | ||
|- | |- | ||
| 1.3.0.1 || 3.100-3.680 || ES2 || dc1320f5a3c98ba4ad80d4a9c04a957641a44167bbfac30b2597cff3cac49af4 | | 1.3.0.1 || 3.100-3.680 || ES2 || dc1320f5a3c98ba4ad80d4a9c04a957641a44167bbfac30b2597cff3cac49af4 | ||
|} | |} | ||
Latest revision as of 13:19, 7 January 2023
Communication Processor update files are stored in a .tar.gz encrypted within a CpUp file, encrypted into a SPKG contained within Development kit (DEM or PDEL) PUP files.
Every Playstation Update Package (PUP) up to version 0.996.090 ship with 2 distinct CpUp files of the same version for platforms ES1 and ES2 (and later) respectively. Every TOOL PUP since 1.00 only contains a single CpUp.
CpUp Structure
CpUp file is made of a header followed by a data area.
Header
Offset | Size | Description |
---|---|---|
0x0 | u32 | Magic "CpUp" byte-reversed ("pUpC") |
0x4 | u32 | Version. Ex: 01 00 03 01 (1.3.0.1) |
0x8 | u64 | Reserved. Always zeroed. |
0x10 | u32 | Unknown. Always 0x01000000. Maybe CpUp format version or type. |
0x14 | u32 | Size. Full CpUp size. 0x10 aligned. |
0x18 | u32 | Header size. Always 0x20. |
0x1C | u32 | Unpacked data size. tar.gz size. |
EOF-0x100 | 0x100 | RSA Encrypted AES-128-CBC KeyBlob. 0x00-0x10 = IV, 0x10-0x20 = Key, 0x20-0x34 = Sha1 |
CP Information
CP board id
- DEM-3000H has CP board GCP-001 (0-835-185-02) -> CP board id 3
- DEM-3000L has CP board GCP-002 (0-851-147-03) -> CP board id 4
- DEM-3000P has CP board GCP-002 (0-851-147-07) -> CP board id 4
- PDEL-100x has CP board GCP-002 (1-884-532-11) -> CP board id 4
CP version
Here are the known CP firmware versions:
CP Version | PUP System Software Version | CP Platform | cpupdate.bin SHA256 |
---|---|---|---|
0.6.0.4 | 0.902 | ES1 | ada895a81cc6c71382eb8e84444d9b512f9349999636f8baa921919c02a51ee3 |
0.6.0.4 | 0.902 | ES2 | ad10843589b88ba63438cd7a0ef2fd42f3e4d22ff5917ff845c8d80f030c386e |
0.8.5.8 | 0.931 | ES1 | 11861ef73bebd95653dcdaa77454a7b3520c890a043b831d07a0b68389af1ab2 |
0.8.5.8 | 0.931 | ES2 | 2aaf8610f306385d395ccb8aaeaa245388f58ee4b2bf689dc40b99e9e4a5a10f |
0.9.1.0 | 0.940 internal-0.940.050 external | ES1 | 7452fadcd867861bf5c852f8019814fd063ea46276391234e4a3b38ef4473352 |
0.9.1.0 | 0.940 internal-0.940.050 external | ES2 | de98625e0bb2410c9e3aa775b6968cfdfeebdbe186b4af29c8ce620d29b9a68d |
0.9.2.0 | DEM-3000H Recovery | ES2 | n/a |
0.9.2.3 | 0.945 | ES1 | 9cf6da719c78f5674a0b0bb7042a2b4eac599a93afe75a04d573af1e69763c3e |
0.9.2.3 | 0.945 | ES2 | d774e280067950c69e6ebaf585ee636ae0bfc7078d3261186e5ee000fa8ef863 |
0.9.5.1 | 0.990.030 internal-0.990.140 external | ES1 | aef385dd3651b94df6ab61a6ae5578e2f0e5361efabb08ca243734a2e463348e |
0.9.5.1 | 0.990.030 internal-0.990.140 external | ES2 | fc47823201ba6ce2b4010db64ec4001fc807166c1a3a732629abedcbd6c94afd |
0.9.6.0 | 0.995.000 internal | ES1 | f0ed013839eb9e69c73ec0308b341078d6c5f46984355c9b8ef11e098eae5814 |
0.9.6.0 | 0.995.000 internal | ES2 | 71c15860ef68b6ab0bff8d44776d47fad592ec3efaa8fe6cfd80a351fd0a9422 |
0.9.6.4 | DEM-3000L Recovery | ES2 | n/a |
0.9.7.0 | 0.995.070 external | ES1 | 91d41950af1c619663455d79430ac9fde2f2bbfce9ca32c612fbbbe7f318a6cd |
0.9.7.0 | 0.995.070 external | ES2 | 9197cb159aebec2e1ea39e879ab7ecf1222df6f36e75548f5c4821c7a2fbd1f6 |
0.9.7.8 | 0.996 | ES1 | b3bc194db1a07d7a2165b94a6f9031bcf3f6232c31d2e7e0c49f5869d6610db6 |
0.9.7.8 | 0.996 | ES2 | 31bd4495f97311b5eec636c4eb7744604c76d535ffe707cbac590f54158726cb |
1.0.0.0 | 1.000.041 | ES2 | 0a97fec5726dd2588cdb3e388d6f6bbb4780001269afca58ea6f4ace9ff50c48 |
1.0.0.1 | 1.000.071 | ES2 | b8554c110b7ab1bc26476c417fdf0eca3b37afaf513009ff9331529e39b76e6b |
1.0.0.2 | 1.030 / PDEL-1001 Recovery | ES2 | d863715a2733aca58f8ec17d96079ba3150d31df35738a3e287739babdd161e4 |
1.0.1.6 | 1.500 | ES2 | ce654edc6801709e35ee80df6224ede77a072073dc7772293398ed518e165788 |
1.0.3.0 | 1.600 | ES2 | eb96c2e1e45d5e95b975e9f07e90f9e38d1d69a9041aa9d06f90f8f13a91392c |
1.0.8.0 | 1.800 | ES2 | f8caa537dddd4a4a0c90276c9d718dd2262a91addda9bdccbb410aa85e2cc1a3 |
1.1.0.0 | 2.000-2.060 | ES2 | f92e3c497cc9d8e729442463b11f7c93759a23fb3e2f14d05142f7bc9a08a7e6 |
1.1.7.2 | 2.100-2.120 | ES2 | bcf9551a8d8c0b64d3d7a5ea5e861ded24cab4eee37cdc352d615b8310a063c5 |
1.1.9.4 | 2.500 | ES2 | ff175d1b5806794c4c1d5bdc111f6b04bdb18b031a73ac51e94d95e6c6e30d9e |
1.2.0.1 | 3.000 | ES2 | f9faa70d20263179cfea0d5f95684148a2de12dffa7dbe187aafc4a2dcfb8676 |
1.3.0.1 | 3.100-3.680 | ES2 | dc1320f5a3c98ba4ad80d4a9c04a957641a44167bbfac30b2597cff3cac49af4 |
Kernel Boot Loader logs
The Kernel Boot Loader and Non-Secure Kernel Boot Loader respectively reference the current CP version in their bootlogs (the version issued by KBL appears in the console output). This follows the following standard:
KBL:
Starting PSP2 Kernel Boot Loader [0x%08x]: %d...revision : %d.build date : %s.....cp info. : bid.%x ver.%04x
NSKBL:
Starting PSP2 Kernel Boot Loader (Non-secure) [0x%08x]: %d...BOOTSW.......%d: 0x%08x....: CP time...: CP bid & version
Where bid. is the Board id and ver. is the CP firmware version For example "bid.4 ver.1301" stands for board id 4, CP version 1301
In NSKBL format the information is logged in the following format: "0x00041301 [0x00041301]: CP bid & version" where 0x0004 is the mask for bid (Board id 4) and 0x1301 is the mask for version (Version 1301).
This version information appear to most likely be read from KBL Param#DIP Switches.
psp2ctrl info
You can get additional information by using the sdk's psp2ctrl info command. Information is displayed as such:
DEM-3000H in normal mode
CP: BoardVersion: 3 PackageVersion: 0.9.6.0 RecoveryPackageVersion: 0.9.2.0 ProtocolVersion: 1.0.7.0 Flags: 0x0
DEM-3000H in recovery mode
CP: BoardVersion: 3 PackageVersion: 0.9.6.0 RecoveryPackageVersion: 0.9.2.0 ProtocolVersion: 1.0.5.0 Flags: 0x1
DEM-3000L in normal mode
CP: BoardVersion: 4 PackageVersion: 1.0.3.0 RecoveryPackageVersion: 0.9.6.4 ProtocolVersion: 1.0.7.0 Flags: 0x0
DEM-3000L in recovery mode: MISSING
PDEL-1001 in normal mode
CP: BoardVersion: 4 PackageVersion: 1.3.0.1 RecoveryPackageVersion: 1.0.0.2 ProtocolVersion: 1.0.7.0 Flags: 0x0
PDEL-1001 in recovery mode
CP: BoardVersion: 4 PackageVersion: 1.3.0.1 RecoveryPackageVersion: 1.0.0.2 ProtocolVersion: 1.0.7.0 Flags: 0x1
Note: The flag exposed in the above examples is the recovery mode flag, while the flag is set to 0x1, recovery mode is active and the CP is running from the recovery bank.
Update Protocol
The Communication Processor is updated through the use of the SceDeci4pCpup kernel module.
Downgrade
The Communication Processor on PS Vita Development units is not downgradable within normal operations (even when downgrading the unit itself using a PUP). It may be possible to downgrade by using the psp2ctrl recover-cp cpupdate.bin command while in recovery mode where cpupdate.bin is a CPUP of a version equal or higher to the RecoveryPackageVersion, it may also be possible to downgrade from the vita side by patching or bypassing the version check performed by SceDeci4pCpup.
CP Recovery Mode
In the event that the CP becomes unresponsive, a special recovery mode exists. To enter this mode you need to press the "init" button (physically located at the bottom of the CP) while the AC is plugged in. The CP will then reboot into recovery mode (the LED will turn blue, then green). If your unit is connected, you will get disconnected from TM server until you reconnect the USB cable. You may still experience timeouts when running the psp2ctrl info command, if so your SDK binaries might not be compatible with the version used in the recovery bank and you may need to use older ones.
While in recovery mode, until the AC gets disconnected, the CP will be running its recovery package firmware. While this essentially acts as a downgrade, the version located in the active bank will not change. The version reported by the CP is not the running version but rather the version that is currently flashed in the normal/active bank. It is therefore not possible to downgrade a unit by updating to a PUP while in recovery mode because the version reported will still be higher than the CPUP present inside the PUP.
While this does not permanently downgrades your CP firmware, this is however useful in the attempts of triggering a possible vulnerability that would have been patched on a later revision.