Hey everyone
Shortly ago Acid_Snake posted about the state of the Vita scene, calling to the forefront yifan’s recommendations to go after webkit.
Well you may all be in for some good news. Around July of this year, I returned to the scene after a while’s absence and decided to dedicate myself to webkit. I founded a new team dedicated solely to hacking the native side of the vita, codenamed Project Mayhem and eventually named “team mayh3m.”
Over a period of 3 months we have been able to get nearly all the way through the process of exploiting webkit. The purpose of this post is to encourage you not to update to 3.20 if you desire to work with webkit, as well as to bring other developers up to speed in terms of where we are in the exploiting process. I will not be covering the basics of ASLR, DEP, ROP, or other security concepts in this paper. If you need to learn those you will want to study the “useful links” section.

Unfortunately the vita is not vulnerable to that exploit, however, I was able to find several other exploitable bugs in the vita webkit source. We currently have the ability to execute a single ARM instruction, 0xE7FE, which is equivilent to “while (1) {}”. This is a classic proof of code execution as it causes the program to hang without crashing. It hangs in a very “clean” way as it were. I will be releasing the exploits required to get to that point as soon as Sony patches them. A patch is anticipated in 3.20 as it looks as if sony is going to be pushing for parity with the browser on the playstation 4.

We also have the ability to dump the ram of the browser process. This is approximately equivalent to psplink’s savemem function. We are currently slightly stymied by ASLR, but expect to have full dumps of the process memory very soon.

The two exploits can be combined to begin a ROP chain to bypass aslr and dep. In theory, unsigned code running on the vita in usermode is only a few steps away.

I’ve got a collection of links and information below for you. The workflow should be as follows:
Search through CVE reports and bugtracker information for various webkit ports and find exploits that look promising (and have been patched in the latest version)
Look at the changelog to determine how the code has been changed to patch the exploit
Check if sony’s webkit source has been patched for the exploit
Download or create a test for the exploit and run it on the vita
If you get a reload loop (the vita browser will turn grey and say “please wait”) the browser is vulnerable to that exploit!
Now go figure out how to exploit it! I’m not gonna give you everything haha…

What you are expected to know:
Have a decent understanding of c++ syntax
Have a decent understanding of modern exploit mitigation techniques (DEP, ASLR, etc)
Have a strong understanding of computer science and security in general

So in summary, the vita exploiting workflow is not all that much more complicated than the PSP exploiting workflow, except instead of trying lots of PSP games for crashes, you are trying lots of HTML files.
A release is imminent with an HTML file capable of dumping the Webkit process memory
A release is coming within the next months capable of running unsigned code through ROP chain

Future steps include a compiler to ROP, allowing any ordinary developer compile code for the native vita. Thats right, some day quite soon, anyone will be able to compile a hello world for the native vita.

Happy Hacking!
CodeLion

For the end user this means that there’s a few things that need to be done to get homebrews working: a ROP compiler, an SDK and enough homebrew developers interested in coding homebrews that take advantage of what the exploit has to offer. Fortunately those things are easy to do (and we are in the process of doing it: we have people working on ROP and codestation and I are working on the SDK), except for the homebrew developers part.
But there’s one more thing to overcome: NID poisoning. But I will leave that for the next post.