/talk member and dev Guidobot (if your PS vita is hacked, you’re probably using his 138Menu, unless you decided to give a try to the recently released OneMenu) posted yesterday a pretty cool explanation on how the latest PSP Kernel exploit (running on the PSP emulator on Vita Firmware 3.36) actually works.

If you remember, I stated a couple days ago that it was apparently relying on a race condition, and it seems I was right (although that was only part of the story).

For those of you not familiar with the term, race conditions occur when two events in the code happen in an unexpected order. Those can be pretty common in multithreaded code, if proper locking of shared resources is not done by the threads.

In this case, the exploited function checks that the parameters are valid before proceeding, but before it can actually use these values, another (“malicious”) thread changes the content of the parameters with exploited content.

In this case specifically, the function giving us kernel access is “sceMeVideo_driver_4D78330C“, (that would be “do_some_stuff” in my picture above), while the function with a race condition is scevideoCodecStop (that would be “myfunction” in my picture).

That’s it for the general idea. To understand how this specific exploit works from End to End though, you’ll have to read the details in GBOT’s original thread.

If you’re interested in more PSP Kernel exploit explanations, you can also check GBOT’s explanation of the  sceSdGetLastIndex exploit (2014), Some1’s explanation of the 0xFFFFFFFFailSploit (2011), and Acid_Snake’s “Kernel Exploit: how they work” summary article (2013).

Source: GBOT on /talk