January 2010

Here’s another “how to look for exploits” post from me, I hope it’ll be useful to all the people who are currently trying to free the PSPGo from the chains that prevent it to breathe

Recently we’ve seen lots of crashes involving images, especially TIFF files. Let me start by correcting something here: some people believe that TIFF support has been removed from the PSP after the laughing man tiff exploit. This is NOT true, only support of a class of TIFF files (files with an unassociated alpha layer) has been dropped by Sony. So, yes, even in the latest firmwares, the PSP can display tiff files.

Now let’s go back to the recent crashes. So, you’ve crafted a tiff file that crashes your PSP. Or you’ve found one on the internet. That’s great. People will tell you that this could lead to an exploit. They are right. Other people will tell you that this is an exploit. They are wrong. A crash is not necessarily an exploit, and, in the case of tiff files, a crash is very likely to NOT be an exploit.

Let’s take for example a file that can easily be found these days on various sites, a tiff crash apparently created by CoD3r-D. This files does crash the latest PSP firmwares, but a quick analysis in PSPLink gives us the following:

Ok. So let’s be clear here: the error we get is a breakpoint. a breakpoint cannot lead to an exploit. A breakpoint is how your PSP tells you: “you tried to mess up with me, I’d rather stop everything here, and while I’m at it, I’ll shut down very soon to prove my point.”

Why do these breakpoints happen frequently with Tiff files? Well the libtiff (the library used on the PSP to handle TIFF files) has a pretty good error handling system. Any file that is “corrupted” will trigger some error handling code, that is supposed to spit an error message. That’s how it works on a PC. On the PSP, for some reason, it seems that instead of getting a nice “unsupported file” error screen, in most cases, the PSP just crashes with a breakpoint. It feels like Sony’s engineers have replaced all error handling code with breakpoints, but that’s just my guess so don’t quote me on this.

So I’m saying it again: breakpoint == not exploitable. Keep looking for other crashes!

I’ll try to have a more detailed post on “how to go further” with other crashes, but that’s it from me now

3 Weeks ago Datel made it to the (PSP) news headlines by releasing the new version of the Action Replay, a piece of software not signed by Sony and yet running on non hacked PSP.
As it seems clear that Datel figured out how to reproduce Sony’s signature (and technically, run everything they want on every PSP model), the PSP scene was excited at the possibilities that opened up for the future of homebrews.

There were several ideas about “how” this could be used for the benefit of the underground scene, but unfortunately all of these apparently led to … nothing at all.

The idea of figuring out the encryption process just by looking at the action replay EBOOT didn’t feel like a doable thing. It was clear from the start that it wouldn’t be any easier than figuring out Sony’s encryption process, which hackers haven’t been able to do in the 5 years of the PSP’s life.

Other attempts were made to find an exploit in the PSPAR Eboot, with classic buffer overflow exploits, through the program’s configuration files, which proved to be quite secured against such attacks.

Hackers were also hoping to be able to inject a fake “cheat code” into the Ram, that would actually be nothing more than a binary loader (a homebrew Loader). It turns out that the PSPAR does not allow users to create their own cheat codes (old Action replay software allowed to do that through the help of a “trainer” program). Actually the cheats are all stored in the EBOOT itself, making it virtually impossible to “inject” anything.

Finally, it was expected to maybe trick the update mechanism. Previous versions of the Action Replay would patch themselves by loading a data file in the PSP/COMMON folder. But it seems that this new version does not update itself. Rather, users have to connect to the pspar.com website and download an entirely new EBOOT for each update. This was somewhat expected, as it would otherwise mean that the EBOOT has the code to sign itself again after being modified, which was very unlikely. Nevertheless, it’s now officially clear that this won’t work either.

So all of this has been a dead end so far. The last ray of hope could come from Datel themselves, if they decide to come up with a commercial “homebrew loader” solution, like they did for the gameCube/Wii (SD Media Launcher). Personally I’d pay good money for that, but Datel hasn’t replied to people who inquired about that (do it too, if many people show interest, maybe they’ll consider it!). I guess they need to weight the pros and cons of going (yet again) at (legal) war against Sony…

On a side note, it means that people on official firmwares can now cheat in games, so the whole “we lock CFW users out of the PSN because CFW users can cheat” crap has no meaning at all anymore. It also probably means that online play will become less enjoyable now, but I can’t really tell, I’m on CFW and therefore can’t access the PSN or the playstation store…