Checksum 64-bit long

[lorak]

I have a decrypted and decompressed game save for MLB 14 The Show from PS3. My problem is that I have no idea of the checksum algorithm this game is using. I just know that the outcome seems to be 64-bit long, appearing at the end of the file. I have tried with different algorithms but cannot find the correct one. According to me, the checksum is at the end of the decrypted and compressed file.

I am able to edit different sections of this game save, but of course, it shows a corrupted file message when trying to load it in-game as the checksum do not match.

A couple of game saves are attached for you to have a look.

By the way, the PS Vita version of this game applies the CRC-32 checksum algorithm to the decrypted and compressed game save, storing it in a different file. This does not seem to be the case for PS3.

Thanks in advance!

game saves.zip

Edited June 8 by lorak

[applecuckoo]

Got it - it's an Adler-32 checksum. ImHex picked it up straight away and I was able to reproduce it with another tool.

Edit: whoops, forgot to ping @lorak.

Edited June 7 by applecuckoo

[lorak]

On 6/7/2024 at 3:36 AM, applecuckoo said:

Got it - it's an Adler-32 checksum. ImHex picked it up straight away and I was able to reproduce it with another tool.

Edit: whoops, forgot to ping @lorak.

Many, many thanks!😁
It finally seems that I would be able to port my updated rosters to MLB14TS PS3.

On which file and data block you apply the Adler-32 checksum algorithm?
Where is the Adler-32 checksum stored? I mean, which file and offset.

By the way, what is the name of the other tool you mention?

Edited June 8 by lorak

[lorak]

ImHex editor (Windows) is constantly crashing my end.

Edited June 8 by lorak

[applecuckoo]

Hi! The checksum is of the entire uncompressed data file. I wouldn't be able to give you an exact offset, but the checksum is always at the four bytes right at the end of the decrypted and compressed file. For example, the checksum of your 32F842A7 save is 4ef3dd54, while the checksum of your DEFF340A save is cdce4959. If you go to the bottom of the two compressed files, you'll find that the hex values should match. By the way, I used Collision, a Linux tool, to calculate the initial checksum, but you could also use Jacksum, a more advanced cross-platform tool, or this simple Python script I made:

# Quick adler32 checksum calculator - applecuckoo

import zlib

file = "uncompressed.be5" # substitute this to your filename, note that this has to be the same directory you're running this
bin = open(file, mode="rb")
data = bin.read()
hash = hex(zlib.adler32(data))
print("Your hash for the file", file, "is", hash)

Hope this helps!

Edited June 8 by applecuckoo

[applecuckoo]

@lorak You might want to mark the last post as solved.

[lorak]

@applecuckoo Thank you very much for all the information you shared!!
At the beginning, I thought that this game is working with a 64-bit long checksum stored at the end of the decrypted and compressed file as there are 8 bytes at the end of that file. However, you found out that this game uses the Adler-32 checksum algorithm for game saves (computed on the decrypted and decompressed file), checksum stored in the last 4 bytes of the same file. 

What do you think about those 4 bytes just before the start of the Adler-32 checksum? I am wondering about it because a third person made a first test with no success. I will try to load a custom roster in MLB14TS PS3 myself following your findings.

Edited June 13 by lorak

[lorak]

10 hours ago, applecuckoo said:

@lorak You might want to mark the last post as solved.

How I mark that post as solved? It seems that you already did it.

[ikskoks]

4 hours ago, lorak said:

It seems that you already did it.

I did it.

[lorak]

2 hours ago, ikskoks said:

I did it.

Ok, thank you.
I assume any moderator or the person that started the thread could mark a post as solution. Is it done just once, right?

[ikskoks]

12 hours ago, lorak said:

I assume any moderator or the person that started the thread could mark a post as solution. Is it done just once, right?

Yes, exactly.

[applecuckoo]

On 6/13/2024 at 4:49 AM, lorak said:

@applecuckoo Thank you very much for all the information you shared!!
At the beginning, I thought that this game is working with a 64-bit long checksum stored at the end of the decrypted and compressed file as there are 8 bytes at the end of that file. However, you found out that this game uses the Adler-32 checksum algorithm for game saves (computed on the decrypted and decompressed file), checksum stored in the last 4 bytes of the same file. 

What do you think about those 4 bytes just before the start of the Adler-32 checksum? I am wondering about it because a third person made a first test with no success. I will try to load a custom roster in MLB14TS PS3 myself following your findings.

The ImHex pattern (similar to 010 Editor's 'binary templates') just show the four bytes before the checksum as part of the compressed data block.

[lorak]

On 6/14/2024 at 1:36 AM, applecuckoo said:

The ImHex pattern (similar to 010 Editor's 'binary templates') just show the four bytes before the checksum as part of the compressed data block.

Ok, thank you.
I will try to load a custom roster for MLB14TS PS3. Hopefully it works.