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 learnt 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
Contents
Writing a binary loader from a savegame exploit requires the following steps:
- Find a place to jump to
- Find the function imports
- Compile a binary loader
- Inject your binary loader in savegame
- Write a SDK adapted to your game
- Create a small “proof of concept” binary file (a.k.a. “Hello World”)
- 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 20000000 memdump.bin in psplink. This will create a memdump.bin file on your drive, which should be roughly 20MB.
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 0×43F0 in the savegame, and at offset 0×32C3E0 in the ramdump. That last one is actually 0×8800000 + 0×32C3E0 (0×08B2C3E0) 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 0×08B2C3E0 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 (0×08B2C3E0), and where in the SDDATA.BIN we will inject our binary loader (0×43F0).
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 the sparta_sdk from Matiaz and Freeplay as it is a good example.
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 Matiaz’s work to fit our game, so it’s only a few replacements here and there.
Open the file “loader.S” from the sparta sdk.
Basically what we want to replace here are the function addresses used by the sparta binLoader. Matiaz used addresses that made sense for Gripshift, 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 “grisphift” value with the value for your game. In my example, I’ll replace 0×08A69854 with 0×08C88590 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 will change the 0xC0 from sparta 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, since you’d have to change it massively for it to work on your exploit, so I suggest you go with the method 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 update the sample sdk.h in sparta_sdk. It’s pretty straight forward. In my example, I would replace 0×08A69854 with 0×08C88590 and so on, just like I did with the .S.
But the sparta_sdk sdk.h file is not actually the best example here. Rather, you should have a look at sdk.S from the MOHH exploit. 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 get the sdk.h from the MOHH 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 samples provided in the sparta 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.
Just remember to replace all occurences of “sparta_sdk” with your own sdk. If you used the MOHH sdk.S technique instead, your makefile might need a few changes (take inspiration from the Makefile from MOHH 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
)
