dissecting the .psp file...

bpoint · Post by **bpoint** » Fri Mar 11, 2005 7:53 pm

Just a little something I've found inside the unknown.psp file after a few hours, in addition to what mc mentioned in this thread:

- There are two more size-like values at offset 0x48 (00101640h) and 0x54 (00101610h). The _difference_ between these two gives 30h, which could be the weird block at 0x80 -> 0xB0. But the values themselves don't make any sense... just lucky, maybe?

- All of the values from 0x28 to 0xD2 (excluding the weird block) are 4-byte aligned, and have values smaller than the file size of the .psp file, except for 0x3C (00400040h).

- There are quite a few 0000h's (16-bit) in the file, placed about every 20000h +/- 5000h bytes. I wouldn't expect something like this to happen in an encrypted data stream, so maybe they're separators, or... this isn't encrypted.

Since the PSP can display PNGs, it makes sense that it has zlib. I'm gonna try this weekend to see I can get something to be decompressed...

mc · Post by mc » Sat Mar 12, 2005 9:25 am

You are right. Statistically speaking, any combination of two bytes should appear about 50 times, given the total size of the file. But 00 00 occurs about 400 times after the header part, so it's definitely overrepresented. It might be interresting to look for other combinations which are overrepresented as well.

mc · Post by mc » Sat Mar 12, 2005 9:29 am

Bah. I'm too tired. I made an error in my quick check. It turns out it's more like 80 occurances of 00 00. The it falls quite a bit closer to the statistical coincidence zone...

mc · Post by mc » Sat Mar 12, 2005 9:41 am

D'oh! Even the revised value was wrong. I made a proper program for it now, instead of hacking it with grep, and 00 00 has 46 occurences after position 0x100, so it's definitely _not_ overrepresented. Here's the top 10:

ae f6: 83
a0 b0: 82
22 3f: 82
27 24: 82
61 ed: 82
28 77: 81
b9 f3: 81
bb ce: 81
4b 01: 81
fc f1: 80

and the bottom 10:

97 9f: 26
15 38: 27
25 36: 27
5f e7: 27
fc 38: 27
82 77: 27
87 f4: 28
8f d2: 28
10 aa: 28
9d cf: 28

bpoint · Post by **bpoint** » Mon Mar 14, 2005 2:49 am

Crap, you're right. I thought I was onto something there... :/

I caught a nasty cold this weekend, so I haven't had a chance to do anything more. :( I'll try poking at it again once this fever goes away.

KiWi · Post by **KiWi** » Mon Mar 14, 2005 7:37 am

If you're intrested in decrypting stuff / analyzing data / doing statistics then have a look at this:

http://www.cryptool.de/download.en.html

It has also the possibility to AES decrypt (and brute force *lol*) psp stuff ..

bpoint · Post by **bpoint** » Thu Mar 17, 2005 5:52 pm

I'm starting to finally get over this cold, and have been hacking at the .psp and .psar files some more. And I think I might have found something interesting...

It looks to me like the structure of the .psp and .psar files are very similar. Maybe they're both "archive" type files, of some sort, but the .psp file only contains one large file.

Taking the notes from nem's post in this thread (near the bottom):

Code: Select all

&#40;Tbl.nem.1&#41; 
ofs in header  size  
+0x000..+0x07f  128  COMMON1   same between some headers, random number 
+0x080..+0x0af   48  RND1      completely different, random number 
+0x0b0..+0x0b3    4  DATASIZE  dword, must be "archive member data size" 
+0x0b4..+0x0cf   28  FIX1      0x80 and zeros 
+0x0d0..+0x0d3    4  FIX2      0x00 0x00 0x00 0x06 
+0x0d4..+0x0e7   20  RND2      completely different, random number 
+0x0e8..+0x0ef    8  COMMON2   same between some headers, random number 
+0x0f0..+0x12f   64  COMMON3   same between some headers, random number 
+0x130..+0x13f   16  COMMON4   same between some headers w/datasize 0x110, random number 
+0x140..+0x14f   16  RND3      completely different, random number

If we ignore the COMMON1 section (as it's the .psp header itself), we have the 48 bytes of RND1 (0x80 -> 0xB0), 4 byte DATASIZE, 28 byte FIX1 and 4 byte FIX2 (except the value is 00 00 00 0B instead) line up perfectly in the .psp file as well!

Just doing a quick hex search of the COMMON2, 3, and 4 fields in the .psp didn't find anything similar in the .psar file however.

Anyway, this does explain why the header size difference at 0x28 and 0x2C (33AFF0h - 33AEA0h) is 150h! So maybe the actual data does start at that offset after all, since 150h + DATASIZE (33AEA0h) is the entire size of the file.

edit: slight clarification (I seem to be forgetting my English :) )

zigzag · Post by **zigzag** » Fri Mar 18, 2005 10:38 am

we need the DeCSS guy working on this...

Post by **mrbrown** » Fri Mar 18, 2005 11:41 am

zigzag wrote:we need the DeCSS guy working on this...

Why? There's no available software with the keys that he can reverse.

zigzag · Post by **zigzag** » Fri Mar 18, 2005 11:47 am

Its about the talent, not about the code...

Post by **ooPo** » Fri Mar 18, 2005 12:58 pm

Its all moot because I heard the DeCSS guy is working with Mitnick on cracking the PS3.

He never responds to my email, though... I guess we'll have to make do.

PompeySteve · Post by **PompeySteve** » Fri Mar 18, 2005 7:03 pm

zigzag wrote:we need the DeCSS guy working on this...

Wasn't DeCSS merely based on the code found in the Xing DVD player software which was lifted quite easily?

bpoint · Post by **bpoint** » Fri Mar 18, 2005 7:07 pm

zigzag wrote:we need the DeCSS guy working on this...

If I remember right, the DeCSS guy got lucky because Real left their keys in unencrypted form inside the Windows player. Firing up Soft-Ice and trapping the code to find where what memory gets used is a lot easier than trying to comprehend a completely closed system.

Back on topic, I'm curious as to how many of you think the data blocks we've found are encrypted with AES? Why do you think it is AES and not something else (possibly completely propietary)? After studying the way AES works, it does leave itself to be implemented fairly easy on something like the PSP (16 byte blocks [good for alignment], fast and easy to process).

If it is AES, then without the keys, there isn't much else that can be done except brute-force (uh, no)... however, we _could_ make semi-intelligent guesses about certain sections of what the encrypted data would be if it was decrypted, and possibly calculate some keys which match that encryption -> decryption, and then test those keys on the real data itself.

Of course, there's also the possibility that the keys change every block too, by chaining the output data to the previous key... urgh.

I'm going to try to compare save data images next. Namco Museum's old-skool save data is tiny and is most likely simple (score + 3 byte name), so detecting differences should be easy. Anyone want to post some samples up before me are welcome to try -- I probably won't get to it till later this weekend.

zigzag · Post by **zigzag** » Sat Mar 19, 2005 3:12 am

The key will probably end up being leaked as well.

Why would game saves be encrypted?

And perhaps we can do a distributed brute force? How long would that take? With say, thousands of computers working together...

Update: Nevermind, just read 149 trillion years for a computer doing 255 keys per second :-/

kry.sys · Post by **kry.sys** » Sat Mar 19, 2005 4:06 am

PompeySteve wrote:
zigzag wrote:we need the DeCSS guy working on this...
Wasn't DeCSS merely based on the code found in the Xing DVD player software which was lifted quite easily?

he found where the keys passed with any software player.

you actualy dont even need decss anymore.. most dvd backup apps will tell you to run a legit software player then kill it once the dvd loads.. the key stays in memory and the backup app picks up where the player left off.

this is no where near what happens on the PSP... my "speculation" of course. not to mention there is no software player for the psp availible to the public. the one devs get plays un-packaged code at a snails pace anyway

edit: engrish new 2 meh

bpoint · Post by **bpoint** » Sat Mar 19, 2005 4:59 am

zigzag wrote:The key will probably end up being leaked as well.

At some point in time, yes... it inevitably will be leaked. Most likely someone who has access to a real devkit and creates a few tools to help himself out.

So, do we just sit around and do nothing all day until the leak happens (who knows when it could happen), or do we make an honest attempt at cracking this thing? :)

zigzag wrote:Why would game saves be encrypted?

If you have even looked at the saves on the memory stick, you wouldn't be asking that question. They _all_ are encrypted (er, well... all being the three games I have in my possession).

It would make sense that the memstick read/write function in the OS does the encryption/decryption automatically. That way everything is locked down, from firmware upgrades to saved games.

bpoint · Post by **bpoint** » Thu Mar 24, 2005 9:35 pm

bpoint wrote:I'm going to try to compare save data images next. Namco Museum's old-skool save data is tiny and is most likely simple (score + 3 byte name), so detecting differences should be easy.

I finally got around to checking Namco's save data. Unfortunately, it's worse than I expected.

I took a save from DigDug, where I had already made the top high score. Then I played again, and made a new high score. An unencrypted save would only have a few bytes different (like I mentioned earlier, 4-byte score, round number and 3-byte name/initial data), but it turned out the _entire_ .bin file was completely different. There was not a single byte that matched from the previous version to the next -- even though the file size was exactly the same.

Even if the file had been encrypted with AES (assuming a static key), then at some 16-byte aligned position in the file would start to show differences.

I then performed another test, checking to see if perhaps DigDug's save was at the top of the file, which possibly caused the difference. Going into PacMan, changing an option, and then exiting, I was able to get it to save the new options to the memory stick. Again, this new save data was _entirely_ different than the previous two, and again, the file size was unchanged.

So... if the PSP is using AES, it's either got multiple keys, or the key is randomly generated each time and is itself somehow stored in the save data.

One odd thing I did notice about Namco's original save data in comparison to Mingol, Lumines, and Namco arranged is that only the original version .bin is _not_ filesize aligned to 16-bytes. It's size is exactly 19Ch, 4 bytes short of alignment. Hrmm...

PinkPeach · Post by **PinkPeach** » Fri Mar 25, 2005 10:36 pm

In case you need it, here is another namco saves: Tales Of Eternia.

You will find 4 sets of bin+sfo files. each time i just loaded and resaved directly without moving, so only time has changed.

sfo key has changed as well as nearly every bytes of the corresponding bin.

Dunno if you can make anything out of this.

http://tokyo.cool.ne.jp/barfhappy/uljs00015-003.zip

uspual · Post by **uspual** » Tue Mar 29, 2005 1:31 am

bpoint wrote:So... if the PSP is using AES, it's either got multiple keys, or the key is randomly generated each time and is itself somehow stored in the save data.

It is likely that AES keys are made with certain formula like,

[random 4-byte-key] + [pre-defined 12-byte-key]
[random 8-byte-key] + [pre-defined 8-byte-key]
blah blah..

This is common way to encrypt data. In general, random part is stored in front of the encrypted data.

-uspual

Kamilion · Post by **Kamilion** » Tue Mar 29, 2005 1:53 am

or it's using CBC -- Cipher Block Chaining.
If the beginning of the file unencrypted only has one byte changed, the whole rest of the file will be encrypted differently.

nem · Post by **nem** » Wed Mar 30, 2005 12:03 am

Kamilion wrote:or it's using CBC -- Cipher Block Chaining.

I bet CBC. It's nearly obvious.

cheetah · Post by **cheetah** » Wed Mar 30, 2005 2:51 pm

http://www.rsasecurity.com/press_releas ... oc_id=5648

here is a press release from RSA. It sounds like it is something similar to protection of the ps2.

DBG · Post by **DBG** » Thu Mar 31, 2005 4:14 am

*hands kappa ebisen bags (fukuro?) to bpoint and everyone else that's working hard*