Running a game (WWE '12) via emulated NAND, accessed the save, edited a few things to my liking (name changes, NPC unlocks, etc) and I can't seem to get the game to accept the save, comes up as damaged, obviously because of a checksum, but the problem is..there seems to be no checksum in the header of the save.dat file, any idea as to how to find it/bypass the "damage"?
create a couple saves with very little changed. like adjust the volume or something small in the game. then compare your saves with a hex editor and look for a u32 that has changed drastically. once you got that, load the game up with a usb gecko/dolphin and set a read breakpoint at that point of your save. then you can catch the game computing the checksum. and then you can see the offsets and whatnot it uses.
I found one byte that changes constantly, but everytime I change it on my edited save, it still says damaged, hmm..also, how do I set a read breakpoint in Dolphin, I'm assuming I might need another build or something?
Edit shortcut to dolphin:
Target: "C:\Program Files\Dolphin-win-x64-r7719\Dolphin.exe" -d
Note: This seems to slow things down a lot. Make sure to disable "options -> boot to pause".
I would also like to know how to set a read breakpoint on a save. (Actually, on a GameCube save.)
Target: "C:\Program Files\Dolphin-win-x64-r7719\Dolphin.exe" -d
Note: This seems to slow things down a lot. Make sure to disable "options -> boot to pause".
I would also like to know how to set a read breakpoint on a save. (Actually, on a GameCube save.)
i wrote a little app to find & fix the checksums and whatnot. http://www.multiupload.com/FL9U6LO99M . I only have a minimal save with a single custom character and i found 3 checksums. there are 6 references to their checksum function, and only 3 of those compare the result. so i assume i got them all.
im using the pal copy of the game. so it may or may not work on the usa version.
funny story... this game misbehaves when you give it a long name for your custom character
.
im using the pal copy of the game. so it may or may not work on the usa version.
funny story... this game misbehaves when you give it a long name for your custom character
.
misbehaves exploitably?i wrote a little app to find & fix the checksums and whatnot. http://www.multiupload.com/FL9U6LO99M . I only have a minimal save with a single custom character and i found 3 checksums. there are 6 references to their checksum function, and only 3 of those compare the result. so i assume i got them all.
im using the pal copy of the game. so it may or may not work on the usa version.
funny story... this game misbehaves when you give it a long name for your custom character
possibly. i honestly didnt look into it very far. i only fed it a long name and got it to crash. IDK if it is because of a buffer overflow or because the long name caused some out-of-index-array shit or anything else.
I usually use the usb gecko. But I went ahead and went through the steps to do this with dolphin. It turns out you need the debugfast build, which shuffle was a great help with. The regular build can set execute breakpoints, but not ram read/write ones. Anyways, after building dolphin with the debugfast stuff, heres how I did it.
Open up the save file and change a byte in it to force a corruption.
Start dolphin with the "-d" option for debugging. Go to the "view" menu and enable the memory, breakpoints, ect. Then start the game and let it run up to the point where it says the save is broken
Find some data in you save that is not likely to be in the RAM outside your save. My character's name is Pune, so I used that.
Dig through the RAM in dolphin and eventually you end up with this section. It looks like a section right in the middle of the save file.
Go to the breakpoint tab, and click the "+MC". Then enter the memory range where the save was, select "read", and select "break".
Now restart the game. Let it run till it hits the breakpoint and freezes.
Hop to this instruction in your favorite disassembler. It looks like this is our bitch. r3 is the pointer to memory, r4 is the length. The "mr %r3 %r6" near the end means that r6 will be the return value See all those "lbz"? Those are reading 1 byte at a time, and adding it to r6. So there is their kindergarden checksum.
If youre in IDA, right click the function and chart the xrefs. These are the 6 functions that are calling the checksum. The first 3 here never check the
result, they only compute it. The last 3 of them actually check the result and compare the result.
This is the first one I looked at. There is a magic word or whatever stored right before the checksum that must match a handcoded value. They
load the location of the section of the save they want to check and a length, save the current checksum in r31, and set the one in the save file to 0.
then calculate the thing. And then store the old value back in the save and compare the expected and actual results. It sets r3 to 0 for failure and
1 for success.
the other 2 calls to the checksum function we care about are very similar. they are varying the length and location, as well as some magic word
stored directly ahead of the sum.
Open up the save file and change a byte in it to force a corruption.
Start dolphin with the "-d" option for debugging. Go to the "view" menu and enable the memory, breakpoints, ect. Then start the game and let it run up to the point where it says the save is broken
Find some data in you save that is not likely to be in the RAM outside your save. My character's name is Pune, so I used that.
Dig through the RAM in dolphin and eventually you end up with this section. It looks like a section right in the middle of the save file.
Go to the breakpoint tab, and click the "+MC". Then enter the memory range where the save was, select "read", and select "break".
Now restart the game. Let it run till it hits the breakpoint and freezes.
Hop to this instruction in your favorite disassembler. It looks like this is our bitch. r3 is the pointer to memory, r4 is the length. The "mr %r3 %r6" near the end means that r6 will be the return value See all those "lbz"? Those are reading 1 byte at a time, and adding it to r6. So there is their kindergarden checksum.
If youre in IDA, right click the function and chart the xrefs. These are the 6 functions that are calling the checksum. The first 3 here never check the
result, they only compute it. The last 3 of them actually check the result and compare the result.
This is the first one I looked at. There is a magic word or whatever stored right before the checksum that must match a handcoded value. They
load the location of the section of the save they want to check and a length, save the current checksum in r31, and set the one in the save file to 0.
then calculate the thing. And then store the old value back in the save and compare the expected and actual results. It sets r3 to 0 for failure and
1 for success.
the other 2 calls to the checksum function we care about are very similar. they are varying the length and location, as well as some magic word
stored directly ahead of the sum.
Similar threads
- Question
-
Psionic Roshambo
- S StealthD0g99
-
Xdqwerty
what are you looking at?
-
-
-
-
-
-
-
@
BakerMan:
fellas, would you rather have a scouter from dragon ball irl or a pip boy from fall out irl? -
-
-
-
-
-
-
-
-
-
-
-
-
S @ StealthD0g99:I am trying to hack Fire Emblem Warriors on my 2DS XL, I have been trying to get it to work, but I need some extra help figuring it out. I have HEX codes, and a possibly outdated plugin, but I dont know how to implement them
-
-
-
-
-
