[Tutorial] How to find a PSP Savegame Exploit without PSP (JPCSP Emulator)

Post or find tutorials, how-to, guides, tips & tricks here
Post Reply
User avatar
Freakler
Site Admin
Posts: 171
Joined: Mon Feb 17, 2014 6:37 am
Location: Germany
Contact:

[Tutorial] How to find a PSP Savegame Exploit without PSP (JPCSP Emulator)

Post by Freakler » Fri May 20, 2016 11:40 am

See this as an updated version of wololo's original tutorial here (which btw tought me all the essential things years ago)
I'm not trying to go that much into detail but explaining things as noob-friendly as possible. In the end the goal of this guide should be that you have a simple Proof of Concept (PoC) of custom code execution working!

Prologue
At first you might think; Whats the benfit of not using an actual PSP for this?

Well firstly the available PSP Emulators like PPSSPP and JPCSP got pretty good with emulating and are quite fast nowadays. Additionally they are having everything we need for exploit-hunting implemented and thats why its way much easier and faster compared to doing all steps on an actual PSP. For example the emulators can store all savegames unencrypted as plain files where on the PSP they are always encrypted and need to be converted twice each time you change something. Additionally they have implemented debuggers and memory viewers where on PSP we needed to use additional programs.

However don't get this guide wrong: To be a hundred percent sure that your found crash really works on a PSP, you need to test it! (But from my experience thats the case for maybe 99% of the crashes.)

In the end the emulators are still emulators and may handle some instructions differently!



What are we looking for? / trying to do?
The short version is -> find a crash -> see if we can exploit it -> run a simple PoC

The most common exploits are buffer overflow exploits and what we are going to concentrate on today.

An example: Its quite common in games that you have to select and enter a username at some point, right? Depending on the game you have a limited number of characters and it wont let you enter any additional ones once reached. This text string is then saved in your savegame and will be loaded to the PSPs memory the next time you load the savedata. If we now manually extend the length of our name by messing with it via a HexEditor (and our game doesn't have any security checks for that implemeneted), it is loading more data in memory than allocated for it. If that happens we already have a buffer overflow and the additional data might cause some other things to break and load our data to other places in memory where they shouldn't exist.

The easiest and best case would be that a return address of a function gets overwritten, but more about that later. And of course there are even more exploit-types but I think thats going too far for now..



Which games should I concentrate on and why?
Full PSP Games, Demos? Minis?

A PSP game when developed makes use of different pre-existing and necessary system functions provided by Sony itself. They are normally starting with the prefix 'sce' eg 'sceIoRead' and are compiled into the game to make it work. Depending on the complexity of the game there are more of these system functions imported. For our goal of getting a simple PoC running it doesn't really matter but once you are looking to port VHBL for example, the general criterion is: The more functions the better.

A simple example: If your game does have a multiplayer mode, we can be quite sure that the needed System functions for utilizing Wifi and Ad-hoc (Net Functions) were imported and we can for example use the FTP homebrew via VHBL.

So which games should you concentrate on now with the goal of high compatability for VHBL? --> Definitely 'big' and complex PSP games.

PSP Games - expensive but often 'good programed' because of professional studios and having alot of system functions -> good compatability
PSP Minis - cheap/free but often 'badly programed' and often missing alot of functions -> bad compatability

Of course it all depends on the game itself. This is just a general advice!

So lets get started!


Setting up our Emulator

I'm going to use JPCSP here as its the 'better' one for our purpose in my opinion. (There however are differences to PPSSPP in performance and rendering some stuff for special cases though)

Enabling the debugger: (to make the debugger start by default you need to add a '-d' to the start parameters in the start.bat file)
enable_Debugger.png
enable_Debugger.png (25.49 KiB) Viewed 109570 times
Turning save-encryption off
enablesavedec.png
enablesavedec.png (30.75 KiB) Viewed 109570 times
Oh and you might want to 'learn' the assignment of keys :P



Getting started

At first we are going to need our Game in ISO format. (A tutorial on how to get ISOs directly from the PlayStation Servers can be found here)

For this guide I'm going to use the game Arcade Darts [US-Version] and show how it was exploited before. Just place the ISO in JPCSP's umdimages -folder.
arcadedarts.png
arcadedarts.png (259.72 KiB) Viewed 109570 times
Lets launch our JPCSP and select the game.
emulator_setup.png
emulator_setup.png (111.52 KiB) Viewed 109570 times
Depending on the game you have to actually play it, select a username and that kind of stuff until it saves for the first time. Once the save dialog is over you can now close the emulator.
username_aaa.png
username_aaa.png (95.82 KiB) Viewed 109570 times

Editing our savegame

You can now open the saves location (JPCSP/ms0/PSP/SAVEDATA/) and it should have created the savegame containing all the normal savegame files (ICON0.png, PARAM.SFO aso) and our actual data in .bin format.
savegame.png
savegame.png (47.43 KiB) Viewed 109570 times
In case of Arcade Darts the file would be 'SECURE.BIN' and thats where all your Userdata is kept at.
bin_before.png
bin_before.png (18.02 KiB) Viewed 109570 times
What we are going to do now is basically filling it with junk and see if that affects the game!!
bin_aaaa.png
bin_aaaa.png (17.63 KiB) Viewed 109570 times
Why A(s)? Because their Hex ID would be 41 (B = 42, C = 43 aso) and thats easy to recognize later on when analyzing a crash.



Loading our custom Savegame

Yup, it crashed! And by looking at the debugger we can see that the return address ($ra) got overwritten by our AAAAA(s)! Note: As mentioned earlier this is the easiest and best case scenario since we can directly return to any address in RAM we want. This is an exploit!
crash.png
crash.png (307.78 KiB) Viewed 109570 times
However, more commonly you will only have some of the registers influenced. From there you will need time, pacience, understanding of how MIPS works and probably a real PSP with PSPlink to debug everything.
$zr -> Zero Register, always contains 0x00000000
$at -> Assembler temporary, can generally ignore this
$v0-v1 -> Function return values, these tend to be easily changed from loading functions
$a0-a3 -> Function arguments, if you have control of these you will need to look into the following functions
$t0-t9 -> Temporaries, usually useless, may be useful depending how they are used
$s0-s7 -> Saved temporaries, should keep an eye on these in complex sections of code, can be useful
$k0-k1 -> Kernel registers, defines the exception handling
$gp -> Global data Pointer, name kind of says it all
$sp -> Stack Pointer, VERY useful in more complex sections of code, contain old $ra values and $s# values
$fp -> Frame Pointer, points to somewhere in the stack, only used by some(usually large) functions
$ra -> Return Address, easiest register to exploit if you have control

Normaly the registers should start with 0×08, 0×09, 0x48, 0x49 or have 0×00000000, 0xDEADBEEF. Other registers with unusual addresses (i.e. 0×61616161, 0x534F1B20 and any other weird looking addresses) are influenced!

The following games have direct overflows in $ra:
- the Arcade games (because they all use the same engine)
- Widgets Odyssey 1 & 2
- Splinter Cell
- the Petz games
- Apache Overkill
- FieldCommander [US]
and probably alot more

Next up we need to locate the exact offset of our $ra. To do that we simply compartmentalize our area with different values.
bin_trash.png
bin_trash.png (17.67 KiB) Viewed 109570 times
trash_debug.png
trash_debug.png (103.6 KiB) Viewed 109570 times
Now we already know which line (the one filled with aaaaaaa) and are close to the exact offset. Just one more time should do it..
bin_trash2.png
bin_trash2.png (18.82 KiB) Viewed 109570 times
trash2_debug.png
trash2_debug.png (104.2 KiB) Viewed 109570 times
There we go!
bin_trash3.png
bin_trash3.png (18.98 KiB) Viewed 109570 times
What to do next? Right, create a very simple PoC to see that it works!



Creating an Exit Game PoC

Basically what we are doing now is redirecting the function to return to the exit-function which simply exits the game. So when the game exits after loading our savegame we know it worked.

At first we need to find out the address of the function 'sceKernelExitGame' (which every game should have!) When doing this on a PSP we can use PSP link to create us a list of all imported functions. But since we want to do everything with our emulator we are going to look for it manually in the memory.
dump_code.png
dump_code.png (54.6 KiB) Viewed 109570 times
sceKernelExitGame.png
sceKernelExitGame.png (55.49 KiB) Viewed 109570 times
We can now write the address 0x089B6240 to the exploited function's $ra address. Because of endianness in the HexEditor that would be

Code: Select all

40 62 9B 08
bin_exit_poc.png
bin_exit_poc.png (6.25 KiB) Viewed 109570 times

And now test it: Yes it jumps right to the exit function!
debug_exit_poc.png
debug_exit_poc.png (99.74 KiB) Viewed 109570 times
However since there is not much to see with this very simplistic PoC (especially in the emulator), we will go one step further..



Creating a Color Flasher PoC

Download these simple ColorFlasher source files and compile them yourself.. or download this pre-compiled binary for Arcade Darts right here.
colorflasher_bin.png
colorflasher_bin.png (38.19 KiB) Viewed 109570 times


Find the address to jump to where we will store the ColorFlasher code

To find the real address we need to find and calculate it manually! Therefore we are going to write some unique string somewhere in the savegame with enough space.
bin_LoremIpsum.png
bin_LoremIpsum.png (9.51 KiB) Viewed 109570 times
After the savegame was loaded we can make a RAM Dump 'ramdump.bin' which will be about 32MB big and then open it again with our HexEditor

Next we simply search for the unique string and check if the savegame memory block was loaded completely or splattered all over the RAM. This one is fine..
memorydump_lorem.png
memorydump_lorem.png (45.46 KiB) Viewed 109570 times
To get the real address we need to calculate:

Code: Select all

0x08000000 + 0x00AA2190 = 0x08AA2190
Now lets open the Memory Viewer and go to 0x08AA2190 to check if we see our string. If yes we calculated correctly!
memory_loremIpsum.png
memory_loremIpsum.png (34.87 KiB) Viewed 109570 times
We can now write the address 0x08AA2190 to the exploited function's $ra address. Because of endianness in the HexEditor that would be

Code: Select all

90 21 AA 08
All we need to do now is place the ColorFlasher code in our save where our string started..
bin_colorflashatlorem.png
bin_colorflashatlorem.png (13.11 KiB) Viewed 109570 times
And now lets run the game, load our save again and see..
colorflasherworking.png
colorflasherworking.png (21.43 KiB) Viewed 109570 times
Done! I hope this helps understanding the process of exploiting a little better and motivates some of you to go hunt for yourselfs. Oh and of course our ColorFlasher works on a PSP as well ;)
IMG_0547.png
IMG_0547.png (741.04 KiB) Viewed 109570 times
User avatar
112madgamer
Junior Member
Posts: 16
Joined: Sat Oct 31, 2015 2:01 pm

Re: [Tutorial] How to find a PSP Savegame Exploit without PSP (JPCSP Emulator)

Post by 112madgamer » Sun May 22, 2016 4:24 am

This is awesome thank you could you also do one on writing a binary loader to load a h.bin?
User avatar
Freakler
Site Admin
Posts: 171
Joined: Mon Feb 17, 2014 6:37 am
Location: Germany
Contact:

Re: [Tutorial] How to find a PSP Savegame Exploit without PSP (JPCSP Emulator)

Post by Freakler » Sun May 22, 2016 8:58 pm

112madgamer wrote:This is awesome thank you could you also do one on writing a binary loader to load a h.bin?
Yea sure why not. :) Creating the binary loader could even work with just the Emulator but everything further will need to be done with an actual PSP then.
User avatar
112madgamer
Junior Member
Posts: 16
Joined: Sat Oct 31, 2015 2:01 pm

Re: [Tutorial] How to find a PSP Savegame Exploit without PSP (JPCSP Emulator)

Post by 112madgamer » Mon May 23, 2016 7:15 am

Awesome cant wait :) :) :D :D
Post Reply