w3g reversing

[chusrubi2]

I've been trying to analyse w3g files and I'm really stucked in the step of the CRC32 header checksum calculation.

http://w3g.deepnode.de/files/w3g_format.txt

Following that tut I have these 40 bytes from a replay header:

57 61 72 63 72 61 66 74 20 49 49 49 20 72 65 63 6F 72 64 65 64 20 67 61 6D 65 1A 00 44 00 00 00 77 1A 00 00 01 00 00 00 E0 3C 00 00 02 00 00 00 50 58 33 57 1B 00 00 00 AB 17 00 80 49 E6 02 00

and the following 4 bytes which is the checksum:

50 25 A0 11

So what I do to calculate the checksum is to get the 40 first bytes, add 4 bytes of zeroes and generate it. But it doesn't work!

I also tried reversing the whole header chain from back

0002E649800017AB0000001B573358500000000200003CE00000000100001A7700000044001A656D616720646564726F63657220494949207466617263726157

and then adding the 8 zeroes (at the end or at the start) and still nothing.

Any lights?

 

[GhostWolf]

I am assuming you are talking about the version 0 header.
If that's the case, the note there says the whole header is 0x40 (64) bytes, not 40.

 

[chusrubi2]

I am assuming you are talking about the version 0 header.
If that's the case, the note there says the whole header is 0x40 (64) bytes, not 40.

No, version 1 (1.26). So 68 bytes.

Overall header size for version 1 is 0x44 bytes.

Anyway, I still can't figure out how to make it.

 

[GhostWolf]

Make what? You wrote you are getting 40 bytes. If the header is 0x44 bytes, then you need to read 68 bytes.
I am not sure why you care about the checksum in the first place though.

 

[Dr Super Good]

I am not sure why you care about the checksum in the first place though.

To properly evaluate the file (detect checksum failure) and also to generate valid files WC3 will process (it probably fails with a "damaged" warning if checksum mismatches).

You need to CRC32 the full 0x40 (version 0) or 0x44 (version 1) bytes of the header with the CRC field 0ed.

 

[chusrubi2]

To properly evaluate the file (detect checksum failure) and also to generate valid files WC3 will process (it probably fails with a "damaged" warning if checksum mismatches).

You need to CRC32 the full 0x40 (version 0) or 0x44 (version 1) bytes of the header with the CRC field 0ed.

Ive tried this and always failed. Could you try with these bytes and tell if it works for you? Or just with a common replay from 1.27 :}

 

[GhostWolf]

I just ran those bytes with the zero padding here, and it produced the correct checksum.

 

[Dr Super Good]

What CRC32 implementation are you using? There are many different 32 bit CRCs but only one is known as CRC32.

Since CRCs are numbers rather than a sequence of bytes I would imagine endian can play a factor in their correct interpretation once stored.

 

[chusrubi2]

Okay, it was a silly mistake of mine.

I succeeded and I was able to make a replay converser that is actually working (from 1.26 to 1.27) just by changing the game version and then the checksum.

I can post it if requested.

Thanks both for the help.

 

[Dr Super Good]

I succeeded and I was able to make a replay converser that is actually working (from 1.26 to 1.27) just by changing the game version and then the checksum.

The reason WC3 does not support older replay files is because changes to the game engine could cause some replay files to desync. For example if Blizzard were to change the rate the movement loop updated to support twice as many units moving at once then movement in the replay would quickly out of sync and combat results would start to be different.

Modern RTS games like StarCraft II support this functionality by loading the map and replay file with an earlier game executable version, kept in a version archive of sorts.