Slynk's Revenge A blog dedicated to my adventures in the world of programming.

There are many methods to accomplish qa and I'm too lazy to document them all so I'll tell you one way. Linux.

PS3
Step 1) Install OtherOS++, install linux, make sure to enable the ps3 modules when compiling the kernel.

Step 2) Download, and compile the ps3dm utils

PC
Step 3) Download my tokenator

First off, I will not help you obtain a copy of IDA. Go buy it.

http://www.mediafire.com/?kb3s14zi6hramrx

Extract the contents into your IDA folder. I don't take credit for these plugins and loaders.

Loading a File

There are two file types I'll teach you to load. SPU and ELF files.

SPU files can only loaded in IDA 32bit mode. When you load IDA choose "Go" and drag the file onto IDA. Make sure elf is highlighted at the top. In processor type, choose "IBM SPU Cell Processor: spu." Click set. Click OK. "Undefined or unknown...blabla" yes. You should be good to go.

Elf files can be loaded in either 32 or 64 bit mode. When you load IDA choose "Go" and drag the file onto IDA. Make sure PlayStation 3 ELF is highlighted at the top. Don't mess with the processor type. Kernel option 1 check "Create function if data xref data-> code32 exists.

Optional: I don't know what these do but I turn them on anyways XD In kernel option 2 choose "Coagulate data segments in the final pass", "Perform 'no-return' analysis", and "Perform full stack pointer analysis."

Click OK. Sometimes you get a better result from running the analyze_self script. (File->IDC File->C:/Program Files/IDA/idc/analyze_self.idc) Hit yes, copy the TOC Address it shows you and click OK. Go to Options->General->Analysis->Processor specific analysis options. Type the TOC address in (I use 0: instead of 0x to be safe. No clue if it makes a difference.) While you're at it click "Create subi instructions. Click OK. Click Reanalyze Program. Click OK. And wait.

You'll know when a script is done because at the bottom left it's say "AU: idle".

IDA Basics

Just a few things. The program is expansive and I'd love to get to know more about it but here's a few things I know. Hex view and IDA view are connected. That means if you find a string in hex view, you can see it in IDA view. This won't show you magically where it's used at but sometimes, that string is xrefed. If under the string you see "# DATA XREF: " you can right click the ":off_XXXX" at the end, and choose XREF To or From. To, will give you a graph of any functions that have a call "to" that offset. From give's a graph of offset's called "from" that offset (mostly only useful for viewing a graph of where all a function leads to.)

In IDA view, you can search for either an immediate value, a string, or a byte sequence. I've never "not" checked "find all occurrences." Don't know why you wouldn't want to. It'll return a list of occurrences in its own window.

If you're lucky, the file you scanned will have some of the functions named (something other than sub_, nullsub_, or start). These are known functions that are defined in the ps3 sdk.

When exiting, always make sure, unless you WANT to re analyze the whole file again, to choose one of the Pack database options and Collect garbage.

I'd like to begin this post with a few comments.

1. Only a little bit of this is my own findings, a lot of this info was found from other sources.
2. NPDRM discussion does not have to be a topic of piracy, it can be used in conjunction with signing/encrypting homebrew if it is fully documented one day.
3. This is mostly to bring together the bits of info scattered across the interwebs.

typedef struct 
{ 
    byte[4] block_type;  // this is 3(NPDRM) 
    byte[4] block_size;  // this is 0x90(sizeof(Self_NPDRM)) 
    byte[4] unknown1;    // So far always 0 
    byte[4] unknown2;    // So far always 0 
    byte[4] magic;       // 0x4E504400(NPD) 
    byte[4] unknown3;    // So far always 1 
    byte[4] license;     // 1 Network License, 2 Local License, 3 Free 
    byte[4] type;        // 1 Executable, 21 Update for Disc Based Game 
    byte[0x30] titleid; 
    byte[0x10] hash_unknown; 
    byte[0x10] hash1; 
    byte[0x10] hash2; 
    byte[0x10] padding; 
} Self_NPDRM

I'll keep this article simple for its target audience, the newbs. (That's not to be confused with noob.)


Learn about AES Encryption:


AES is an encryption that uses a key and an initialization "vector" to encrypt the file. The key can be 16 bytes (numbers, for simplicity), 24 bytes, or 32 bytes long. These numbers are the same as when you see AES-128, AES-192, and AES-256 respectively. The initialization vector is, at least in PS3 encryption, always 16 bytes.

AES can be used in a variety of "modes." Such as the PS3 uses AES in both CTR mode and CBC mode. Think of these as just... a different set of instructions for reading and writing the encrypted data.

Brute forcing AES is just out of the question. Think about this. If you had a 1 digit password, with a possibility ranging from 0-9, there would be 10 possibilities aka 10^1. If you had a 2 digit password, there would be 100 possibilities aka 10^2. 3 digits would be 1000.

Now with AES, each digit ranges from 0-255. Even if you used a 16 byte key, that would be 256^16 possible keys which is 3.4028236692093846346337460743177e+38. That's just for the key. If you don't know the initialization vector, because you need that too, there are (256^16)(256^16) possible combinations to cycle through. It's unrealistic with current hardware, even with a distributed attack.

Learn about Hashing:

Hashing's a pretty easy concept to understand. It's like a book summary. You get the gist of what's in the book but you couldn't replicate the entire book from that summary. It's the same with hashing. You generate a summary of the file, or part of the file, then store it to be checked later. Now the problem with this is if you know the algorithm used to calculate the hash, you might be able to tweak a file to loosly match it. Or anyone could easily just hash the file themselves and replace your hash. To avoid that, HMAC uses a key to encrypt the hash. If the person doesn't have the key, they can't replicate a similar file structure nor can they make their own hash.

Learn about ECDSA:

I'll be honest, I'm still learning about this. But from what I understand, this is for authenticity. You have 2 keys, the public key (the one you give to people to verify that the file that get is from you) and the private key (the key you use to sign the file.) Due to one of the parameters for generating the key not being random like it should be, the people could calculate private keys for the ps3 to sign their own files. This has since been fixed for most keys.

For those who live under a rock and don't watch Raocow play Super Mario World rom hacks, you probably wouldn't know he's also an artist with a large following. The community following raocow is full of skilled individuals who can sing, hack a rom, and even make some kick ass music.

With that said, these folks have taken an interest in making a custom editor / engine to a tune similar to SMBX. I am currently working with warioeagle to make a custom editor and engine for the community.

The editor and engine are being written in C#/XNA. It's still in a very early stage of development but I will post any updates as they arrive. Currently I'm working on a Player Editor that lets you set powerups, sprite sheets, and animations. It's mostly done, but I'm working out a few bugs and tweaking some things (such as allowing the designer to adjust the animation speed).

I decided I really should have a site to chronicle anything I do. Especially if it was a point of interest to others. So what you can expect from this site:

• Tutorials on a wide range of topics from General Programming, to Game Development, to Security.
• Updates on current projects.
• Philosophical posts for when I'm feeling extra chatty.
• Probably other stuff as well.