psp dev

After studying both the Gripshift and the MOHH exploit, I now feel confident to write a little guide on creating a binary loader.

What This article is about

The first step to running homebrew on a PSP is to find a user mode exploit, which is done by taking control of the Ram through techniques such as a buffer overflow in a game or crafted images.
Imagine that you’ve found such a vulnerability, and have full control of our beloved variable $ra. The next step for you is to create a proof of concept. The basic idea is to create a binary loader, that is, a piece of code able to load another piece of code from a file on the memory stick, then run it.
Writing a binary loader is fairly simple once you know how to do it, but it relies on lots of tribal knowledge, as there is no central place that gathers that kind of information.

So there it is
Disclaimer: I just learned how to do it myself very recently. Some of the techniques I describe here might not be optimal. I also suck big time at MIPS. Oh, and I tend to write a ruby script for things that could probably go in a Makefile. As usual, take everything you read on the internet with a grain of salt.

In this guide I’m assuming you already have control of the variable $ra and can change it to whatever value you want. I’m taking the example of a savegame. Some steps are fairly different if you found a vulnerability in the XMB, but overall the principles are the same. I’m assuming you know how to use PSPLink, and have a fair knowledge on how to use a hexeditor, scripting languages, a bit of C and/or MIPS,  basic Makefiles…roughly, the kind of stuff you learn writing homebrews

Tools you will NEED (Download links)

• prxtool and psplink are part of the minimal psp sdk. Honestly you should already have this installed if you are reading this.
• For windows users, cygwin might be useful, and install ruby with it if you plan to run my scripts
• A Hex editor (on Windows I use XIV32)
• Savegame Deemer to work on savegame data easily
• PRXDecrypter to decrypt Eboots
• SED (Savegame Encrypter/Decrypter) to encrypt your exploit once it’s ready
• Silverspring’s libdoc (for 5.00)

Contents

Writing a binary loader from a savegame exploit requires the following steps:

1. Find a place to jump to
2. Find the function imports
3. Compile a binary loader
4. Inject your binary loader in savegame
5. Write a SDK adapted to your game
6. Create a small “proof of concept” binary file (a.k.a. “Hello World”)
7. Reencrypt your savegame

Find a place to Jump to

Run psplink and crash your game like you “usually” do. Keep that running, you’ll need it for this step.

You have control of $ra, and need to have it jump to wherever you will inject your binary loader code. Basically, your code will be injected in the savegame, so you need to know where in Ram that piece of the savegame ends up. To do that, you need to visually compare your Ram and the savegame. To do a dump of your ram just after you found a crash, type savemem 0×08800000 200000000 memdump.bin in psplink. This will create a memdump.bin file on your drive, which should be roughly 24MB.
Now look for a very recognizable pattern in your savegame. A series of letters or bytes that you can easily look for. And look for these values in your Ramdump as well (with an hexeditor, obviously). In the image below, my ramdump is on the left, and the savegame is on the right.

Once you’ve found them in you’re ramdump, you pretty much know where you will want to jump, AND where you will inject the code in your savegame. In this example, my pattern is at offset 0x43F0 in the savegame, and at offset 0x32C3E0 in the ramdump. That last one is actually 0×8800000 + 0x32C3E0 (0x08B2C3E0) in ram since we dumped our file starting at 0×08800000. You can check if your psplink is still open: you should find your pattern if you type:  memdump 0x08B2C3E0 20 (replace the address with whatever you chose, of course).
You want to make sure the place you jump to is exactly equivalent to the pattern you chose in your savegame, over a few hundred bytes. If there are differences in this area between your savegame and the ram, it means this savegame block is not entirely loaded at this position, and it will make your code injection more difficult (you want your code to be in one block, not splattered all over the Ram )
So you have step one: we found a nice place to jump to (0x08B2C3E0), and where in the SDDATA.BIN we will inject our binary loader (0x43F0).

Find the function imports

OK, this one sounds extremely difficult, as if it required lots of exceptional knowledge: that’s not the case. Or, rather, we have tools that do the work for us.
When you write a homebrew, you call functions of the PSPSDK. The position of these functions in Ram is not known in advance in the case of a game exploit, so we need to find them and “redirect” them correctly.
In the case of a game, you’ll want to extract the “EBOOT.BIN” from your game and decrypt it. The EBOOT.BIN is inside the iso of your game, so to get it you will need an iso of your game. If the game is an UMD, it’s very easy to do on any custom firmware with the “USB Drive” option that you can find in any custom firmware. (If the game is a PSN game, you’ll need NPDecryptor to create the ISO).

Most likely, this “EBOOT.BIN” is encrypted, so you additionally need to decrypt it with prxdecrypter.

Once you have your decrypted EBOOT.BIN handy, use prxtool to retrieve information from it, with the following syntax:

prxtool -f EBOOT.BIN

This will give you the actual addresses of each function that the game imports and uses. These are the functions that you will be able to use in your homebrews or in the binary loader.

You’ll notice that instead of function names, you get a library name followed by hexa values. From there you can either manually do the associations, or (better) get an xml file with the nids/function names associations. Such xml files can be found on silverspring’s website (http://silverspring.lan.st/).
Once you have one of those xml nids files, just type

prxtool -f -n yourfile.xml EBOOT.BIN

which will give you a much more readable output

Keep this output somewhere!
If prxtool complains about your file not being a prx… you probably screwed up the decryption process at some point, or you used the wrong EBOOT.BIN (there are several of those in the ISO, most of them are dummies)

Compile a binary loader

For this step I suggest you download my patapon exploit SDK as it is a good example. This SDK can be found as a part of HBL, here.
The binary loader itself is pretty simple to write, directly in assembly. You could write it in C based on the SDK you will create (that I describe below), but my inspiration here is the sparta_sdk which has its binary loader written in mips assembly. Assembly is a bit tougher than C/C++, but in this case, we are simply going to adapt my patapon work to fit your game, so it’s only a few replacements here and there.

Note: this work is heavily inspired by Mattiaz’s “sparta sdk”, it is recommended that you download it too if you want to see the differences, which can be educational.

Open the file “loader.S” from the patapon binloader folder.

Basically what we want to replace here are the function addresses used by the patapon binLoader. I used addresses that made sense for Patapon, but not for your game. So for the 4 functions involved (sceIoOpen, sceIORead, sceIOClose, sceKernelDcacheInvalidateRange) , you will take your list of imports generated earlier, and replace the “patapon” value with the value for your game. In my example, I replaces 0x08A69854 (the value from the Gripshift exploit) with 0x08C88590 (the value from the patapon exploit) for sceIoClose, and so on.
Additionally, you need to update the address where the filename is stored. The filename is the name of your binary, and is traditionally ms0:/h.bin. You need to add this string in your savefile somewhere around your jump location, and inject this address into the asm code. In my example below, I put the file name “0xF0” bytes after my jump point, so I changed the 0xC0 from the sparta sdk into F0. Don’t forget to put a “0×00″ at the end of your string!! Note that this also means that the length of my compiled binary loader has to be less than F0 bytes, otherwise when I inject it I will overwrite my file name  :’(

That’s pretty much the only things you have to change. We’ll now compile this file and inject it in the SDDATA.BIN.
Compiling assembly is not especially difficult as all the tools for that are provided in the PSPSDK. Again, taking inspiration from the spartaSDK, here are the needed compilation commands:

psp-as loader.s
psp-objcopy -O binary a.out a.bin

The first step compiles the code, and the second step creates a binary version of it.

Inject the binary loader in your Savegame

Once you’ve got a compiled version of your binLoader, it is then easy to inject it into your save file, either manually with a copy paste, or through the scripting language of your choice. The only thing to remember is that you want to inject it at the precise location matching $ra, that you found above in this article.

For the injection, I have a small ruby script that takes a valid SDDATA.BIN file and loads the exploit + the compiled binary loader into it directly. I’m only providing a picture of the code but you can also find the code here. I suggest you go with the method you prefer (and the language you prefer) for injecting your code.

Note that at this step, you already have a way to create your hello world (in asm) and inject it instead of the binary loader. It’s actually not necessarily a bad idea to try much easier code (such as calling sceKernelExitGame) before aiming for a binary loader, to make sure your thing works.

Write a SDK

This sounds difficult. It’s not. Once you have your function imports, writing the SDK is a piece of cake. What you need to do here is take the list of function imports you retrieved through prxtool, and write a file named sdk.S just like the one in the patapon SDK. It’s pretty straight forward. In my example, I replaced 0x08A69854 with 0x08C88590 and so on, just like I did with the .S. This is assembly, but it’s dead simple, as you don’t even need to look for what the functions actually do.

In my case I wrote a simple ruby script that parses my prxtool “functions imports” file into a sdk.S  function, but there probably are some options in prxtool to help you with that task.
You then copy the sdk.h from the patapon exploit, and that’s it. One .S file and one .h, and you’re done!

Write a Hello world

Once you’ve got your sdk, writing a Hello World is extremely simple. Actually, you can even cheat and reuse the sample provided in the patapon SDK. Be sure to start with the smallest file possible, just to make sure your code actually works. A simple proof of concept is just some C code that calls “sceKernelExitGame()“. That’s enough for you to confirm that your SDK is roughly correct and that your binary Loader (coded previously) does its job. Additional samples can also be found in the sparta SDK.

The sparta_sdk makefiles might need a few changes since we are using a different way of writing the SDK(take inspiration from the Makefile from patapon rather than that from sparta in that case)
The output of the compilation should be a h.bin file. If your binary loader loads ms0:/h.bin, then just put that h.bin at the root of your memory stick, put your binaryLoader SDDATA.bin in the correct subfolder of the SAVEPLAIN directory, and fire up your game (with SGDeemer and psplink enabled of course), trigger the exploit…and your hello world should appear

TroubleShooting

There might be several reasons for your exploit to fail at that point. Although computer programming IS exact science, it’s extremely easy to do stupid mistakes if your working environment is not “good” enough. At that point, PSPLink is the key to your success. If you get a crash, try to investigate the Ram. Are you actually jumping to the correct location? Is your binary loader really at that location? Is it entirely there or did it get truncated for some weird reason? Add breakpoints to your binary loader to see if it actually runs. When you are sure the binary Loader runs, make sure it really loads your hello world where you expect it to be loaded in Ram. If so, add breakpoints to your hello world as well. Or simplify it.
All these steps can be extremely painful if you don’t automate some of your work. I highly recommend taking the time to write a few scripts that will automate the work for you (compile the binLoader and inject it, etc…). Choose whatever scripting language you’re confident with

Reencrypt your savegame

That’s the last step when you want to make sure your exploit works on official firmware. A tool called SED allows you to reencrypt your exploited savegame. To do that though, you need the savegame key. That key can be found in the SAVEPLAIN data given by SGDeemer. It’s at the very bottom of XXXX.bin where XXX is the code of your game . At the bottom of that file, the last 20 bytes should be only zeroes. you want the 16bytes before that. That’s your key
For the usage of SED… well, google for it, I’m feeling lazy. If you made it that far, SED shouldn’t be a problem for you