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.

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.

Library
This module does not export any libraries.

Module
This is a user application that is found inside the update PUP.

Library
This module does not export any libraries.

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

Libraries
This module only exports libraries to both kernel and user.

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
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 authentication 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 Vita.

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
exports function with NID  that 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 is to patch the import from  function NID   (takes no arguments) 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.

The second way is to patch  export of   (takes no arguments) to return 0. Alternatively patch 's import of that function. 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.