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.

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).

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.

So, you’re a Konami fan, too, huh?

You forgot about START, or SELECT, START for two players, like back in the day.