PSX Eboot discussion

[tommydanger]

Hi
I thought I would share my findings about the PSX Eboots. (official ones )
It's by far not complete, there is still many unknown. (atleast to me :P)
(I haven't found a place with a proper discussion about it yet :/ )
But I hope with the help of others we are able to reverse engineer the format much quicker

Feel free to correct me If I got something wrong

keys.bin
16 Byte file with the "keys" required to run the game?
If you try to run the game without the keys.bin present it gives you CA000005 error on 3.02 OE-B. I don't know if this is a custom error code from Dax?!
Used for XOR encryption -> memory card?!

document.dat
According to Dax bunch of pngs which hold the manual
Encrypted

Infact if you try to enter the manual with no document.dat present, it states that there is no user manual.
You can however switch document.dat, it doesn't seem to be tied to the eboot (I could open Cool Boarders 2 manual even though I was playing Hot Shots Golf )

16 byte header which is the same on every document.dat.
Starting with magic key 0"PGD", 0 Byte is followed by PGD
followed by 2 4bytes which MSB is 1 and other 0 then followed by 4 0 Bytes to finish of the header.

00 50 47 44 01 00 00 00 01 00 00 00 00 00 00 00

Eboot.pbp
Contains the compressed ISO image of the psx game.
40Byte header, just like any other pbp.
Contains offset to:
-sfo
-icon0 (icon you'll see in the xmb)
-pic0(semi transparent png which is always in front of pic1)
-pic1(full res background)
-psp
-psar
Psar offset points to
"PSISOIMG0000" followed by 4 Bytes of unknown purpose.
(Maybe some offset?)
16 bytes header, however only the last 4 bytes differ from eboot to eboot.
Resident Evil Directors Cut [JP]

50 53 49 53 4F 49 4D 47 30 30 30 30 00 B3 82 16

Cool Boarders [US]

50 53 49 53 4F 49 4D 47 30 30 30 30 C0 DD 7D 11

Hot Shots Golf 2 [US]

50 53 49 53 4F 49 4D 47 30 30 30 30 40 C2 F6 08

Immediately after the PSISOIMG0000 header there are some 0 bytes, which size vary from eboot to eboot
(Note, there are some 0 bytes before the PSISOIMG0000 label too)
After the 0 bytes there's a PGD header of unknown purpose

At the very bottom of every PSX Eboot you can find a PNG image.
(I still have to figure the offset to it out)
This is simply the image you will see when you execute your PSX Eboot.
On a non PSX Eboot you would see the gameboot.pmf.
I think it can be changed without breaking the eboot.

Then after the PNG image, theres another PGD header also of unkown purpose. After it -> EOF.
(Maybe the 2 PGD files in it are responsible for the way the manual works.
e.g When you browse through the manual and say exit it at page 15 and then you reenter the manual or reenter after you exited the game it's still at page 15.
I tested it on document.dat, leaving it on page 15 and then on page 20, nothing changed, file is still the same.
So there must be some indicator that keeps track of which page you browsed the last, maybe these two PGD's have something to do with it?!)

Savegames
It saves at ms0:/PSP/SAVEDATA/GAMEID
param.sfo
Ordinary param.sfo
icon0.png
Png which was extracted from the eboot
config.bin
Always 1024 bytes.
Purpose yet to be revealed
memcard1.dat/memcard2.dat
Always 131104 bytes.
Most likely imitates the playstation memory card file system
Encrypted (xor keys.bin?!)

Yeah that's it for now, tell me what you think

[rabbit]

Just to let you know, you'll want to call those "4 bytes" a DWORD, it'll make your life easier. In fact, here's basically how it is (on a 16-bit processor, as it's the typical standard)
Bit - 1 bit
Byte - 8 bits
WORD - 2 bytes
DWORD - 4 bytes
FILETIME - 8 bytes
QWORD - 16 bytes

Why do you think that KEYS.BIN is a XOR encryption? It's easily the weakest encryption there is, aside from a shift. I'd think it would be RSA. Odds are the KEYS.BIN is a file that holds a seed and a salt, or a bunch of seeds.

At first, I thought that last DWORD in the EBOOT header (by the way you've described it) could be a timestamp, but it doesn't really seem like it.

Now, by reasoning, there is a hash somewhere in the header, since changing the icons using PBP Unpacker or some similar tool breaks the EBOOT. I suggest looking for that first off, and then trying to find the hash routine in the PSP's system

[Coldbird]

config.bin - "purpose yet to be revealed?!" - Man... its the Emulator Config... ~_~

Fullscreen - Normal Screen - Original Screen, etc.

About 4-bytes... lol... normal peaple indeed call it DWORD... :P

Also the DOCUMENT.DAT thing is kinda logical...

[rabbit]

Originally Posted by Coldbird

config.bin - "purpose yet to be revealed?!" - Man... its the Emulator Config... ~_~

But what does everything in there mean? Surely screen size does not take up 1 kB!

[tommydanger]

thanks for the info
Yah I know about the DWORD, WORD thing, but I don't used it cause it could be also easily 2 WORD, who knows :P So I thought I would be safe saying 4 bits ^_^

Well I will do some research on config.bin tonight, I'm pretty sure it also stores the last viewed manual page in there

[rabbit]

4 bits is a half byte
Anyway, just call it a DWORD, since a DWORD = 2 WORDs. If you find out it's something different later, just update your spec.

[adrahil]

Might help you:

const char pops_savedata_key[] = {0x2D, 0x0C, 0xA1, 0xFE, 0xD1, 0x89, 0x67, 0xC6, 0x49, 0xA1, 0x68, 0x24, 0x82, 0x55, 0x78,0xA8};

All three files in savedata (memory cards 1 and 2 and config.bin) are encrypted with this key, which is the same for all... This encryption is the standart one for PSP Savegames by sceUtilitySave*. One can decode it with sceChnnlsv* though. Anyway, there *might* be some more encryption with XORs and stuff involved on the files BEFORE the sceUtilitySave* processing, but I highly doubt it. I just can't be arsed to decode the files right now, so if someone could at least decrypt config.bin, and post it, it would be appreciated.

[rabbit]

Again, what's with everyone talking about XOR "encryption"? It barely qualifies as encryption!

[das_buddy]

Someone please start testing the keys with included sample
RIGHT HERE

should be self-explanatory

[ymgve]

The PSAR file contains the whole image for the PSX cd, compressed and encrypted. All offsets in this text are relative to the start of the PSAR file.

Like others have said, the header always starts with:

50 53 49 53 4F 49 4D 47 30 30 30 30 nn nn nn nn

which is the string PSISOIMG0000 followed by a DWORD in lsb format.
This gives the size of the first part of the PSAR, which also means it's the offset for part 2 (More on that later).

At offset 0x00000400, there's these bytes:

00 50 47 44 01 00 00 00 01 00 00 00 00 00 00 00

followed by encrypted bytes up until offset 0x000B6A00. This area has been the same size on both images I've examined (Golf and Syphon). I've been told this is the area that contains offset and length information about the sector data, but I don't have this in decrypted form.

Then there's padding of 00 until offset 0x00100000.

At offset 0x00100000 the real sector data starts. It is organized in blocks, where each block equals 16 cdrom sectors. Due to compression, the blocks aren't evenly distributed, but they always start at a 0x20 aligned boundary. The blocks seem to be encrypted, but it also seems like the key is the same for all images. Check if this is the case by seeing if the offset at 0x00100000 contains the following data:

06 FF B8 03 29 92 FF FD 4F 44 BA 05 2E 1C F1 A5
A9 C5 CD 99 70 DC 8F 6E 44 20 7D BD 67 69 51 57
04 DF 1F 8F 93 74 89 AB 48 8B 06 F2 3D BF DD 7E
E2 30 D4 70 F3 A9 C8 7B B1 26 17 4A AD C7 29 7A

Every block I've seen so far starts with one of three byte sequences:

05 FF B8 02 BB 51
06 FF B8 03 29 92
07 FF B8 03 29 92

which is then followed by something that seems like a DWORD counter counting downwards.

The smallest block size I've seen is 0xC0 bytes, which corresponds to 16 empty cdrom sectors.



Now, on to part 2 of the PSAR.

It starts with a header:

53 54 41 52 54 44 41 54 01 00 00 00 01 00 00 00

which is the string STARTDAT followed by some DWORDs (version numbers?).
There are then two DWORDs, again in lsb format, one containing the size of the header, the next one containing the size of the PNG file. The header is then padded by 00s.

After the PNG, there's again a PGD section:

00 50 47 44 01 00 00 00 01 00 00 00 00 00 00 00

and then encrypted bytes until the end of the file.

One strange thing is that after the first 16 encrypted bytes, there's a byte string that's exactly the same for the two games I've examined:

C0 07 FB BD 3A E7 C7 D9 C9 17 DB 5D 8D 14 95 9A

Also, the whole encrypted region can be overwritten with garbage, so I guess whatever it contains is duplicated in the OEB firmware.