For my current game, Rot Gut, I’ve been using Flash and with the inherent bad design of SWF it literally has all the source code and assets inside the final SWF. So if anyone wants, they can easily see your code and do bad things with it which in Flash world is usually hosting your game on the sites that have no right to do so. I can elaborate more on why this is the case with SWF and not with regular EXE files but I think it will bore the audience a bit but just know that EXE files are “compiled” from source code thus the source code from it’s text type is turned into binary that is understandable by machine, even though that can be understandable to humans and goes to topics of reverse engineering but that’s clearly way beyond scope of this blog and this review. Just know that in SWF files anyone can view your source code or open up your assets with a simple flash decompiler, which is bad.
There are ways to solve this problem but one that is mainly used is some category of software called Obfuscators. Obfuscation is generally the act to cipher your code so when seen can be hard or next to impossible to understand to humans. (Note that it still can be de-obfuscated by some other special software but that depends on if anyone wants to go that far to do that so basically depends on the project). That’s where SecureSWF comes into play.
1- First and foremost is the degree of complexity in the generate obfuscated code. Even though that I’m the only programmer on our game, I really have a hard time even guessing what part of the generated code by SecureSWF is representing.
2- Another important feature of SecureSWF is Domain Locking / site locking. Site-lock generally restricts your SWF file to run from list of URL(s) that you provide and is essentially needed when you sell a game to sponsors on sites like FlashGameLicence.com because no one will pay you for a game that someone else can steal and host on their own site.
3- Usually flash games have advertisement and those ads are communicating with their host via specially created keys which are literal strings. SecureSWF has a section to protect your sensitive string literals such as these but make sure to create a function that assign these values because that’s the only way they will get obfuscated.
4- If any part of your code can’t be obfuscated or is sensitive to obfuscation and breaks, you can define several degrees of obfuscation to it so if it breaks you can lower the degree until it works, which is great as you can do this for every part of your project.
I can say that there are still room for it to get even better, as I mailed some of them to the developers and hopefully they will be noted, but generally I really liked and enjoyed the experience. For example since flixel uses some hack to read input, any obfuscation on that part will break your game so you have to know to quarantine org.flixel.* from your project or any other library that is open source, after all there is no need to obfuscate an open source framework. So some template for some widely used stories would help newcomers as there are forum posts that people have no idea how to fix such things.
At the end, I’m posting my project’s config file’s screenshots so anyone using flixel with SecureSWF can easily config their project:
Kindisoft’s SecureSWF comes with 3 different versions that you can see their differences here.
I would be glad to answer any question or read any comments regarding this! Also their customer support was very responsive and informative and helped me to get me started, so feel free to use their support system as well.
Hope this review will be useful and thanks for reading!
If you want to buy it, you can use this coupon “FGL25” to get %25 discount on your purchases!