As I said in previous posts, I’m leaving behind ePSP development in favor of native vita hacking, it was one of the reasons I gave a helping hand to qwikrazor87 into fully destroying the PSP/ePSP scene a few days ago.
The PSP is a system from 2004 and any new development in it is just beating the same old dead horse, so it was time this site finally moved on. So with that said, what’s the current situation of Vita Native hacking and why do we not see that much information floating around?

It’s no secret that the Vita is a damn well secured device, it implements quite a few security measures that make it really hard to hack and execute code, but, yifanlu once said it best:

So what’s webkit and why is it so important for Vita hacking? and more importantly, how do webkit exploits work?

Webkit is an open source web browser engine used by most web browsers today to render web pages.
Since it’s open source and widely used by many big browsers like Chrome and Safari, it’s really common to find webkit in proprietary embedded devices like gaming consoles, and normally it is an older, more exploitable version. Did I mention the Vita uses webkit?
This basically means that we have the source code for a software used by the Vita that has a lot of exploits giving us code execution, or at the very least the ability to do a ROP chain, and on top of that, we don’t even have to find exploits ourselves, there’s lots of devs and hackers outside the scene that make a living out of finding effective webkit exploits.
But how do these exploits work? we’re not talking about PSP usermode exploits that rely on buffer overflows, or PSP kernel exploits that rely on missing checks or flawed implementations, webkit exploits usually rely on the so called use-after-free exploits.

Use after free essentially means a pointer is used after the memory is references has been freed. Here’s a very basic code showing the idea behind this:
int* pointer = (int*)malloc(sizeof(int)); // we allocate a region of the heap
*pointer = 0; // we use the allocated space
free(pointer); // we free the area we allocated previously
*pointer = 1; // we use the pointer even after it has been freed

This code causes what’s known as undefined behaviour, meaning nothing at all could happen, or the entire thing can crash.
Of course webkit code doesn’t really do this intentionally, a bunch of things need to happen for this scenario to take place, we need to make it happen ourselves, and to do that we make use of one of webkit’s features: javascript.

---

---

Javascript allows us to access underlying C++ classes and other functionality, which allows us to trigger a uaf exploit. But how do we use uaf to our advantage? well we need to understand how C++ classes work.

C++ classes are represented by a structure in a manner similar to this:
typedef struct _myClass_{
void* vtable[MEMBERS];
// actual data here
} myClass;

A C++ class has an array called virtual table, which contain pointers to all the members of the class (be it attributes or methods). When you pass a pointer to class to one of the methods, this virtual table is reconstructed so the pointers are pointing to the needed data at the needed offsets in the vtable, this allows for class inheritance and polymorphism.

When a uaf exploit is triggered, the vtable can be sprayed with data so we have control over the pointers and hopefully one of them is a pointer to a method, and hopefully this method gets called and the system jumps to our specified address. Hoppefully we also spray a pointer to an attribute that gets loaded, giving us control over a register or two.

Unfortunately we have something called NX bit that prevents us from executing instructions in an address not marked as executable, so where do we go from here? a ROP chain, but that’s to be explained in another blog post.