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

I was planning to give a list of all the “exploits” of the past weeks, tell you which ones are fakes, which ones are real…but the truth is…the confusion is probably better for the time being. There’s definite proof that Sony is closely monitoring  underground websites for these exploits. Actually, one of the 5 exploits I tested last week has probably been made useless because of that.

Anyways, what happens if you find and release a game exploit? Well, pretty much nothing. You’ll be able to release a hello world (yay…), Sony will remove the game from the PSN store and improve their security in a firmware update, and we will end up with a wasted game exploit AND a system that is tougher to crack. Consider releasing a “proof of concept” as useless as drinking antibiotics when you’re not sick. It makes the bacterias stronger, for nothing.

Bottom line: if you find a game exploit, keep it for yourself and use it to improve your knowledge of the current OFW. Sadly, releasing a proof of concept that cannot be turned into an eLoader or a HEN does more harm than good to the community.

What’s left for us is hope: the last weeks have proven once again that the PSP is not 100% secure, eventually something good will happen. Oh, and if you’re looking for user mode exploits, focus on non game ones

Oh, and, of course, the CFW from Mad Daemon was a fake, but that was quite obvious from the start, right?

Please.

Remember what happened with Gripshift. it HAD an exploit, a Hello World, and even a SDK. you bought that very expensive copy. AND it led nowhere good for you.

Now I see people buying games for a very expensive price, based on fake “hints” that this might be THE game in which pspjoke found an exploit.

Ok, clear your mind. Imagine the game is MGS (which, by the way, it’s not). Do you think buying it now for such a high price will do you any good? Based on what? A proof of concept code? What are your chances that this becomes an eLoader? And maybe an eLoader is not what you are looking for. Maybe you’re expecting a HEN? But it’s been said many times that a HEN requires a kernel exploit…which pspjoke and N00b81 probably don’t have.

We’ve had several examples in the past of perfectly working Game exploits that led to nothing really useful for end users: Gripshift, Medal of Honor, Mercury,…

Bottom line: don’t buy an expensive game based on hope, you will be disappointed.

But hey, let me be bold: The game in which pspjoke found an exploit is NOT MGS.

I’m thinking I should start rumors of hacks in some of the crappy games I own, I could sell them for good money

In order to test, I myself created an overflow in a savegame for that game and could confirm the vulnerability (I’m amazed to see that it takes 10 minutes to create that overflow when I spent 3 months crafting mine on the libtiff back in 2009, talk about wasting time )

So, people can stop asking if it’s real or fake, it’s real.

The only question is: will it lead to something useful for users? Maybe, maybe not. N00b81 and pspjoke are actively working on an eLoader (a program that would load homebrews) for this vulnerability, but it is still unclear if this will ever be publicly released.

As usual, it’s not that the devs are selfishly keeping their exploits for themselves, but rather that, as soon as the exploit is made public, the game will be removed from the PSN Store by Sony, making it basically useless. In other words, PSP3000 and TA88v3 owners who can’t enjoy the power of Chickhen may hope for an eLoader in a near future…if they can afford an extensive UMD. PSPGo owners already know that there’s pretty much no hope for them in game exploits, and can try to contact Datel and beg for them to create a signed homebrew Loader, or look for exploits in the firmware itself.

Anyways, as long as no eLoader or HEN is ready for that exploit, knowing the name of the game is useless for most people. People who would have the knowledge to use the information should rather dig their own UMDs and start looking for their own exploits using my awesome guide

This post is not to tease people. It’s to confirm that the exploit is real, and if you see people claiming it’s fake, tell them I said it’s real. You can quote me on that

One of the things I enjoy the most in Wagic is when the AI surprises me with extremely clever moves.

The AI in Wagic is driven by randomness, logic, and a bit of revenge. It basically “learns” which cards in your deck are a threat to it, and tends to target these cards more than others with its spells.

Today I got owned in something like 6 turns by the AI deck Depletion, and the moves were so good I have to talk about them.

On its first turn, the AI cast “Tome scour” on me, making me moving 5 cards from my library to my graveyard.

Unfortunately, the best card of my deck was in there: Ob Nixilis, the Fallen. That card is sooo unbalanced that it’s a great game finisher.

On its second turn, the AI cast Animate Dead on my beloved creature.

3 turns later, I was dead. (On top of the AI’s excellent moves, I had a very crappy starting hand, but even without it, such a powerful creature on turn 2…what can you do?)

Owing to its “revenge” mechanism, the AI in Wagic can be extremely good against combo decks, or, in my case, decks that mostly rely on one card to win

If you have good stories about the AI owning you in a way that seemed “clever” don’t hesitate to share them

J also fixed a bunch of issues for compilation on 64bits OSes, but some of his changes are not in the SVN yet. They should be there soon though. Thanks a lot Dude

JGE++ is the only library that allows you to compile a game for the Sony PSP, Windows and Linux from the same source code. The latest version of JGE is available on our SVN.