HENkaku - Exploit teardown - Stage 3

Here it is, Stage 3, the last stage of HENkaku.
This was by far the toughest to crack, so, let's dive in!

HENkaku - Stage 3

In Stage 2, we analyzed how HENkaku exploits two distinct kernel bugs to achieve code execution: a memory leak bug (in the sceIoDevctl function) to defeat KASLR and a use-after-free (in the sceNetIoctl function) to break into the kernel and do ROP.
However, since the execution flow switches over to a ROP chain planted into the kernel, we still couldn't figure out what was happening next.

Like I mentioned in the previous write-up's ending note, dumping the kernel (more specifically, the SceSysmem module) was now necessary. Team molecule did not provide any additional vulnerability that we could use for this purpose, so, it was up to the participants to figure it out themselves.

I had already found a potential memory leak vulnerability while playing around with Stage 2 but, unfortunately, due to it's nature (out-of-bounds read) it wasn't enough to reach the SceSysmem module.
Frustrated, I began looking for other plausible entry-points. It took me several attempts and required analyzing several key components of the Vita's system:
- Network:
    The SceNet module was the origin of the use-after-free and I had already an OOB read there, so, what else could be in there?
- Filesystem:
    The SceDriverUser module exposes a decent amount of unique system calls for the filesystem. Some of them crash. Can I leak memory here?
- Audio:
    Developers don't pay much attention to security when it comes to implement media handling. Some specific audio handling features are taken care by the kernel itself. Can I compromise it?
- Graphics:
    Just like with audio, graphics are a common source of flaws. The Vita has plenty of libraries with unique system calls for this (SceGpuEs4User, SceGxm, ScePaf). Will this help?
- Application:
    User applications are managed by modules that heavily communicate with the kernel (SceAppUtil and SceDriverUser via SceAppMgr calls). Perhaps this can be taken down?
   
Eventually, one of those gave me what I wanted and I was able to dump the entire Vita's kernel memory. After locating the SceSysmem module among the dumped binaries I became able to solve the rest of the challenge.
On a side note, I did attempt blind ROP at first by relocating a few gadgets and taking wild guesses, but team molecule made sure it wouldn't be that easy. The gadgets' placement makes it very difficult to predict what each one will do.

Anyway, here is the result:

So, random comments and mistakes aside, this gives us a clear view of what the kernel ROP chain is doing:

If you recall, the kernel loader was an encrypted chunk of 0x100 bytes that was appended to the bottom of the ROP chain we copy into a kernel stack using sceIoDevctl:

• // NULLs for padding at the bottom of the chain
  0x00(x_stack + 0x00008D7C) = 0x00000000;
  0x00(x_stack + 0x00008D80) = 0x00000000;
  0x00(x_stack + 0x00008D84) = 0x00000000;
  
  // Code starts here
  0x00(x_stack + 0x00008D88) = ...;

The kernel ROP decrypts this chunk using AES-256-ECB and the key is a piece of code from SceSysmem itself.
This is what the kernel loader looks like (note that base offset is set to 0x00000000):

In sum, the loader allocates two memory blocks, one for data and another for code. Then it fetches the HENkaku's payload from user memory (using copy_from_user) and decrypts it in place using a static key (stored inside the kernel loader binary data). Finally, it copies the decrypted payload into an executable memory block, set's PC and SP and jumps to it.

Now we have HENkaku running on our system!
As proof, here are the SHA-1 hashes of the two crucial keys for the entire process:
Kernel loader key (AES-256-ECB): f1a8e9415bf3551377a36a1a5b25ba64f2d96494
Kernel payload key (AES-128-ECB): eacac4a780065c8c106349e412696aabd1b1b8d1

And that's it! This concludes the final stage of the HENkaku's KOTH challenge.
I don't plan on dwelving much into how I leaked the kernel's memory and I don't plan on releasing the keys themselves out of respect for other groups attempting to complete the challenge and for the developers themselves.
I believe the goal of this challenge was not to simply crown the first person to crack HENkaku, but to get the whole community engaged and bringing new ideas to the table.
By not releasing the decrypted binaries or the method I used to leak memory, others still have the chance to solve the challenge themselves.
I may publish a few more posts detailing some interesting features of the HENkaku's payload, but I will leave the full source code reveal to the developers themselves.

Until next time!

HENkaku - Exploit teardown - Stage 2

HENkaku - Stage 2

 

Stage 2's payload is composed by another ROP chain and data.

It creates two userland threads (each one with it's own ROP chain), that take care of leaking kernel pointers (by issuing devctl commands to "sdstor0:") and breaking the userland sandbox (by exploiting sceNet functions).

  

Stage 2 leverages a bug in sceIoDevctl in order to leak 2 distinct kernel pointers. These 2 pointers refer, respectively, to SceSysmem module's base address and SceIoFilemgr(?) thread's stack address:

•     // Store leaked kernel pointer 1
      // Comes from devctl_outbuf + 0x3D4
      scesysmem_base = 0x00(x_stack + 0x00007308) + 0xFFFFA8B9
      // Store leaked kernel pointer 2
      // Comes from devctl_outbuf + 0x3C4
      sceiofilemgr_stack_base = 0x00(x_stack + 0x000072F8) + 0xFFFFF544

When preparing to write the kernel ROP chain, we can see a few pointers being set. These translate to:

•     // Kernel ROP inside sceiofilemgr
      // This is where our ROP chain gets copied to inside the SceIoFilemgr module
      kern_rop = sceiofilemgr_stack_base + 0x000006F8
      // Encrypted kernel code
      kern_code = kern_rop + 0x300

Now we write down our kernel ROP chain in the stack, but we can see that some values only get written afterwards.

This is because these values are directly related to the decryption of the next kernel level stage! Team molecule likely only writes them into the ROP chain later so they can easily update the encrypted stage without having to change the kernel ROP chain directly.

So:

•     // Overwrite specific NULLs in the ROP chain
      0x00(x_stack + 0x00008C04) = 0x00(x_stack + 0x00008EAC)     // kern_code
      0x00(x_stack + 0x00008B48) = 0x00000090
      0x00(x_stack + 0x00008CC0) = 0x00000240
      0x00(x_stack + 0x00008D58) = 0x00000200
      0x00(x_stack + 0x00008D14) = 0x00008FC0                     // kern_next_payload

And our final ROP chain should look like this:

Now we copy the chain from the stack into the buffer that's being sent through sceIoDevctl:

•     // Copy kernel ROP chain
      memcpy(x_stack + 0x00007448, x_stack + 0x00008A8C, 0x300);
      // Copy the first 0x400 bytes of "obfuscated" data
      // and append them at the bottom of the ROP chain
      memcpy(x_stack + 0x00007744, x_stack + 0x00008EB8, 0x400);

And so, the final input buffer will look like this:

•     // SceSysmem address
      // Unknown pointer written right on top of the input buffer
      0x00(x_stack + 0x00007444) = scesysmem_base + 0x0001E460
      // Kernel ROP chain
      0x00(x_stack + 0x00007448) = 0xXXXXXXXX;
      ...
      0x00(x_stack + 0x00007734) = 0xXXXXXXXX;
      // A few NULLs for padding
      0x00(x_stack + 0x00007738) = 0x00000000;
      0x00(x_stack + 0x0000773C) = 0x00000000;
      0x00(x_stack + 0x00007740) = 0x00000000;
      // Encrypted kernel code
      // Only the first 0x100 bytes will fit in the buffer
      0x00(x_stack + 0x00007744) = 0xXXXXXXXX;
      ...
      0x00(x_stack + 0x00007B44) = 0xXXXXXXXX;

Finally, we must craft a buffer that will have our ROP chain's SP and PC. This is the buffer we feed the SceNet exploit with:

•     // Set kernel thread SP, PC, UNK
      0x00(x_stack + 0x0000884C) = sceiofilemgr_stack_base + 0x000006F8 + 0x00000004      // SP
      0x00(x_stack + 0x00008850) = scesysmem_base + 0x00000347                            // PC
      0x00(x_stack + 0x00008858) = sceiofilemgr_stack_base + 0x000006DC                   // UNK

When the SceNet exploit finishes, we should have hijacked a kernel thread inside the SceNetPs module and overwritten it's stack contents with our own.

This results in the kernel jumping to scesysmem_base + 0x00000347 (which is very likely a POP {PC} gadget) and executing our ROP chain at sceiofilemgr_stack_base + 0x000006F8 + 0x00000004 (which translates to kern_rop + 0x04).

  

To further reverse the exploit, one must dump the target kernel modules, rebuild the kernel ROP and deobfuscate/decrypt the rest of HENkaku's code.

Next up, stage 3!

HENkaku - Exploit teardown - Stage 1

This post aggregates my previously published write-ups that detail the first stage of HENkaku's exploit chain.
Information has been reorganized to reflect the original developers' naming scheme.

HENkaku - Stage 1

Visiting http://henkaku.xyz and pressing the "Install" button results in a server side useragent check.

If the browser's useragent matches the one of a PS Vita/PSTV on the latest firmware version (3.60), the user is redirected to http://go.henkaku.xyz and an exploit is deployed.

This exploit re-uses elements from the older public exploits (heap spraying method, sort() bug, scrollLeft attribute manipulation) and pairs them with a new heap corruption technique.

Team molecule renamed variables and methods to provide a simple obfuscation layer on the HTML code.

Partially reversed HTML:

Similarly to older exploits, this allows to corrupt an object's vtable and achieve ROP inside the SceWebkit module.

Offsets for libraries and relevant ROP gadgets are fetched from a javascript file (http://go.henkaku.xyz/payload.js) during the last stage of the exploit.

Team molecule implemented a dynamic method to relocate gadgets and functions' offsets for each module after their base addresses' are found (by looking at SceWebkit's import stubs).

The payload.js file contains two arrays, one containing the payload's binary data and another containing the relocation type for each word.

By crossing this information the exploit reads the payload and relocates all code offsets to their target module's address space by adding the module's base address to them:

    Relocation type 0 -> Plain data stored inside the ROP space itself. No relocation needed.

    Relocation type 1 -> Offset inside the ROP payload's stack.

    Relocation type 2 -> Offset inside the SceWebkit module.

    Relocation type 3 -> Offset inside the SceLibKernel module.

    Relocation type 4 -> Offset inside the SceLibc module.

    Relocation type 5 -> Offset inside the SceLibHttp module.

    Relocation type 6 -> Offset inside the SceNet module.

    Relocation type 7 -> Offset inside the SceAppMgr module.

Payload's generated binary data:

This payload is responsible for taking care of a few things like:

After the payload is done, an HTTP request is sent to the server using the following template:

    http://go.henkaku.xyz/x?a1=stack_base&a2=webkit_base&a3=libkernel_base&a4=libc_base&&a5=libhttp_base&a6=net_base&a7=appmgr_base&

Example:

    http://go.henkaku.xyz/x?a1=89f02000&a2=81b009a0&a3=e000dd00&a4=811c0cc0&&a5=e0607c80&a6=e01302b0&a7=e0047bf0&

The "x" script on the server side collects the base addresses for each module and generates a second payload to be run on the Vita.

This second payload is composed by another ROP chain and obfuscated ARM code.

A preliminary analysis of this payload reveals a few interesting things:

Next up, stage 2!

HENkaku - KOTH Challenge Recap

As most of you know, Team Molecule (a collective of console hackers composed by Yifan Lu, Davee, Proxima and xyz) released what I consider to be a true work of art in the realm of videogame console hacking.

They released "HENkaku", a homebrew enabler for the PS Vita, almost 3 months ago.
Along with the release, they posed a challenge to the community: reverse what we've done in HENkaku and become "king of the hill".

As soon as HENkaku was out, I began looking into it and slowly tried to pick it apart. Most of my progress and findings were published in a collection of "pastebins" I scattered around the web.

The road was harsh, but I finally managed to crack down the full HENkaku's code flow a few weeks ago.
Now that I've finally had the time to put it all up together, I decided to publicly claim my title by posting the hash of a very important key. ;)

To make all the effort complete, I'm going to publish in this blog all of my previous progress first (as an attempt to aggregate the data from the "pastebins") and end it with a detailed write-up of the last and final stage of this awesome challenge.

Stay tuned!

Hello World

Welcome.

This blog is meant to be a collection of posts, documentation and overall information on my feats in the world of cyber security.
Nothing too fancy, just a more organized way to publish my ideas and accomplishments.

Let's start!