Updater

Various components in user, kernel, and secure kernel work together to update the system. All the relevant libraries are documented in this one page because they work close together.

= SceCuiSetUpper =

Module
This is a user application that is found inside the update PUP. It has not been seen used outside of development units but is included in retail updates. It does not change often between firmware updater versions.

Libraries
This module does not export any library.

= ScePsp2Swu =

Module
This is a user application that is found inside the update PUP, and extracted to ud0:UPDATE/.

Libraries
This module does not export any library.

= SceSblUpdateMgr =

Module
This module exists only in the non-secure kernel. The SELF can be found in.

Libraries
This module exports libraries to both kernel and user.

sceSblUpdateSpackageForDriver
Temp name was sceSblUsUpdateSpackageForDriver.

sceSblUsGetUpdateModeForUser
Temp name was sceSblSsUpdateMgrGetBootMode.

Get UpdateMode from Ernie NVS. See SceSblSsMgr.

sceSblUsSetUpdateModeForUser
Temp name was sceSblSsUpdateMgrSetBootMode.

sceSblUsPowerControlForUser
Temp name was sceSblSsUpdateMgrSendCommand.

sceSblUsGetSpkgInfoForUser
Temp name was sceSblSsUpdateMgrGetSpkgInfo.

sceSblUsVerifyPupForUser
path max len : 0x3FF, path len >= 0x400 : error

sceSblUsVerifyPupAdditionalSignForUser
path max len : 0x3FF, path len >= 0x400 : error

sceSblUsVerifyPupHeaderForUser
path max len : 0x3FF, path len >= 0x400 : error

sceSblUsVerifyPupSegmentForUser
path max len: 0x3FF bytes

sceSblUsVerifyPupSegmentByIdForUser
path max len: 0x3FF bytes

Maybe that seg_id is uint64_t and so it might be part of arg2 or arg4

sceSblUsVerifyPupWatermarkForUser
path max len : 0x3FF bytes

sceSblUsCheckSystemIntegrityForUser
Not implemented: does nothing.

SceSblSsUpdateMgr_92A8002B
= Update Process = The Vita updater is composed of various parts.

Initiator
The first part is the initiator of the update. The responsibility of the initiator is to copy the update file to the   partition and extract   from the update file to. Then it signals the syscon to start in update mode, where  is loaded instead of the usual shell.

The initiator that most people use is likely the update option in SceSettings. Another is the update option in SceSafeMode. Another option is, which is extracted from the update PUP. is likely used in development units as it can load the update data from, which only exists on development units. This file, however, can be found in retail update packages. also sets a flag to start updater in CUI mode.

ScePsp2Swu
Once the system restarts into update mode, the updater runs. Normally, it runs in GUI mode which is the green screen with the progress bar. If a flag is set by the initiator, the updater will run in CUI mode, which is a text interface that provides more verbose information about the update process.

The updater first makes calls to  to verify the PUP header. For more information, check out PUP. Next, the updater will spawn a thread that calls into the kernel to decrypt, verify, and flash each package file according to the information found in the package header. For more information, check out PUP.

SceSblSsUpdateMgr
This is a kernel module that actually does the work and performs the update. It verifies the PUP headers as well as the package headers and then flashes the decrypted images directly to the eMMC with block writes.

= Update Package Decryption Code =

The following code snippet will decrypt and update a directory of package files on 1.69 (the kernel functions called are specific to 1.69 NIDs). It is an attempted reproduction of the main code in. The requirements are that you patch the application to be running in Vsh context (or specifically patch the Authority ID to allow access to the kernel update functions). You also need an ability to read and write to the kernel from within your application. Finally, the updater will always attempt to flash the decrypted contents. If the flash failed because of model checks or whatever, it will return an error but the data will still be successfully decrypted and outputted. If it succeeds, note that you have now updated your PSVita.

= Bootloader =

There's evidence that the bootloaders are re-encrypted with probably per-console keys during the update process. and  are transformed into   and   respectively by F00D before flashing (and the same thing is done to  ).

= Some useful notes =

sceSblUsUpdateSpackageForUser does the bulk of the work decrypting and flashing all the update parts. There appears to be two ways to skip the version checks (but not revokion checks).

First way is to patch the imported function  to return 1. Alternatively, patch Sysroot offset 0x2C+3 and set bit 0x2. This will bypass ALL version checks, including the peripherals which might be dangerous.

Update: don't do this, it does brick as expected.

Second way is to patch  export of   (takes no arguments) to return 0. Alternatively patch 's import of that function.

Update: this doesn't work because the export is used by other functions and fails earlier checks. This flag is set by psp2swu.self to indicate bypassing of version checks on the bootloader and system partitions. All other components will be updated if at higher version. This is what devkits do by default. You can also patch the flags directly. In,  , and   (in order: flash, dry run, decrypt only) you can patch the flags argument directly and set   to indicate skipping version check on bootloader and system partitions. The flags argument found in R1 (second argument) as a user memory pointer offset 0x10.

Auth id for psp2swu.self is either  or.