PBP Unpacker Documentation

1. PBP Unpacker
1.1 New
1.2 Extract
2. SFO Editor
2.1 Data Editor
2.2 Structure Editor
2.3 Character Representation
3. Technical Overview
3.1 PBP Files
3.2 SFO Files
1. PBP Unpacker
PBP Unpacker allows you to open, save and modify Sony PSP PBP archives.
1.1 New
Here you can create a new PBP archive.
Click on the square box (button) to select a file to add in each slot. Also, you can drag & drop files onto this square/box to add it.
Right-click on the button for options regarding the file:-

- Clear - Remove the file from the New PBP archive.
- SFO Editor - View the file in the SFO editor.
- or-
- View Image - View the image.
- Open With - Open the file for editing in an external program. A Hex Editor is the best choice here.

File Type / Version must not be changed.
A PBP archive must contain at least 2 files - one of which must be the PARAM.SFO file.
1.2 Extract
Once you have opened an existing PBP archive, the extract screen presents itself.
The files in the archive are listed in the listbox and the main preview picture (ICON0.PNG) is displayed by default.
Clicking on an image file in the list will display the picture.
Double-clicking on an image file in the list will display the picture in full size.
Right-click on a file for options:-

- Extract - Extract the selected file(s) to a destination of your choice.
- SFO Editor - View the file in the SFO editor.
- or-
- View Image - View the image.
- Open With - Open the file for editing in an external program. A Hex Editor is the best choice here.
- Send to New - Add the selected file(s) to a New PBP archive.

The way to modify an existing PBP archive is to load it, select some or all of its files in the list and select "Send to New". This way you may retain or change the PBP archive/files as you wish.
2. SFO Editor
SFO files are essentially a list of field and value pairs.
2.1 Data Editor
Here, the SFO data items are edited. The data is listed in the listbox.
The information displayed for each item are is follows:-

- # (Number) - This simply indicates to the user which data item it is. Useful when analysing in the 'advanced' view.
- Key - The field name of the data item.
- Data - The actual data value.
- Padding - Each data value is filled with blank space (null bytes) at the end. This is not strictly necessary but it is used for developer convenience. For casual SFO editing, this value does not need to be changed.
- Data Type - This describes the type of data it is. "0" indicates binary data, "2" indicates a normal text string and "4" indicates an integer (whole) number.

Right-click on an item for options:-

- Add - Add a new item.
- Edit - Edit the selected item.
- Delete - Delete the selected item.
- Edit Binary Data

- Binary Editor - Open the internal editor for binary data. See the section on Character Representation for further information.
- Open With - Open the data for editing in an external program. A Hex Editor is the best choice here.

- Data

- Move Up - Move the selected item up. This can also be done by pressing the blue Up arrow at the bottom
- Move Down - Move the selected item down. This can also be done by pressing the blue Down arrow at the bottom
- Sort by Alphabet - Sorts the items in alphabetical order by Key.

2.2 Structure Editor
This is for advanced used only.
Changes here will only be saved if the "Save with Manual Structure" button is pressed. The normal "Save" button automatically writes the correct file structure.
Press the "Update Structure Now" button for 'Data' changes to be shown in the 'Structure' view. You must do this before saving.
Use the "Save to PBP/Save to File" radio buttons to select where/how the manually structured file is saved.
When saving with 'Manual' structure, it is up to the user to ensure the fields are sorted alphabetically before saving.
Note that the 'Data Type' of an item is taken from the 'Data' view.
Naturally, if you save a broken SFO file then SFO Editor may not be able to load it again!
The 'Advanced Options' should be self-explanatory for those who would want to use them. Please read the Technical Overview of SFO Files to fully understand the implications and effects of these options.
2.3 Character Representation
If a single byte is used to represent a character, it can be 255 different values/letters.
Many of these cannot be represented properly and certainly cannot be entered properly, as they are non-keyboard characters.
PBP Unpacker uses the <#x> notation to represent characters, where 'x' is the decimal value of the byte.
For example, <#0> would be a null byte.
The user may enter characters this way in the 'Binary Editor' or when entering the 'Data' value in an SFO.
Note that <#13><#10> acts as a line-break (CRLF) for an SFO 'Data' value.
Also note that while you may enter any <#x> character in the 'Data' value box and it will be converted to the desired byte but when reading SFO files, the application will only convert #10 and #13 bytes into the <#x> format for editing. This is due to the fact that we are dealing with UTF8 strings and it is not applicable to convert non-keyboard characters in this way.
3. Technical Overview
Credit goes to Marcus Comstedt for a lot of this.
3.1 PBP Files
A PBP file is a rigid/inflexible file archive format used by the Sony PSP. It is designed specifically for storing a 'complete' program. As such, it has a certain number of file 'slots':-

1. Archive description file (PARAM.SFO)
2. Small preview picture (ICON0.PNG)
3. Small preview video (ICON1.PMF)
4. Overlay picture (PIC0.PNG)
5. Large background picture (PIC1.PNG)
6. Music to play (SND0.AT3) [codec]
7. Executable data (DATA.PSP)
8. Package for misc. data files (DATA.PSAR)

The files are simply put into the PBP file one after another (no kind of EOF markers or anything). The 40-byte header describes the offset of each file as a 32-bit unsigned little endian value. The structure of the header is as follows:-

Offset | Contents | Remarks
--- | --- | ---
0-3 | File type/descriptor | Always a null byte followed by "PSP".
4-7 | PBP Version (?) | Always 00 00 01 00.
8-11 | Offset of PARAM.SFO |
12-15 | Offset of ICON0.PNG |
16-19 | Offset of ICON1.PMF |
20-23 | Offset of PIC0.PNG |
24-27 | Offset of PIC1.PNG |
28-31 | Offset of SND0.AT3 |
32-35 | Offset of DATA.PSP |
36-39 | Offset of DATA.PSAR |

If a file is not in the PBP archive then its offset is the same as the previous file's offset. For example, if a PBP archive only contains PARAM.SFO, ICON0.PNG and DATA.PSP then the offsets would be as follows:-

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

3.2 SFO Files
SFO files are used by the Sony PSP to provide information about SaveGames and software such as firmware updates and UMD games. They are essentially a file of Key/Data pairs. It is important to know that SFO files have 4-byte data-alignment requirements. That is, the size of some parts must be divisible by 4. Where and how this is applicable will be explained. The 20-byte SFO header is as follows:-

Offset | Contents | Remarks
--- | --- | ---
0-3 | File type/descriptor | Always a null byte followed by "PSF".
4-7 | PSF Version (?) | Always 01 01 00 00.
8-11 | Offset of Key Table | In bytes. Relative to start of file. 32-bit unsigned little endian.
12-15 | Offset of 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 comes the Index table. Each entry in this 'table' describes a data item. Each item in the Index table contains the following data:-

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" includes 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. Essentially, 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.
Last modified on 16-Jun-2005
http://pdc.me.uk/pbp/
pdc@pdc.me.uk