A pbp file is actually a file container. The possible file formats include:
- Description file (Param. SFO)
- Preview image (icon0.png)
- Preview Video (icon1.pmf)
- Introduction image (pic0.png)
- Background Image (pic1.png)
- Music (snd0.at3)
- Execution data (data. PSP)
- Other data files (data. psar)
There is no separator between these files. The pbp file header is fixed to 40 bytes, as described below:
Offset |
Content |
Description |
0-3 |
File type/Description |
Always one 00 followed by "PSP" |
4-7 |
Pbp version (?) |
Always 00 00 01 00 |
8-11 |
Offset of Param. SFO |
|
12-15 |
Icon0.png offset |
|
16-19 |
Icon1.pmf offset |
|
20-23 |
Pic0.png offset |
|
24-27 |
Pic1.png offset |
|
28-31 |
Snd0.at3 offset |
|
32-35 |
Offset of data. psp |
|
36-39 |
Offset of data. psar |
|
If pbp does not contain a file, the offset of the file is the same as that of the previous file. For example, if a pbp contains only Param. SFO, icon0.png, and data. PSP, the offset should be similar to the following:
File |
Param. SFO |
Icon0.png |
Icon1.pmf |
Pic0.png |
Pic1.png |
Snd0.at3 |
Data. psp |
Data. psar |
Offset |
40 |
1772 |
1772 |
1772 |
1772 |
1772 |
20606 |
20606 |
SFO File
SFO files are used by PSP to store information about games and software, such as firmware upgrades and UMD games. They are essentially key-value pairs. The alignment is 4 bytes ). The SFO header file contains 20 bytes. As follows:
Offset |
Content |
Description |
0-3 |
File type/Description |
Always one 00 followed by "PSF ". |
4-7 |
PSF version |
Always 01 00 00. |
8-11 |
Offset of the key table |
In bytes. Relative to start of file. 32-bit unsigned little endian. |
12-15 |
Offset of the value table |
In bytes. Relative to start of file. 32-bit unsigned little endian. |
16-19 |
Number of data items. 32-bit unsigned little endian. |
|
Next is the index table, where each record describes a data item. Each data item includes the following data in the index table:
Offset |
Contents |
Remarks |
0-1 |
Offset of key name in key table |
Always a NULL byte followed by "PSF ". |
2 |
Data-alignment requirements (?) |
Always 04. Single (1) byte. |
3 |
Data Type of Value |
Single (1) byte. See below for data-type information. |
4-7 |
Size of value data |
In bytes. 32-bit unsigned little endian. |
8-11 |
Size of value data and padding |
32-bit unsigned little endian. |
12-15 |
Offset of data value in data table |
32-bit unsigned little endian. |
"Offset of key name in key table" means just that. The first item will have offset 0 (zero). The same principle is true for "offset of data value in data table"
Data types are one of 3 :-
- 0-binary data. Its format and interpretation depends on its key.
- 2-text. a null-terminated UTF-8 string. note that "size of value data" has des the null byte. also note that CRLF acts as a line break-this can be used for "title" data and so forth.
- 4-number. A 32-bin little endian integer value.
Next comes the key table. This is a simple list of all key names. Each key name is null-terminated.
Key names need to be in alphabetical order. Presumably, a binary search is carried out to find data values and their respective keys.
The 'key table' must conform to 4-byte data alignment. null padding can fulfill this requirement after the final key.
After this comes the all-important value table. essential, the data items are listed one after another.
String (Type 2) and binary (Type 0) data may have any amount of padding in the form of NULL bytes.
Each data item has to conform to the Data Alignment requirements. Once again, null bytes can fulfill this requirement by being added on the end of the data.
N. B.
The "category" Key describes the purpose of the SFO file. The three options are MS (memorystick savegame), Mg (memorystick game) and UG (UMD game ).
An interesting observation is that when "category" is "Ms", the "Ms" string and only the "Ms" string is not NULL terminated.
The practical implication of this is simply that "size of Data" for "Ms" is 2 (rather than 3) and NULL bytes must still fill the remaining 2 bytes as normal.