Full Disclosure: This is a paid review. We are receiving a free license of Kindisoft secureSWF in exchange for evaluating the product and posting our opinion. This has not necessarily effected a positive or negative review; while a post can be bought, our favourable opinion comes at a higher price. (That price, incidentally, is one large basket of Peek Frean’s chocolate Bourbon Cream cookies, a variety of points cards for leading video game consoles, a 1-year subscription to Games Magazine, and a commercial-grade Sno Kone machine.)
i would give WISDOM TOOTH EXTRACTION a positive review for a basket of these babies
What follows is a review by Jeff Gold (ue_jeff), our indomitable Game Developer and Keeper of All AS3 Knowledge.
From the Mouths of Jeffs
Today I set out to evaluate Kindisoft secureSWF, a product designed to help Flash / Flex developers secure and obscure their flash content from prying eyes. Thanks to several products on the market today (I am going to use SoThink SWF Decompiler as my point of reference here) it is possible, and quite easy, to open up Flash content found online to view and re-use all of the file’s source code and art assets. There are many reasons why developers would not want their files being decompiled this way. Theft of ActionScript code, theft of art assets, and hacking of controlled systems are just three.
Log in to the MochiMedia community forums and read this post about how one developer’s game was completely ripped off by someone with a swf opener:
Sep 07, 2009
On of my puzzle games was hacked. The person replaced my site logos, but apparently left my mochibot code in place, so I can see where all the hacked copies are. Anyone familiar with the site OyunKolu.com ?
SecureSwf was recommended to us by a number of our Twitter friends, including Chris Hughes from Flash Game License/GamerSafe. We had been evaluating other encryption software (most notably Amayeta SWF Encrypt 6.0) and were not entirely impressed with the Actionscript 3 code obfuscation. With Amayeta’s product, I found that using anything but the most minimal settings made my swf report many errors.
ERROR! ERROR! DOES NOT COMPILE!
That New Software Smell
Upon opening SecureSWF I immediately noticed many options compared to the other products we had tried.
Our first victim: a pie chart swf that we use in Interrupting Cow Trivia
Being momentarily overwhelmed by all the panels in front of me I decided to just try out the default configuration. On the first simple swf I tried to encrypt, the default configuration worked quite well causing no errors while running the swf.
secureSWF’s default settings
Immediately after encrypting my first swf with Swf Encrypt, I busted out my swf decompiler to see the results. Decompiling the swf was still possible ( I think this will be the case with any swf encryption ) , but inspecting the extracted code I could see a fair deal of obfuscation had occurred. (Obfuscation Translation: Code is EFFED-UP. – Ryan) With the default settings, Class names, function names, and class variables are obscured to things such as “_-V” or “_-02″, making the code very hard – but not impossible – to follow. I did notice immediately that variables scoped in functions were not obscured , but were left as var _loc_1 , var _loc_2 etc. as the compiler defines them (which I suppose is already obscure).
Before secureSWF …
… After secureSWF.
Giving It Some Welly
My next step was to crank up the security settings on the same simple swf. This time around I went to protection options and checked “Statement-level Randomization”, Maxed out “Control Flow Obfuscation” and “Dynamic Code Wrapping”, and checked “Break function Calls”. Honestly I am not 100% sure what all these things are doing, but I just went for overkill settings.
The swf still managed to run without any errors, and like last time I was still able to decompile the swf. Taking a look at the code again I immediately noticed quite a bit more obfuscation at the function level, and the code seemed more verbose and harder to follow.
Again, the same code before secureSWF …
.. and after, with settings cranked to the max.
Enter the Cow
So after my successful runs on a simple application, I tried to run a complex application through the process (Interrupting Cow Trivia, our real-time multiplayer trivia game) once again with default settings. At first the swf seemed to work with no errors, but after doing some stress testing I did notice few issues. After about 20 minutes of tinkering with the many settings available I figured out the culprit: “Control Flow Obfuscation”. Turning this one option off and then cranking all the other options managed to produce a 100% functional swf for me, and after decompiling I could not discern much difference from with the option on.
Spot the difference.
secureSWF has some other interesting features that I had not seen in other products (but, to be fair, I haven’t tried every competing product). These features include “Encrypted domain locking” and “Literal String Encryption”. I am not sure how the encrypted domain locking works , but it is a nice option and saves you from having to setup your own site locking in ActionScript each time. (Site-locking prevents your swf from being played on any domain other than the one[s] you specify.)
Literal String Encryption is another nice feature as it allows you to encrypt potentially sensitive text in your code. By default, strings will not be encrypted and will be perfectly readable when the code is decompiled. I am sure this process could be reverse engineered by digging through the code, but either way it just adds another barrier to the hacker to keep him from messing with your work.
Overall, Kindisoft secureSWF seems to be a solid product with lots of customizable features – far more than its competitors – that we plan to take advantage of for current and future projects.
End Jeff Transmission
Ryan: Of course, swf encryption is just one side of the story. If you have a game that posts information to your server to store high score data, to save games, etc, it’s important to know that all that stuff is wide open. Just grab Fiddler, a “web debugging proxy”, and run it while you play any game that makes server calls. With an unprotected game, you’ll be able to sniff out the exact asp or php page where scores are being posted, and you can use that info to trick the server into posting a high score for you. You can also use an app called Cheat Engine to wreak serious havoc with an online game, Flash or otherwise. Here’s how:
You may be wondering why, for the love of all that is Holy, we would be linking to movies and products about how to hack Flash games in a review of encryption software. It’s to illustrate the point that no protection solution is 100% effective (which is also why i have two children running around my house). Another saying i really like is “locks keep the honest people out”.
You’ll never make your game immune to hacking, but you can throw so many locks and contrivances in the way that it might take some serious skill to unlock them … and it follows that anyone with enough haxxor skillz to get through all those locks has something better to do with his considerable talents than to post a high score to your free-to-play Escape the Room game.
Win a Copy of secureSWF
Kindisoft is offering a 25% discount on secureSWF through various Flash game development sites, including FlashGameLicense.
For more articles about Flash and Actionscript, check out our Flash and Actionscript 911 feature.
[kml_flashembed publishmethod="dynamic" fversion="8.0.0" movie="http://www.untoldentertainment.com/games/interruptingCowTrivia/img/promo/blog_promo_bar.swf" width="545" height="185" targetclass="flashmovie" wmode="transparent"]