PARAM.PFD: Difference between revisions
m (all offsets mapped) |
(→Header) |
||
Line 30: | Line 30: | ||
Size = 120 bytes | Size = 120 bytes | ||
The end of the header is not clear at first sight, but it can be deduced by counting the number of entryes in | The end of the header is not clear at first sight, but it can be deduced by counting the number of entryes 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 entryes). 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 | |||
{| border="1" cellspacing="0" cellpadding="5" border="#999" class="wikitable" style="border:1px solid #999; border-collapse: collapse;" | {| border="1" cellspacing="0" cellpadding="5" border="#999" class="wikitable" style="border:1px solid #999; border-collapse: collapse;" | ||
Line 36: | Line 40: | ||
! Offset !! Size !! Value !! Description | ! Offset !! Size !! Value !! Description | ||
|- | |- | ||
| 0x00 || 4 bytes || 00 00 00 00 || why this padding??? | | 0x00 || 4 bytes || 00 00 00 00 || ???why this padding??? | ||
|- | |- | ||
| 0x04 || 4 bytes || PFDB || Magic value (in ASCII) | | 0x04 || 4 bytes || PFDB || Magic value (in ASCII) | ||
|- | |- | ||
| 0x08 || 8 bytes || 00 00 00 00 00 00 00 03 || file type??? | | 0x08 || 8 bytes || 00 00 00 00 00 00 00 03 || ???file type??? | ||
|- | |- | ||
| 0x10 || 80 bytes || Public key || | | 0x10 || 80 bytes || ???Public key??? || ???Unknown??? | ||
|- | |- | ||
| 0x60 || 08 bytes || 00 00 00 00 00 00 00 39 || Number of entryes in the "index table" (57 in decimal) | | 0x60 || 08 bytes || 00 00 00 00 00 00 00 39 || Number of reserved entryes in the "index table" & "weird table" (57 in decimal) | ||
|- | |- | ||
| 0x68 || 08 bytes || 00 00 00 00 00 00 00 72 || | | 0x68 || 08 bytes || 00 00 00 00 00 00 00 72 || Number of reserved entryes in the "file table" (114 in decimal) | ||
|- | |- | ||
| 0x70 || 08 bytes || | | 0x70 || 08 bytes || 00 00 00 00 00 00 00 ** || Number of used entryes in the "file table" (it can vary from 1 to 114 in decimal) | ||
|- | |- | ||
|} | |} |
Revision as of 09:08, 25 December 2011
Description
This file is responsible to prevent modification of other files, 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:
/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
Usually PARAM.SFO is one of the entryes in the list of files controlled by PARAM.PFD but this can vary
e.g. the folder _TROPSYS_ only contains 2 files: TROPSYS.DAT & PARAM.PFD (TROPSYS.DAT is the trophy index, and PARAM.PFD secures 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 files that have changed (e.g. when you update a savegame there is some text that changes inside PARAM.SFO with your current game time, status, level, etc..., or when you install new trophyes from a new game the TROPSYS.DAT "index" needs to be updated to list the new trophy installation as valid in the XMB, or when you unlock a new trophye the file TROPUSR.DAT is updated with this data)
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 entryes in "index table" & "weird table" is always 57 (when the entry is not used his position is reserved and marked as blank)
In the "files table" the space is reserved too, as result the file contains the maximun number of possible entryes (usually most of them are not 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 entryes 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 entryes). 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 | 4 bytes | 00 00 00 00 | ???why this padding??? |
0x04 | 4 bytes | PFDB | Magic value (in ASCII) |
0x08 | 8 bytes | 00 00 00 00 00 00 00 03 | ???file type??? |
0x10 | 80 bytes | ???Public key??? | ???Unknown??? |
0x60 | 08 bytes | 00 00 00 00 00 00 00 39 | Number of reserved entryes in the "index table" & "weird table" (57 in decimal) |
0x68 | 08 bytes | 00 00 00 00 00 00 00 72 | Number of reserved entryes in the "file table" (114 in decimal) |
0x70 | 08 bytes | 00 00 00 00 00 00 00 ** | Number of used entryes 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 entryes = 57
The used entryes seems to be randomly placed in the table and are indexed with something like a counter.
This table is directly related with the "weird table" at the end of the file, both matches in the total number of positions, and the positions used (e.g. when the "index table" has a entry in position 12... the "weird table" has position 12 used)
Some common entryes | Description |
---|---|
00 00 00 00 00 00 00 72 | no entry (not used or blank) |
00 00 00 00 00 00 00 00 | entry nº 1 |
00 00 00 00 00 00 00 01 | entry nº 2 |
00 00 00 00 00 00 00 02 | entry nº 3 |
Files table
From 0x240 to 0x7B60 Size = 31008 bytes Entry lenght = 272 bytes Number of entryes = variable (from 1 to a maximun of 114)
This table has a fixed size that can be divided in 114 entryes of 272 bytes each exactly. The table is filled with data from top to bottom, the not-used entryes are at the end of the table filled with zeroes
Lenght | Description | Notes |
---|---|---|
8 bytes | Entry mark | 00 00 00 00 00 00 00 72 (this can vary but usually 72) |
64 bytes | Filename | Name of the file included the point and the extension (Null-terminated) |
8 bytes | Unknown | First five bytes zero + 2 bytes vary + 1 byte fixed ?? (this can vary, usually zeroed) |
188 bytes | Certificate | When PARAM.SFO is the file then certificate is bigger and uses data from the attribute PARAMS including ACCOUNT_ID (Null-terminated). Method unknown |
4 bytes | File size | 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 entryes = 57
This table matches in number of entryes with the "index table"
It contains 57 entryes with the same "20 bytes string" in all them, only the used positions in the matching "index table" has a different "20 bytes string"
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 entryes in "index table" & "weird table" (that are fixed to 57) and the numer of files listed in the "file table" (i found a file with 96 that seems to be near the limit)
What are this tables?, seems like an old school "lucas arts" anticheat card where you pick 2 values and by mixing them you get the unlock code :D
But here what is random is the position, and index number of the entry in the "index table"