Flash & AS3 info, source, & experiments
MD5 Checksum Doesn’t Match in swf Files
In the gambling industry, software integrity is vital. It would be all too easy for someone to write a magical up, up, down, down, left, right, left, right, b, a, sequence into an electronic gambling machine, tell a few friends about it, and make some money. To prevent this, most jurisdictions require the game to go through an approved lab before they will allow it. In the US, the primary lab is called GLI (Gaming Laboratories International). GLI requires a copy of our source code and the ability to build the game in-house. They then use the md5 (Message-Digest algorithm 5) checksum from this in-house build to compare with any other created “copies” of the game to determine if any tampering or errors have occurred.
This works fine for C++ code, but what about compiled swf’s? Using the Adobe Flash CS3 IDE, I compiled one swf, duplicated it, and then used the Windows freeware tool MD5sums 1.2 by Jem Berkes to see if the checksums matched. Sure enough, a perfect match. So then I recompiled the swf without changing anything at all, and retested the checksums. No match. Well, I assumed that the compilation date would give me a problem, but I thought that I might be able to do some code injection to fix this issue. So I ran a hex compare on the two “should-be-the-same-swf-files” to see what was different. There were TONS of differences! Way more than could be warranted by just a time stamp change.
Adobe, help me out. As Flash broadens its competing markets and as it becomes more and more common on the casino floor, there has to be a way to compile two swf’s that will be byte for byte identical. I wonder if Silverlight allows this?
This work, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 3.0 United States License.
SWF files are generally compressed (they don’t have to be, though). I imagine that if a timestamp is saved into the SWF before compression, the MD5 sum would be completely different every time even if the rest of the uncompressed SWF is the same.
@Josh – I agree completely and the MD5 sum would definitely be completely different even if the only thing that changed was the date. But when I did the hex compare, there were TONS of things different in the actual files (not just the checksum). This is the part that baffles me.
Hey.
So, you’re a Konami fan, too, huh?
You forgot about START, or SELECT, START for two players, like back in the day.
Hey.
Ok, seriously.
MD5 has what they call the “avalanche” effect, where even the slightest change in the data produces a totally different output.
Have you tried compiling the Flash, moving the resulting SWF to another folder, so you don’t overwrite it, then compiling it a second time, and comparing the two SWFs? I don’t have Flash CS3, so I don’t what implications that would have.
Off topic, if I may digress…
What a coincidence! I was looking for was to add some security my Flash SWF game once I am ready to put it on the net, and I found this page. Comparing hashes is something I am currently implementing.
One idea I had was to have a “pre-preloader” SWF, which loads a preloader SWF. The preloader is encrypted, so it’s a bunch of mangled bytes. Then I compute a checksum, or some other hash, of this encrypted data, and run the result against a hash value stored in a server-side database. If they match, then it’s ok; the preloader is decrypted then loaded into Flash, which finally loads the “real” Flash SWF (which would be the game), which also is encrypted. Using AES-256 encryption.
__________
-Zir0 out.
Hey Zir0, I understand about the md5 “avalanche” effect, but this should not also be true of a hex compare when nothing at all has been changed. And yes, I compiled once, moved the swf, immediately compiled a second time without changing anything, then did the hex compare. The hex compare of the swf’s were *completely* different. My only guess is that Adobe uses some sort of hash key or something when the compiler runs–probably for security reasons.
What your proposing to do for your security sounds like it would work great, with one caveat: each time you recompiled the external swf, your checksum would no longer match. So you would also have to update your preloader (or better, some external file/database that the preloader gets the checksum values from).
Hey.
Mr. Nate – Thanks for your reply.
They were STILL different!? Wow… don’t know why that would be. It could very well be Adobe using hashes of sorts at compile-time as you mentioned, or it can probably be explained in the format of a SWF, since it is open-source and all. Or, Adobe just likes to play games.
Speaking of games… what about that Konami code, man? Maybe try putting the code in WHILE your SWF is compiling, and that will stop random hashes.
lol No, wait, don’t do that – it might produce THIRTY swfs, all totally different!
———-
Thanks for your comments on my idea, and yes, I am already aware of the caveat. That’s not a big deal for me, as the SWF is not likely to change much, once you are done working on it.
I started to work on the idea, and I’ve already re-calculated the hashes several times after recompiling my SWF while testing, just to make sure it works. You’d only have to re-calculate and upload your hashes, say for example, on a new version of your SWF.
Hope you find out why your comparisons are always off, soldier.
__________
-Ziro out.
Very interesting blogpost. Well, if silverlight allows it, this difference would be it´s right to exist, as there are no benefits from silverlight, it´s just a redundant product.
Hola,
Super post, tienen que marcarlo en Digg
Gracias