Gareth Jones

Company: DCOMsoft
Product: SWF Protector 3
Price: From $39.95

Well, it’s finally here. Nearly three months after Magus released his SWF Decryptor which circumvented both Amayeta’s SWF Encrypt and DCOMsoft’s SWF Protector 2, DCOMsoft has returned with SWF Protector 3. The update was initially promised to be with us within days, so let’s hope this new version is worth the long wait.

First impressions were slightly dampened by the installer’s default install location and icons being labelled “Swf Protector 2″, despite the text and the graphics on the installer claiming that this is in fact “Swf Protector 3″. Clearly whoever compiled the installer didn’t take the time to check the strings in the setup script, which seems a bit slap-dash considering the length of time this thing’s been in development. I manually updated the paths and names and continued with the installation.

Once installed, SWF Protector 3 looks pretty much identical to its predecessor apart from the label in the application’s title bar. What with the above installer issue and the identical application interface, it’s pretty clear that all that’s changed in this version of SWF Protector is the obfuscation engine so that’s where I’ll focus my attention for this review. For any other aspects of the software you might as well check out the review for the previous version.

I decided to take an in-development Learnalot resource (blog) as my test file because I’d actually had trouble with it with SWF Protector 2. Despite working perfectly with Settlers, the second version of SWF Protector broke a single button in this resource which prevented the user from progressing from the first activity. I never did work out the exact reason for this failure, but nevertheless SWF Protector 2 was always adamant that the file had been obfuscated “successfully”. As a workaround I had simply used another obfuscator because I don’t have the time to invest in making one piece of software work when alternatives work by default.

Anyway, I published the resource in question to give me a file of 337kb in size. First I decided to see if SWF Protector 2 was still breaking the resource. Had the file fixed itself in the time that had passed since I last tried SWF Protector 2? No, it hadn’t and the button in question was once again broken and the file was now 464kb in size.

I republished the file and this time obfuscated it with SWF Protector 3. The new file was 424kb in size, which is exactly 40kb smaller than the output from SWF Protector 2 – impressive! I ran the SWF to see if the button in question was now working, and I’m happy to report that yes it was!

As is always the case with an arms race the winning side depends purely on the time-frame in which you make your analysis. It could be just a matter of time before Magus (or someone else) releases a decryptor that undoes SWF Protector 3′s work, and then it would just be a matter of time before SWF Protector 3 was updated once more. As such, being drawn into such an argument is pretty futile so for now, I’ll just confirm that yes it protects against today’s version of SWF Decryptor.

With everything else in the application being identical to the previous version, there’s not much else to say other than to perhaps ask, where are the new features, DCOMsoft? Over two months ago in a comment over on Magus’ blog, a beleaguered Alex Chevalier did all he could to reassure the Flash community that a new version of SWF Protector was already in development a week before Magus released his tool, complete with “new algorithms and features” that was going to be out as soon as the testing process was over. Three months on, we certainly have new algorithms but where are the new features? We have support for Flash 10, but that’s it. After three months of hype I must admit that I was expecting a little more than Flash 10 support.

Nevertheless, any over-hyping (and anticlimactic) issues are irrelevant when it comes to reviewing the software as it is, and as this software is an improvement on what came before it (albeit an evolution rather than a revolution), I’ve got to mark it accordingly. The lack of any new features means there’s just as much distance between SWF Protector and Kindisoft’s SecureSWF as there was before, but the obfuscation algorithm in SWF Protector 3 is clearly a vast improvement on its predecessor both in terms of reliability and efficiency, and the official support for Flash 10 is of course a bonus for those working with the very latest plugin.

8.5/10

Company: Kindisoft
Product: SecureSWF
Price: From $99

Kindisoft’s SecureSWF is the latest Flash obfuscator to go under the microscope (SWF Protector 2 and SWF Encrypt are reviewed elsewhere), so as the most expensive of the three (when considering the luxury versions), how does it stack up in terms of interface, functions, usability and stability?

Having downloaded the .zip file from the website, the first thing you notice is that there’s no installer. SecureSWF comes in a .zip file ready to extract and use without installation which has both pros and cons, though the benefits do outweigh the drawbacks. You can stick SecureSWF straight onto a USB drive like a portable app without worrying about whether or not it will run (assuming Java VM 1.5 is installed on the target machine), though if you believe in consistency you’ll have to manually stick the folder in your Program Files directory and create the relevant shortcuts in your Start Menu or favourite application launcher. As I said, the benefits do outweigh the drawbacks and I’m not suggesting that this is an issue – it’s just an observation.

So, after settling on where you’re going to run SecureSWF from, the next thing you notice after running the application is the number of options available. Compared to the other two solutions, there is a lot going on here (even the entry level SecureSWF has more options than both SWF Encrypt and SWC Encrypt combined), and it does seem a little daunting at first, but you quickly come to realise that it’s actually not that bad.

There are five tabs along the top – four of which contain settings and the last one is a status summary page. The fourth tab is just a rules page that overrides some of the options on the previous tabs, so in reality you have just three options tabs to familiarise yourself with rather than the initially anticipated five.

The first tab is the lightest on the options with just a SWF selection area, a list of presets to choose from and somewhere to specify the output location. You can select multiple files to import from the file browser (SWF, SWC and AIR formats – the others can only do SWF), though unfortunately there is no recursive import. There are five presets to choose from ranging from most- to least- aggressive, and a custom option should you want to tweak any of the presets yourself.

The second tab gets into more detail, allowing you to completely customise the level to which identifiers are renamed. Everything including local identifiers, labels, instance names, global variables and class members can be renamed to your exact requirements, and there’s even a tree structure that allows you to go in and select individual values. While this is great for offering the maximum level of obfuscation and the ability to make slight adjustments in the case of too many changes causing problems, I probably wouldn’t spend too much time here as it’s far easier to just let the presets take care of it all. Still, if I was in a situation where the maximum protection was available to me apart from one little identifier somewhere causing a problem, it’s nice to know that I can go in there and make the necessary change without having to sacrifice the security of the rest of the SWF.

The third tab offers code transformation, obfuscation, encrypted domain locking, SWF optimisation and literal strings encryption. The domain locking worked as expected, preventing my SWF from running anywhere other than this website and also from being run locally on my computer. Because I can only tell how well the other features are working by running them through a deobfuscator, I’m reserving those for another article that I’m working on which will be coming shortly.

Obfuscating a test SWF of 1,115kb, SecureSWF delivered a file of 1,156kb on maximum settings and 1,111kb on minimum settings – yes, it was actually smaller than the original. Obfuscation time was quick and on par with the others, and I experienced no crashes or freezes from the software no matter how hard I tried.

SecureSWF is a feature-packed obfuscator that not only works on Flash SWF files, but also SWC and AIR files as well. As the only obfuscator that works with these alternate file types, SecureSWF is really your only option when working with these formats. With regards to SWF files, the level of detail with which SecureSWF allows you to customise its obfuscation is significantly higher than that of SWF Protector 2, and an order of magnitude higher than that of SWF Encrypt.

One issue that always seems to come up in SecureSWF reviews is price. Yes, the fully-fledged bells-and-whistles version costs $400 which is significantly higher than either SWF Protector 2 or SWF Encrypt. However, the obfuscating methods, options and features available in this package – not to mention the fact that it will also protect your Flash components and AIR files – mean that you are getting a lot more here so naturally the cost is going to reflect that. I don’t really want to start comparing SecureSWF with its competitors here because this is supposed to be a review – not a comparison – but when one of the factors that could potentially put people off SecureSWF is its price when compared to its competitors, it’s difficult not to get sucked into such a comparison.

The bottom line is that SecureSWF starts at just $99, which is $151 less than SWF Encrypt and SWC Encrypt combined, but it offers more features than those two and does everything better. In light of that, even if price is an issue for you then SecureSWF blows SWF Encrypt out of the water having beaten it on options, features and price. Where things start to get interesting is when you compare SecureSWF to DComSoft’s $39.95 SWF Protector 2, but for that you’ll have to wait for my Versus feature which is coming soon.

In its own right, SecureSWF is a very impressive tool that is bursting with options and features. Due to the extreme levels of flexibility, it should be possible to tune every possible SWF file so that it’s protected as securely as possible without breaking any functionality. The fact that it allows obfuscation of everything from function names to labels and global variables to class members means that SWF files will be that much closer to being totally secure.

Out of 10, the usability and features on offer here have to command top marks, but I think the price of the professional edition could possibly push the application slightly out of reach for some lone developers. Yes, the Personal Lite Edition is only $99 but if you’re buying SecureSWF then you want the best version. Bearing the price of the professional edition in mind and the fact that a portion of its features are found in a product that only costs 1/10th as much, I’ve got to take a mark off. However, the wealth of additional options and features that you get for your money, their importance and the extra protection they bring to your work – plus the additional format support of course – mean that it’s just a single mark.

9/10

Coming soon: A review of how these SWF protectors stack up against SWF decryption tools.

Company: DCOMsoft
Product: SWF Protector 2
Price: From $39.95

About a week ago, DCOMsoft emailed me to ask if I’d be interested in trying out their SWF Protector 2 product and posting my thoughts in exchange for a licence. Always on the lookout for new software that’s better than what I currently use, I said yes. I’d like to stress though that in no way does providing a license obtain a favourable review for any old product – I always approach a product objectively and will post both positive and negative findings whether the review is commissioned or not.

So, on with the review. On installing the application it came to time to register it. I copied and pasted in the serial and hit the Enter button without noticing that I hadn’t selected the serial number properly before copying and had missed off the last digit. The little registration window closed and gave me no feedback, so it wasn’t until I tried to run the application again and found that it wasn’t yet registered that I noticed that the registration had failed. I tried again, this time re-selecting the serial number and making sure I had it all in there, and it then gave me a message confirming registration. For instances where a mistake like this can happen, it would be worth having a message to say “Registration failed” or “Incomplete serial number”, but that’s a minor gripe.

Once registered, the application’s interface is very clean and quite minimalist. The first thing I noticed – and with some excitement – was an “Add folder recursively” button which, I’m pleased to say, works a treat. The application adds all of the SWFs contained within a parent and all child folders, tells you their protection status and offers the ability to open each one if you need to make sure you’re looking at the right file here.

As opposed to SWF Encrypt which shows you all the SWFs in a directory and asks you to select all of the ones you want to obfuscate, SWF Protector 2 assumes you’ll want to protect everything by giving you just one “Protect all” button. This makes sense, because if you didn’t want to protect your SWFs then chances are you wouldn’t be using the application in the first place. If there are any SWFs in there that you don’t want to protect however, you can simply remove them individually from the list before hitting the “Protect all” button. Alternatively, if you do only want to protect a single file, you can right-click on that file and select “Protect one file” from the menu.

Having had SWF Encrypt crash on me a few times after trying to obfuscate a file that was currently open inside the Flash IDE, I was curious to see what SWF Protector would do in this case. It didn’t disappoint, prompting me with a message stating that it could not overwrite the file – a much more elegant solution that simply crashing unexpectedly!

When my target file wasn’t open inside Flash’s IDE, SWF Protector 2 further impressed by renaming the original file “example_original.swf” and creating an obfuscated version with the original file’s name. This eliminates the issue I outlined in SWF Encrypt’s case where you either have to rename all your files manually or change all of your file links on your server to take into account the different name of the protected file. Bonus.

I also wanted to see what SWF Protector 2 did when revisiting a previous project – would it remember the last location or would I have to navigate to the project all over again? It actually remembered my previous location, and did so even when I closed the application without protecting any files. Excellent.

Also available at the top of the screen is an Advanced option which lets you configure the level of obfuscation – either on a per-class basis or you can set the level for the entire file. I took an unprotected SWF that was 518kb in size and ran it through the obfuscator at minimum settings and the output was also 518kb. I ran the same file again at maximum settings and this time the output came out at 555kb, so obviously the level of protection is such that it can make anywhere between 0% and 10% difference to the file-size – exactly how much protection you apply is up to you, so you can balance protection against file-size depending on the exact needs of your specific project. This is another feature that is missing from SWF Encrypt.

One bug that I did notice in SWF Protector 2 though was that after protecting a file in Advanced mode, the “Protect all” button would not become re-enabled for me to run another pass despite me selecting a new, unprotected file. To get the button back I either had to switch to Simple mode or restart the application and switch back to Advanced mode. This isn’t a deal-breaker, as you won’t be re-protecting files with different levels of security one after the other very often (if at all), and I only noticed it because of the test I was running. However, to get top marks an application does need to be bug-free, so I’ll have to take this and the failure to notify on a failed registration into account when coming up with a score.

The fact that SWF Protector 2 not only does what it says on the tin but does so with much more thought towards usability and thus efficiency of use does make it a better product than SWF Encrypt. I’m sure DCOMsoft will endeavour to resolve the two small issues I experienced with the application as soon as they read this post, whereas from past experience (here, here and here) I know that Amayeta is unlikely to even care about SWF Encrypt’s bugs, let alone fix them. Being a better product is one thing, but being a better product that costs only a third of Amayeta’s price (the personal license costs just £25, though you’ll probably want the business license at £39 to be able to use it commercially) is just great and easily makes it a recommended product.

8/10

Coming soon: A review of how these SWF protectors stack up against SWF decryption tools.

Company: Amayeta
Product: SWF Encrypt 6.0
Price: £75 / $145

I’ve used Amayeta’s SWF Encrypt for a couple of years now I guess, since version 5.

Coincidentally, Amayeta is owned by the same guy who owns MDM (Jaspal Sohal) – the guys behind Zinc. There have been a fair few posts on this blog about Zinc, its poor quality and its ridiculous bug count, so why would I be using SWF Encrypt to obfuscate my Flash files? Well, it does what it’s supposed to do and does so without much fuss. Granted, that it does so without requiring multiple support requests like Zinc is probably more down to the fact that it’s such a simple application than anything else, but as an end-user I don’t care about that – I just want an application that works.

Are there any problems with SWF Encrypt? Yes, there are a few, but as I said the application is so simple there aren’t many ways in which it can go wrong. All it needs to do is open a SWF, obfuscate it and output the result as a new file.

So, with such a simple list of requirements, what’s wrong? Well, if you select a SWF that you already have open within the Flash IDE and try to obfuscate it, the application actually crashes. There’s no elegant message informing you that you need to close the target SWF first – the application simply quits without warning. I suppose it wouldn’t be a Jaspal Sohal application if it didn’t unexpectedly crash somewhere along the line, but even for one of his products this is surprising. I mean, surely an application that is designed to open one file and save another should be able to cope with files that are locked, have read-only permissions or different user permissions etc? Apparently not. Having said that, it hasn’t crashed while working on any files that aren’t already open elsewhere so I suppose I should count myself lucky here.

The other two issues are less significant but still a little irritating. When you obfuscate a SWF, the application creates a new SWF with a new name, such as “example_secure.swf”. This is fine in theory, but in practice after buying such an application you’ll want to go through your back-catalogue of work and apply some protection to all your previous files – ideally done so that you can just upload the new files to your web server without any fuss. Having a file with a new name like this means you either need to rename the file (making sure to either manually rename or delete the original first) or update all of your file name references everywhere else. This gets to be a pain in the arse when you have a large number of SWFs to do. There’s also no recursive feature so you’ll have to navigate into each and every folder manually to select each file individually – again, this can be a pain in the arse on larger projects.

The last irritation is that the application doesn’t seem to remember UNC directories and reverts to a default directory every time you open it, forcing you to navigate back down a long UNC tree structure every time you want to republish that one SWF that you keep having to update on client requests. There is a “favourite folder” option available, but using this just brings up the SWFs available in that particular folder and doesn’t update the navigation tree, so if you want to go into a folder that’s one up or one down from there (such as in a medium/large-sized project) it’s of no help.

SWF Encrypt offers no flexibility in terms of the obfuscation it applies. Perhaps this isn’t really a requirement if the obfuscation technique is solid enough, but as different techniques can have different effects on the file-size of the output, it would be nice to be able to tweak these settings on projects where minimal file sizes are important.

Technically SWF Encrypt does what it claims to do – it obfuscates SWF files – but when there are alternatives available that also do this and actually put some effort into being more usable, this isn’t really enough – especially when SWF Encrypt retails for considerably more than its competitors. SWF Encrypt costs £75 for a single license, whereas some of its competitors cost less than half of that and offer the same – if not more – features.

Update: Since writing this review I’ve been presented with alternative products from different vendors, and as a result I feel that I need to adjust SWF Encrypt’s score to better reflect the difference between it and its competitors.

4/10

Coming soon: A review of how these SWF protectors stack up against SWF decryption tools.

Following on from the previous post about protecting your code with obfuscation, an obvious statement would be that the best way to protect your work is to ensure that no-one gets a copy of it! However once you put your work online, anyone with a cable or broadband connection could download it and make copies of it. Is the only option then to stop making your work available for download? Of course such drastic measures would prevent anyone from seeing your work at all and make developing a product totally pointless, but what if there was a compromise between the two? What if there could be a difference between what you gave people and what they actually saw on-screen when they ran that file?

Having a “key” file (which I’ll refer to as the Key) to access a “resource” file (which I’ll refer to as the Resource) centrally also means only ever having one location for that Resource, and so if you were to spot a bug in your Resource or if you wanted to add a feature, you’d only have to replace a single file for that change to permeate instantly throughout the internet.

Since your Resource would only ever be run centrally, this also opens the door for tracking. You’d be able to see who was accessing your resource and how often. If the Key was to provide information on where it was being run from you’d also be able to control the locations that had access to that Resource, and in effect you’d be making an “intelligent” Key that only worked for certain people.

All of this serves as the foundation for a piece of software that I have developed and called the Game Wrapper. Although called the Game Wrapper because I wanted to use it to serve my games to different websites, the same technology would actually work with any type of resource – games, animations, elearning etc.

I use Game Wrapper to serve games to various online gaming websites, so I know that every site has the same version of the game and if I ever want to add or change something in any of my games, I make that change once and upload the new file to my server and that new version instantly becomes the version that everyone is playing.

Game Wrapper also allows me to specify whether games are allowed to be played locally on a user’s machine or online only. If online only, I can also specify which websites are allowed to play it and this ensures that no-one steals the game to use it without my permission. If the game is ever run from a site that hasn’t been added to the Allowed list, I get an email that tells me which game has been run illegally and from which website.

I can also serve adverts before the game starts to load or I can serve the game right away – whatever’s best for any particular game.

Developers will know that when a Flash file downloads another Flash file, the downloaded file is stored in “Temporary Internet Files” so the scenario with which I opened the post about ensuring that users don’t ever get access to the Resource isn’t strictly true, but despite physically being on that user’s machine the file will only run if it’s run from the host website, only if it’s run from a Key, and only if the user is on the Allowed list.

Both the Keys and the Resources are also run through SWF Encrypt for an added layer of security.

Due to the unsecure nature of Flash, I’ve always been wary of having my work decompiled and its code re-used without my knowledge or consent. By default Flash offers very poor protection against this. While it’s undoubtedly impossible to prevent this from happening completely (despite various security software vendors’ claims), you can make the process so difficult that most people will give up trying.

Of course, not all Flash work will be a target to such piracy but games and elearning products can be targets because the cost and time of developing these resources legitimately can be quite high.

An easy way to protect your work against decompiling is to run your work through an obfuscator. I use Amayeta’s SWF Encrypt, and while a file that has been obfuscated in this way is larger in terms of file-size, the protection that this process offers your code is well worth it. Obfuscating your file like this makes the code almost impossible for a human reader to know what’s going on inside it, much less be able to steal it or change it for their own needs. In a decompiler the code will appear to be nothing more than a load of gibberish, and in fact some decompilers will be tripped up by the obfuscated file and won’t even open it at all.