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 folders of the PS3, usually to controll 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 trohpye folders /dev_hdd0/home/0000000*/trophy/_TROPSYS_/PARAM.PFD <---- in the trophy "index" folder /Maybe other places ?
Usually PARAM.SFO is one of the files listed (and supervised) by PARAM.PFD but this can vary.
e.g. the folder _TROPSYS_ only contains 2 files: TROPSYS.DAT & PARAM.PFD (the first is the trophy index for this user, and the second supervises it).
Every time one of the files listed inside the .PFD is updated... the .PFD itself needs to be updated to store the new "signatures" of the other updated files 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 trophye the file TROPUSR.DAT is updated with this new data When you install new trophyes (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 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
Total file size = 8000 bytes
The size seems to be fixed because the number of entries in "index table" & "weird table" is always 57 (when the entry is not used his position is reserved and marked as "not-used"). In the same way... the "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 that entries in the "file table" (114) is exactly the double than the entries in "index table" (57) & "weird table" (57). For a theoricall maximun of 114 files listed in the "files table"... both "index table" & "weird table" must have all his entries used
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 "index table" & "weird table" and comparing the positions used in both
e.g. look for one used entry in the "weird table" and count his position in this table... then look for other used entry in the "index table" (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 "index table")
Then... the start of the "index table" is the "end offset" of the header
| Offset | Size | Value | Description |
|---|---|---|---|
| 0x00 | 04 bytes | 00000000 | ???why this padding??? |
| 0x04 | 04 bytes | PFDB | Magic value in ASCII |
| 0x08 | 08 bytes | 0000000000000003 | ???file type??? |
| 0x10 | 80 bytes | ???Public key??? | ???Unknown??? |
| 0x60 | 08 bytes | 0000000000000039 | Number of reserved entries in the "index table" & "weird table" (57 in decimal) |
| 0x68 | 08 bytes | 0000000000000072 | Number of reserved entries in the "file table" (114 in decimal) |
| 0x70 | 08 bytes | 00000000000000** | Number of used entries in the "file table" (it can vary from 1 to 114 in decimal) |
Index table
From 0x78 to 0x240 Size = 456 bytes Entry lenght = 8 bytes Number of entries = 57
This table has a total of 57 entries, with 8 bytes each, for a total of 456 bytes (57*8=456)
The used entries seems to be ???randomly placed??? in the table (its not filled from top to bottom) and are "indexed" with a counter that points to the "file table" (from 1 to 114 in decimal... or from 0 to 71 in hexadecimal)
When this counter is 72 it means that this entry is not used
| Some possible entries | Description |
|---|---|
| 0000000000000000 | Entry nº 1 |
| 0000000000000001 | Entry nº 2 |
| 0000000000000002 | Entry nº 3 |
| 000000000000000A | Entry nº 11 |
| 0000000000000071 | Entry nº 114 |
| 0000000000000072 | No entry (not used) |
Files table
From 0x240 to 0x7B60 Size = 31008 bytes Entry lenght = 272 bytes Number of entries = variable from 1 to 114
This table has a total of 114 entries, with 272 bytes each, for a total of 31008 bytes (114*272=31008)
The 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 (the entry mark) can store another "counter" that never repeats for 2 entryes and can have a maximun around 88 (probably higher). But seems not to be pointing to one of the other tables (that are limited to 57) and neither is pointing to its postioin itself in the "file table", and for more randomness, only around hals of the entries are indexed (the others has a 72 of not-used)
| Size | Value | Description |
|---|---|---|
| 008 bytes | 00000000000000** | Index mark, it can vary (value 72 = Not indexed) |
| 064 bytes | EXAMPLE.WTF | Name of the file included the point and the extension in ASCII (Null-terminated) |
| 008 bytes | 00000000******** | ???Unknown??? First four bytes zero + 4 bytes vary (usually zeroed) |
| 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 | **** | Size of the file in bytes |
Weird table
From 0x7B60 to 0x7FD4 Size = 1140 bytes Entry lenght = 20 bytes (some kind of sha-1 hash??) Number of entries = 57
This table has a total of 57 entries, with 20 bytes each, for a total of 1140 bytes (57*20=1140)
All the entries contains the same "20 bytes string", only the used ones has a different "20 bytes string" in the other "index table" (in a theoricall PARAM.PFD with no files listed in "file table" the weird table must have all his 57 entries with the same string)
Is directly related with the "index table", both matches in the total number of entries and wich ones are used (e.g. when the "index table" has a entry in position 12... the "weird table" has position 12 used)
The weird 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 "index table") seems to have different number for every one, never repeats, but there is not direct relationship between the number of entries in "index table" & "weird table" (both are fixed to 57) and the numer of files listed in the "file 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 "weird table" (limited to 57)... so what trick they used ? hmmmm
What are this index in the "index table" and in the "file 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 "index table", and the indexed files in the "file table" ??? 2 index ???