The one (and only) counter-argument I’ve heard against SWF protection goes something like this:
It doesn’t matter what you do, thieves will always be able to steal your work, so don’t bother with SWF protection.
This is a textbook example of the “perfect solution” fallacy. Thieves will always be able to crack safes, so why bother storing your money and valuables in them? And of course encryption can always be cracked, so why bother using it when transferring valuable information? Why not just release all your work and hard-earned assets out to the wild for anyone to plunder, since apparently it will be plundered regardless of whatever you do to protect it?
Why try?
Obviously we use safes and encryption &c to minimize the chances of bad things happening to our precious stuff. It’s just the same for people like me who make money with SWF files–I don’t want anyone stealing my Intellectual Property and posting it elsewhere, claiming it as their own, so I do everything I can to make the process of stealing my SWF files as difficult as possible. The more difficult a thing is to steal, the less chance there is of it being stolen–and less often.
The tools
Right now there are several tools, some even free, that allow you to decompile a SWF file to take a look at everything it contains. This is usually pretty easy because the SWF format is an open specification. This means there’s no way to fully protect anything contained in the file, such as code, graphics, sounds, or videos. However, there are applications that take precautions against decompiling using a variety of methods.
Protectors
I’ll review the biggest names in that market today:
- Amayeta SWF Encrypt 6.0.8
- DComSoft SWF Protector 3.0.1 (on twitter)
- Kindisoft secureSWF 3.5 (on twitter)
- Ambiera irrFuscator 2.1.2 (on twitter)
Decompilers
I’ll be using a combination of SWF Decrypt 1.2 and Eltima’s Decompiler v4.1 to test the effectiveness of these applications. (Side note: Eltima’s Decompiler and Sothink’s are freakishly similar.) SWF Decrypt really upset the industry when Magus (the author who wishes to remain anonymous) released it completely for free. It apparently decompiles any SWF file “protected” by Amayeta’s and DComSoft’s applications. He’s very loud about it too, calling them out on their “tricks”, such as their latest releases (which I’m reviewing here). You’ll notice he left Kindisoft and Ambiera alone, and he claims that’s because they offer real protection schemes, such as renaming functions and variables in the code. But the others claim they also use renaming, so we’ll see who’s right.
The SWF files
I’m a Flash game developer so that’s all I’m going to focus on here–single SWF files containing AS3 code compiled to run on Flash Player 9 and 10+. The files contain references to the Stage object, multiple event listeners, very high frame rates (60fps usually), and numerous computationally expensive operations such as pixel-level manipulations and heavy math functions. Here are the files I’ll be using:
- FlxCollisions
- Mode
- My pixel-level collision demo
These are free with source code available so that I can alter it if the protector requires it. The first two use Flixel (an old and new version), but if you have any (or know where to find some) non-Flixel open sourced Flash games then I’ll try that too. The third is a demo I wrote a while ago that has some heavy computation and sensitive optimizations that could trip up the protectors. Now, let’s get into the apps and see how they perform.
Amayeta SWF Encrypt
Image may be NSFW.
Clik here to view.
Amayeta is a subsidiary focused solely on the Flash platform. It used to have a single product, SWF Encrypt, but now also provides a SWF compression utility. Magus, author of SWF Decrypt, provides a deeper look at their history and he isn’t kind about it.
The problem I have with Amayeta right off the bat is that its flagship product’s name is completely misleading since it’s not possible to encrypt a SWF. I mean you can, but then the Flash Player wouldn’t be able to run it because the player doesn’t have a way to decrypt it at runtime–that’s just not how the player was engineered. So they are being deceitful.
Interface
SWF Encrypt has two main areas in the window: on the left is a file explorer where you pick your SWFs to protect, and on the right is the main area where you check the ones to protect (again) and view their properties.
It has an “encryption” setting with the values of “high”, “recommended”, “low”, and “custom”. If custom is selected you only have the option to set the “minimum data length”, which apparently just lets you put in a number that represents the level of “encryption” to use, with lower values being more protection.
Effectiveness
First using the recommended settings, the SWFs worked fine, no performance hit that I could tell. When I tried to open them up in Trillix, I could get to all the assets, but when I tried to access the scripts, it gave me an “out of memory” error. I tried to put it through SWF Decrypt but then the SWF wouldn’t play at all. I told Magus about this and he’s going to release a new version of Decrypt next week that should break Amayeta’s latest patch. It appears that the junk code Amayeta put into the SWFs actually worked this time.
SWF Encrypt has the options to “encrypt names” which I think is their way of saying they rename indentifiers like variables and functions. But because I couldn’t look into the scripts, post-protection, I could not verify this. I have conflicting reports about whether or not they truly obfuscate code, so I’m going to wait to see if Magus can break their patch, then revisit them again later.
Overall
It appears this latest version actually keeps Trillix from being able to look through it. However, I can’t check to see if there’s any actual renaming going on. Without true indentifier renaming, your SWFs will never be guaranteed to stay safe since the arms race between decompilers and protectors escalates endlessly. So for now, I can’t say one way or another if SWF Encrypt is solid. I can say that the level of control provided by the app is extremely limited, so even if they did do renaming, the user can’t fix a problem if the protection is too aggressive. An option to comb through your SWF and control protection on a per-object basis (ideally, per-variable and -function basis) is needed.
DComSoft SWF Protector
Image may be NSFW.
Clik here to view.
DComSoft has a much bigger catalog than Amayeta, all focused on Flash. Better, but the company history doesn’t appear very legitimate. According to research done by this dude and this dude, DComSoft is the same company as Eltima, a company that creates a SWF decompiler (one that I’m using for these reviews actually). That, my friends, is called “bad business practice”, if true. Besides that though, what the hell is up with the logo? If anyone has any idea what a tire has to do with Flash file protection, please let me know.
Interface
Protector has two modes: Simple and Advanced. Switch between modes using the tabs at the top of the application window. In Simple mode you can batch protect files but there are zero options. In Advanced mode though you can only protect one file at a time, but you can comb through each object and variable and check the boxes next to them, which are “Obfuscate” and “Protect”.
According to the help file:
Obfuscate renames variables, features etc. in a definite way. It doesn’t prevent from decompilation, but makes the subsequent compilation impossible.
And “protect” means
Protect modifies ActionScript in such a way that a SWF file can be played, but it is impossible to decompile it.
Right, we’ll see about that.
Effectiveness
The protected SWFs ran normally with no noticeable framerate drop. When I loaded it into Trillix though, everything appeared just fine with ZERO obfuscation–no renaming except for what Flash does automatically, no junk code/characters that would trip up the decompiler, nothing. All scripts I opened were very readable. I’d like to note however that I’m using an old version of Trillix (4.1), because the newest version would just crash if I tried to open the scripts (well, sometimes it’d work, but most of the time not). Anyway, really nothing else I can say here, just “epic fail”.
Overall
Image may be NSFW.
Clik here to view.
The interface is clean but offers very few options. If it actually worked I’d be ok with that, but maybe they need to add more granular controls so we can pick what we want obfuscated and by how much. It would also help if they added real obfuscation. Regardless, SWF Protector has a few licensing options. The Personal license ($40) doesn’t allow any of the SWFs protected by it to make money, while the Business license ($60) does. There’s other types for companies and OEMs too, but who cares–the software doesn’t work, end of story.
Kindisoft secureSWF
Image may be NSFW.
Clik here to view.
Kindisoft doesn’t mess around. When I emailed them about reviewing their app, they sent back this:
While I definitely love to hear your opinion of secureSWF, we’re not interested to see a comparison with SWF Encrypt and SWF Protector. We think of secureSWF as a professional level ActionScript obfuscator while SWF Encrypt and SWF Protector as single purpose tools that might prevent some decompilers from working for a while.
Ok then. So we start out on a completely different footing with Kindisoft than the others already. But while Kindisoft doesn’t have dirt on it like Amayeta and DComSoft do, it’s still a niche-based company providing only one product. Although that should mean they make a really great product, right?
I’d like to note that the free web-based version of secureSWF that is available to developers who put their games up at FlashGameLicense.com is apparently a different product. When I tried to add its protection to my first game, it broke it. When I brought this up with Kindisoft, they replied saying:
secureSWF is a completely different solution than FGL encryption feature. We built this complementary encryption feature for FGL community to help avoid more thief incidents. It does not use the same technology or techniques as secureSWF.
I just hope their software is better than their grammar.
Interface
SecureSWF is a bit more complicated but makes up for it in options. There are 5 tabs:
Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
Image may be NSFW.Clik here to view.
The fifth one is just a summary of what it did after you hit the big “Protect SWF Files” button. The GUI is pretty much self-explanatory and gives you a fine level of control. Hovering your mouse over any option will bring up a tooltip that further explains what the option does. So far, looks great.
Effectiveness
The real meat of the app is in the renaming, since eventually all SWF files can be cracked open to reveal their code. SecureSWF does a great job in this area. By default it will leave alone most public functions, probably because they’re usually used by other classes, so renaming them inconsistently would break the SWF.
When I protected the SWF files with the default settings, I was able to play my collision demo and Mode (which uses the old version of Flixel). I could not run FlxCollisions though, instead I got back this error: ReferenceError: Error #1056: Cannot create property D on _-9l._-68. Obviously the renaming was set a little too aggressively for it to work (and the “strength” was only at 20% with most advanced options turned off). When I tried to open the working SWFs with the decompiler, I got an access violation and the program crashed.
Overall
Image may be NSFW.
Clik here to view.
secureSWF only offers variable renaming in their Standard and Professional editions ($200 and $400 respectively), leaving it out in the Personal edition ($100). Considering the functionality SWF protectors provide (and how difficult they are to produce) these prices seem too high to me. The Pro edition (the version I’m using) does provide some nice additional features though, such as removing unused code (it happens), literal string encryption, and solid domain locking controls).
SecureSWF provides users with a lot of options and it would take me all day to go through them all. But the point is that secureSWF utilizes true obfuscation by renaming variables, encrypting literal strings (which Flash Player can deal with), and inserting illegal characters that will trip up decompilers… and sometimes the Flash Player too. So it takes some effort to get working, but the point is that it works. But is it good enough to justify the price? Let’s see what irrFuscator provides for its price to compare.
Ambiera irrFuscator
Image may be NSFW.
Clik here to view.
Ambiera comes out of the gate with significant reputation points for having developed irrLicht and related creation tools–quality open source tools for the indie game developer. Ambiera got into the Flash scene when they decided to extend their game tools to the web via the Flash platform with their own 3D engine and creation apps. They figured developers will want to protect their games and, as the irrFuscator author told me via email, the current offerings in that market “sucked”, so he built his own. With this excellent history of software already under their collective belt, I had high hopes for irrFuscator.
Interface
A quick glance at irrFuscator’s interface will bring a sigh a relief, since the layout is dead simple but all the options are there and well-explained.
If you still have trouble figuring out what’s what, the online docs are helpful and there’s even an active forum for it at Ambiera if you’re still having trouble. Very nice.
Effectiveness
irrFuscator sets itself apart by allowing you to rename all variables BEFORE you compile your project, so you can see exactly what it did and, if it messed up somewhere, you can go in and manually fix it before compiling again. This is the best method of obfuscation since you know it works, you know what it does, and you know you can fix it easily with your debugger. ALL classes and variables can be renamed, plus it removes whitespaces–even Vectors were retyped to the renamed classes, and all packages were also renamed (Flash built-ins as well). The resulting code was impossible to read.
I did run into a few problems though. I tried obfuscating my game, which references an SWC, but when I added it to the list, I got an error saying it couldn’t open it. I just removed it and it continued fine. Also, while it does encrypt literal strings (it replaces them with a function call to irrcrpt() to decrypt at runtime, which will impact performance a bit) it can’t encrypt them when they’re inside an Array or similar data structure. Not a big deal, but I was thrown off by that. The other thing is just a small UI annoyance, which is that it uses Windows’ “browse folders” dialog to pick out your SWF (in “SWF File” mode). This dialog doesn’t remember where you last looked and it always starts you back at your computers root, so it takes me a while to drill down to the proper folder, which wastes a lot of time. Those are the only issues I found though, which is saying a lot.
Using the SWF File mode is nice, but it didn’t work for me; I got back this error when trying to run the protected version of FlxCollisions (again): VerifyError: Error #1053: Illegal override of _iq39 in org.flixel.FlxEmitter. Since this also happened with Kindisoft’s secureSWF, there’s something going on in the latest version of Flixel (v2.35) that gives them grief. Both packages give you ways to work around them though with their fine-grained controls. For irrFuscator, you just have to use the Flex Project option. In secureSWF you can just uncheck that file… if you knew which file that was, but there’s no way to find that out. irrFuscator wins that one.
Overall
Image may be NSFW.
Clik here to view.irrFuscator has Standard and Professional editions (~$100 and ~$200 respectively–original prices are in Euros). The difference is that the Pro edition has comment directives, which means you can be extremely precise in telling the app which portions of your code NOT to obfuscate using specially formated comments. This is because code obfuscation sometimes results in worse performance or breaks it completely, depending on the code, so this is a great feature. You decide whether or not the comment directives are worth $100 for your projects. Still, these prices are far more reasonable than Kindisoft’s–you get everything secureSWF does at a quarter of the price. Not bad.
Conclusion
I’m bummed that I couldn’t determine how effective Amayeta was, but maybe some of you will think the fact that it can’t be decompiled yet is good enough. Not for me though, because SWFs will eventually be cracked–we need better protection than that. What I did determine though is that Kindisoft’s secureSWF and Ambiera’s irrFuscator offer true obfuscation for sure and therefore true protection of your code. Assets cannot be encrypted and can always be wrestled out of a SWF, unfortunately, so obfuscation is really a Flash developer’s best weapon.
Overall I’d say irrFuscator takes the cake for being reasonably-priced and offering that Flex Project option which makes it very powerful, yet it still retains simplicity of use through an easy user experience, plus the program itself was fast to load and responsive. The others were written in Java or were otherwise slow to start, so they were a bit sluggish.
That’s it for now, but I will be updating this article later if/when we can determine if Amayeta’s obfuscation methods are valid. Thanks for reading Image may be NSFW.
Clik here to view.
