Gareth Jones

After upgrading to Flash player 11.1 this week (11.1.102.55 to be exact) I noticed that a number of my games and applications were no longer displaying correctly. The screen would either be blank on startup or after a couple of button presses, and after that point right-clicking on the stage would present me with a “movie not loaded” message and not much else.

At first I thought that Adobe had simply dropped the ball again. It wouldn’t be the first time, let’s be honest.

I considered reverting back to a previous player version but of course that wouldn’t solve the problem for everyone else who is using my applications so I decided instead to investigate.

One of the applications that was affected was a personalised video messenger I’ve just finished for a major UK greetings card company. The strange thing was that the application would work on some screens when it was in normal mode, but not at all when it was in debug mode. The only difference between debug mode and normal mode was that for the benefit of the non-technical staff at the card company the application would output its traces to a text field at the bottom of the screen. No other logic was different so naturally my first thought was that it was related to dynamic text fields or maybe an embedded font issue.

After some messing around it turned out that it wasn’t the text field or the embedded font at all. In fact in turns out that Flash player 11.1 is happy with all of that stuff: until you run the SWF through SWF Protector 3. At that point the SWF again either refuses to work at all or refuses to work on screens that use dynamic text fields. For every Flash player version prior to 11.1 the SWF works fine so I can only assume that either there is a bug in 11.1 that SWF Protector 3 exposes or Adobe has deliberately changed something that happens to trip up this particular obfuscator.

So, I’ve had to consign SWF Protector 3 to the bin and am now using Kindi SecureSWF which, although technically a more secure product isn’t as user-friendly as there is no batch import of SWFs and no option to have the protected file over-write the original. I’m actually hoping the next Flash player resumes its compatibility with SWF Protector 3, but with SWF Protector 4 due out for PC any minute now there is also hope that DCOMsoft can resolve the problem themselves.

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

Following my recent re-review of Amayeta’s SWF Encrypt 6.0, here’s another look at SWF Protector 3 from DCOMsoft.

The latest version of the software is 3.0.1.191 which means it hasn’t changed at all for over a year, so it will be interesting to see if it still offers protection against decompilers that are advancing all the time.

First the interface. In the default simple mode this is clean and quite minimalist. You have a button to add individual files, a button to add folders and a button to recursively add folders which is a nice feature that can save a lot of time on larger projects. After adding your files to the list you can either protect them individually or all in one go.

A properties window on the right gives you rudimentary information on each file while a log window at the bottom keeps you informed of progress.

When protecting a file the program will attempt to use default obfuscation settings which it will automatically wind down if there are any problems so that the resulting file always works. If a file does ever break during the process there’s an advanced mode that allows you to tweak the obfuscation applied to each function individually, though to be honest I have never needed this as the automatic settings have never broken a file.

Obfuscated files are given the original file’s name while the original file is renamed which is great news if you’re obfuscating large projects as it means you won’t have to go round renaming files or updating references afterwards. This was something I highlighted in its predecessor as a major advantage over SWF Encrypt last year, before Amayeta shamelessly copied the feature.

The program does occasionally crash and when it does it will be one of two ways – either immediately after loading up despite no interaction from yourself or immediately after you add a file to the obfuscation list. Resolving the issue in both instances is a simple case of closing the program and running it again, but of course such a crash is an annoyance that can’t really be justified in this day and age of tried and tested OSes, drivers, middleware etc.

So, how does it perform when it comes to obfuscating? For this test I again used Sothink’s SWF Decompiler (version 640, build 3450) and Burak’s ASV 2011 (version 2011/08).

First Sothink’s SWF Decompiler. This tool opened both SWFs without crashing or throwing up any error messages, but the AS it gave me was all obfuscated. In both AS3 and AS2 it seemed to only show me the code as SWF Protector 3 wanted it to be seen, which is what we want from an obfuscator really. When I attempted to rebuild the AS3 FLAs the tool crashed, and while the AS2 files did yield FLAs they was completely worthless as none of the code was intact and the library assets were a mess. In short, all I could get from SWF Decompiler was the audio, fonts and graphics, but none of that is realistically going to help someone rip off your Flash project.

Burak’s ASV fared much better with AS3, but slightly worse with AS2. It was completely thrown by the AS2 files and gave me nothing but a long list of error messages. I couldn’t browse the file properly, let alone rebuild an FLA. This implies that the AS2 obfuscation in SWF Protector 3 is significantly more effective than that found in Amayeta’s SWF Encrypt 6. AS2 is traditionally easier to obfuscate than AS3 though, so how did an AS3 file compare? AS3 was a different story as ASV was not only able to open the file but it also showed me all of the code in original, unobfuscated form. It wasn’t quite able to get all the way through to rebuilding an FLA as the FLA that it exported would not compile into a functioning SWF, but with the asset library intact and the original code all visible in ASV’s code browser, it wouldn’t take too long for a determined developer to put together a working rip-off of your Flash project.

An interesting observation was that the test AS3 SWF increased in size slightly after it was run through ASV, but this didn’t seem to affect the file’s running in any way. I do wonder what extra data ASV injected into the file though.

To conclude, if your SWF files are AS2 then SWF Protector 3 looks like an excellent purchase. The two most well-known decompilers on the market couldn’t even get close to decompiling the files, and this tool costs less than half of what Amayeta charges for its ineffective SWF Encrypt software. If you work in AS3 however it’s clear that although SWF Protector 3 will still protect your work against Sothink’s SWF Decompiler, Burak’s ASV almost has it fully cracked. Indeed, a developer with some time on his/her hands would have no trouble in rebuilding your AS3 project from the exported FLA and unobfuscated code, which means that for AS3 developers the search for the perfect obfuscator continues.

UPDATE: It appears that SWF Protector 3 isn’t compatible with Flash player version 11.1.102.55 and it’s not clear if compatibility will return with a future release of the player. SWF Protector 4 is already out for Mac so it can’t be long before the PC version is made available so hopefully the issue will be resolved soon. Alternatively if you need a Flash obfuscator for PC today then you Kindi SecureSWF is your best bet.

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.

I noticed a lot of traffic coming from the SWF Decrypt blog so I decided to take a look and see what was going on over there. It appears that Magus, the blog’s admin and author of the above named software has gotten pretty excited about DComSoft and Eltima being the same company. The reason for this is supposedly because both companies sell competing software – a SWF obfuscator and a SWF deobfuscator respectively, though an additional reason I think would be that for a few weeks now Magus has had a bee in his bonnet having broken DComSoft’s SWF protection and he no doubt sees this as a way of sticking the boot in.

To be honest though I wouldn’t at all be surprised if they were the same company:

• From correspondence I’ve had with reps from both companies, English is not their first language despite the USA being their registered addresses.
• When reviews of software from both companies go up on this blog, it’s Ukrainian traffic that comes for a look in both cases – not American.
• In all the correspondence I’ve had with these reps, their writing style is very similar.
• Products from both companies use the same activation tool and, as it would seem, the same EULA.
• Lastly, Eltima contacted me to offer me a review sample the *same day* that the DComSoft SWF Protector 2 review went up.

The thing is, who cares if they are the same company? Hundreds (if not thousands) of companies all around the world sell products that compete against each other – it’s known as a Multibrand Strategy or Multiple Branding and is defined below:

Marketing of two or more mutually competing products under different brand names by the same company. The motive may be that the company wishes to create internal competition to promote efficiency, or to differentiate its offering to different market segments, or to get maximum mileage out of established brands that it has acquired.

Source: http://www.brandchannel.com

One example would be BT, the UK’s telecommunications giant offering one phone number for recipients to tell who just called (1471), and another number to prevent this service from working if the caller doesn’t want the recipient to know who they are (141). Another would be that the same cosmetic companies offer both nail varnish and nail varnish remover. This really isn’t anything new.

In fact, you could even argue that a company that makes one product would be the best choice for a competing product – after all, the best lock-pickers are all lock-smiths.

Perhaps DComSoft’s/Eltima’s mistake is making themselves look suspicious by denying the link – or at least failing to acknowledge it – when accepting the link would have been no big deal to anyone with even a basic understanding of the markets.

Finally, it’s worth pointing out that however unlikely it is that this is all coincidental, it’s not an absolute impossibility that these two companies are independent. While we can all speculate I think we should wait to hear from a rep from either company before making such conclusions.

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.