PSXperia: Converts any PSX game to work on Xperia Play

After two hard weeks of decompiling, reverse engineering, graphing, and coding, I’m proud to announce PSXperia, a set of tools to extract, patch, and repack the Crash Bandicoot game that comes with all Xperia Play phones to use any PSX game (that you legally own). In addition to allowing you to play any property ripped PSX game, you can also set a custom icon and the game will show up in the phone’s Playstation Pocket app, so you can quickly access it when you flip the gamepad out. I’ve converted and tested 8 games with this tool and they all run flawlessly, but if things don’t work out so smoothly for you, submit your issues to GitHub.

Download the program here and the source here
Setup and usage guide here
Support here
Bug reports here

Reverse engineering a dynamic library on the Xperia Play

Welcome to part two of my journey to completely reverse the PSX emulator on the Xperia Play. When we last left off, I managed to figure out the format and the basic order of execution of the emulator. It’s been a week now, and I have more stuff to reveal.

Decrypting the data

One of the main problems was that most of the important files are encrypted. More specifically, these three files: ps1_rom.bin (BIOS), (the emulator), and image_ps_toc (then unknown data). As I mentioned before, Sony used what’s called white box cryptography, which means obfuscating the code to hide the decryption keys. But, we don’t need the keys, we just need the decrypted data. The obvious way of extracting the decrypted data is dumping it from the RAM. However, the Android kernel I’m using doesn’t support reading /dev/kmem and I don’t want to mess with recompiling the kernel. I’ve also tried dumping with GDB, and it did work, but the data isn’t complete and is messy. I used a more unorthodox method of obtaining the decrypted data. After hours of reading and mapping in IDA Pro, I figured out that everything that is decrypted goes through one public function, uncompress(), a part of zlib. This is important, because this means everything that is decrypted is sent to zlib and zlib is open source. That means, I just need to recompile zlib with some extra code in uncompress() that will dump the input and output data. A simple fwrite() will do, as the data is already in a clean, memcpy-able form. (I forgot about LD_PRELOAD at the time, but that might have worked easier). After some trouble getting NDK to compile zlib, I have dumps of both the compressed/decrypted and uncompressed forms of all encrypted content.

Analyzing the dumps

The next thing is to find out the meaning of the data that we worked so hard to get. ps1_rom.bin is easy. Surprisingly, it is NOT a PS1 BIOS file, but actually part of a PS2 BIOS dump (part, being only the PS1 part of the PS2 BIOS). Does this mean a PS2 emulator is coming for the Play? I don’t know. Next, we have Plugging it into IDA Pro reveals the juicy details of the PS1 emulator. It’s really nothing interesting, but if we ever want multi-disk support or decrypting the manuals, this would be the place to look. Finally, we have image_ps_toc (as it is called in the symbols file). I am actually embarrassed to say it took almost a day for me to figure out that it’s a table of contents file. I did guess so at first, but I couldn’t see a pattern, but after a night’s sleep, I figured out the format of the uncompressed image_ps_toc file. (Offsets are in hex, data are little-endian)

0×4 byte header

0×4 byte uncompressed image size

0×12 byte constant (I’m guessing it may have something to do with number of disks and where to cut off)

0×4 byte number of entries

Each entry:

0×4 byte offset in, where the compressed image is split format

I actually forgot to mention this in my last post. The “rom” that is loaded by the emulator is a file named It is found on the SD card inside the ZPAK. It is unencrypted, and if you delete it, it will be downloaded again from Sony’s servers unencrypted. How it works is that an PSX ISO is taken and split into 0×9300 (about 38kb) sections, and each section is compressed using deflate (zlib again) and placed inside (with a 0×14 byte header). The offsets of each section is stored in the toc file (and encrypted) because although uncompressed, they’re perfect 38kb sections, compressed, they’re variable sized. I already wrote a tool to convert to an ISO and back again/

Putting it all back together

Now that we’ve tore apart, analyzed, and understood every element of the PSX emulator on the Xperia Play, what do we do? The ultimate goal is to convert any PSX game to run on the Xperia Play, but how do we do that. There are two main challenges. First of all,, which loads everything, expects data to be encrypted. Once again, we need keys. Also, I’m pretty sure it uses a custom encryption technique called “TFIT AES Cipher”, because I was not able to find information on it anywhere else. However, since we have the decrypted files, we can patch the library to load the decrypted files directly from memory, and I was halfway into doing that when I realized two more problems. Secondly, if I were to patch the library to load decrypted data, that means every user needs to decrypt the files themselves (because I won’t distribute copyrighted code). Third, image_ps_toc is variable sized, which means if the image is too big, it’ll break the offsets and refuse to load.

Currently, I’m trying to find the easiest and most legal way of allowing custom image_ps_toc files to work. (Bonus points if I can also load custom BIOS files). What I hope for is to write a wrapper library,, which loads and patches GetImageTOC and GetImageTOCLength to load from a file instead of memory. This means I have to deal with Java and JNI again (ugh), and also do some weird stuff with pointers and memcpy (double ugh). The JNI methods in the library do not have their symbols exported, so I have to find a way of manually load them.

Bonus: blind patching a binary

When trying to patch a method for an ARM processor, it’s a bit of a pain and I’m too lazy to read about proper GDB debugging techniques. In additions, Sony wasn’t kind enough to compile everything with debugging symbols. However, I came up with a hacky-slashy way of changing instructions and seeing what happens. First, open up IDA Pro and find the function you want to modify. For example, I want decrypt_executable() to bypass decryption and just copy data plain. Find the instruction to change, and the opcode to change it to. For example, I want to change a BL instruction to NOP and CMP to CMN (don’t jump to decryption process and negate the “return == 0″). I have ARM’s NOP memorized by now 00 00 A0 E1. I don’t know what CMN’s opcode is, but if I look around I can find CMN somewhere and I see it’s just a change from a 7 to a 5. After everything’s done, copy it over to the phone and run it. If it crashes (and it should), look at the dump. The only important part is the beginning:

I/DEBUG   (  105): signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000054
I/DEBUG   (  105):  r0 002d9508  r1 413c103c  r2 2afcc8d0  r3 002d93d8
I/DEBUG   (  105):  r4 00000004  r5 002d93e0  r6 6ca9dd68  r7 00000000
I/DEBUG   (  105):  r8 7e9dd478  r9 2cbffc70  10 0000aca0  fp 6caa4d48
I/DEBUG   (  105):  ip 002d93e8  sp 7e9dd0c0  lr 00000001  pc 4112d01c  cpsr 40000010

The error message doesn’t help at all “SIGSEGV,” but we have a dump of all the registers in the CPU. The important one is the PC (program counter), which shows what offset the last instruction was at offset 0x4112d01c in the memory. To get the program offset, just cat /proc/{pid}/maps to find where is loaded in memory. Subtract the offsets, and pop it into IDA pro. Now figure out why it crashed and try again. I need to learn proper debugging techniques one day.

ASCIIMan: A Windows Console platformer game written in Java

For my final project in my Computer Science class, I decided to write a game in Windows Console, in Java. It’s hard to appreciate how hard this was unless you REALLY know Java and you REALLY know Windows SDK. I basically wrote a entire game engine complete with collision detection, physics, etc from scratch in Java. I used almost every obscure Java knowledge I have including reflections, JNI, enums, and thread handling. It is really less of a game and more of a technology demo because I can’t design anything. I hope someone else can write a better level (I made it very extendable), and fix collisions (those are the only major “bugs”, otherwise, it’s a fully playable game). Again, this is one of those things where people who don’t know alot about Java won’t think it’s a big accomplishment, but those who do will bow down to this wonderful code. /ego trip

ASCIIMan Project Page

P.S: I updated Josh again, I converted the whole project to NetBeans, my new found love.

Update Foursquare from Twitter

Ok, so I THOUGHT this was going to be a quick one hour project. I want to update foursquare from Twitter because my cell phone plan ONLY allows access to Twitter and MS Exchange (why, I don’t know). The goal was to write a application that sits in the background and waits for “command” tweets. My original plan was to do it in C++, however, networking & sockets in C++ is too complicated for such a small project, plus no good libraries are available for Twitter in C++. Ok, so I moved to Python. It has great networking tools right? Plus a wonderful Twitter API library. I was halfway through when I found that Foursquare support was crappy. Finally, I went to the language I hate the most. Java. Also, note that I’ve been messing around for hours now. Fuck. So I quickly wrote this in Java, tired and angry. The result is the worst code I ever written. I am the only person who would ever make use of this, so I didn’t care. I’m only releasing it for archival purposes, for some laughs to random strangers, and as an example of what you should NOT do. It’s a great example of “it compiles, ship it”.

So, the only features are: search foursquare, checkin to foursquare, and greet the user. To use it, you need to set up two twitter accounts, one for the client (you will tweet commands from here) and one for the server (the server will use this account to tweet). Make the client follow the server and the server follow the client. Make sure your twitter client supports geotags. If your tweet doesn’t have a geotag, the listener will crash. (I know, stupid)

Again, you MUST have a geotag with every tweet.

To search, tweet:

Search for “restaurant”

Note: You MUST put the quotes for the search to work. For all commands, the server only reads “key” words. That’s the first word and any word in quotes. You can type in

Search for some shitty “restaurant” up in this bitch

and it’ll work just fine. For search, if you don’t have any words in quotes, then you’ll just get a list of 10 closest venues.

Now, the server will return top ten results near you, in two tweets (a random character appearing at the end of server tweets is not a bug, I did that because Twitter rejects any two tweets that are identical).

0: Random Chinese Restaurant

1: Some Mexican Restaurant

2: Another Crappy Restaurant

and so on, to check in to “Another Crappy Restaurant”, tweet

Checkin 2

If you know the name of the venue, you don’t have to search, you can just tweet.

Checkin to “another crappy restaurant”

That’s basically it.

Now, about the spaghetti code, here’s some of the things I used: depreciated methods, tons of try-catch just to bypass errors (no actual error handling), bad variable name and no documentation, bad code flow, usage of Runtime.getRuntime().exec() to call cURL because I was too lazy to write a proper HTTP controller which is a security and stability issue, use of reflections with data across the internet, and so much more. My hope is that someone will take it and fix it up or something, because I’m too tired to do anything about it.