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!