HENkaku exploit – stage 3 reversed and explained
Two developers have separately reverse engineered the next step of the HENkaku exploit, stage 3 of the exploit.
It’s worth mentioning that both hackers say they have found vulnerabilities allowing them to dump the vita kernel, a step that was necessary in order to progress on the reverse engineering of Henkaku. It is unclear if they both found the same vulnerability, and if those could be later used in PS Vita hacks for newer firmwares.
Since HENkaku was released it give us a way to run homebrews and it really was very useful to fuzzy the system. I was reading this while I was doing the rop brute-force and decided to give a try and I found a vuln that when exploited gave me a way to dump the kernel, I won’t explain details about it, but when Sony fix, I promise I will make another writeup explaining it.
Hexkyz gives details on his own process:
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:
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?
The SceDriverUser module exposes a decent amount of unique system calls for the filesystem. Some of them crash. Can I leak memory here?
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?
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?
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.
As proof of his success, Hexkyz published the SHA-1 hashes of the encryption keys used in HENkaku:
Kernel loader key (AES-256-ECB): f1a8e9415bf3551377a36a1a5b25ba64f2d96494
Kernel payload key (AES-128-ECB): eacac4a780065c8c106349e412696aabd1b1b8d1
St4rk, on his end, mentions there is still a lot to be discovered on the PS Vita:
it’s far from the end, there is still a long way to hack the vita system. We are now in the Vita Kernel and we need to explore and study the max possible here, but there are the Trust Zone and Security Core, this saga is far from finished and I hope be back here soon to talk more about Vita.
Both articles are super interesting read, but be warned, they are extremely technical:
If you’re too lazy to read them all, I think I like H’s summary below:
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.