(Link to AcmlmWiki) Offline: thank ||bass
Register | Login
Views: 13,040,846
Main | Memberlist | Active users | Calendar | Chat | Online users
Ranks | FAQ | ACS | Stats | Color Chart | Search | Photo album
05-08-24 10:06 PM
0 users currently in ROM Hacking.
Acmlm's Board - I3 Archive - ROM Hacking - Calculating checksum... need help New poll | |
Add to favorites | Next newer thread | Next older thread
User Post
FloBo

Goomba








Since: 05-18-06

Last post: 6365 days
Last view: 6290 days
Posted on 05-18-06 04:10 AM Link | Quote
Hi there.

I'm currently doing a little sram-hacking and there's the "problem" that the sram is checked for integrity by a 16-bit checksum... Now that I looked for some common 16bit-checksums and returned being not any step further, it looks like it's now up to me, to figure it out myself...

So here comes an example:
This is the checksum: 6E 61
It represents a sequence of 2040 Bytes with value E5.

So can anyone give me a hint on how to calculate such a checksum, or on how to best figure out the algorithm doing it? Ah, btw, it's an snes game, I'm hacking


Any help would be appreaciated. Thanks in advance,

FloBo


MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6289 days
Last view: 6288 days
Posted on 05-18-06 05:15 AM Link | Quote
The checksums on most games are simple addition based checksums, not CRC16 or stuff like that you may have found on wikipedia. It's a balancing act, if you add $0E52, for example, to a certain location, you must add $0E52 to the checksum. If it's an inverse checksum, you must subtract it. You can do this kind fo stuff with the windows calculator if need be. Stating what game might help out a bit, as i've worked with zelda3, Super Metroid, and Chrono Trigger.
FloBo

Goomba








Since: 05-18-06

Last post: 6365 days
Last view: 6290 days
Posted on 05-18-06 07:21 AM Link | Quote
Thank you MathOnNapkins,... just tried to just increase one byte of the sram and to increase/decrease the checksum also by one...

Well. Didn't work though... how else could it be calculated? Another idea was calculating the sum of all bytes and performing mod(FFFF) on them... but unfortunately it's also not the right result...

Any other ideas?!
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6289 days
Last view: 6288 days
Posted on 05-18-06 04:24 PM Link | Quote
Again, could you say what game? There is no way for me to tell you for sure without knowing this. Also, you have to view the file as an array of words, not bytes. i.e. the checksum is usually a 16-bit checksum. observe:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 01 01 01 01 01 01 01 01 01 01 01 01 01 XX XX

XX XX is the checksum, but is it $000E? no. It is $0101 + $0101 + ... + $0101 = $0707, which would be 07 07 in hex.

Let's modify it to:

00 05 FF 00 00 00 00 00 00 00 00 00 00 00 00 00
01 01 01 01 01 01 01 01 01 01 01 01 01 01 07 07

well since the original word on the first row was $0000, we have added $0500 to the first word. The second word on the first row has had $00FF added to it. So when we go to calculate the checksum it will be $0707 + $0500 + $00FF = $0D06

So again, you probably should view it as changing a 16 bit value that is summed, rather than an array of 8-bit values that get summed into a 16-bit value. e.g. when I tried this with GBA games, the checksums were typically 32-bit aligned. It makes sense.
FloBo

Goomba








Since: 05-18-06

Last post: 6365 days
Last view: 6290 days
Posted on 05-19-06 07:37 AM Link | Quote
The game is Lufia1 for the SNES.

I just wrote some crappy little C-tool calculating all checksums by adding all words of one block together and then performing mod(FFFF) on the sum... the result still doesn't fit, but anyway, here's a description of the structure of the decompressed sram:


The first part of the SRAM consists of three blocks. Each one for one savegame slot within the game. Those three blocks are constructed in the following way:

3 words (Ascii-text): File0X //where X is replaced by 0, 1, or 2
1 word: 16-bit checksum of the following 1020 words
1020 words: containing the save-specific data like hitpoints etc.

So this thing is there three times --> for three saveslots. Afterwards there's some space left for global game variables and stuff which i do not intend to modify at all, so this might not be that interesting...


Thanks again for the info about calculating with words (should have been clear to me as it's a 16 bit system, but yeah O_o)...
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6289 days
Last view: 6288 days
Posted on 05-19-06 07:48 AM Link | Quote
So you have no more problems?

When I say you have to view it as 16-bit, I don't mean you HAVE to, I'm just saying it's likely to be 16 bit aligned b/c it's a SNES. However, the checksums for actual SNES roms are sums of 8-bit values mod 2^32, then trancated to mod 2^16. So it depends on who implements the checksum really. Hence having to know what game.
FloBo

Goomba








Since: 05-18-06

Last post: 6365 days
Last view: 6290 days
Posted on 05-19-06 08:38 AM Link | Quote
No, actually the problem is still the same...

As the sum won't get that large as for an snes ROM (because the sram is MUCH smaller than the rom), a mod 2^32 operation doesn't change the value at all...

And what difference does it make who implemented that thing? Do you hava access to a database of programming habits of recent programmers / teams?! *confused*
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6289 days
Last view: 6288 days
Posted on 05-19-06 10:07 AM Link | Quote
the mod 2^32 checksum I was referring to is the checksum for the actual ROM, not the SRAM. You know, when you start up your emulator and it says "checksum: ok" or "checksum: failed" or any other notification of that sort. That was a checksum that Nintendo decided developers had to use when creating binary images of their games. Hence Nintendo decided the implementation.

In any case, the point is... I just downloaded Lufia 1 and am too tired to mess with this today. will edit later when I wake up.

From looking at the machine code, it appears the checksum formula is thus: the value $6502 + each word, starting from address $0008 in the save slot, ending at address $07FF in the save slot. I would check this myself but I cannot find my TI-83, and don't have a convenient way of checking this otherwise at this time.

edit: considering the old NES processor was the 6502, I am not surprised at all. Btw, using the windows calculator, ($E5E5 * $3FC)+ $6502 = $616E. Shocking isn't it?


(edited by MathOnNapkins on 05-19-06 09:31 AM)
(edited by MathOnNapkins on 05-19-06 09:36 AM)
(edited by MathOnNapkins on 05-19-06 09:37 AM)
FloBo

Goomba








Since: 05-18-06

Last post: 6365 days
Last view: 6290 days
Posted on 05-19-06 01:38 PM Link | Quote
Heh^^ About that thing with the Rom checksum: I got that in the first place... seems like my english wasn't good enough to get wrap this into words

Lol... 6502... they're funny, those people from Taito, aren't they? And you got that Info out of the asm of the rom? Damn... I really need to learn 65816 soon... How did you do that? Did you use Gaigers Snes9x debugger?

Anyway thank you very very much! You'll definately be metioned in the credits, once my translation and/or any editor for this game gets released
MathOnNapkins

1100

In SPC700 HELL


 





Since: 11-18-05

Last post: 6289 days
Last view: 6288 days
Posted on 05-20-06 01:52 AM Link | Quote
Originally posted by FloBo
Lol... 6502... they're funny, those people from Taito, aren't they? And you got that Info out of the asm of the rom? Damn... I really need to learn 65816 soon... How did you do that? Did you use Gaigers Snes9x debugger?


Yes, I used Geiger's Debugger. I set a breakpoint on writes to $700806 then went to a shrine to "record" my game into save slot 2. I found out where it was being written in the code when the debugger snapped. I then figured out what routines were being called to calculate this checksum prior to recording it in SRAM by setting some strategic execution breakpoints (not read/write breakpoints).

The funny thing is that of all the time I spent figuring this out, most of it was spent fighting the Sinistrals in the intro so I could get to a point where I could save . About 90% of the time really. The 65816 required to understand this is minimal really. Experience certainly helps too.
Add to favorites | Next newer thread | Next older thread
Acmlm's Board - I3 Archive - ROM Hacking - Calculating checksum... need help |


ABII

Acmlmboard 1.92.999, 9/17/2006
©2000-2006 Acmlm, Emuz, Blades, Xkeeper

Page rendered in 0.031 seconds; used 397.69 kB (max 485.83 kB)