Vulnerabilities

Userland

WebKit exploits

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) (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 (Vita FW 2.00-3.20) (CVE-2012-3748) (PSA 2013-09-03-1)

Ported to PSVita 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 Vita FW 3.30-3.36) (CVE-2014-1303)

Ported to PSVita 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 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 Vita FW 3.30-3.72) (to be disclosed)

Will be released at the same time as xyz's next PSVita kernel exploit, named 2050 and 2051. TheFloW also have a WebKit exploit and it may be same or different than xyz's.

Working on <= 3.72. Not patched yet.

PSM (PlayStation Mobile) exploits

PSM apps for PSVita were removed from the PSStore in 2015. Nevetheless, a set of tricks allow to install and use PSM on any PSVita on FW <=3.51.

PSM apps can't work on FW >=3.52 because they are blacklisted in PSVita OS. This can be bypassed only with a kernel exploit and ref00d 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 ux0:app/PCSI00009/managed/UnityEngine.dll 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 SecurityCritical 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.

using System;
using System.Security;
using System.Runtime.InteropServices;
using Sce.PlayStation.Core.Services;

namespace NetHax
{
	public class AppMain
	{
		[SecurityCritical]
		public static void Escalate (IAsyncResult result)
		{
			Console.WriteLine("Should be SecurityCritical");
			IntPtr ptr = Marshal.AllocHGlobal(1000);
			Console.WriteLine("Look at me allocating memory: 0x{0:X}", ptr);
		}
		
		public static void Main (string[] args)
		{
			Network.Initialize("af1c0a1b-a7b8-4597-a022-eee91e6735d1");
			Network.AuthGetTicket();
			NetworkRequest req = Network.CreateRequest(NetworkRequestType.Get, "", "");
			IAsyncResult result = req.BeginGetResponse(new AsyncCallback(Escalate));
			while (!result.IsCompleted)
			{
				Console.WriteLine("waiting...");
			}
			Console.WriteLine("Completed!");
		}
	}
}

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 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 (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 sp control exploit

There was a vulnerability in the Youtube application that could manipulate sp.

but, Sony has already stopped delivering applications.

And it ’s not DRM Free and ca n’t be exploited.

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 userland memory read)

Discovered on 2018-06-04 by TheFloW. Implemented in Trinity by TheFloW.

writeup

Fixed on 3.71.

System

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.

Kernel

Syscall handler doesn't check syscall id (integer overflow)

Discovered on 2015-07-03 by Molecule Team.

A large syscall id passed in R12 can overflow syscall table and cause an arbitrary kernel function pointer to be dereferenced then executed.

Tested on 1.50-1.60. Patched on 1.61.

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?

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             _import_SceSblSsMgr_SceSysmemForDriver_sceKernelMemcpyUserToKernelForDriver
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 sceIoOpen). Then call sceIoDevctl and get upto 0x3FF bytes of that stack!

    // make a buffer, tagged with '0x66' bytes
    char outbuf[0x400];
    memset(outbuf, 0x66, 0x400);
    
    sceIoOpen("molecule0:", 0, 0); // populate kernel stack
    
    // kernel stack leak to outbuf
    sceIoDevctl("sdstor0:", 5, "xmc-lp-ign-userext", 0x14, &outbuf, 0x3FF);

    // check if our data was actually written to outbuf
    hex_dump("kstack", (unsigned char*) outbuf, 0x400);

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 int sceNetSyscallIoctl(int s, unsigned flags, void *umem). When memsz = (flags_ >> 16) & 0x1FFF 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:

v13 = (*(int (__fastcall **)(int, signed int, unsigned int, char *))(*(_DWORD *)(socket + 24) + 28))(
      socket,
      11,
      flags_,
      mem_);

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 exploits are not usable on retail/testkit because the used functions are exported only by DevKit modules.

Kernel stack leak in sceMotionDevGetEvaInfo

This can be used to defeat kernel ASLR on DevKit on FW < 3.68.

uint32_t get_sysmem_base() {
  uint32_t info[0x12];

  // 1) Call a function that writes sp to kernel stack
  sceAppMgrLoadExec(NULL, NULL, NULL);

  // 2) Leak kernel stack
  sceMotionDevGetEvaInfo(info);

  // 3) Get sysmem base
  uint32_t sysmem_addr = info[0] & 0xFFFFF000;
  
  return sysmem_addr;
}

sceNgsVoiceDefinitionGetPresetInternal can read kernel memory

See full exploit code by TheFloW here.

Also reimplemented by CelesteBlue here.

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 user function.

sceKernelGetMutexInfo_089 vulnerability is a restricted kernel write from userland.

No PoC available.

// usermode export
int sceKernelGetMutexInfo_089(SceUID mutexid, SceKernelMutexInfo *info) {
	int res;
	SceUID kernel_mutexid;
	void *a_ptr;

	kernel_mutexid = ksceKernelKernelUidForUserUid(0, mutexid);
	if (kernel_mutexid < 0)
		return 0xC0028141;

	res = sceKernelGetMutexInfo_089ForDriver(kernel_mutexid, info);
	if (res < 0)
		return res;

	info->mutexId = mutexid;
	res = SceSysmemForKernel_86E83C0D(0, mutexid, &a_ptr);
	if (res < 0)
		return res;

	a4 = *(uint32_t *)(a_ptr) << 0xC;
	FLAGS = a4;
	if (N == 0) // signed > 0
		goto loc_8102D744;

	*(uint32_t *)((int)info + 0x28) |= 0x80000;

loc_8102D744:
	return res;
}

// kernel export
int sceKernelGetMutexInfo_089ForDriver(SceUID mutexid, SceKernelMutexInfo *info) {
	int state;
	int res;
	void *a_ptr;
	SceKernelMutexInfo mutex_info;

	ENTER_SYSCALL(state);

	if (info == NULL) {
		res = 0x80020006;
		goto loc_8100E862;
	}

	if ((uint32_t)(info->size) > 0x40) {
		res = 0x8002000B;
		goto loc_8100E862;
	}

	res = sub_8100D344(mutexid, &mutex_info);
	if (res < 0)
		goto loc_8100E862;

	asm("mrc p15, #0, r3, c13, c0, #3\n");
	a4 = a4 << 0xF;
	FLAGS = a4;
	if (N == 0) // signed > 0
		goto loc_8100E852;

	if (mutex_info.currentOwnerId != 0) {
		res = ksceKernelGUIDGetObject(mutexid, &a_ptr);
		if (res < 0)
			goto loc_8100E862;
		mutex_info.currentOwnerId = *(uint32_t *)(*(uint32_t *)(a_ptr) + 0xC0);
	}

loc_8100E852:
	memcpy(info, &mutex_info, ((uint32_t)(info->size) >= 0x40) ? 0x40 : info->size);

loc_8100E862:
	EXIT_SYSCALL(state);
	return res;
}

The exploit was patched in FW 3.68:

// usermode export
int sceKernelGetMutexInfo_089() {
    return 0x80028141; // SCE_KERNEL_ERROR_UNKNOWN_MUTEX_ID
}

Example:

Kernel memory dump:
0x018E2540 : 25 00 00 00 00 FF 00 00 01 00 00 00 05 00 01 00
0x018E2550 : FF FF FF FF 2D 91 07 00 55 55 00 00 3B 57 A2 00
0x018E2560 : 00 00 02 00 78 56 34 12 00 09 00 00 FF FF FF FE

sceKernelGetMutexInfo_089(0x40010173, (SceKernelMutexInfo *)0x18E2540);

In this case, only 0x25 bytes from 0x18E2540 will be overwritten by mutex info.

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 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 address faster on that firmware).

#define DEVCTL_STACK_FRAME 0x728  //value specific for 1.692

SceInt32 gRet = 0;

SceUInt32 findkstackaddr(SceNgsHSynSystem synSys, SceUInt32 paramsize)
{ // exploit and ROP code by TheFloW - C code by LemonHaze
    SceInt32 ret = 0;

    SceNgsRackDescription rackDesc;
    rackDesc.nChannelsPerVoice   = 1;
    rackDesc.nVoices             = 1;
    rackDesc.nMaxPatchesPerInput = 0;
    rackDesc.nPatchesPerOutput   = 1;

    unsigned int voiceDef[0x400];
    memset(voiceDef, 0x00, 0x400);
    voiceDef[0] = SCE_NGS_VOICE_DEFINITION_MAGIC;
    voiceDef[1] = SCE_NGS_VOICE_DEFINITION_FLAGS;
    voiceDef[2]= 0x40;
    voiceDef[3]= 0x40;
    sceIoDevctl("", 0, voiceDef, 0x3FF, NULL, 0);

    sceKernelDelayThread(2*1000*1000);

    for(unsigned int addr=DEVCTL_STACK_FRAME; addr < 0x3000000; addr+= 0x1000)
    {        
        rackDesc.pVoiceDefn = (struct SceNgsVoiceDefinition*)(addr);
        ret = sceNgsRackGetRequiredMemorySize(synSys, &rackDesc, &paramsize);
        gRet = ret;
        if (ret == SCE_NGS_ERROR_INVALID_PARAM)
            continue;
    else return (addr-DEVCTL_STACK_FRAME); 
    }
    return 0xFFFFFFF;
}

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.

Non-secure Boot Loader (NSBL)

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. 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 File:Psvita 1.80 tz nids.txt

SMC 0x12F does not validate arguments (arbitrary read/write and code execution)

Discovered on 2017-01-01 by Mike H. No public implementation except in write-up.

writeup by Mike H.

See also sceSblSmSchedProxyGetStatusForKernel.

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

sm_handle is a pointer to TrustZone memory in the form of (tz_addr >> 0x01) and shared_mem_index is an integer value calculated as ((shared_mem_blk_addr - shared_mem_base_addr) / 0x80).

By passing the right value as sm_handle, SMC 0x12F will read 0x08 bytes from (tz_addr + 0x28) and return them at (shared_mem_base_addr + index * 0x80) which translates to a TrustZone arbitrary memory leak (0x08 bytes only).

By passing the right value as shared_mem_index 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 0x00400000 (size is 0x5000 bytes) and the Secure Kernel sees the exact same memory region at 0x00560000, 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.

Example code exploiting this vulnerability for writing 8 bytes from Non-secure Kernel to TrustZone:

void tz_memcpy_8(uintptr_t dst, const void *src)
{
	memcpy((void *)0x00400028, src, 8);

	uintptr_t sm_handle = 0x00560000 >> 1;
	uintptr_t shared_mem_index = (dst - 0x00560000) / 0x80;

	asm volatile(
		"mov r0, %0\n\t"
		"mov r1, %1\n\t"
		"mov r12, #0x12F\n\t"
		"smc #0\n\t"
		: : "r"(sm_handle), "r"(shared_mem_index) : "r12"
	);
}

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

Patched somewhere around after 1.80 before 2.10.

Hardware

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/

Petite Mort

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

F00D exception vectors reused as SLSK load buffer

(2018-07-27) When an Enc is loaded by the bootrom, it is first read to 0x40000 which is the uncached alias of 0x800000 (both are F00D-only private memory) and then later decrypted to the final address it is executed from. However, 0x40000 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. Unfortunately, there is no way to trigger any exception from bootrom code (which is why Sony thought it would be safe to re-use the buffer). Below is a summary of all the exceptions and why they are not possible.

Exception	Offset	Reason
Reset	0x0	Requires hardware reset signal
NMI	0x4	Requires hardware NMI signal
RI	0x8	No reserved instructions used
ZDIV	0xC	DIV/DIVU instructions are used in one place but safe from /0 bugs
BRK	0x10	BRK instruction not used
SWI	0x14	SWI/STC instructions not used
DSP	0x18	No DSP unit
COP	0x1C	No coprocessor unit

However, 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 ENC file that actually masquerades as a F00D exception handler table that all points to our payload, we can execute F00D 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 the bootrom there are two SLSK load paths. The first one is used at initial boot to read Second Loader 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 ENC 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 F00D ("you are allowed to reset me") and ARM TZ ("I am going to reset F00D"). However, as long as both F00D 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 F00D 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 F00D memory. The disadvantage is that it requires more work to trigger (code execution both in ARM TZ and F00D) and it takes longer to trigger (since you have to boot the system to a point where you can pwn F00D and ARM TZ).

Boot ROM Enc buffer overflow

(2019-08-30) The development boot ROM does not check Enc header correctly. Specifically, the "code size" field (at offset 0x10) is only checked after adding it to "offset to code". The calculation can overflow, for example, when code_size == -offset_code. Further, when loading an Enc binary from ARM, the size to copy in is calculated with (scratch->code_size + scratch->offset_code) - 0x40. Now that the sum of code_size and offset_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.

F00D Processor

second_loader

moth exploit

(2019-02-05) second_loader does not check idstorage factory firmware version padding after decryption. In order to verify the factory 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 factory firmware of "0.garbage". This effectively lets us bypass the factory firmware check implemented in second_loader and downgrade below the factory firmware, provided that enough samples of the signed blob are collected.

secure_kernel

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.

Heap buffer overflow in update_service_sm

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