PARAM.PFD
Description
This files are responsible to prevent tampering of other files of the same folder, the only purpose is the security of the folder contents. Contains the cryptographic signatures of other files of the same folder (not all, but the ones that developers decided to be important enought to be secured).
Its used in several paths of the PS3, usually to secure data related with the user profile e.g:
/dev_hdd0/home/0000000*/savedata/SAVEDATA_DIRECTORY/PARAM.PFD <---- in all save game folders /dev_hdd0/home/0000000*/trophy/NPCOMMID/PARAM.PFD <--- in all trohpy folders /dev_hdd0/home/0000000*/trophy/_TROPSYS_/PARAM.PFD <---- in the "user trophy index" folder
Usually PARAM.SFO is one of the files listed (and supervised) by PARAM.PFD but this can vary.
Every time one of the files listed in the Protected files table inside the PARAM.PFD is updated... the PARAM.PFD itself needs to be updated to store the new signature of the updated file. e.g:
- When you save a game there is some text that changes inside PARAM.SFO with your current "gameplay time", "character level", etc...
- When you unlock a new trophy the file TROPUSR.DAT is updated with this new data
- When you install new trophies (with a "trophy installer" in .TRP format) from a new game the TROPSYS.DAT is updated to index the new trophy installation
... In all this cases, there is a PARAM.PFD in the same folder that has been updated to store the new "signatures" of the other updated files
More info on other related file formats: PARAM.SFO Game Saves Trophy files.
Structure
Header (120 bytes) X table (456 bytes) Protected files table(31008 bytes) Y table (1140 bytes) Padding (44 bytes) Total file size = 120+456+31008+1140+44 = 32768 bytes (0x8000)
The size is fixed because the number of entries in both X table & Y table is 57 (when the entry is not used his position is reserved and marked as "not-used"). In the same way... the Protected files table has the space reserved for a maximun of 114 entries (usually most of them are not used and are filled with zeroes). As result the file contains the maximun number of possible entries
- Note
Entries in the Protected files table (114) is exactly the double than the entries in X table (57) & Y table (57)
Header
From 0x0 to 0x78 Size = 120 bytes
The end of the header is not clear at first sight, but it can be deduced by counting the number of entries in X table & Y table and comparing the positions used in both
e.g. look for one used entry in the "Y table" and count his position in this table... then look for other used entry in the "X" (both tables matches in the used entries). Then count towards behind to find the first entry (the start of the first entry is the start of the X table)
So the start of the X table is the end offset of the header
| Offset | Size | Value | Description |
|---|---|---|---|
| 0x00 | 0x08 bytes | PFDB | Magic value in ASCII |
| 0x08 | 0x08 bytes | 0000000000000003 | constant |
| 0x10 | 0x10 bytes | random bytes | key to en/decrypt |
| 0x20 | 0x14 bytes | hmac sha1 | encrypted, decrypted by vtrm |
| 0x34 | 0x14 bytes | hmac sha1 | encrypted, decrypted by vtrm |
| 0x48 | 0x14 bytes | hmac sha1 | encrypted, decrypted by vtrm |
| 0x5C | 0x04 bytes | padding, encrypted by vtrm |
| Offset | Size | Value | Description |
|---|---|---|---|
| 0x60 | 0x08 bytes | 0000000000000039 | Number of reserved entries in the X table & Y table (57 in decimal) |
| 0x68 | 0x08 bytes | 0000000000000072 | Number of reserved entries in the Protected files table (114 in decimal) |
| 0x70 | 0x08 bytes | 00000000000000** | Number of used entries in the Protected files table (it can vary from 1 to 114 in decimal) |
X table
From 0x78 to 0x240 Size = 456 bytes Entry lenght = 8 bytes Number of entries = 57
Each entry can contain a "file index" that points to the Protected files table from 0x00 to 0x71 (from 1 to 114 in decimal)
If the "file index" is 72 it means that is pointing out of the Protected files table (not used)
The table does not fills with entries from top to bottom, usually the first entries are not used (marked as 72) followed by entries with whatever number from 0 to 71, and mixed with more 72's entries
Used entries has a number asigned by his position in the table e.g:
Example of a "non-standard" X table with a "entry lenght" of 1 byte, and 8 entries 72 01 72 72 00 72 72 02 This X table can be translated as: -File index nº 1 (00) assigned as position 5 -File index nº 2 (01) assigned as position 2 -File index nº 3 (02) assigned as position 8
| Some possible entries | Description |
|---|---|
| 0000000000000000 | File index nº 1 |
| 0000000000000001 | File index nº 2 |
| 0000000000000002 | File index nº 3 |
| 0000000000000071 | File index nº 114 |
| 0000000000000072 | Out of Protected files table (not used) |
- Example
00000070 00 00 00 00 00 00 00 72 .......r| 00000080 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000090 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 000000a0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 000000b0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 00 |.......r........| 000000c0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 000000d0 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 72 |...............r| 000000e0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 000000f0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000100 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000110 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000120 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000130 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000140 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000150 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000160 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000170 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000180 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000190 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 000001a0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 000001b0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 000001c0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 000001d0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 000001e0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 000001f0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000200 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000210 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000220 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00000230 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r|
Protected files table
From 0x240 to 0x7B60 Size = 31008 bytes Entry lenght = 272 bytes Number of entries = variable from 1 to 114
Each entry can store the signature of one of the files in the folder, there is always an entry used to store the signature of PARAM.SFO, this gives a maximun number of protected files generated by the game of 113
Used entries fills the table from top to bottom, not-used entries are placed at the end of the table filled with zeroes
The first 8 bytes of each entry (file index) works in the same way than the entries in the X table, usually not used (72) and when used are randmonly placed asigning an "file index" to the entry
This "file index" does not matches with the position of the entry in the Protected files table itself... so seems that this "indexes files" are ???virtually reordered???
In fact, for a theoricall file with alll entries used, half of the "file index" numbers will be spreaded between the X table (can only contain 57) ant the first 8 bytes of some entries in the Protected files table
Example of a "non-standard" Protected files table with 4 entries and 8 bytes length each 0000000000000072 0000000000000001 0000000000000000 0000000000000002 The "file index" of each entry of this Protected files table can be translated as: -File index nº 1 (00) assigned as position 3 -File index nº 2 (01) assigned as position 2 -File index nº 3 (02) assigned as position 4
| Size | Value | Description |
|---|---|---|
| 008 bytes | 00000000000000** | File index (value 72 = Not indexed) |
| 064 bytes | EXAMPLE.WTF | Name of the file included the point and the extension in ASCII (Null-terminated) |
| 008 bytes | :Wtf-o0- | In ASCII, Usually zeroed (crysis2 savedata contains the string "CELL" and heavenly sword contains "s:Music") ???Unknown??? |
| 188 bytes | ????????... | Certificate for the file. When the file is PARAM.SFO then the certificate is bigger in size and uses imput data from the attribute "PARAMS" and/or "ACCOUNT_ID" inside PARAM.SFO. Method unknown (Null-terminated) |
| 004 bytes | 1A2B3C4D | Size of the file in bytes |
Y table
From 0x7B60 to 0x7FD4 Size = 1140 bytes Entry lenght = 20 bytes (some kind of sha-1 hash??) Number of entries = 57
All the entries contains the same "20 bytes string", only the used ones has a different "20 bytes string" in the other X table (in a theoricall PARAM.PFD with no files listed, the "Y table" would have all his 57 entries with the same string)
Is directly related with the X table, both matches in the total number of entries (57) and wich ones are used (e.g. when the X table has a entry in position 12... the Y table has position 12 used)
The Y table has a repeating pattern so an entry for each potential file with the blank entry (I.E. no file) being represented by the repeating byte pattern.
Padding
Size = 44 bytes
Cryptography
Unknown by now, but some questions rises...
Why the files are listed in this order and not in other in the "files table" ?
Because are not listed alphabetically, neither by size
Indexes files (in the X table) seems to have different number for every one, never repeats, but there is not direct relationship between the number of entries in X table & Y table (both are fixed to 57) and the numer of files listed in the Protected files table (114)... the most logicall explain if that this 114 files can be linked to both tables (57 each)... but in fact the only table that stores crypto is the Y table (limited to 57)... so what trick they used ? hmmmm
What are this index in the X table and in the Protected files table itself?, his positions seems to be random, seems like an old school "lucas arts games" anticheat card where you pick 2 values and by mixing them you get the unlock code :D
But here what is random is the positions, and index numbers of the entries in the X table, and the indexed files in the Protected files table ??? 2 index ???