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!