Editing PARAM.PFD
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 712: | Line 712: | ||
===More brainstorming=== | ===More brainstorming=== | ||
*The | *The maximun number of entries in the '''Protected files table''' (114) is exactly the double than the maximun number of entries in '''X table''' (57) & '''Y table''' (57). Or from other point of view 114 = 57 + 57 | ||
**Seems obvious that there is an "index number" assigned to each "protected file", but | **Seems obvious that there is an "index number" assigned to each "protected file", but his positions are "scrambled" | ||
*The order of the files in the "protected files table" is based | *The order of the files in the "protected files table" is based in his timestamps (not alphabetically, not by size). Or in other words... is related with how the PARAM.PFD was generated for first time | ||
** | **Is the original order when the file was created for first time (based in his timestamps), when the files in the list are updated by the ps3 (his timestamp changes) they keeps his original position. When new files are added to the "protected files list table"... are added to the end of the list, based in his timestamps. | ||
**When several "protected files" | **When several "protected files" has the same timestamp (something very probable because can be generated by the game very fast)... the order is alphabeticall | ||
**So when ordering them, the timestamp is preferent... and when | **So when ordering them, the timestamp is preferent... and when timestamp matches is used his name (alphabetically) | ||
*Indexed files in the '''X table''' has a different number for each 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 | *Indexed files in the '''X table''' has a different number for each 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 "protected 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?, | *What are this index in the '''X table''' and in the '''Protected files table''' itself?, his positions seems to be random (but the number of indexed files matches with the number of "protected files"), 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 | ||
**Seems to be "jumps" from one table to the other. The files are | **Seems to be "jumps" from one table to the other. The files are readed in order by the ps3 by "jumping" using his "index nº" to locate the next one... "Index nº0" seems to be located always at position 8 in the "X-Table" (offset 0xB8). In most complex PARAM.SFO (e.g: heavy rain, mirror's edge or motogp10/11) the value at this position is replaced by another "index nº" (by now seems random) that is pointing to the "protected files table" index area of each entry (where index nº0 is located). How this "jumps" works is partially unknown and by now is only notable in the first jump | ||