Hacking Find the Checksum Algorithm for a game

[Lilio]

Hi all,
I am trying to edit the save data of Sonic and the Black Knight for Wii. I have extracted the save files and tried to edit them but the game kept saying they are corrupted.
That's when I've learned about checksums. I'm pretty sure that I have found the checksum bytes in the save file but right now I'm stuck trying to figure out the actual checksum algorithm.
I know that this is not a simple thing to do but people are doing this for a lot of games so, can someone point me in the direction of what I should do in order to make this work?
Thanks

 

[FAST6191]

There are a few choices depending upon what you want to do.
If you are intending to make a save editor or something
Learn a few checksum algorithms (a basic parity, bytesum, basic CRC and then maybe one of the crypto or formerly crypto grade ones like MD5 or SHA1 should do). You can now follow through the game's save loading options and see what it is. Chances are it will be a minor variation on one of those, or indeed one of those but just over a small portion of the ROM. Assembly coding is slightly annoying to watch for maths in but it can be done easily enough.
https://www.youtube.com/user/eaterbc/videos?disable_polymer=1 has a few videos if you want to go that way.

I assume you have checked other regions or other games from the save dev as they often reuse code and if an editor or something exists for that and is open source or documented...

If you just want a single edit or can afford to take a bit of time for the edits you want to do.
Find where the game loads the save. Somewhere in that will be the algorithm as discussed above but at the end of that will be a if good then carry on with life if bad then goto the corrupt routine. Change this to ignore it instead and always go down the "is good" path and you can edit your save and load it. Bonus is the check above likely does not break the saving routine so if you load in the modded game, and save in said same the game will generate you the correct checksum you can use with hardware or an unmodded game.
A bit annoying to have a save checksum fixer that is tedious to use and possibly multiple gigabytes in size but if it gets the job done...
Such a modded ROM will also allow you an easier time to check what each part of the save does.

Both of those will require some knowledge of coding and debugging (assuming you don't stumble upon the checksum algo and find the area such that you can do it with a hex editor's checksum options). Such things make a decent introduction to it all though, maybe not the gentlest but not bad and if it is something that will hold your interest then I would skip the theoretically easier/gentler stuff any day for it.
Standard tracing methods would apply, don't know if we have a Wii specific tracing guide right now though. Either way I would probably dump the memory after the save is loaded, find where the data from the save ended up in memory (or what changed between immediately before and after the save) and then work backwards from there until you find the compare command for the checksum or the checksum algorithm itself.


If what you want to edit can be done as cheats then do that. This tends to be more for levels unlocked, items in inventory or money, maybe levels for a game with stats, maybe character names if they were selectable at one point but not so much for times or high scores (though it can be an option in some cases -- if the game dumps the score table in memory and then back again afterwards).

 

[Lilio]

There are a few choices depending upon what you want to do.
If you are intending to make a save editor or something
Learn a few checksum algorithms (a basic parity, bytesum, basic CRC and then maybe one of the crypto or formerly crypto grade ones like MD5 or SHA1 should do). You can now follow through the game's save loading options and see what it is. Chances are it will be a minor variation on one of those, or indeed one of those but just over a small portion of the ROM. Assembly coding is slightly annoying to watch for maths in but it can be done easily enough.
https://www.youtube.com/user/eaterbc/videos?disable_polymer=1 has a few videos if you want to go that way.

I assume you have checked other regions or other games from the save dev as they often reuse code and if an editor or something exists for that and is open source or documented...

If you just want a single edit or can afford to take a bit of time for the edits you want to do.
Find where the game loads the save. Somewhere in that will be the algorithm as discussed above but at the end of that will be a if good then carry on with life if bad then goto the corrupt routine. Change this to ignore it instead and always go down the "is good" path and you can edit your save and load it. Bonus is the check above likely does not break the saving routine so if you load in the modded game, and save in said same the game will generate you the correct checksum you can use with hardware or an unmodded game.
A bit annoying to have a save checksum fixer that is tedious to use and possibly multiple gigabytes in size but if it gets the job done...
Such a modded ROM will also allow you an easier time to check what each part of the save does.

Both of those will require some knowledge of coding and debugging (assuming you don't stumble upon the checksum algo and find the area such that you can do it with a hex editor's checksum options). Such things make a decent introduction to it all though, maybe not the gentlest but not bad and if it is something that will hold your interest then I would skip the theoretically easier/gentler stuff any day for it.
Standard tracing methods would apply, don't know if we have a Wii specific tracing guide right now though. Either way I would probably dump the memory after the save is loaded, find where the data from the save ended up in memory (or what changed between immediately before and after the save) and then work backwards from there until you find the compare command for the checksum or the checksum algorithm itself.


If what you want to edit can be done as cheats then do that. This tends to be more for levels unlocked, items in inventory or money, maybe levels for a game with stats, maybe character names if they were selectable at one point but not so much for times or high scores (though it can be an option in some cases -- if the game dumps the score table in memory and then back again afterwards).

First of all thank you very much! I will look at the videos of the youtuber you've linked so I can get more familiar with what I'm doing.
I have a decent knowledge in coding and debugging (more OOP though than low level and asm). I'm not really into writing a save editor just for this game.
I have tried to apply some checksum algorithms by the HxD Editor to different parts (and all) of the save file and I couldn't find the correct one.
Also I have tried to find some editors for other Team Sonic games but that didn't really help.
To be honest I learned about what I could do theoretically, like finding where the game loads the save. However I'm stuck with actually figuring out exactly how to do it.
I am using Dolphin, I have ran it in debug mode but for some reason I can't figure out how to use it really, most of the addresses are unknown, and also I don't understand how to search for values in the memory using Dolphin's debug mode. Is there a special version of Dolphin? Or maybe another tool that I can use? Also how do I decompile Wii games so I can check what's going on?

 

[FAST6191]

If you already have an idea about program flow, some boolean and operational stuff then that is most of the stuff sorted -- watching something manage registers and IO, and do low level number fiddling to over overflowing said same, is tedious if you are more used to something high level that probably has a compiler/main library for the language function but in the end nothing drastic. You are not going to get a surprise test on the timings of SIMD instructions -- it is going to be add this to this (possibly many times), read this memory section, compare and branch accordingly. Compare and branch is not the same wording as IF and ELSE but it is not worlds apart.

I am unfamiliar with Dolphin's current abilities as far as being a debugger. I even want to say it might have lost some at one point so you might need to dig up an older version. Being a fairly potent console as well it is not as nice as the "could run 10 of them at once and still not get too close to choking a modern system" stuff like most ROM hacking sites/sections focus on. You might also have to dump the memory and feed it to a debugger (IDA will naturally have modules). That said https://blog.delroth.net/2011/06/reverse-engineering-a-wii-game-script-interpreter-part-1/ was 2011 so things have probably got better since then, or you can find an older version.

I mentioned the method I would likely use to find where the save lands in memory. It is basically an expanded version of the standard cheat search -- take a savestate from before the save is loaded (you usually have a nice on screen prompt for that one, or you press a button to make it happen, or if it is more subtle then you already know how to break a save to get it to error out on you), load the save but don't do anything else, grab another savestate and compare. Alternatively if the save is not compressed and data is not processed much you can try comparing a savestate/memory dump with the contents of the save.
The big boy hacker would likely watch the Wii speak to the IO to get the save (the Wii is kind of modern so I imagine it will be speaking to the game's chosen IOS module to fetch data from NAND or SD) but if you don't want to do that or Dolphin is limited then memory stuff is fine as it is not like you are getting a game to have a save where there was none before -- you only care about what the save means for the game and how it processes the checksum.