PS3 Savegame Reverse Engineering
this weekend i will start reverse engineering the savegame of ps3. My Toolchain is up and everything is working.
My start idea is an Tool which creates encrypted and non encrypted save game with userdata (user may enter something). I may release the savegames. And try to make en non encrypted save game out of the encrypted and vice versa.
The keys are hardcoded in the games.
We need to be able to decompile the games to extract their keys, then we were maybe able to let the ps3 decrypt and re-encrypt savegames. Or it has to be possible to hook into a game. I don't know how the hooking should be possible. If anyone has an idea how you can hook into other games tell me (PN would be nice). I guess it is not possible at the moment. I hope the custom firmwares will come soon. Till then sorry i couldn't achieve more at the moment.
UPDATE 17.09.2010 17:41
Test program to save some data compiled and pkg created.
I am not at home. I will test it later and give some feedback.
UPDATE 18.09.2010 01:51
Got home and deployed on PS3, failed ;) doing some error in my code or something have to recode it. Shit happens.
You have to give the save file (each file in the save game can have it's own) a 16 byte size key.
a) Only Key is used for encryption
If the Key is the only thing you need to encrypt there can be two theories:
a.1) Game uses always same keys
a.2) Key is safed in the PFD file ( I LIKE THIS ONE MOST )
b) Key and game related like gameId is used for encryption.
Depending on what game related information is used we can handle it
Again some theory. Maybe i got one lucky shot someday :P
If you have the key it is maybe possible to let the ps3 encrypt and decrypt savegames. So we don't have to reverse encryption and so on. Just use the given functions.
I will be back at sunday with more i guess.
UPDATE 19.09.2010 01:46
Added PFD research
Research is chaotic and did it twice to make sure
The PFD File
- size is 0x8000 (32768) bytes
- 8 byte magic start [REST 32760]
- 8 byte version or sth like that [REST 32752]
- 80 unkown bytes [REST 32672]
- 480 bytes of repeating signature [REST 32192]
- structure for each file is 0x110 (272) bytes
- file can have 113 secured files 0x7810 (30736) bytes for file structures ;-) matches [REST 1456]
- last strucure is only zeros size 0x110 (272) bytes [REST 1184]
- 22 bytes unkown data [REST 1162]
- repeating 20 byte long data 56 times 0x460 (1120) bytes [REST 42]
- 42 times 0x00 [0x2A (42) bytes] [REST 0]
=> Magic Start (0x000000000050464442) [4 times 0x00 and PFDB]
=> DUMMY (0x00000000000000) [7 times 0x00]
=> Version ?!?! (0x03)
=> unkown (80 bytes)
=> 60 times 8 byte unkown data
(0x0000000000000000) [7 times 0x00 and 0x00] OR
(0x0000000000000001) [7 times 0x00 and 0x01] OR
(0x0000000000000002) [7 times 0x00 and 0x02] OR
(0x0000000000000039) [7 times 0x00 and 0x39 (ASCII 9)] OR
(0x0000000000000072) [7 times 0x00 and 0x72 (ASCII r)]
NOW comes an intressting structure
first struct is for the SFO and then 113 reserved for the max possible encrypted files in a save game
114 times struct sizeof is 272 bytes
=> 8 byte struct start?!?!?! (0x0000000000000072) [7 times 0x00 and 0x72 (ASCII r)]
=> x Byte filename buffer
=> 1 Byte 0x00 (to end the string)
=> 16 Byte repeating data for every File (due to the example mostly same key is used for every file. Maybe its our key)
=> x Byte unkown data
=> Huge number of 0x00 i guess it is a buffer because one save file can have only 113 encrypted files -.- what a sick number in my opinion.
=> 1142 bytes of unkown data
=> 42 times 0x00
I'M PRETTY SURE THAT:
THE PFD FILE DON'T HOLD THE KEY. BECAUSE YOU HAVE TO GIVE THE KEY TO YOUR LOAD FUNCTION AND IT WOULDN'T MAKE SENSE IF THE KEY IS ALREADY THERE. AND IN THE PFD FILE IS THE PARAM.SFO LISTED TOO, WITH THE SAME STRUCTURE.