Today is a short post, but I've recently started playing around with ClipUpload. ClipUpload is a very clever, yet very simple clipboard upload tool which will upload whatever is in your clipboard to a variety of sources including: facebook, imgur, pastebin or even your own FTP server. Whilst I think it is pretty cool to upload to an FTP server,…
This will be a small introduction into return oriented programming, commonly referred to as ROP. I’ve had a lot of experience with security measures (duh) but never really had any hands on experience with more modern security technologies such as non-executable stack/data (DEP, NX, XN, W^X) or Address Space Layout Randomisation (ASLR).
The non-executable stack isn’t really limited to just the stack, anything that isn’t code memory can’t be executed. So as in PSP, you can’t just jump to the savedata and have the day’s work done. No, instead the only code executable is real code provided by the OS when binaries are loaded. This is a nice and funky way but ROP is the counter and tends to poop on this method.
Just to start, congratulation to yifanlu for his excellent work on gaining the first vita native hack. I’d like to note that I’m just relaying information from a forum post by yifanlu and did not have any input on yifanlu’s work, it’s all his!
Also, if you’re not a developer, please note that there is currently no way to run homebrew, colour your screen, download binaries, hack your device, make a milkshake from 10 miles away or such. This post is purely informational.
Continuing on, considering my audience gathers quite a few developers I think this post should complement the cause. So, if you don’t know, vita dev yifanlu has been looking around for developers who are interested in developing native software on the vita. He is calling out for developers to help him develop an ELF loader.
Well, this place has been cleaned up a little bit and I can log back in again. You might of noticed that I’ve changed the theme, and you’ll probably find out that I do this often!
Well this post is going summarise what the hell I’ve been doing since my last post in terms of development and perhaps you’ll be disappointed. Follow the link and find out!
Turns out he’s not just a green frog! So, I’ve been throwing this word around recently and it’s probably about time I explain. Kermit, either a protocol or perhaps a funny name (see KIRK/SPOCK) is a communication interface for the PSP emu. Specifically it allows the PSP to talk to the host.
Now, I can tell there aren’t as many developers here, so I’ll try to simplify for the curious minds but this stuff is pretty complicated. I’ll only explain the API in detail as the lower level still need a little bit of clearing up, but here goes.
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.
Thanks to a facebook message from my dad yesterday, I was informed of this website: Can you Crack it?. So, promptly, I got onto the job and it was surprisingly easy and I imagine it will be for most people who can reverse engineer and has experience doing so.
Click read more to see how I did it, but I suggest you have a good attempt beforehand. It’s a nice little reverse engineering exercise.
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.
Well, I’m no beginner to electronics, but this is my first microcontroller that can directly interface them! So yeah, pretty cool, never messed with AVR in my life, always used PIC for my USB controller. So I’ve been messing around a bit and I’ve done some very basic stuff working with components here and there.
Read on to see the stuff I’ve done.
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.