Endless Paradigm

Full Version: [Random Info] (decrypted) PSX EBOOT (PSAR) Format
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Note: This only explores the PSAR section of the EBOOT.  The rest of the EBOOT is the same as standard EBOOTs so see the PBP File structure guide for more info.  Also, this refers to the decrypted EBOOT format used in the 3.0x OE popstation, not offical Sony EBOOTs.


This only focuses on the PSAR section of the EBOOT for PSX EBOOTs.  For 3.02 OE-B EBOOTs, the PSAR section had to go at 0x50000 (according to Dark_AleX - I've heard reports that the start can go elsewhere).  Now the PSAR section isn't fixed, starting from 3.03 OE-A.

One thing to note, the PSAR is divided into two parts.


Contents
First part contains the actual ISO:
OffsetType/SizePurpose
0x0012 bytesPSAR Signature - always is the string "PSISOIMG0000"
0x1BDWordOffset to the second part
0x40011 bytesGame ID in the format "_????_#####" (?=character, #=digit)
0x800Start of TOC information (see TOC for more info)
0x122C128 bytesGame Save (if the text is too short, the remaining bytes are null)
0x4000Start of ISO Indexes (see ISO Indexes for more info)
0x10000Beginning of ISO - note the ISO may be padded with null characters

The second part of the PSAR immediately follows the ISO:
OffsetType/SizePurpose
0x008 bytesThe string "STARTDAT"
0x10DWordSize of the "STARTDAT" header in bytes (always seems to be 0x50)
0x14DWordThe size of the gameboot PNG, in bytes

This header section is padded with nulls to satisfy the "STARTDAT header" value.  Following this section, is the gameboot PNG file.  Following the PNG is a "PGD" - possibly something to do with the Documentation???


TOC (Table of Contents)
The PSP's pops emulator uses the standard TOC format.  The TOC describes track information - some games use CD-DA audio, meaning that there's one data track, and multiple audio tracks on the disc.
Here's a breakdown - each "record" or "entry" consists of 10 bytes.  Here's an example:

Code:
00020800h: 41 00 A0 00 00 00 00 01 20 00 01 00 A1 00 00 00 ; A. ..... ...¡...
00020810h: 00 15 00 00 01 00 A2 00 00 00 00 69 59 74 41 00 ; ......¢....iYtA.
00020820h: 01 00 00 00 00 00 02 00 01 00 02 02 42 48 00 02 ; ............BH..
00020830h: 44 48 01 00 03 02 51 18 00 02 53 18 01 00 04 04 ; DH....Q...S.....
00020840h: 06 67 00 04 08 67 01 00 05 05 19 03 00 05 21 03 ; .g...g........!.
00020850h: 01 00 06 08 31 41 00 08 33 41 01 00 07 11 50 10 ; ....1A..3A....P.
00020860h: 00 11 52 10 01 00 08 15 01 54 00 15 03 54 01 00 ; ..R......T...T..
00020870h: 09 18 19 42 00 18 21 42 01 00 10 21 33 41 00 21 ; ...B..!B...!3A.!
00020880h: 35 41 01 00 11 21 43 10 00 21 45 10 01 00 12 24 ; 5A...!C..!E....$
00020890h: 07 34 00 24 09 34 01 00 13 25 04 25 00 25 06 25 ; .4.$.4...%.%.%.%
000208a0h: 01 00 14 26 18 25 00 26 20 25 01 00 15 29 42 38 ; ...&.%.& %...)B8
000208b0h: 00 29 44 38 00 00 00 00 00 00 00 00 00 00 00 00 ; .)D8............

Sorting it out into 10 byte chunks:

Code:
41  00  A0  00 00 00  00  01 20 00   <-- describes the first track
01  00  A1  00 00 00  00  15 00 00   <-- describes the last track
01  00  A2  00 00 00  00  69 59 74   <-- describes the lead-out

41  00  01  00 00 00  00  00 02 00
01  00  02  02 42 48  00  02 44 48
   [...]
01  00  15  29 42 38  00  29 44 38

Note, TOC uses "binary decimal" for various things - that is 0x60 = 60 in "binary decimal".
Okay, here's the breakdown:

OffsetType/SizePurpose
0x001 byteTrack type - 0x41=data track, 0x01=audio track
0x011 byteAlways null
0x021 byteThe track number in "binary decimal"
0x033 bytesThe absolute track start address in "binary decimal" - first byte is minutes, second is seconds, third is frames
0x061 byteAlways null
0x073 bytesThe "relative" track address - same as before, and uses MM:SS:FF format
  
Note that there's three special tracks at the beginning - these have track "numbers" A0, A1 and A2 (also note that a TOC cannot have more than 99 tracks).
The structure of these are slightly different - the absolute track field is always null:
Track "A0" - 41(type of track 1?)  00  A0  00 00 00  00  First track number 20(disc type, 20=XA) 00

Code:
41  00  A0  00 00 00  00  01 20 00

Track "A1" - 01(type of last track?)  00  A1  00 00 00  00  Last track number 00 00

Code:
01  00  A1  00 00 00  00  15 00 00

Track "A2" - 01  00  A2  00 00 00  00  Length of disc in the same format as normal track entries, MM:SS:FF

Code:
01  00  A2  00 00 00  00  69 59 74



ISO Indexes
Each index is 32 bytes long:

OffsetType/SizePurpose
0x00DWordOffset of block
0x04DWordSize of block (see note below)
the other 24 bytes are just junk
Blocks - uncompressed blocks are 16*2352 bytes (there's 2352 bytes per CD sector).  Although ISO sectors only have 2048 bytes per sector (don't include RAW data) the uncompressed block size is always 16*2352 bytes long.
Compressed blocks are compressed with zlib.


Anyways, I'm still looking into this format - mainly for my popstation GUI :)
cool
any way to open .psar files
michaelp Wrote:any way to open .psar files
Dunno what you're on about.

This is the format of the decrypted PSX PSAR section...  A normal PSAR is quite different.

Necro-Bot

[Image: Necropost.jpg]
Good info Madwin

Necro-Bot

[Image: gd9au.jpg]
Reference URL's