PSVita Hacking - First Steps, PSP Emulator

Hello, my name is Alexander. A little bit about yourself. I am 16 years old, I finish 11th grade, I live in a city that is very far from the capital. I have been doing programming on Sony game consoles for 2.5 years already. The author of many plugins and programs, as well as, more recently, firmware.

I think many people remember the old woman PSP, which has pleased our eyes since 2005. Many, being children, were very jealous of their peers with wealthy parents who could please their child with such a gift. But time passes, technology is improving, and the PSP is not the same. About a year ago, Sony launched a new project called PSVita, also known as NGP (Next Generation Portable) and PSP2. The last term is not disdained by the company itself, applying it as a code name. The console received good technical characteristics and unique features. Many of the hackers of the PSP field have thrown their forces into breaking into PSVita protection.

Having a massive experience in the field of PSP, most of the views of the scene turned in the direction of the PSP emulator, the device of which is almost identical to the internal structure of the PSP itself.
')

Step 1 - Usermode access in the PSP emulator

The first and current usermode PSP emulator exploits on PSVita, allowing to run unsigned code were built on buffer overflow vulnerabilities. The initial code and the “water” that overflowed for the buffer were in the body of the save game, bought for hard-earned money in the PS Store. De / crypt save and vulnerability search in this field became possible due to compatibility of save data with PSP.

I'll tell you more. What is a buffer overflow vulnerability knows most, from computer security experts to ordinary people who have studied any assembler. But I will try to explain it from the point of view.

The game reads the save, parses it and writes data to the structure. It happens that the data is copied by the function strcpy or it is used as a string argument in the sprintf function. These functions are not secure, since they do not control the size of the output buffer that is allocated from the stack.

Suppose there is a code in the game.

//    struct { char username[64]; int other_data[256]; }SaveData; ReadSavedata(&SaveData); //    //   char username_backup[64]; //   sprintf(username_backup, "%s", username); 

I knowingly left the other_data section. I wanted to show that in saving there is still a place other than 64 bytes for the player's name. If we extend the player's name to 128 characters, then the vulnerable function, regardless of the size of the buffer, will record the data at its pointer. 128-64 = 64. That is, the buffer will be filled to 64 characters. And, since the buffer is allocated from the stack, arbitrary data from the string will fill the service records of the code.
There are 3 types of operating instructions.

1. Register $ ra (jr instruction)

If later the data from the stack is restored to the $ ra register (the address return register in MIPS), then we will be able to execute the code from an arbitrary address. We will be served by the instruction "jr $ ra", which is intended to return the code to the source section from the subfunction. Of course, we will put our code in the free space in the storage, there are still 64 bytes, which are plenty.

2. Argument jalr instructions

If the data is restored to the register, which is an argument to the jalr instruction, then we can also redirect the code in the same way as in the first case. The only difference is that in this case you will have to tinker with examining the code, and when in the first one you notice a buffer overflow right away (“Exception - Bus error (instr)” in the debugger).

3. Arguments sw

If we take control of the arguments of the sw (store word) instruction, then we will be able to substitute any instructions for ourselves, including redirection.

All these manipulations are carried out on the PSP using a debugger (psplink), then the preservation is encrypted and served for breakfast PSVita with a deliberately purchased vulnerable game.

As proof, I will provide a screenshot of Hello World, launched using an exploit in the save data.


With only the usermode exploit, it is possible to port the usermode software loader (Vita Half-Byte Loader). He has a lot of limitations and bugs, but, nevertheless, this does not prevent users from enjoying only the emulators of the first consoles (Dendy, Atari, Sega, GameBoy Advance).

Step 2 - Kernel access in the PSP emulator

The next step is kernel access. When it is possible to make changes to the kernel memory, we can do anything with the system. This was done by the famous hacker and developer Total_Noob, writing and releasing CEF (Custom Emulator Firmware) based on a leaked kernel exploit from a person who chose to remain anonymous. After firmware 1.81 there was a long crisis in terms of hacking. No one was in a hurry to release a new exploit, then I decided to release my own. And here you can use CEF on firmware above 1.81 up to 2.02. Now I will try to explain his concept. I think she is familiar to many.

1. Read-only kernel exploit

As far as you know, having only user rights, it is impossible to write or even read the kernel memory. Attempts to do this are limited to the ex-crash “breaking” module and the subsequent crash of the entire system. One gets the impression that there is no its, this kernel of memory. But we know that it is and even know its address - 0x88000000.

But where should we start? We do not have firmware modules, and we cannot read kernel memory to get them!
To do this, we need to find a read-only kernel exploit. Its principle is simple. We have to use a function in the kernel module, which can write to a pointer or return from the function the value of a section of code whose address can be specified with the argument of the function itself. For research, you can use the PSP firmware modules (I recommend 6.60). After all, the PSP emulator firmware in many places is simply identical to the PSP firmware, as I said above. Accordingly, the holes remained.

An example of a leaky function (an example without garbage and service instructions).

 sceKernelReadOnlyKxploit: move $s0, $a0 lw $v0, 0($s0) 

The $ a0 register is the first argument of the function, the value of which is then moved to the $ s0 register. The $ s0 register, in turn, is the second argument for the lw instruction, it specifies the address. The first argument to lw is the $ v0 register, which returns the value of the return operation (in C). The lw instruction is a load word - loading a four-byte word (its address is the value of the second argument) to the register (first argument).
Having understood the paragraph above, we can conclude that this function will return the value of a four-byte word to the address specified in the first argument.

An exploit for this function will look like this.

 u32 *target = (void *)0x08A00000; u32 i; for(i = 0; i <= 0x00400000; i += 4) { *(target + i) = sceKernelReadOnlyKxploit(0x88000000 + i); } 

As a result, at the address 0x08A00000, the contents of the kernel memory of 0x00400000 bytes will be recorded in memory. Save it as a file will not be difficult, as well as the search for identical vulnerabilities.

Pulling out the necessary modules, you can explore them. Disassembly is done by the prxtool program.

2. Kernel exploit with write permissions

With the search for these animals will have to pull, they are very rare and valuable. I will explain only the basic concept.
Look at the sceKernelLibcTime function (sysmem.prx module, it is better to look at the firmware code 6.60 and experiment while on the PSP). See jalr on register $ a1? And now think what will happen if you wipe “lw $ a1, 2244 ($ v1)” with several instructions above? That's right, we will gain control over the jalr argument and will be able to redirect the execution of the code to any existing address. And how can we do this? Only using kernel functions.

So, you can find a suitable function only by examining the kernel functions for the presence of control of the second store argument of instructions (sw, sh, sb) using the input arguments of the function itself ($ a0- $ a3, $ t0- $ t7) and the presence of errors in the structures. Be attentive, especially to structures.

Due to the fact that the latter is written in the abstract, you can read more about this here , in my old article.
A good reference for MIPS architecture is on wikipedia .
Just a great tutorial on assembler from scratch on the example of MIPS (for which special thanks to Bradley Kjell) you can find here .
Description of kernel exploit on the PSP console in firmware 6.20 and 6.60 .

I want to express my gratitude: SilverSpring, Malloxis, Dark Alex and some1.

In conclusion, I want to say that I do not support piracy and the article was written for informational purposes only. If you have any questions I will always be happy to answer on twitter (frostegater). Thanks for attention.