PSP File (Research Thread)

[ChaosKnight]

Currently this is what's known about the PSP file.

1) It is the executable file for a PBP package.
2) It seems to have a header, what we know about it is here:
(Link provided by MelGibson http://www.psp-linux.org/forums/index.p ... #entry1748)

My summary of that:
char[4] = "~PSP"
int = 0x00080000 (version?)
short = 0x0101 (?)
char[28] = Text
short = 0x0102 (?)
int = File Size - 336
int = File Size
int x 3 = Offsets?
short x 2 = 0x40 (64)
int x 2 = 0x00000000
int = 1067008
int x 2 = 0
int = 1067008
int = 2553296
int x 8 = 0
int = 12
int x 12 = Encrypted Data? MD5 Checksum?
int = File Size - 336
int = 0x80 (128) Encryption?
int x 6 = 0x00000000

So far I've done some header modifications to test and come up with an error (80020148). If anyone else can get this error please post how you got it, as it would be very helpful.

Also please make sure to post any error codes you get and how you got them while researching the PSP file. Understanding these codes will go a long way towards advancing our research. They are one of the few favors Sony has done us.

So far discovered error codes:
80020130 - Executable is 0 length.
80020001 - ?? Executable is invalid.
80020148 - [UPDATE] Missing PSAR file.
800200D9 - Invalid PSP header. (Happened when I changed ~PSP to ~PSX)

Anything with ?? is subject to change, it's just my personal guess.

Thanks!

[zith]

I might be an ignorant fool, and i'm not too good at this low level stuff, but shouldnt an md5 checksum be 128 bytes and thus should not be conscidered for that "int x 12 = Encrypted Data? MD5 Checksum? " -part?

[ChaosKnight]

128 bytes? No. 48-bit.

[pedroleite]

128 bytes? No. 48-bit.

You could fool me... a MD5 checksum last time I checked used 16 bytes.

What are MD2, MD4, and MD5?

Also ... an AES-128 implementation requires a 128 bit (16bytes) key and an equal size IV (initialization vector) - if encoded in 16 bytes blocks.

I'm focusing on the Online System info, produced (at least) from the first time Wipeout Pure writes to the memory stick.

The profile, ghost ships, other saves have time and visible alterations.

These, recreated every time I remove them, appear to have the same content, altough encrypted somehow. (The byte size is the same).

The same section on the PARAM.SFO file are changed. Only a DATA1.BIN is listed, but binary data in DATA2.BIN is changed also.

[ChaosKnight]

The profile, ghost ships, other saves have time and visible alterations.

These, recreated every time I remove them, appear to have the same content, altough encrypted somehow. (The byte size is the same).

The same section on the PARAM.SFO file are changed. Only a DATA1.BIN is listed, but binary data in DATA2.BIN is changed also.

I found that interesting as well, that DATA2.BIN was unlisted but present. Do you think that comparing a few identical saves will lead to finding a private key (encrypted or otherwise)?

[ChaosKnight]

Also ... an AES-128 implementation requires a 128 bit (16bytes) key and an equal size IV (initialization vector) - if encoded in 16 bytes blocks.

My apologies. 12 x 4 = 48 bytes, not bits. So more than enough for a key + IV.

Int in this case = 32 bits = 48 bytes.

[pedroleite]

Comparision of identical saves could lead to the understanding of those "random" bytes ever-present in the param.sfo files...

Those could lead to a way to uncumber the structure of cipher and compression on the other important files...

The wildcard in the deck is the download.pspdif file from the wipeout pure japan downloads... Not having a single companion hash or public key, diffie-helman handshake gives way to a plain shared secret or just compressed.

My time is somewhat limited to make deep analysis on files. I would recommend having a large number of these identical saves, and building relationships of those files... statistically and then trying keys.

This effort could be distributed, if using the same files.

Also comparision between diferent consoles of the same files, could lead to identical results (ever wondered how the US games played on the Japan Console... shared keys at least..)

Maybe some operations on those bytes from PARAM.SFO could produce the key... also I bet the IV is the first 16 bytes of the file listed on the PARAM.SFO...

[pedroleite]

Also ... an AES-128 implementation requires a 128 bit (16bytes) key and an equal size IV (initialization vector) - if encoded in 16 bytes blocks.

My apologies. 12 x 4 = 48 bytes, not bits. So more than enough for a key + IV.

Int in this case = 32 bits = 48 bytes.

I tried all the "openssl enc" ciphers with combinations of those... could make it stick to a key, IV and hash...

I guess a couple more of firmware updates till this could be answered... :)

One way to press Sony for updates would be to make reports of know copyright circunvents :) This would show an update with new keys and methods ASAP :)
<grin>

[ChaosKnight]

I tried all the "openssl enc" ciphers with combinations of those... could make it stick to a key, IV and hash...

Maybe, but then again I think (could be wrong) that encrypting using AES has a tendancy to bloat whatever you are encrypting a bit. Maybe it could be that too. It would be nice to have a key + iv + hash though.

[pedroleite]

I tried all the "openssl enc" ciphers with combinations of those... could make it stick to a key, IV and hash...

Maybe, but then again I think (could be wrong) that encrypting using AES has a tendancy to bloat whatever you are encrypting a bit. Maybe it could be that too. It would be nice to have a key + iv + hash though.

Bloat? You could mean the padding + the IV in the start of the file... plus that it's less compressible...

By having uncompress headers in a compressed file, on could almost state that it must be parsing them to get the proper memory fixures and expansion...
I for one believe the offsets seen could mean:

- Position in file
- Size of block
- Position in memory where to expand

This would explain the large and small numbers... also I can't really tell if some should be int or long (void pointer)...

Being a 32 bit platform, and knowing the memory size, one could just make assumptions as who the memory could be distributed... (it must have kernel, video, bus and user space...)

The crash test experiences can show that some kind of loader program is examining the program... assumming it's a program...

Maybe this and the download.pspdif, could be some kind of libraries, dll, just placed inside an already constructed skeleton.

I noticed that by powering down, and doing power up with a game UMD inside it runs the UMD... each time it power ups (from shutdown not standby) it scans the memory stick also...

I wouldn't wonder if game demos came in "execute-only" memory sticks :)

[ChaosKnight]

I noticed that by powering down, and doing power up with a game UMD inside it runs the UMD... each time it power ups (from shutdown not standby) it scans the memory stick also...

I wouldn't wonder if game demos came in "execute-only" memory sticks :)

That would make sense. There's a bootable flag in the SFO.

[zith]

Argh, sorry people, i meant 128 bits of course (16 bytes).

[deadhead]

80020130 - file read error
80020001 - generic kernel error (default)
80020148 - PRX type unsupported
800200D9 - failed to allocate the memory block

[pedroleite]

80020130 - file read error
80020001 - generic kernel error (default)
80020148 - PRX type unsupported
800200D9 - failed to allocate the memory block

Hope you didn't read that somewhere not legally correct :)

Also... PRX sounds a lot like IRX (just browsed the other forums...)

Is there a simple layout map of the files used on the PS2, that could be transposed to this console...?

[Vyrus001]

Currently this is what's known about the PSP file.
So far I've done some header modifications to test and come up with an error (80020148). If anyone else can get this error please post how you got it, as it would be very helpful.

i got that err when i changed

int = 0x00080000 (version?)

to

int = 0x00070000

also, on a side note, i think these "err" msgs are actuly where in the hex code of the os that the app is breaking down, i have tried compileing sevral mips and mipsel elf's and saveing them as uncrypted DATA.PSP files and each time i compile under mips i get a "generic kernel err" but i have downloaded a mips simulator that works with the r4000 and found that 40020001 is the first instruction of my program. unfortunitly this simulator only works with non compiled assembler so i have not been able to asses the other err codes. another thing interesting to note is that when i compile the same hello world app under mipsel it just freezes the whole psp and it turns it self off...

btw here is the asm

main:
# print the number 1337
addi $2, $0, 1 # "print int"
addi $4, $0, 1337 # arg 31337
syscall # run

addi $2, $0, 10 # exit
syscall # run

[Neila]

a few relevant things:

Sony has licensed BSAFE from RSA, and uses its Public Key Infrastructure.
ELF/PRX type unsupported (err80020148) is triggered when PSAR is missing, so it's easy to assume that the ELF's of the programs are encrypted there.

What is stored in the PSP with regards to KEYs, is likely to be similar to the Public Key Accelerator Table, which the 1999 internet draft states are used only by Elliptic Curve cypher in BSAFE. It is most likely updated, but I do not know if it's possible to have the accelerator tables created for AES keys.

It would be necessary to have encryption and decryption some as fast as possible, so I guess only One type hardware encryption/decryption algorithm is used. It would have to encrypt and decrpt game-saves on reaquest of read/write. Wether there's a separate key used for game-saves, or it is the Private key used for decoding of Game data (like eboot) is still pretty much in the air.

here are the 1999 key-size reccomendations for BSAFE:

ALGORITHM USER KEY ORGANIZATIONAL ROOT KEY
OR LONG-TERM KEY
Diffie-Hellman 768-bit prime 1024-bit prime 2048-bit prime
DSA 768-bit prime 1024-bit prime 2048-bit prime
ECAES 160-170-bit modulus Not recommended
at this time
EC Diffie-Hellman 160-170-bit modulus Not recommended
at this time
ECDSA 160-170-bit modulus Not recommended
at this time
RC2 ----------8-128 effective key bits----------
RC4 ----------8-128 effective key bits----------
RC5 8-128 effective key bits with
16 rounds for 32-bit word or 20 rounds for 64-bit word
RSA 768-bit modulus 1024-bit modulus 2048-bit modulus

Internet-Drafts (public documents made availabe from RSA itself, now expired as specifications, but not tottaly useless to us)
BSAFE specs (1999):
http://quimby.gnus.org/internet-drafts/ ... afe-00.txt
TestCases:
http://quimby.gnus.org/internet-drafts/ ... est-00.txt

[SkyPanther]

80020130 - file read error
80020001 - generic kernel error (default)
80020148 - PRX type unsupported
800200D9 - failed to allocate the memory block

This my be usless information, but..

If trying to run a MIPSEL compiled elf, boot fails with a 800200D9 error
If trying to run a MIPS compiled elf, boot fails with a 80020001 error.

A i686 compiled elf (with uclibc) fails with a 80020001

[kry.sys]

If trying to run a MIPSEL compiled elf, boot fails with a 800200D9 error

Really?... What are you using to compile? (options/switches)

[SkyPanther]

DBL Post.. Sorry :/

[SkyPanther]

If trying to run a MIPSEL compiled elf, boot fails with a 800200D9 error

Really?... What are you using to compile? (options/switches)

I use my WRT54GS toolchain, its a mipsel-unknown-linux-uclibc-gcc compiler.

mipsel compiled file(Note that adding -static does not change anything, nor does stripping it, it always comes up with the same error):
ELF 32-bit LSB MIPS-II executable, MIPS, version 1 (SYSV), dynamically linked (uses shared libs), not stripped


PSP Datafile show up as:
ELF 32-bit LSB MIPS-II processor-specific, MIPS, version 1 (SYSV), not stripped


I just do:

For MIPS-1

Code: Select all

mipsel-unknown-linux-uclibc-gcc helloworld.c -o hello

For MIPS-2

Code: Select all

mipsel-unknown-linux-uclibc-gcc -march=mips2 hello.c -o hello

For R4000 (MIPS-3) (R4000 is the CPU the PSP uses)

Code: Select all

mipsel-unknown-linux-uclibc-gcc -march=r4k hello.c -o hello

Note this is not the Generic Linksys toolchain that linksys put up on their site, I built this toolchain manually on my Gentoo box using crossdev.

If anyone has Gentoo and wants to try it:

Code: Select all

emerge crossdev
crossdev --target mipsel-unknown-linux-uclibc

[blackdroid]

or just use the ps2dev toolchain. just stay away from using r5900 specific opcodes when doing inline asm.

[MelGibson]

I'm right now disecting these 2 files:

Wipeout: Pure -> File List:
0000032 , >:\PSP_GAME\SYSDIR\EBOOT.BIN
0001872 , >:\PSP_GAME\SYSDIR\BOOT.BIN

the structure of eboot.bin seems very similar to the structure of data.psp from the 1.5 (and 1.0) update...

eboot.bin

char[4] = "~PSP"
int = 0x00000000 (version?)
short = 0x0101 (?)
char[28] = Text
short = 0x0102 (?)
int = File Size - 347
int = File Size


And here comes the interesting part: File Size - 347 is exactly the size of boot.bin !!! So what I'm guessing right now is that eboot.bin is the encrypted / packaged version of boot.bin....

So i would update the structure right now to this:

char[4] = "~PSP"
int = 0x00000000 (version?)
short = 0x0101 (?)
char[28] = Text
short = 0x0102 (?)
int = File Size of unecrypted version
int = File Size of ecrypted version


So long
Mel

[dregin]

An encrytped file is gonna be bigger than the plaintext file unless they're using a substitution cipher, which would have been cracked ages ago.

Caesar's cipher. lol.

[qleyo]

char[4] = "~PSP"
int = 0x00000000 (version?)
short = 0x0101 (?)
char[28] = Text
short = 0x0102 (?)
int = File Size - 347
int = File Size


char[4] = "~PSP"
int = 0x00000000 (version?)
short = 0x0101 (?)
char[28] = Text
short = 0x0102 (?)
int = File Size of unecrypted version
int = File Size of ecrypted version

I'm a little confused, what was the same size as what exactly? ChaosKnight had 336 and not 347?

Comparision of identical saves could lead to the understanding of those "random" bytes ever-present in the param.sfo files..

nice idea i reckon...when do we start? :-p

edit: can someone post a link to the script that reads these files? and where exactly are the files located...i'm sorry for sounding so naive i understand whats going on but dont understand the steps to getting it done. Especially as i joined yesterday and got my PSP 2days ago...thanks

[MelGibson]

An encrytped file is gonna be bigger than the plaintext file unless they're using a substitution cipher, which would have been cracked ages ago.

Caesar's cipher. lol.

Ceaser's cipher is great... *lol*

However modern encryption schemes use archive techniques, too.... I just encrypted the boot.bin with a Elgamal 1024 bit key (didn't have a an AES key ) and the file shrank by ~50%.

[MelGibson]

I'm a little confused, what was the same size as what exactly? ChaosKnight had 336 and not 347?

ChaosKnight was refering to the file DATA.PSP that comes with the 1.5 firmware update....
There the difference between the long at 0x28 and the long at 0x2c was 336


I was refering to the file EBOOT.BIN from Wipeout (check for more here : http://forums.ps2dev.org/viewtopic.php?t=1566 )


Small update:

It has been confirmed that it's the same for the .BIN files from Ridge Racers. EBOOT.BIN containing the filesize of BOOT.BIN at 0x28

And i bet my left toe that it will be the same at vampire chronicl. Maybe someone who has access to it can check ?


Small update2:

Won my left toe... :D It's the same at Vampire chroncal

[ZeroOne]

The difference could be explained by any padding that might have been needed for the encryption.

(looking at the Wipeout Pure BOOT.BIN and EBOOT.BIN)

The size at 0x28 appears to be the original (unencrypted) file size and the size at 0x2C is the encrypted file size.

At 0x80 there is that block of 48 bytes which looks like a key/hash, 128bit AES + IV + Hash? It could well be encrypted with RSA. But where is the public key?

Well at 0xD0 the random data begins, or does it? Is this possibly an RSA key? there's about 128 bytes there which is enough for a 1024 bit key.

The extra size of EBOOT.BIN compared to BOOT.BIN is 347 bytes. The size of BOOT.BIN is 0x394AB5 bytes, lets say for AES encryption the source data has to be padded to 16bytes or even more likely 32bytes (128 bit), then the padded size of BOOT.BIN would be 0x394AC0.

So taking the size of EBOOT.BIN minus the padded size of BOOT.BIN
0x394C10 - 0x394AC0 = 0x150 (336)

So, I'd say that the ~PSP header is 336 bytes in size and encrypted data starts at 0x150. With the last 128 bytes (1024bits) of the header being some kind of large asymmetric key. Not sure what this key would be used for, but I doubt it is used to encrypt or sign much data, maybe just that 48 bytes in the header, who knows.

Anyone got any ideas how Sony is using public key encryption in this system?

[Krevnik]

For AES-128, you use 16 byte chunks, not 32 byte... minor niggle, but needed.

Most likely, something like RSA is used to encrypt the AES-128 key, or for signing the hash. Unfortunately, the block-size for encrypted data in RSA is the same size of the key, so we would be looking for a 128-byte block of encrypted data. Sony wouldn't /need/ to store an RSA key anywhere in distributed binaries, so I wouldn't be looking for one...

Oh, ****, I just realized something... we could be so seriously screwed. We have been running under the assumption that Sony chose to put the PRIVATE key on the PSP for decryption of the RSA... but I just came up with a situation that could lock us out of homebrew:

- Sony keeps the private key, hence why developers have to go through them
- The RSA encryption is used to store the actual AES key for an encrypted binary, a hash, and some other information
- Each PSP has the public key, which can be used to extract the AES key, the hash, and the other information

Why is this bad? Because Sony wants to secure the PSP, but also wants some form of digital signing. This method works out well, because if we find the RSA key used in the PSP, it is a public key. We would have to literally brute-force it through factoring to get the private key, which is the only key that can be used to sign a binary, and securely within Sony. Ouch. If Sony took this route (and this is just conjecture at this point), then we are truly screwed, and are stuck with using hacked firmware or loopholes to execute code. I personally hope this isn't the case, but I fear that with their RSA BSAFE claim, they might have actually been paranoid enough to do it.

[ZeroOne]

Oops, yeh 16 byte == 128 bit, so ignore the bit about 32 byte alignment, just got my maths a bit mixed up.

Yeh, I can't see a good reason to include an asymmetric key in the ~PSP file.

If each PSP has a public key, surely Sony don't care if its get found or made public, but if someone leaks the private key or somehow RSA gets cracked in the future their encrpytion scheme is broken. If there is one and only one public key on all PSPs it must stay the same for backward compatibility with games encrypted with this key, right. So why bother using RSA at all, why not just keep the AES key secret.

What if the public key is attached to the ~PSP file, and then used to decrypt the AES key. Well this is just as dumb because then anyone could decrypt the PSP file. So what is that 128 byte block? A signiture perhaps?

I just don't see where asymmetric encryption helps here, esspecially if the keys are not changing.

Looks like I'm going to have to go and swot up on cryptography again...

[Krevnik]

Asymmetric is invaluable here because unless the private key is leaked, or the public key factored (which is very slow, since 1024-bit keys take an absurd amount of time to check even one possible factor, let alone the max 2^1024 possibilities for a full-search), then any binary can be verified to be from Sony, without exception.

The nice thing about Asymmetric is that you can give anyone the public key, and the system is still reasonably secure (especially at 1-kilobit and higher keys). It also has this interesting tendancy that you can encrypt with either key. If I encrypt with the private key, I can decrypt with the public /or/ private key (since you can generate the public key from the private key). If I encrypt with the public key, only the private key can decrypt it. So, what you see is that if the public key can decrypt it, you /know/ it came from the private key (i.e. it is like a signature that is very difficult to forge).

So here is the thing, Sony probably doesn't give a rats-ass if we find a public key used to verify binaries. Sure, we can verify binaries ourselves, know how the process works, but without the private key, we can't create our own that are considered valid by the system. Even though it is /possible/ to get the private key from the public (since the private key really is an exponent with two reasonably-prime factors, and the public key is that same exponent, and a value which is both of those prime factors multiplied together), the search space is so boggingly large to be nearly hopeless.

Remember that Sony did mention something about signing, which does hint they have the private key, not the public one. :(