Suspend

When the system is suspended, it enters a low power state where the main application processor is turned off. The main DRAM state is preserved so upon resume, the kernel does not have to be reloaded.

Suspending
To suspend the system, the Vita saves the current context into a buffer and sends it to the syscon. Then it issues a syscon request to enter the low-power state.

Saving Context
The context buffer defined above is built and the physical address of the buffer is sent to the Syscon with command. It calls Send command with. Then it issues the command to suspend the device.

Resuming
Upon power up, the Boot Sequence is the same until the point where the secure kernel loader would jump into the non-secure kernel loader at. Instead, it copies the context resume function to the scratch buffer at  and the context buffer to. The resume function clears the caches and then enables the MMU. Next, it uses the context buffer to restore CP15 registers that were saved. On 1.69, it does not seem to restore,  , or. After the CP15 registers are restored, the translation tables should be restored and it then calls the resume function.

Rebooting with Patches
By abusing the way resume works, we can reboot the device into a custom firmware by patching the non-secure kernel loader. The general framework to do this is (enso): first, patch the non-secure kernel bootloader in RAM to accept unsigned SELFs and load a custom skprx after. It could be the case that by the time your exploit runs the DRAM region containing the kernel loader has been wiped (enso) / reused (webkit). If so, you must use a lower level exploit (shell exploit / h-encore) to dump the loader. It may even be possible to dump the compressed version of the NSBL, in that case you wouldn't even need to perform cleanup. Your custom skrpx (taihen.skprx) will be loaded after the bare essential kernel libraries are loaded (memory management, threads, file IO, etc) and it can then patch the full module loader to accept unsigned SELFs as well as any other patches (henkaku.skprx).

Cleaning up Bootloader
Ideally, if we can get the original compressed version of the non-secure bootloader that is extracted from, we can load that to memory and jump to it from our resume function. However, by the time the system is in a state we control, usually that data would be corrupted. What we are left with is the non-secure kernel loader in the state after bootup is completed. In order to get it to run successfully again in our resume function, we need to clean up the data it uses.