Vulnerabilities

WebKit exploits in Email app
Implemented by xyz, in order HENkaku to be launched offline.

See xyz's writeup.

WebKit 531.22.8 (PS Vita FW <= 1.81) (CVE-2010-4577 and CVE-2010-1807)
There are two exploits used for WebKit prior to 2.00. One is a data leakage exploit CVE-2010-4577 using type confusion to treat a double as a string memory address and length. The other is a type confusion exploit CVE-2010-1807 on the parseFloat function using a Nan as the arg.

WebKit 536.26 (PS Vita FW 2.00-3.20) (CVE-2012-3748) (PSA 2013-09-03-1)
Ported to PS Vita by many many people. Patched on FW 3.30.

The heap memory buffer overflow vulnerability exists within the WebKit's JavaScriptCore JSArray::sort(...) method. This method accepts the user-defined JavaScript function and calls it from the native code to compare array items. If this compare function reduces array length, then the trailing array items will be written outside the "m_storage->m_vector[]" buffer, which leads to the heap memory corruption.

Packet Storm Exploit 2013-0903-1 - Apple Safari Heap Buffer Overflow

exploit code by Davee

WebKit 537.73 (as used in PS Vita FW 3.30-3.36) (CVE-2014-1303)
Ported to PS Vita by xyz. Patched on FW 3.50.

The CSSSelectorList can be mutated after it's allocated. If the mutated list contains less entries than the original one, a restrictive 1-bit OOB write can be achieved.

WebKit 537.73 (as used in PS Vita FW 3.30-3.60) (JSArray::sortCompactedVector)
Discovered by xyz. Implemented in HENkaku by Molecule Team. Patched in FW 3.61 (see how it was patched).

The JSArray::sort method has a heap use-after-free vulnerability. If an array containing an object with a custom toString method is sorted, and the toString method causes the array to be reallocated, then the sorted elements will be written to the old freed address.

xyz's writeup about 3.60 WebKit exploit

xyz's writeup about ROP in webbrowser

3.60 WebKit exploit source code by xyz

3.60 WebKit exploit commented code by St4rk

WebKit 537.73 (as used in PS Vita FW 3.30-3.73) (to be disclosed)
It will be released at the same time as xyz and St4rk' next PS Vita kernel exploit, named 2050 or 2051. TheFloW also has a WebKit exploit and it may be the same or different than xyz and St4rk'. No WebKit exploit should be disclosed before a PS Vita 3.74 FW is released and in the case it patches hencore-2 kernel exploit.

Working on <= 3.73. Not patched yet.

PSM (PlayStation Mobile) exploits
PSM apps for PS Vita were removed from the PSStore in 2015. Nevetheless, a set of tricks allow to install and use PSM on any PS Vita on FW <=3.51.

PSM apps cannot work on FWs >=3.52 because they are blacklisted in PS Vita OS (at cmep level). This can be bypassed only with a kernel exploit and ref00d/0syscall6 plugin.

PSM Dev For Unity can be installed without PSStore
PSM Dev For Unity is packed into a DRM-free .pkg. It can so be installed using PKG Installer, or BGDL .pkg trick. Not patchable.

PSM+
PSM developper license can be spoofed using filesystem write access and signed with keys.

PSM Mono privilege escalation
See writeup by yifan lu.

PSM Unity privilege escalation
UnityEngine.dll is a trusted assembly (SecurityCritical) and is not signed (can be modified). However, the actual file at  is PFS signed and encrypted, making this (and any) resource based hacks just as difficult as unsigned code execution hacks (which is the original goal).

PSM NetworkRequest privilege escalation
NetworkRequest.BeginGetResponse(AsyncCallback callback) invokes callback with  allowing for a privilege escalation. Unfortunately, Sony closed down the scoreboards feature which means that Network.AuthGetTicket fails and Network.CreateRequest cannot be invoked. There is no other way of creating a NetworkRequest object.

Game savedata exploits
Discovered in 2015 by TheFlow. Released on 2018-06-29.

This sort of exploit works in theory on any firmware (not patchable, or hardly).

Savedata exploits VS WebKit exploits
h-encore uses a different entry point than its predecessor HENkaku. Instead of a WebKit exploit, it is using a gamesave exploit. The reason for that is after firmware 3.30 or so, Sony introduced sceKernelInhibitLoadingModule in their browser, which prevented us from loading additional sysmodules. This limitation is crucial, since this was the only way we could get more syscalls (than the browser uses), as they are randomized at boot and only assigned to syscall slots if any user module imports them. h-encore needs to load SceNgsUser, a sysmodule vulnerable to kexploits.

Old games do not have ASLR
The reason why a gamesave exploit is possible on such a system is because games that were developed with an SDK 2.60 and lower were compiled as a statically linked executable, thus their loading address is always the same, namely 0x81000000, and they cannot be relocated to an other region. They also don't have stack protection enabled by default, which means that if we can stack smash in such a game, we can happily do ROP.

Patched on games developed with 2.60 and newer SDKs.

Method for finding a savedata bug
Looking for gamesave exploits is a boring process, you just fuzz gamesaves by writing random stuff at random locations until you get a crash (best bet is extending strings and hope that you can smash the stack).

Bittersmile game buffer overflow (h-encore)
Bittersmile game found exploitable on 2018-02-17 by Freakler. Implemented in h-encore by TheFloW.

The bug relies on the parser of the bittersmile game. The gamesave is actually a text file and the game reads it line by line and copies them to a list of buffers. However it doesn't validate the length, thus if we put the delimiter \n far away such that the line is longer than the buffer can hold, we get a classic buffer overflow. If this buffer is on stack, we can make it overwrite the return address and straightly execute our ROP chain. However it is on the data section, but luckily for us, the content after the buffer is actually the list that contained destinations for other lines. This means that if we overflow into the list and redirect the buffer, we can copy the next line to wherever we want and therefore enable us an arbitrary write primitive.

Not patchable. Bittersmile game requires minimal FW ?2.50? to run.

h-encore writeup by TheFloW

Youtube Stack Pointer control vulnerability
There was a vulnerability in the Youtube application that could allow to manipulate sp.

But this vulnerability is not interesting because Sony removed the Youtube app from the PSStore, it's not DRM Free and it cannot be exploited easily.

PSP Emulator escape
See Trinity writeup by TheFloW.

Why hack the PSP Emulator? Why not WebKit/games?
The PSP Emulator runs at system privileges which are equivalent to root. By gaining control over the emulator, we are exposed to almost ALL syscalls, unlike the WebKit process that is sandboxed. Similarly, the previous jailbreak h-encore exploited a gamesave vulnerability such that it could invoke the NGS syscalls.

Buffer overflow in ScePspemuRemoteNet-KERMIT_CMD_ADHOC_CREATE
Discovered on 2018-05-26 by TheFloW. Implemented in Trinity by TheFloW.

writeup

Fixed on 3.71.

CSC doesn’t sanitize check the row number (arbitrary usermode memory read)
Discovered on 2018-06-04 by TheFloW. Implemented in Trinity by TheFloW.

writeup

Fixed on 3.71.

PS Vita can use PSP/PS3 PS Store licenses
PS Vita can use .rif downloaded from PS Vita, PSP, or PS3 (ReStore by CelesteBlue).

PS Vita can use PSP or PS3 act.dat if we spoof ConsoleId (idps) and OpenPSID (ReNpDrm by CelesteBlue).

This means that Sony can secure PS Vita's Store as much as they want, we will always be able to activate til PS3 Store is not secure.

PSStore Activation server does not check challenge anymore
Since May 2018, the challenge string in requests sent from PS Vita to PSN for Content and PSN Account activations is not checked anymore server-side.

This means that to activate PS Vita, we only have to spoof firmware version for bypassing FW Update popup, and we also have to spoof a recent PSN passcode key in SceShell. Both are done by taiHEN (in henkaku.suprx). This also means ReStore and ReNpDrm are not needed anymore.

Syscall handler treats the syscall ID as a signed integer
Discovered on 2022-08-28 by CreepNT.

In old firmwares, the syscall handler in SceKernelIntrMgr treats the syscall ID passed in  as a signed integer (note that this is a separate vulnerability from the unchecked syscall ID).

The handler also has a special code path for "fast syscalls":

This code may look safe, but due to 's signedness, it will also be executed if   is negative (as any negative number is also inferior to 0x100) - thus a pointer from an arbitrary address before the global table can be dereferenced and executed.

On firmwares affected by this bug, the available range for the the unchecked syscall ID vulnerability is thus halved since all values between  and   are treated as negative and fall in the fast syscall path instead of the regular path. Because both cases lack bounds checks, however, this can largely be ignored.

Present since 0.931.

Fixed in 0.990 by treating the syscall ID as an unsigned integer instead of a signed integer.

Syscall handler doesn't check syscall ID
Discovered on 2015-07-03 by Molecule Team.

The syscall handler in SceKernelIntrMgr finds the function to execute for a given syscall ID with a simple. However, the value in  is never checked to be in the bounds of the syscall table. A large syscall ID passed in  will cause the function pointer to be read past the syscall table, leading to an arbitrary kernel function pointer being dereferenced then executed.

Present since 0.931. Tested on 1.50-1.60.

Fixed in 1.61 by ensuring the syscall ID is valid ( - the first 0x100 syscalls are handled differently).

Syscall handler leaks syscall table vaddr
Calling svc with an invalid syscall id will end the svc interrupt without clearing syscall table vaddr in r0.

Tested on 1.50. ?Patched on 1.61?

Syscall table another reference
If know the idx of any syscall in the library, can calculate the idx difference of the syscall function in the library and call another syscall that has not been imported into the process.

The syscall function referenced by this exploit must already be imported by another process and mapped to a syscall table.

Stack buffer overflow in sceSblDmac5EncDec
Discovered on 2014-09-16 by Molecule Team. Implemented in xyz's 1.61 exploit chain in 2016, then in CelesteBlue's QuickHEN_PSVITA.

SceSblDmac5Mgr_sceSblDmac5EncDec

This function: reads in 0x18 bytes from first arg processes a little then: ROM:005F711A                MOV             R1, R11 ROM:005F711C                ADD             R0, SP, #0x88+var_70 ROM:005F711E                MOV.W           R2, R10,LSR#3 ROM:005F7122                BLX             sceKernelCopyFromUserForDriver R10 comes from original read in buffer+0x10

Tested on 1.61. Patched on 1.80. They also added an IsShell check.

Kernel stack leak in sceIoDevctl
Discovered on 2014-11-24 by Molecule Team. Used in HENkaku by Molecule Team.

Tested successfully on firmware 0.995 in fSELF. Since at least firmware 1.030, it works only via WebKit (not fSELF nor games but maybe ePSP or PSM) exploits.

Call some interesting functions that interest you in a kernel context (call some damn syscalls, for example SceLibKernel). Then call SceLibKernel and get upto 0x3FF bytes of that stack!

Fixed in 3.61.

Heap use-after-free in sceNetSyscallIoctl
Discovered on 2016-04-05 by Molecule Team. Implemented in HENkaku by Molecule Team.

See xyz's writeup.

sceNetSyscallIoctl is declared as. When  is in range (0x80; 0x1000], it will use SceNetPs custom malloc to allocate a buffer of that size on the heap.

However, the second argument to malloc is 0, meaning that when not enough memory is available instead of returning NULL, it unlocks the global SceNetPs mutex and waits on a semaphore.

Then, while malloc is waiting, another thread can free the socket sceNetSyscallIoctl is operating on, causing a use-after-free condition.

When passed proper arguments, sceNetSyscallIoctl will execute a function from the socket's vtable at the end:

Fixed in 3.63. See how it was fixed.

3 kernel exploits on DevKit by TheFloW
Patched on 3.68 or on FWs just before. These functions cannot be called because they are not imported into system or released games.

Kernel stack leak in sceMotionDevGetEvaInfo
This can be used to defeat kernel ASLR on DevKit on FW < 3.68.

But, this vulnerability may not be available depending on the model.

Click here for detailed code of exploit.

sceNgsVoiceDefinitionGetPresetInternal insufficient checks (arbitrary kernel read)
sceNgsVoiceDefinitionGetPresetInternal does a memcpy from kernel to usermode and does not do sufficient checks to prevent out of bounds arbitrary kernel read.

FW 0.990 pseudo-C:

See original full exploit code by TheFloW here.

Also reimplemented by CelesteBlue here.

And detailed code by CelesteBlue:

sceKernelGetMutexInfo_089 can write into kernel memory
sceKernelGetMutexInfo_089 should have been exported only as a kernel function, but Sony mistakenly exported it as a usermode function.

The vulnerability is a restricted kernel write from usermode, because it executes a memcpy with controlled destination, where destination must not necessarily be in usermode.

The copied data cannot be totally controlled because it must follow SceKernelMutexInfo structure. Maximum copied size in one call is 0x40 bytes.

The exploit was patched in FW 3.68:

PoC:

In this PoC, 0x25 bytes at kernel vaddr 0x18E2540 are overwritten with a mutex info structure.

SceNgs design flaws (h-encore)
Discovered on 2018-02-04 by TheFloW and successfully exploited four days later. Released on 2018-06-29 in h-encore by TheFloW.

Should be exploitable at least on 3.00 and up to 3.68. Fixed in 3.69.

Some functions in SceNgs take a kernel pointer (xor'ed with a known static value) from the user.

This can be used to partially defeat kASLR and also as an out-of-bounds exploit to get kernel execution.

Writeup and source code.

Kernel stack address leak using sceNgsRackGetRequiredMemorySize
Write-up about h-encore kstack leak.

IMPORTANT: On old firmwares (at least until FW 1.692) the voice definition address MUST NOT be xored (else SCE_NGS_ERROR_INVALID will be returned by sceNgsRackGetRequiredMemorySize function).

Below is a working implementation tested on FWs 0.995 and 1.692 (using the 1.692 DEVCTL_STACK_FRAME allows to get the kstack address faster on that firmware).

2 memcpy bugs (used in h-encore)
Discovered by TheFloW.

Should be exploitable on any firmware up to 3.69. Could even be vulnerable at other levels (TrustZone?, NS KBL?).

write-up

The 2 following bugs are exploited when using a negative length memcpy in order to use OOB without having a too big copied buffer nor triggering a segmentation fault.

memcpy integer overflow
If len is negative, the addition with dst will yield a value smaller than dst due to an integer overflow and as a consequence, the comparison later in the code will result in false, no matter if it is a signed or unsigned comparison, and thus it believes that there are less than 32 bytes to copy.

memcpy length comparizon as signed integer
At some point in memcpy function, the length is compared as signed integer. Hence a negative length will simply bypass the copy loop.

Kernel stack leak in sceUdcdGetDeviceInfo
Discovered on 2018-10-09 by TheFloW. Implemented in Trinity by TheFloW.

writeup

Fixed on 3.71.

Heap overflow in WLAN command 0x50120004
Discovered on 2018-09-26 by TheFloW. Implemented in Trinity by TheFloW.

writeup

Fixed on 3.71.

Kernel heap pointer leak in sceKernelGetLibraryInfoByNID
Discovered by Princess of Sleeping on 2019-12-17.

Leaks kernel heap pointer, but probably not useful.

See SceKernelModulemgr.

SceMsif data segment address leak via vshMsifGetMsInfo
Discovered by Princess of Sleeping on 2021-12-29.

MemoryCard's SceMsInfo, accessible to usermode via SceVshBridge, contains a pointer to an area inside SceMsif module data segment. This allows to partially defeat kernel ASLR.

However, the call to SceVshBridge must pass the SceSblACMgr check. Therefore, it is a useless exploit without a usermode exploit in a System application.

Unpatched as of FW 3.60.

Kernel stack content leak via vshMsifGetMsInfo
Discovered by Princess of Sleeping on 2021-12-29.

SceVshBridge calls SceMsif to get a 0x40-byte SceMsInfo. Unexpectedly, SceMsif forgets to initialize some members of SceMsInfo (missing a memset at the beginning) then copies SceMsInfo to usermode memory. But the content that is actually leaked is a usermode memory pointer (4 bytes), so it seems useless unless someone can fill the kernel stack with sensitive kernel information, for example in order to leak kernel pointers to defeat kernel ASLR.

However, the call to SceVshBridge must pass the SceSblACMgr check. Therefore, it is a useless exploit without a usermode exploit in a System application.

Unpatched as of FW 3.60.

Arbitrary kernel execution due to SceDeci4pDbgpForDriver exported to usermode
Discovered by CreepNT on 2022-01-13.

In early FWs, the SceDeci4pDbgpForDriver library is exported to usermode, but as the "ForDriver" suffix means, it should only be exported to kernel. Due to this bug, the sceDbgpSetDTraceBreakpointHandlerForDriver function can be called from usermode. By installing a custom breakpoint handler with this function then triggering a DTrace breakpoint, an arbitrary function might be able to be executed with Kernel privileges (either that, or kernel will panic). Because the SceDeci4pDbgp module is only present in TOOL firmware, this vulnerability only works on DevKit. On DevKit, usermode code execution is allowed in fSELF so this exploit should be easily testable if one gets a hand on a DevKit on a FW between 0.990 and 1.000.071.

Confirmed on FW 0.940. Fixed in FW 1.000.071 by not exporting library to usermode.

Unlimited stack pointer (SP) control in SceAppMgr
Discovered by Princess of Sleeping on 2022-03-07.

In FW 0.990, in some SceAppMgr syscalls like SceAppMgr, SP can be controlled with the value passed from usermode as the function does not sufficiently check the validity of the argument.

By exploiting this vulnerability, it may be possible to write data to any kernel address. As the length of data to be copied is proportional to the control size of SP, it is not possible to copy larger data.

It seems to be patched since FW 0.996.

Kernel modules addresses leak by kernel non-syscall functions import from usermode fSELF
Discovered by Princess of Sleeping on 2020-10-21.

SceKernelModulemgr kernel module is allowed to process non-syscall kernel functions exports even when imported by usermode modules.

Kernel ASLR bypass procedure is thus simple: load a custom usermode fSELF that has in its module imports section the NID of a non-syscall function exported by the target kernel module. When the custom usermode SELF is started, SceKernelModulemgr searches the function to import by its NID, decomposes the function address (4 bytes) into low and high, converts it to, and copies it to the import table of the importing module. Once the usermode module imports have been resolved (that occurs between when sceKernelModuleStart is called and module_start is run), the attacker usermode SELF can refer to its own import table, decompose the instructions and translate it back to the function address then finally derive the address of the kernel module.

There are two limitations with this vulnerability exploitation:
 * The target module must have a non-syscall export that is not in NONAME library. For example  is exported in NONAME library. Hence why SceSdstor, SceSysStateMgr and SceWlanBtRobinImageAx addresses for example cannot be leaked using this method.
 * The attacker needs to launch a custom fSELF on the target PS Vita. So this exploit can only be used on activated DevKits and TestKits but not on retail consoles, except if the attacker has an exploit to do so on retail consoles.

A vulnerable kernel module is for example SceIofilemgr, because it exports SceIofilemgr as non-syscall function in SceIofilemgrForDriver library. SceSysmem, SceSblSsMgr and a lot of kernel modules are also vulnerable.

Proof of concept code for firmware 3.65 (should work on 3.60):

This vulnerability is working on every firmware versions and will likely never get patched.

Null reference by Kernel panic at early boot
2021/06/19 - The kernel panic handler accesses SceSysroot ptr, but since the pointer is set to NULL at the early booting, NULL access to SceSysroot occurs.

Ensō
Released on 2017-07-29 by Team Molecule. Patched in 3.67.

yifan's write-up

enso source code

Buffer overflow during eMMC init
2016 - Yifan Lu discovers a buffer overflow in NSKBL that occurs during eMMC initialization. With kernel execution we can mod eMMC MBR to change block size. However at this time yifan was trying to exploit it with an adjacent malloc (controlled_size) and couldn't find a way so he just left it there.

Logic flaw about error checking
2017-04-30 - xyx finds a way to exploit the NSKBL eMMC buffer overflow. He discovers a logic flaw related to error code propagation in NSKBL. A function does not check a error return: if it did then the corrupted value in buffer overflow would not have been used. And later on the field that was written was used in a separate call.

It so allows for a usable buffer overflow in the data section and early code execution on ARM in non-secure privileged mode.

Secure World (TrustZone)
A 1.80 TrustZone modules imports/exports list is available

SMC 0x12F does not validate arguments (arbitrary read/write and code execution)
Discovered on 2017-01-01 by Yifan Lu. Exploit implementation by Proxima.

Video by Yifan Lu

See also sceSblSmSchedProxyGetStatusForKernel.

SMC 0x12F (sceSblSmSchedGetStatusMonitorCall) takes two unchecked arguments:  and.

is a pointer to TrustZone memory in the form of  and   is an integer value calculated as.

By passing the right value as, SMC 0x12F will read 8 bytes from   and return them at   which translates to a TrustZone arbitrary memory leak (8 bytes only).

By passing the right value as  it is also possible to write the leaked data into an arbitrary TrustZone memory region. The non-secure Kernel sees the shared memory region at  (size is 0x5000 bytes) and the Secure Kernel sees the exact same memory region at , thus making it possible to plant data inside the non-secure Kernel's region and having the SMC copy this data somewhere into TrustZone memory (e.g.: TrustZone SceExcpmgr SMC table). This results in TrustZone level arbitrary code execution.

Example code exploiting this vulnerability to write 8 bytes from non-secure Kernel to TrustZone:

To achieve code execution in TrustZone, it is needed to set dst to the SMC table address in order to plant 2 pointers (8 bytes = 2 pointers * 4 bytes).

Patched somewhere around after FW 1.80 before FW 2.10.

Access to device with out of range
Discovered on 2022-01-20 by Princess of Sleeping.

To decode ARZL encoded Tzs SceSysmem, SKBL maps Compati SRAM (PA 0x1C000000) to Tzs VA with a size of 2MiB. It then calls SKBL with an improper argument, thus using glitches during decoding to exceed 2MiB will pass the size check and access outside the range of the device, so it can trigger a Data abort exception.

Moreover, even if SKBL returns an error code, it will be passed to the argument of SKBL without being checked, so access for up to 0x80560201-bytes will occur.

It is currently just a bug as no glitching has been tried and as a Data abort exception is not useful.

DMAC5 crypto engine allows overwrite of partial AES key allowing for key recovery
(2017-02-01) The Dmac5 crypto engine, accessible from the kernel, allows writing 4 bytes of key material at a time.

This makes it possible to recover plaintext AES keys via bruteforce.

See,.

Bigmac allows partial overwrite of previous AES operation result allowing for derived key recovery
(2017-04-21) Bigmac crypto engine, accessible from cmep, has the following vulnerabilities:
 * it leaves result of previous AES operation in the internal buffer that will be reused in the next AES operation
 * it allows AES input data of less than 16 bytes (1 block) without adding padding

This makes it possible to recover plaintext Bigmac keyslots derived keys via bruteforce.

See.

Petite Mort
(2018-07-27) Jebaited, not an exploit but just tools used to glitch PS Vita bootrom.

See also yifan lu's academic paper about Injecting Software Vulnerabilities with Voltage Glitching.

cMeP exception vectors reused as SLSK load buffer
(2018-07-27) When a SLSK is loaded by the First Loader, it is first read to  which is the uncached alias of   (both are cmep-only private memory) and then later decrypted to the final address it is executed from. However,  is also where the exception vectors lie. By the time the SLSK is read, the exception vectors are stale and therefore the memory is safe to reuse. Interrupts are disabled, so we cannot use those. Exceptions, however cannot be disabled in hardware. Below is a summary of all the exceptions.

Through Glitching, we can inject a fault in either the decoding or execution units of the processor and trigger one of these exceptions. By writing a fake SLSK file that actually masquerades as a cmep exception handler table that all points to our payload, we can execute cmep code at bootrom time (before bootrom is unmapped). This is a very desirable glitching target because it almost requires no precision (any instruction anywhere can be "corrupted" into something that triggers an exception) and allows for "spray and pray" style of glitch attacks. In practice, we found this target to have an insanely high success rate.

In First Loader there are two SLSK load paths. The first one is used at initial boot to read Second Loader .enp or .enp_ file from the eMMC. In this path, the minimum payload size is 0x200 bytes because at most 1 eMMC block must be read. The second path is used in early boot to read the Secure Kernel .enp or .enp_ file which is loaded from the SLB2 partition by ARM TZ processor to volatile memory. This second path is more difficult to reach because it requires a handshake between cmep ("you are allowed to reset me") and ARM TZ ("I am going to reset cmep"). However, as long as both cmep and ARM TZ are pwned post-boot, the second path can be triggered.

The advantage of the first path is that it is easier and faster to trigger (always hits on first boot). The disadvantages are that it corrupts the first 0x200 bytes of cmep memory (which we might want to dump) and that it requires "bricking" the device (because second loader is replaced by our payload). Note that with a proper hardware flasher and a backup beforehand, it is possible to unbrick a corrupted second loader.

The advantage of the second path is that it does not require a hardware flasher and that it only corrupts 0x40 bytes of cmep memory. The disadvantage is that it requires more work to trigger (code execution both in ARM TZ and cmep) and it takes longer to trigger (since you have to boot the system to a point where you can pwn cmep and ARM TZ).

First Loader SLSK buffer overflow
(2019-08-30) Some development (prototype) boot ROMs do not check SLSK header correctly. Specifically, the body_size field (at SLSK offset 0x10) is only checked after adding it to "offset_to_code". The calculation can overflow, for example, when. Further, when loading a SLSK binary from ARM, the size to copy in is calculated with. Now that the sum of body_size and offset_to_code is 0, this calculation would underflow to -0x40, or 0xffffffc0, resulting in a huge amount of data being copied in and overwriting parts of the boot ROM.

Confirmed present on PS Vita units with Product Sub Code 0xB and older. Fixed on PS Vita units with Product Sub Code 0xF and newer.

moth exploit
(2019-02-05) second_loader does not check idstorage minimum firmware version padding after decryption. In order to verify the minimum firmware version number, the binary blob from idstorage is decrypted using a console-specific key, verified using RSA, then decrypted again using a different console-specific key. At no point does it check that the padding of the final decryption is valid. This lets us transplant the block from one console to another by decrypting the outer layer on the donor console and encrypting it on the target. As the second key is different on the target console, after the final decryption we end up with random garbage. However, because the version number is a 4-byte integer, with a probability of 1/256 the major byte of the version would be 00, resulting in a minimum firmware of "0.garbage". This effectively lets us bypass the minimum firmware check implemented in second_loader and downgrade below the minimum firmware, provided that enough samples of the signed blob are collected.

Warning: second_loader sets SNVS handshake key partials by encrypting some hardcoded data with a per-console key; but it uses different data (and non-encrypted) if the minimum firmware version is lower than 0x996000 which, on release units, may lead to secure world not being able to read SNVS.

octopus exploit
(2017-02-18) secure_kernel module loading does not check source address and therefore provides an oracle allowing for memory dump. See https://teammolecule.github.io/35c3-slides/

Fixed in 1.80.

Heap buffer overflow in update_service_sm
(2017-02-23) A heap buffer overflow exists in update_service_sm.

packed exploit
(2020-11-16 by PrincessOfSleeping) kprx_auth_sm verifies SELF header with RSA signature when loading module, but on FW 0.995.070 or lower there is a problem with the location of the RSA signature.

The hash included in the RSA signature is sha256 from the beginning of the header to the position of the RSA signature.

On FW 0.995.070 or lower, there is an unused zero filled area after RSA signature, but that part is not hash verified. So any data can be re-encrypted and packed in the zero filled area that follows the RSA signature.

On FW 3.60, the SELF header size is 0x1000 bytes, the RSA signature offset is 0xF00 bytes, and the RSA signature size is 0x100 bytes, so there is no unused zero filled area.

Fixed on FW 0.996.070.

Bugs
Just a bug not included in the vulnerability

sceAppMgrDestroyAppByAppId's trigger to kernel panic
Triggering a user exception immediately after calling sceAppMgrDestroyAppByAppId causes threadmgr (?) to get confused and trigger a kernel exception

sceKernelCreateThread in thumb mode
sceKernelCreateThread checks the memory attributes to see if the entry point is executable, but in thumb mode, the function pointer always has bit 0 as 1, so if the entry point is the last 4-bytes of a memory page, the next check fails. And returns 0x80020006.

sceNetRecvfromForDriver 0xC0022005 error on kernel calling
This is because the internal function always sets the is_user flag in the parameter, so setting the kernel memory pointer to data in sceNetRecvForDriver will result in an error in ksceKernelMemcpyToUser.

Illegal align check of kernel allocator
Discovered by Princess of Sleeping on 2021-08-30.

For example, if pass 0x880 to the argument align of kernel malloc, the function will not return NULL.

Confirmed is SceNetPs malloc and system malloc internal/external.

Ignored sceGUIDGetNameCore error propagation
Discovered by Princess of Sleeping on 2022-03-10.

sceGUIDGetNameCore, which is called internally by sceGUIDGetName or sceGUIDGetName2, always returns 0 even if an error occurs in the function.