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?