Some time ago I mentioned that a 6.61 (6.60 then) boot-time hack was possible. This doesn't seem that long ago to me, but it actually has been almost a year since I mentioned it. Recently I've been rolling out actual device tests after many simulations and support software through the year. Last year all I had was a proof of…
MAZIORA PLEIADES-2 is not the codename for a military operating but actually is the name of a pigment. MAZIORA pigments change colour respective to the viewing angle, one angle might be red whilst another being blue. The video below is taken from wikipedia and demonstrate the colour changing effect.
First thing first, huge thanks to Proxima and some1. They’ve provided key utilities and advice for this research. So, yeah, it was really only a matter of time till this kind of thing happened. Sony dont just emulate the userland process of a PSP game, they emulate the entire kernel albeit, a modified kernel. The PSP emu has limited access to hardware, with interfacing the hardware done via a Kermit module. Kermit is a old-timers transmission protocol, likely used to talk to the native Vita.
As an ongoing project, me and some1 have been enhancing this downgrader from birth on the 6.31/6.35 firmwares. This multi-firmware downgrader allows you to install a lower (or higher) firmware without any fuss. No complex flash0 sharing, just running the firmware update.
However, there comes restriction with PSP models and compatible firmware. For example, a PSPgo cannot run 1.50 as there are no drivers for the system and the IPL format is incompatible. Much like this, the PSP 3000 09g is unable to install firmwares < 6.30 which removes it’s ability to appreciate the flexibility of permanent custom firmware.
This is no longer the case.
The private key for the KIRK 0x10 functionality is known to be stored in a encrypted buffer of 0x20 bytes. Proxima discovered that the KIRK 0x10 operates as this:
Kirk 0x10 - ECDSA Sign hash Invocation: u8 buffer[0x34] u8 encryptedprivatekey[0x20] - the private key returned by KIRK 0xC must be AES encrypted somehow u8 SHA1hashofmessagetosign[0x14] memcpy(buffer,encryptedprivatekey,0x20) memcpy(buffer+0x20,SHA1hashofmessagetosign,0x14) sceUtilsBufferCopyWithRange(newsig,0x28,buffer,0x34,0x10); newsig will have the r and s values for an ECDSA signature This isn't that useful since it is not clear how to encrypt the private key to sign the message. There are some examples in IDStorage where a pre-encrypted private key and public key pair can be used, but no general cases yet.
First a huge thanks to Gusha for his huge support donating a lot of time for testing stuff on his TA-88v3, cheers mate! This post I’ll describe what I have found out so far with the TA-88v3 and provide a model representing the security and operation of the TA-88v3 pre-IPL. Unfortunately, the hash has not been broken but this could be some useful information.
Sony, being as sneaky as they are decided to do a rather interesting move. As researched by Coyotebean, Sony started enforcing using a public key method of verifying KIRK data and removing the ability to load the old types of data. As they did this, firmware 6.30+ cannot decrypt the updater and the PRX inside and therefore cannot use the index.dat spoofing to downgrade.
Now that 6.20 TN-A is out in the open, allow me to describe the kernel vulnerability used. Back in 5.70/6.00 Sony introduced a feature into the sceUtility_private library that allowed to set and unset a callback with kernel privileges.
sceUtility_private_764F5A3C //Set power callback sceUtility_private_2DC8380C // release (unset) power callback
These two functions are not normally imported so they require some special techniques such as syscall estimation to reach them in order to utilise their functionality.
Now, how does this kernel exploit work?