Vulnerabilities

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

WebKit 531.22.8 (Vita FW <= 1.81)
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 (Vita FW 2.00-3.20) (CVE-2012-3748) (PSA 2013-09-03-1)
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 Vita FW 3.30-3.36) (CVE-2014-1303)
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 Vita FW 3.50-3.60) (unknown or no CVE)
By xyz. 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 simplified code by St4rk

WebKit 537.73 (Vita FW 3.30-3.70) (to be disclosed)
Will be released at the same time as xyz's next kernel exploit, named 2050.

Working on <= 3.70. Not patched yet.

PSM Mono privilege escalation
https://yifan.lu/2015/06/21/hacking-the-ps-vita/

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.

Games savedata exploits (h-encore)
Discovered in 2015 by TheFlow. Released on 2018-06-29.

Exploitable 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 does 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.

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
Bittersmile game found exploitable on 2018-02-17 by Freakler. Bug implemented by TheFloW in h-encore.

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.

writeup

PSVita can use PSP/PS3 PSStore licenses
PSVita can use .rif downloaded from PSVita, PSP, or PS3 (ReStore by CelesteBlue).

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

This means that Sony can securize PSVita'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 PSVita to PSN for Content and PSN Account activations is not checked anymore server-side.

This means that to activate PSVita, 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.

Stack leak using sceIoDevctl from userland applications
(tested successfully on firmware 0.995, fixed at least on firmware 1.030, works on later firmware via webkit) // let's make a buffer, with 0x66's   char outbuf[0x400]; memset(outbuf, 0x066, 0x400); sceIoOpen("molecule0:", 0, 0); // sceIoOpen to populate kernel stack // and now, let's get the stack back and check if our data was actually written there.. sceIoDevctl("sdstor0:", 5, "xmc-lp-ign-userext", 0x14, &outbuf, 0x3FF); hex_dump("kstack", (unsigned char*) outbuf, 0x400);

Stack buffer overflow in sceSblDmac5EncDec
Discovered on 2014-09-16.

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             _import_SceSblSsMgr_SceSysmemForDriver_sceKernelMemcpyUserToKernelForDriver R10 comes from original read in buffer+0x10

Confirmed exploitable before 1.80. Tested on 1.50 and 1.61.

Patched on 1.80. They also added an IsShell check.

sceIoDevctl does not clear stack buffer (henkaku kernel exploit)
Discovered on 2014-11-24.

Only works in webkit, not in fself nor game.

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

Fixed in 3.61.

Syscall handler doesn't check syscall number (integer overflow)
(2015-07-03) A large syscall number passed in R12 can overflow syscall table and cause an arbitrary function pointer to be dereferenced and executed.

This was patched in 1.61.

Heap use-after-free in sceNetSyscallIoctl
Discovered on 2016-04-05. Implemented in HENkaku. 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 just before.

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

sceNgsVoiceDefinitionGetPresetInternal can read kernel memory
See full exploit code by TheFloW here.

Also reimplemented by CelesteBlue here

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

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 firmware 1.692) the voice definition address must not be xored or SCE_NGS_ERROR_INVALID will be returned by the sceNgsRackGetRequiredMemorySize function.

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

memcpy bugs (h-encore kernel exploit)
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.

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 NSBL that occurs during eMMC initialization. We can mod eMMC MBR to change block size. But yifan was trying to exploit it with an adjacent malloc(controlled_size) and couldn't find a way so just left it there.

Logic flaw about error checking
2017-04-30 - xyx find the way to exploit the buffer overflow. He discovers a logic flaw related to error code propagation in NSBL. 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.

SMC 0x12F does not validate arguments -> TrustZone level arbitrary code execution
See also sceSblSmSchedProxyGetStatusForKernel.

(2017-01-01) 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 0x08 bytes from   and return them at   which translates to a TrustZone arbitrary memory leak (0x08 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.: SMC table).

This results in TrustZone level arbitrary code execution.

It was patched somewhere around after 1.80 before 2.10.

A 1.80 TrustZone modules imports/exports list is available there.

Example code exploiting this vulnerability:

DMAC5 crypto engine allows partial AES key overwrite
(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.

Bigmac leaves result of previous AES operation in the internal buffer allowing for derived key recovery
(2017-04-21) See https://lolhax.org/2019/01/02/extracting-keys-f00d-crumbs-raccoon-exploit/

octopus exploit
(2017-02-18) f00d 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.

To be disclosed
(2017-02-23) To be disclosed.

Petite Mort
(2018-07-27) jebaited, not an exploit. Just tools used to glitch bootrom.

moth exploit
(2019-02-05) To be disclosed.