Examining Backups created by Backup-Utility
As far as i have seen here, the Backups created by the PS3 weren't examined in this forum, so i today spent some time doing so. All backups were taken on FW 2.36 on a EU PS3 60gig which was resetted to factory defaults, User 1 created and no network-settings. Backups were stored on MS Pro Duo.
First unusual thing is that the first backup differs in size. The biggest file of them is archive2_00.dat with 6.6MB,and this file is about 50kb bigger than all the other Backups. I've done one backup after another (39 in total), and the first backup is the only one that has another size.
Next i viewed them in a hex-editor. All files seem to have short signature of 64 bytes. The 'archive*.dat'-files all start with "40 00 00 00 00 00 00 05" while all files named 'archive2*.dat' starts with "30 00 00 00 00 00 00 05".
Next part is some random data which is 20 bytes long. The rest of the file after the 64th byte seems to be encrypted.
while looking at the header of the files i came to some speculation:
the first 8 bytes may tell the ps3 if the file is a valid archive... or archive2.... depending on the numers 30 and 40.
leaving 56 more bytes free for something like a key. as i've googled so far, the blowfish-cipher uses keys up to 448 bits, which are, tadaa, 56 bytes. because there are only 20 bytes used (rest of them are 0), the key is 160 bits long. the rest can be used by sony if they decided that 160 bits would not be secure enough and lengthen the key to blowfish's max of 448 bits.
the question now is if it is really blowfish, and are that 20 bytes really the key to decrypt the rest?
did anyone tried to restore the backup from one ps3 on another? then it would make sense to use blowfish as it is a symmetrical cipher.
so, if anybody here is able to run a blowfish-decrypter on the crypted part of the file AND the decrypted file is either human-readable OR starts with 'SCE' like almost every file in the firmware-packages, this would be a step forward.
how do you guys think about that?
EDIT: the files named archive*.dat has no 20 byte long keys, they are 40 bytes long, still usuable for blowfish
I looked into this once awile back, but myself was unable to get anything of real importance for any kind of break through. =( That doesn't mean it's not possible though.