PARAM.PFD
Description
PFD (Protected Files Database) 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
PFD Header (120 bytes) X table (480 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 of the file is fixed because the number of entries in both X table & Y table is 57 (when the entry is not used his position is marked as "not-used"). In the same way... the Protected files table has an area reserved for a maximun of 114 entries (not used entries are filled with zeroes). As result the file contains the maximun number of possible entries
- Useful game saves used in this page as examples
- http://www.gamefaqs.com/ps3/941950-mirrors-edge/saves (the first one region North America). Mirror: http://www.multiupload.nl/SWJ4Y4H7ER
- http://www.gamefaqs.com/ps3/933123-heavy-rain/saves
The structure of the PARAM.PFD used in Mirror's edge game save can be considered "rare", this wiki page uses this file for explaining the structure because is perfect to understand how it works, the structure contains all the "problems" not present in "standard" files that can be considered unknown... there are other game saves that can be used (MotoGP10, Heavy rain)... but the list of protected files in heavy rain contains more than 100 files (use heavy rain if you are coding an app as a "stress test")
PFD Header
From 0x00 to 0x60 Size = 96 bytes
- Mirror's edge game save PFD Header
0x0000 00 00 00 00 50 46 44 42 00 00 00 00 00 00 00 03 |....PFDB........| 0x0010 69 15 2C 97 81 2B 25 C5 2A D4 FA 18 E4 B8 16 A8 |i.,..+%.*.......| 0x0020 7C 1F 5C 28 A7 EE 4D 39 22 AD C8 28 E6 CD 78 88 ||.\(..M9"..(..x.| 0x0030 98 0F 33 B6 23 94 EE E9 97 06 77 4E 71 91 24 13 |..3.#.....wNq.$.| 0x0040 A7 CF DB E5 E3 8E 8D 0C 5B CF 88 07 FC B7 B5 9C |........[.......| 0x0050 4C 5A 3D 98 39 04 B6 CE ED E2 71 52 AA 9C 2F 85 |LZ=.9.....qR../.|
Offset | Size | Value | Description | Notes |
---|---|---|---|---|
0x00 | 0x08 (8 bytes) | 0000000050464442 | magic | PFDB (in ASCII) |
0x08 | 0x08 (8 bytes) | 0000000000000003 | constant | Version ??? |
0x10 | 0x10 (16 bytes) | 69152C97812B25C52AD4FA18E4B816A8 | random key | Used to en/decrypt (generated only 1 time. When the file is updated this key doesnt change) |
0x20 | 0x14 (20 bytes) | 7C1F5C28A7EE4D3922ADC828E6CD7888980F33B6 | sha1 hmac 1 | Encrypted, decrypted by vtrm (X-Table hash?. always changes when the file is updated) |
0x34 | 0x14 (20 bytes) | 2394EEE99706774E71912413A7CFDBE5E38E8D0C | sha1 hmac 2 | Encrypted, decrypted by vtrm (Protected files table hash?. always changes when the file is updated) |
0x48 | 0x14 (20 bytes) | 5BCF880FCB7B59C4C5A3D983904B6CEEDE27152 | sha1 hmac 3 | Encrypted, decrypted by vtrm (Y-Table hash?. always changes when the file is updated) |
0x5C | 0x04 (4 bytes) | AA9C2F85 | padding | Encrypted by vtrm (always changes when the file is updated) |
X-Table
From 0x60 to 0x240 Size = 480 bytes
X-Table Header
From 0x60 to 0x78 Size = 24 bytes
This header defines the structure of the table
- Mirror's edge game save X Table Header
0x0060 00 00 00 00 00 00 00 39 00 00 00 00 00 00 00 72 |.......9.......r| 0x0070 00 00 00 00 00 00 00 21 |.......!
Offset | Size | Value | Description | Notes |
---|---|---|---|---|
0x60 | 0x08 bytes | 0000000000000039 | X and Y tables reserved entries | 57 (in decimal). Seems correct in all the examples found, but is speculation ??? |
0x68 | 0x08 bytes | 0000000000000072 | Protected files table reserved entries | 114 (in decimal). Seems correct in all the examples found, but is speculation ??? |
0x70 | 0x08 bytes | 0000000000000021 | Protected files table used entries | 33 (in decimal). Can vary, from 1 to 114 in decimal (or from 0x00 to 0x71) |
X-Table Data
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:
- Mirror's edge game save X table
0070 00 00 00 00 00 00 00 72 .......r| 0080 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 72 |...............r| 0090 00 00 00 00 00 00 00 0C 00 00 00 00 00 00 00 72 |...............r| 00a0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 1F |.......r........| 00b0 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 1B |................| 00c0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 14 |.......r........| 00d0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 00e0 00 00 00 00 00 00 00 0B 00 00 00 00 00 00 00 0D |................| 00f0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 0100 00 00 00 00 00 00 00 15 00 00 00 00 00 00 00 19 |................| 0110 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 13 |.......r........| 0120 00 00 00 00 00 00 00 17 00 00 00 00 00 00 00 72 |...............r| 0130 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 0E |.......r........| 0140 00 00 00 00 00 00 00 11 00 00 00 00 00 00 00 72 |...............r| 0150 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 18 |.......r........| 0160 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 0170 00 00 00 00 00 00 00 1A 00 00 00 00 00 00 00 12 |................| 0180 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 0190 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00 72 |...............r| 01a0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 1C |.......r.......r| 01b0 00 00 00 00 00 00 00 07 00 00 00 00 00 00 00 72 |...............r| 01c0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 01d0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 01e0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 03 |.......r........| 01f0 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 72 |.......r.......r| 0200 00 00 00 00 00 00 00 1D 00 00 00 00 00 00 00 72 |...............r| 0210 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 20 |.......r........| 0220 00 00 00 00 00 00 00 0F 00 00 00 00 00 00 00 72 |...............r| 0230 00 00 00 00 00 00 00 72 00 00 00 00 00 00 00 1E |.......r........|
In this table there are 25 entries used
Position in table | Virtual Index ID ? |
---|---|
1 | No |
2 | 0x01 |
3 | No |
4 | 0x0C |
5 | No |
6 | No |
7 | 0x1F |
8 | 0x10 |
9 | 0x1B |
10 | No |
11 | 0x14 |
12 | No |
13 | No |
14 | 0x0B |
15 | 0x0D |
16 | No |
17 | No |
18 | 0x15 |
19 | 0x19 |
20 | No |
21 | 0x13 |
22 | 0x17 |
23 | No |
24 | No |
25 | 0x0E |
26 | 0x11 |
27 | No |
28 | No |
29 | 0x18 |
30 | No |
31 | No |
32 | 0x1A |
33 | 0x12 |
34 | No |
35 | No |
36 | 0x04 |
37 | No |
38 | No |
39 | 0x1C |
40 | 0x07 |
41 | No |
42 | No |
43 | No |
44 | No |
45 | No |
46 | No |
47 | 0x03 |
48 | No |
49 | No |
50 | 0x1D |
51 | No |
52 | No |
53 | 0x20 |
54 | 0x0F |
55 | No |
56 | No |
57 | 0x1E |
Other possible values | 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) |
Protected files table
From 0x240 to 0x7B60 Size = 31008 bytes Entry lenght = 272 bytes Number of reserved entries = 114 Number of used entries = variable from 1 to 114
- The table contains 114 reserved entries, each used entry has this structure
Size | Value | Name | Description |
---|---|---|---|
0x08 (8 bytes) | 00000000000000** | Virtual Index ID ? | Valid values from 0x00 to 0x71 (and 0x72 = Not used) |
0x40 (64 bytes) | EXAMPLE.WTF | File Name | Name of the file included the point and the extension in ASCII (Null-terminated) |
0x08 (8 bytes) | :Wtf-o0- | Unknown? | Usually zeroed (crysis2 savedata uses CELL and heavenly sword s:Music) |
0x20 (32 bytes) | ????????... | Certificate 1 ? | Method unknown (Null-terminated). Never change when the file is updated |
0x9C (156 bytes) | ????????... | Certificate 2 ? | Method unknown (Null-terminated) <---- this probably needs to be divided |
0x04 (4 bytes) | 1A2B3C4D | File Size | in bytes (probably longer, there are lot of zeroes before him) |
- Note
Certificate: When the file is PARAM.SFO the certificate is longer and maybe uses imput data from "PARAMS" and/or "ACCOUNT_ID" inside PARAM.SFO. Method unknown (Null-terminated)
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 (Virtual Index ID) works in the same way than the entries in the X table, when not used are marked as "72" and when used are randomnly placed asigning a "file index" to the entry. This "file index" does not matches with the position of the entry in the Protected files table itself... (e.g: indexed 0x06 is in position 14)
For a theoricall file with alll entries used (114 protected files), 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 (the other 57)
- Mirror's edge game save Protected Files Table
The table contains 33 used entries, 8 of them are "indexed"
Position in table | Virtual Index ID ? | File Name | Unknown ? | Certificate ? | File Size |
---|---|---|---|---|---|
1 | No | PARAM.SFO | 00568CD8 | longer than others | 00000AB0 |
2 | No | SAVTOC0.BIN | 00568CD8 | 0000058C | |
3 | No | SAV33.BIN | 00568CD8 | 00000584 | |
4 | No | SAV14.BIN | 00568CD8 | 00009543 | |
5 | No | SAV3.BIN | 00568CD8 | 0000848F | |
6 | No | SAV22.BIN | 00568CD8 | 00008221 | |
7 | No | SAV21.BIN | 00568CD8 | 00009D66 | |
8 | No | SAV13.BIN | 00568CD8 | 00009EF5 | |
9 | No | SAV5.BIN | 00568CD8 | 0000CD1B | |
10 | No | SAV6.BIN | 00568CD8 | 0000B3AF | |
11 | No | SAV7.BIN | 00568CD8 | 00008266 | |
12 | No | SAV8.BIN | 00568CD8 | 00007618 | |
13 | No | SAV16.BIN | 00568CD8 | 0000B95A | |
14 | 0x06 | SAV0.BIN | 00568CD8 | 00009F4D | |
15 | No | SAV19.BIN | 00568CD8 | 0000A11B | |
16 | No | SAV15.BIN | 00568CD8 | 0000CC00 | |
17 | No | SAV20.BIN | 00568CD8 | 000109F0 | |
18 | No | SAV11.BIN | 00568CD8 | 00009C0A | |
19 | No | SAV12.BIN | 00568CD8 | 0000948D | |
20 | No | SAV9.BIN | 00568CD8 | 0000C712 | |
21 | No | SAV17.BIN | 00568CD8 | 0000E4FD | |
22 | 0x02 | SAV18.BIN | 00568CD8 | 0000AE4D | |
23 | No | SAV2.BIN | 00568CD8 | 0000CD55 | |
24 | 0x05 | SAV1.BIN | 00568CD8 | 000098B3 | |
25 | 0x16 | SAV23.BIN | 00568CD8 | 00004FBE | |
26 | No | SAV10.BIN | 00568CD8 | 0000ADBD | |
27 | No | SAV35.BIN | 00568CD8 | 00008E2E | |
28 | 0x00 | SAVTOC1.BIN | 00568CD8 | 00000108 | |
29 | No | SAV36.BIN | 00568CD8 | 00009CBE | |
30 | 0x08 | SAV26.BIN | 00568CD8 | 0000B4D7 | |
31 | 0x09 | SAV27.BIN | 00568CD8 | 00009FD1 | |
32 | 0x0A | SAV28.BIN | 00568CD8 | 00007D73 | |
33 | No | SAV38.BIN | 00568CD8 | 0000D401 | |
Up to 114 | No | No | No | No | No |
Y-table
From 0x7B60 to 0x7FD4 Size = 1140 bytes Entry lenght = 20 bytes (some kind of sha-1 hash??) Number of entries = 57
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)
All the entries contains the same "20 bytes string" that is used as a "default" value for this table, only the used entries contains a different "20 bytes string" (in a theoricall PARAM.PFD with no files listed, the "Y table" would have all his 57 entries with the same string). This "default" string never changes when the file is updated
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.
- Mirror's edge game save Y table
When a entry in this table is not used is "marked" with a "standard" value... for mirror's edge game save is: 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0
Position in table | Hash ??? |
---|---|
1 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
2 | 83C16E92 F5F5FAAF 19A00810 186E82A9 313AADAD |
3 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
4 | 28458FC1 3B00ED44 EF5FA5BE D55D016E 94066099 |
5 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
6 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
7 | 42CBF813 4469B91F 541DCF76 CC4934E9 F6CDEDC6 |
8 | 6B88527E002E78DB1D915573DD44951F0CBE6A3C |
9 | 703F1A6F0A576A8D85E8EB35B30FE5DAB7689988 |
10 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
11 | EFAF21CD389AC84662601AC5B449AE12CCF739F9 |
12 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
13 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
14 | C45F773837AE76FAF3D662974438CE7FD620D2D0 |
15 | 6BE399A6B97F6158C6194ED6C8CC6A1B2AD6ADDB |
16 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
17 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
18 | 933E85E3651EC32C05929CAD2CD23081BC975E9C |
19 | 323A62857BAD6BD1D3B1ED8584723CC36C4D915D |
20 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
21 | 1B9491E3F006528C387F4A8FAD75455E9780EF0D |
22 | A69EC11F680BCDC8260CDF38FA47C3FCD1D16495 |
23 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
24 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
25 | 41534126B047CE6AADC6606C24766246C4F712D7 |
26 | 08F26808FB5A47B4E35E71DDAA3167CD5CD08D75 |
27 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
28 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
29 | 71A20B8F36D2853E4E84AB998AD201A0AC8C629C |
30 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
31 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
32 | 18BA71B3CEC1CCCDAD3395323C4259D72B1EF5E0 |
33 | B08D1FAB5A5FA370B5FF2930024CE7CAC9F08234 |
34 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
35 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
36 | E81D24D0EF67CDC849260668B2A99F982C545929 |
37 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
38 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
39 | 6347B31E98FA9A58195AB5D9ED1548A46CFE6FCE |
40 | 4CB48133E388EDBCF0E0AD0DB6CD55020CB03342 |
41 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
42 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
43 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
44 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
45 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
46 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
47 | D5097670CAF4186E89009EF031FD721FE3C3E083 |
48 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
49 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
50 | 49481F76A9C591E03CA1B115D0FC9737A48837A3 |
51 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
52 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
53 | 389ED925282AFEC432D2A1F042E0043D0E91F785 |
54 | E40D4A3ABB1EEB92A1BEF55B7730AB6BB5CDDB2D |
55 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
56 | 5A7EAF6D 029992D0 7580EBCA 42698114 9F2C5DF0 |
57 | C1CE8AF3 7CA63059 B835B2D6 CD64E506 B2E55397 |
A screencapture of this table with the width fixed (each entry is one row)... there is a total of 57 entries, 25 of them used. http://img6.imagebanana.com/img/q82sh1dj/Ytablemirrorsedge.jpg
Padding
Size = 44 bytes
Not much to say about this padding, is an area filled with zeroes to increase the size of the file to 32768 bytes (0x8000)
Cryptography and Speculation
The "virtual index"
Mirror's edge has a total of 33 "protected files" (listed in the protected files table)... this number matches with the 33 "indexed" numbers that are spreading between "X table" and "protected files table" itself... if we place all the entries from all tables together we can reorder all by using his ID number in a "virtual index"
Virtual Index ID | X Table position | Y table hash ? (same position than X table) | Protected Files Table (position) | Protected Files Table (File Name) |
---|---|---|---|---|
0x00 | No | No | 28 | SAVTOC1.BIN |
0x01 | 2 | 83C16E92F5F5FAAF19A00810186E82A9313AADAD | No | No |
0x02 | No | No | 22 | SAV18.BIN |
0x03 | 47 | D5097670CAF4186E89009EF031FD721FE3C3E083 | No | No |
0x04 | 36 | E81D24D0EF67CDC849260668B2A99F982C545929 | No | No |
0x05 | No | No | 24 | SAV1.BIN |
0x06 | No | No | 14 | SAV0.BIN |
0x07 | 40 | 4CB48133E388EDBCF0E0AD0DB6CD55020CB03342 | No | No |
0x08 | No | No | 30 | SAV26.BIN |
0x09 | No | No | 31 | SAV27.BIN |
0x0A | No | No | 32 | SAV28.BIN |
0x0B | 14 | C45F773837AE76FAF3D662974438CE7FD620D2D0 | No | No |
0x0C | 4 | 28458FC13B00ED44EF5FA5BED55D016E94066099 | No | No |
0x0D | 15 | 6BE399A6B97F6158C6194ED6C8CC6A1B2AD6ADDB | No | No |
0x0E | 25 | 41534126B047CE6AADC6606C24766246C4F712D7 | No | No |
0x0F | 54 | E40D4A3ABB1EEB92A1BEF55B7730AB6BB5CDDB2D | No | No |
0x10 | 8 | 6B88527E002E78DB1D915573DD44951F0CBE6A3C | No | No |
0x11 | 26 | 08F26808FB5A47B4E35E71DDAA3167CD5CD08D75 | No | No |
0x12 | 33 | B08D1FAB5A5FA370B5FF2930024CE7CAC9F08234 | No | No |
0x13 | 21 | 1B9491E3F006528C387F4A8FAD75455E9780EF0D | No | No |
0x14 | 11 | EFAF21CD389AC84662601AC5B449AE12CCF739F9 | No | No |
0x15 | 18 | 933E85E3651EC32C05929CAD2CD23081BC975E9C | No | No |
0x16 | No | No | 25 | SAV23.BIN |
0x17 | 22 | A69EC11F680BCDC8260CDF38FA47C3FCD1D16495 | No | No |
0x18 | 29 | 71A20B8F36D2853E4E84AB998AD201A0AC8C629C | No | No |
0x19 | 19 | 323A62857BAD6BD1D3B1ED8584723CC36C4D915D | No | No |
0x1A | 32 | 18BA71B3CEC1CCCDAD3395323C4259D72B1EF5E0 | No | No |
0x1B | 9 | 703F1A6F0A576A8D85E8EB35B30FE5DAB7689988 | No | No |
0x1C | 39 | 6347B31E98FA9A58195AB5D9ED1548A46CFE6FCE | No | No |
0x1D | 50 | 49481F76A9C591E03CA1B115D0FC9737A48837A3 | No | No |
0x1E | 57 | C1CE8AF37CA63059B835B2D6CD64E506B2E55397 | No | No |
0x1F | 7 | 42CBF8134469B91F541DCF76CC4934E9F6CDEDC6 | No | No |
0x20 | 53 | 389ED925282AFEC432D2A1F042E0043D0E91F785 | No | No |
More brainstorming
Entries in the Protected files table (114) is exactly the double than the entries in X table (57) & Y table (57)
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 ???
Discussion thread ---> http://www.ps3hax.net/showthread.php?p=392684#post392684