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:-

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:-

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:-

Right-click on an item for options:-

  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:-


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