Starting with the release of pre-IPL consoles, kernel exploits have become a must in order to run CFW on our beloved PSPs. This trend passed down to the Vita in the same manner, but, are psp kernel exploits doomed to disappear?

To understand more on the matter, I will go a bit deep on how kernel exploits are found as opposed to usermode exploits. First of all, the method of exploiting is extremely different, for usermode exploits you use simple techniques such as buffer overflow or garbage injection to get control of registers that will be used to jump to our unsigned code, normally this register is $ra, but it can be any if the code is right. Kernel exploits don’t work like this. First you need to disassemble all flash0 modules, then you need to look at all the functions one by one to figure out if they can be exploited or not.

Secondly we also have the medium where exploits occur. For usermode these exploits are found in PSP games, for kernel mode they are found in kernel functions.

This is simple: there are thousands of PSP tittles, a good chunk of them on the PS Vita store, a good proportion of exploitable ones, and new minis coming out very often, on the other hand, there’s only a few kernel functions, only some of them are user-callable (means they can be called from user space), and most of them already have k1 or arg checks (the checks Sony does to secure such functions), on top of that, Sony doesn’t make new functions so often as it’s mostly not needed, sometimes they do quite the opposite, they dummy out unnecessary functions to return generic “ok”. This means that while the number of usermode exploits and possible usermode exploit grows, the number of kernel mode exploits is going down.

Knowing this, we can go back to the history of kernelmode exploits from the 6.XX era.

The first kernel exploit in this era was released by Total_Noob, soon after that some1′ 0xFFFFFFFFailSploit came out for 6.3X, and then the kermit_wlan exploit by frostegater. I have intentionally skipped others as I want to focus on these so you can understand how lucky we were to have these. Kernel exploits is not something we find because we know where to look at, we don’t know which function will contain it, and we will never know how this exploit will work if we don’t look very well. Most kernel exploits come from Sony’s mistake, mistakes that are huge when you look at it from the perspective of a company with thousands engineers at its disposal. Knowing this, let’s analyze those three exploits so you can see why we were lucky and were helped mostly by Sony’s incompetence.

Total_Noob’s 6.20 exploits relied on a mistake done to the k1 check by shifting it twice, wait what? yeah I know, I’m going a bit fast here, so lets pause for a second to understand what this k1 check is. When a kernel function is called from user space, interrupt manager sets the k1 register to 0x100000. This is done because most functions will shift this value by 11 bits, so k1 becomes 0x80000000. This value is usually and’ed and or’ed with the function arguments so that if any of those arguments contain a kernel address (example: 0x80FFAA22) then the result will be 0x80000000, this is checked for negativity, usually by checking if the value is lower than 0. The binary representation of 0x8 is 1000, in two’s compliment any number starting with 1 is negative, so 0x80000000 is negative and the system will refuse to accept the arguments you’ve provided. Now back to TN’s exploit, this exploit resided in a function that shifted k1 by 11, everything good so far, we’ve already learned that this how the system checks for kernel values, the problem comes when this function calls another function before doing any actual argument check, and this other function shifts k1 again, so it becomes 0x40000000000, but the k1 register is only 32 bits to it overflows, becoming 0x00000000, with k1 set to this value all argument checks pass (because an and between 0x00000000 and any other value will always return 0x00000000), after all this hassle, the system branches to a loc_ where there are instructions to write to memory, letting us nop out pretty much whatever we want.

After this one, the second mayor mistake by sony was in some1’s exploit. This function didn’t have any k1 check but it did check for arguments, problem is instead of returning an error upon detecting incorrect arguments they continued to do some other code, one which was a store word, that allowed us to write -1 wherever on memory. (you can read more explanations on this exploit by some1 himself here)

This brings me to the last of the 3, frostegater’s exploit. This one was even simpler than the other ones, it was just one function that didn’t have any argument checks nor k1 checks, and it flat out had a sw command that we could directly use.

All these mistakes are the ones that have allowed us to run our backup games and homebrews with almost perfect compatibility. But as you can see it’s hard for a company like to sony to make these mistakes, and even harder to make them twice.
On top of this, we have kernel functions already patched, and no new ones coming out, and when they so, they usually already have the kernel checks.

We’ve all enjoyed our sweet eCFW, but now they are so scarce that some believe only one is left. Even if there are more, a time will come when Sony would have effectively patched all functions, possibly before we can even get to them.

Meanwhile, enjoy VHBL, cause it’s the only thing you’ll be seeing for a while, and I personally believe it’s best, as to stop piracy on its feet.