Looking for a Colab on cracking the checksum used on .psv saves

[zophar]

As it says I am working with another guy to crack the checksum used in the .psv saves of ps1 games on the ps3.

The checksum has been located, but we are still in search of the key.
Anyone who wants to jump in on this and get your name in the books would be cool.
Shoot me a PM and I will give further info on what progress we have made.

Heads up info:
160 bit encryption is probable.
Each .pdv file contains a checksum in the top of each code.
Checksum is a 40byte tag from 0x08 on.

This holds a chance to unlock ps1 and ps2 save game editors. Not for online cheating purposes, but for single player enhancements. These game are old anyway, we just want to have fun with them while we can.
Any and all hash cyphers apply through PM.

I will keep this post as up to date as I can while working on this and 2 jobs.

[Mods please read]- If this should be in another section please move accordingly, Thanks -

‘-«¤[{(Zophar)}]¤•-’

[vampirexx]

I'm looking forward for this and in particular for ps3 save hex editing!

I post a message form an user that could help on hacking ps3 encryption:

How the saving really works behind the scenes.
Will post the tech version and also explain it for people who don't know how programming works or can read/understand it.

*excerpt 1*
const char secureFileId[CELL_SAVEDATA_SECUREFILEID_SIZE] = {
0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0
};

*excerpt 2*
case LOAD_OPERATION_STEP_MUSTEXISTFILE:
{
/*J */
unsigned int buf_size = dataParam->fileList[FILE_INDEX_MUSTEXIST].fileSize;
_file_buffer = malloc( buf_size );
if( _file_buffer == NULL ) {
ERR_PRINTF("alloc failed\n");
result->result = CELL_SAVEDATA_CBRESULT_ERR_FAILURE;
return;
}
/*J SYS-DATA */
set->fileOperation = CELL_SAVEDATA_FILEOP_READ;
set->fileBuf = _file_buffer;
set->fileBufSize = buf_size;
set->fileName = dataParam->fileList[FILE_INDEX_MUSTEXIST].fileName;
set->fileSize = dataParam->fileList[FILE_INDEX_MUSTEXIST].fileSize;
set->fileType = CELL_SAVEDATA_FILETYPE_SECUREFILE;
memcpy( set->secureFileId, secureFileId, CELL_SAVEDATA_SECUREFILEID_SIZE );
}
break;

Note this is just a small excerpt on how you would do it but gives a general idea.

Right all saves are encrypted using a unique key cooked up by the game developer so it can be different for every game,region,developer and a combination of all 3.
So the previous suggestion of finding the key in the eboot is a good idea but you never ever know what your looking for unless you can pinpoint it on every eboot file and that always depends on where the programmer put his/her code before compiling it. The only consistancy there is boils down to the length of the key. It might be so that its saved in the same location for every eboot but i honestly don't know that for sure

A possible solution is changing/rewriting the libsysutil_savedata.sprx in the fw to skip encryption/decryption request but that would also invalidate all your working saves that are encrypted.

Not saying its impossible to decrypt or turn off decryption on savegames.
Only pointing out how its done and trying to remove some confusion on how it works.
And who knows maybe someone might have some use of this.

[zophar]

I havent been in programming since the early 90s when i was a teenager.. but I still grasp most of what is there.
Makes me wonder if most of these checksums are filesize based.??.

I agree tracking down each key will be a large task, but if we can crack one and figure out a way around it, it may simplify future games.

Our target right now if FFVII. the game itself uses a 2 bit checksum which is easy enough to figure out, but the .psv encryption from the ps3 is the hard part.
I imagine if we can crack the .psv for ps1 gamesaves it should apply or come close to the ps2 exports also.
ps3 saves will come in the future if we can get the ball rolling.

I know seperately there have been a bunch of us hit a brick wall on this, but maybe if we can colaborate together on this it might help with the possibilities.

[zophar]

just pulled two clusters of hash data from a stock save and extracted save.
Covered MD5, CRC32, and SHA1 and nothing matches what they coded in there..