Implement checksum verification
mrhappyasthma opened this issue · comments
It seems the checksums are computed using SHA1 on the zip file itself.
Using sha1sum, I'm getting the following:
manifest.xml for version 4.10.1 / wac / i686
<file path="game/resources3.s2z/heroes/midas/alt2/ability_01/effects/trail_3.effect" size="2529" checksum="58f3c71d" version="3.9.8.0" zipsize="798"/>
terminal
# sha1sum game/resources3.s2z/heroes/midas/alt2/ability_01/effects/trail_3.effect.zip
5965338a71f639b45e2616cabd25cfaf53dc733b game/resources3.s2z/heroes/midas/alt2/ability_01/effects/trail_3.effect.zip
Which is clearly different than 58f3c71d.
Are you able to verify any of the checksums?
Oh I spoke too soon. The server packets all use SHA1 for checksums, but seems the manifest specifies something smaller. It looks like CRC32 by the size of it, but it doesn't seem to match what's specified inside the zip file.
Indeed looks like a CRC32, however this doesn't match either (version 3.7.6):
manifest.xml
<file path="zlibwapid_vc14.dll" size="175616" checksum="1c9614c3" version="3.7.4.0" zipsize="59031"></file>
# crc32 zlibwapid_vc14.dll.zip
e4f1dcf8
(extracted file)
# unzip zlibwapid_vc14.dll.zip
# crc32 zlibwapid_vc14.dll
e369eb3c
Btw I'm using arch linux on WSL to test those, if you have a different OS you can give it a shot as well. I installed CRC32 through perl-archive-zip.
Anakonda cracked the code here.
It uses a linux crc32, which takes the bitwise not of the value.
So if you take the 2nd example, where you extract the file and then take crc32. If you negate the value, you get the checksum in the manifest.
E.g. ~(e369eb3c) == 1c9614c3