Problem using encrypted zips then patching game to new version
by Matthew Jessick · in Torque Game Engine · 04/10/2008 (2:21 pm) · 0 replies
The standard zip encryption resource:
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9896
I have used this resource easily with great success. My comments below have nothing to do with the resource itself, but rather a problem that might crop up when using it within a particular game deployment scenario.
It appears to me that there is likely an incompatibility between using encrypted zip files for your game and "patching" your game after release. "Patching" is used here to mean having users download a fairly small file containing only the differences between two versions in order to get up to date using significantly less bandwidth than just downloading a complete new version (in the usual case where only small changes are made to various files between versions.)
Zip encryption appears to result in different encrypted data for each encrypted file each time the zip builder is run. (I have only tested this using the command line standalone 7-Zip program and WinZip, but I would assume that this is a feature of the Zip 2.0 encryption specification and would carry over to essentially all ZIP creators.) This means that pretty much your entire encrypted mod will "change" when you rebuild your file set EVEN IF NO SOURCE CHANGES are made. Patch build software such as the NSIS VPatch system will happily build up a huge patch for the encrypted mod that is essentially just as big as a complete download.
Unencrypted zipped mods don't have this problem. Unencrypted, changing a few bytes of defaults.cs (for example) and zipping up your fileset then "diff-ing" results in the expected small patch. However, if you need encrypted zips AND small patches, I'm not sure of the best way forward.
Theoretical Option 1: Depending on the reason for the changing encrypted bytes, you might be able to change the source code of your zip utility. Perhaps the zipping-to-zipping variation comes from the pre-pending of 12 random bytes to the front of each compressed file before encrypting. If so, perhaps you could change these bytes to be deterministic with the password (making your zip format even easier to crack, no doubt). This might be feasible, but might also take a lot of work. It might also not fix the problem, depending on exactly what causes the variation. (I believe 7 Zip is open source.)
Theoretical Option 2: Or perhaps you could replace the modified files into the previous version's zip (leaving all the unchanged files alone.) That way, the size of the patch would only be (essentially) the size of the entire changed files rather than the entire mod.
Theoretical Option 3: Put any changed files out into the MOD folder heirarchy rather than into the zip. (Presumably uncompressed.) You keep small patches but lose the "security" of the zip encryption. It seems the patches wouldn't be particularly smaller than option 2 however. (Although patches of previously patched files might ;) )
Hopefully there is a really slick way to get around this issue that I've missed allowing zip encryption and also reasonably small patches. If anyone can think of a better option, please mention it!
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=9896
I have used this resource easily with great success. My comments below have nothing to do with the resource itself, but rather a problem that might crop up when using it within a particular game deployment scenario.
It appears to me that there is likely an incompatibility between using encrypted zip files for your game and "patching" your game after release. "Patching" is used here to mean having users download a fairly small file containing only the differences between two versions in order to get up to date using significantly less bandwidth than just downloading a complete new version (in the usual case where only small changes are made to various files between versions.)
Zip encryption appears to result in different encrypted data for each encrypted file each time the zip builder is run. (I have only tested this using the command line standalone 7-Zip program and WinZip, but I would assume that this is a feature of the Zip 2.0 encryption specification and would carry over to essentially all ZIP creators.) This means that pretty much your entire encrypted mod will "change" when you rebuild your file set EVEN IF NO SOURCE CHANGES are made. Patch build software such as the NSIS VPatch system will happily build up a huge patch for the encrypted mod that is essentially just as big as a complete download.
Unencrypted zipped mods don't have this problem. Unencrypted, changing a few bytes of defaults.cs (for example) and zipping up your fileset then "diff-ing" results in the expected small patch. However, if you need encrypted zips AND small patches, I'm not sure of the best way forward.
Theoretical Option 1: Depending on the reason for the changing encrypted bytes, you might be able to change the source code of your zip utility. Perhaps the zipping-to-zipping variation comes from the pre-pending of 12 random bytes to the front of each compressed file before encrypting. If so, perhaps you could change these bytes to be deterministic with the password (making your zip format even easier to crack, no doubt). This might be feasible, but might also take a lot of work. It might also not fix the problem, depending on exactly what causes the variation. (I believe 7 Zip is open source.)
Theoretical Option 2: Or perhaps you could replace the modified files into the previous version's zip (leaving all the unchanged files alone.) That way, the size of the patch would only be (essentially) the size of the entire changed files rather than the entire mod.
Theoretical Option 3: Put any changed files out into the MOD folder heirarchy rather than into the zip. (Presumably uncompressed.) You keep small patches but lose the "security" of the zip encryption. It seems the patches wouldn't be particularly smaller than option 2 however. (Although patches of previously patched files might ;) )
Hopefully there is a really slick way to get around this issue that I've missed allowing zip encryption and also reasonably small patches. If anyone can think of a better option, please mention it!
