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: Amayeta
Product: SWF Encrypt 6.0
Version tested: 6.0.10
Price: £89 / $145

Since so much of this site’s traffic is from people who are looking for Flash-related obfuscating and decompiling, I decided to revisit all of the products I reviewed last year and once again put them all under the microscope in order to ensure that the information contained within the reviews is still accurate.

First, some background on Amayeta is that it’s owned by Jaspal Sohal, the same guy that owns MDM which makes Zinc. Zinc is a Flash projector that has received a lot of negative press mostly relating to quality and support problems, and with that in mind I must admit I wasn’t expecting much from SWF Encrypt but nevertheless have reviewed the latest build as objectively as possible.

Loading it up

SWF Encrypt 6 takes about 5 seconds to load up on my hefty PC which is quite surprising considering the minimalist interface. The layout of the UI is simple and functional, with all options within easy reach. The window is split into three main areas. A (somewhat clumsy) file browser takes up around a third of the space on the left, a list of SWF files within a given directory takes up the top half of the 2/3 on the right, and settings/properties/logs take up the bottom right 1/3. I’ve attached a screenshot.

The good news

The niggles from last year’s review version are all gone. You can customise your obfuscation preferences to either favour file-size or obfuscation strength, you can over-write the original file with the obfuscated file and two bugs that I discovered last year have also been fixed.

Now the bad news

Unfortunately the removal of last year’s niggles are made pretty much redundant by the fact that what is currently the latest version of SWF Encrypt 6 doesn’t work. I obfuscated some test files using the application’s default (recommended) settings and this is what I found:

Sothink’s SWF Decompiler (version 635, build 3363) was able to rebuild the source FLA and give me access to all of the file’s assets, though the code itself was still obfuscated. Burak’s ASV 2011 (version 2011/07) on the other hand was able to rebuild the FLA along with all of its assets and source code – and it even generated the original class structure for me as well. All I had to do was hit publish and I had a SWF that was identical to the original.

Even changing two out of the three advanced settings (encrypt names advanced and encrypt namespace) failed to stop ASV – and bear in mind that the more of these kinds of settings you enable, the more likely you are to experience problems when you have multiple SWFs working together.

Finally I enabled the third setting, encrypt resources, which did manage to stop ASV because it completely broke the SWF. With this setting enabled, all I got from running the protected SWF was a flashing blue box in the top left with some white symbols inside it. I also noticed that the original file’s size had gone up by 22kb – despite overwrite original filename being set to false – and it no longer worked. SWF Encrypt insisted that the original file had not been touched, yet it had clearly added 22kb of data to it and in doing so had broken that file as well.

Conclusions

So, what we have in SWF Encrypt 6 is a SWF obfuscator that fails to protect your SWFs against one of the best-known SWF decompilers out there on all but the very highest setting, but on that setting it completely breaks your SWF files and even breaks your originals.

Clearly, you’re better off saving your £89 and uploading unprotected files than buying this software from Amayeta. Perhaps the latest version of SWF Protector 3 – at less than half the price – can help? I’ll have a re-review of that up soon.

Company: Eltima Software
Product: Flash Optimizer
Price: From $99.95

I’ve been given a few more applications to review over the next couple of weeks, and the first one is Eltima’s Flash Optimizer. Eltima claim that this is the “most powerful SWF compressor available today” and that it is possible to reduce a file’s size by “up to 60-70%” without any loss of quality. Bold claims indeed. So how did it perform when tested?

First, the interface. The application loads up to reveal an interface that is made less daunting to new users by including easy-to-follow numbered instructions within the interface itself:

1. Select the Flash movie to compress.
2. Select the output destination.
3. Enter the desired output name (appending “_opt” to the name is the default behaviour).
4. Select your compression level (and tailor it to your specific needs if required).
5. Click on Preview or Compress.

When you import your Flash movie the interface changes to give you a preview window and some file properties, which include a breakdown of the file’s assets and the percentage of the total file size that each is responsible for. You can then make your compression choice and preview the results before exporting the final version as a new SWF. One thing that I noticed here (thanks to the game’s repetitive title screen music that quickly gets annoying), is that it’s sadly not possible to turn this preview off and the only escape from the audio was to turn down my computer’s volume. I’d recommend either being able to disable the preview, or at least be able to mute the audio for such cases.

Anyway, underneath the preview window is a list of presets (“best”, “good”, “basic”, “medium” and “sprite”) to choose from, which all affect specific optimisation options differently and to a different degree. The “best”/”good”/”basic” settings suggest a sliding scale from most- to least aggressive, so I thought it was odd that the next setting after “basic” was “medium”. However, while “basic” does turn some of the compression settings down a little from “medium” (and disables others completely), it also increases some of the other compression options and so it probably wouldn’t be accurate to suggest that “basic” is less aggressive than “medium” in all cases – it’s just different. I suppose you need to play with each option to see which is best for you and your particular project, but that’s obviously why there’s a preview window included.

So, how did Flash Optimizer perform? For the test I used Santa’s Parcel Drop, a game that Quak Multimedia was commissioned to develop a few years back. The game features jpeg, PNG and vector graphics, along with dynamic and static text and embedded audio – so a pretty good all-round test subject.

First, here are the file sizes of each of the games published, starting with the original game and then each unmodified preset:

Original game: 680kb
Best: 244kb
Good: 339kb
Basic: 668kb
Medium: 531kb
Sprite: 582kb

Unfortunately each of the presets attempted to compress fonts for me, and as you’ll see in the screenshots this resulted in the HUD totally disappearing from the game which pretty much broke it. I disabled the compression of fonts and for each preset the file size went up around 10kb. It’s worth noting that there are separate tick-boxes and sliders for pretty much every aspect of a SWF that can be compressed, so if you do find something looks unsatisfactory in your SWF after compression you can either scale back the level of compression for that aspect or disable it entirely.

You’ll also see from the screenshots however that some of the more aggressive settings were quite unkind to the jpeg images. They became incredibly blocky, and although this look can be quite fetching (Darwinia, 3D Dot Game Heroes etc), I don’t think that it’s intentional in this case. The vector graphics fared much better, but again I couldn’t be too aggressive with the settings if I wanted to maintain an appreciable level of detail.

The only compressed version of the game that didn’t distort the title screen’s buttons was the “best” setting, which was surprising as I would have assumed this to be the most aggressive from both the way it compressed the jpeg background and its name. I could see from the application that although aggressive in several other respects, “best” doesn’t attempt to delete any unnecessary shapes and morphs whereas the others do.

Even the “basic” preset distorted the title screen buttons (notice the upper left and lower right corners in particular) and the in-game plane and houses (the white lines on the plane’s wing and the window frames of the houses), yet when the fonts were included for the sake of the HUD it only saved me 2kb from the original game.

At this point I wondered if Santa’s Parcel Drop was just being particularly unfriendly to this compressor. I tried Name that Note which is again a mix of jpeg, PNG and vector graphics in the hope of seeing better performance. The results were the same – unusable assets from the most aggressive settings, and assets that had minor but noticeable imperfections on the less aggressive settings but no significant saving in terms of SWF file size.

One thing I did spot that could be useful was a “force to jpeg” option for images, and this could shave a few kb off a file when used properly but only on PNGs that don’t use the alpha channel which, if your graphic designer is doing his/her job properly will already have been done in the FLA anyway.

Due to the nature of compressors detail is going to be lost somewhere along the line no matter what you do, but when detail is so blatantly sacrificed for the sake of a few kb it’s hard to recommend as a process. Some SWFs will perform better of course, with some vectors in particular lending themselves to the compression process more favourably than others (these SWFs tend to be the kind used as examples on compression product websites to show the benefits of using the product), but in the real world such SWFs are few and far between and most of us work with vectors, jpegs, PNGs and even bitmaps.

There is the matter of audio, which obviously isn’t apparent here because the results are presented as static images but there was a saving in terms of file-size there – but again at the cost of quality and as I had already set the mp3 to the bit-rate that I felt was a fair trade-off between quality and size, I didn’t have any room to play with here either.

Sadly, Eltima’s claims that files could be reduced in file size by 60-70% without any loss of quality isn’t even within sight on Santa’s Parcel Drop, let alone within reach.

I haven’t used a SWF compressor since Optimaze! (long since dead, last updated in 2002) back in the Flash 5 days, so I really wanted to like Flash Optimizer and hoped it would be the answer to squeezing a few more kb out of my existing SWFs. Based on the results from Santa’s Parcel Drop however, they just aren’t there to be squeezed. Since the days of Flash 5, Flash’s compression has been tweaked and tightened to the nth degree and as long as you don’t do anything stupid like embed PNG files that are several times larger than they need to be, or embed simple sound effects at 320kbps, a published SWF’s size is already quite minimal.

The extreme loss of quality on the aggressive settings and the negligible file size savings of the less aggressive settings mean that in this case at least, compressing a SWF further simply wasn’t worth the time it took to do so.

It’s difficult to come up with a score for this product because the problem here isn’t so much with the product itself but with what it’s trying to do. The application itself seems very well done, very polished and offers a lot more options and settings than Optimaze! ever did, and yet it’s unlikely that I’d use it on any of my SWFs because I suppose there just doesn’t appear to be any fat to trim in the first place. In trying to cut out some of the non-existent amounts of fat in my SWF, Flash Optimizer is cutting out some legitimate meat. As such, Flash Optimizer seems to be a solution without a problem.

Giving this application a low score feels like giving a professional cleaner a low score for not finding much dirt in one of Intel’s semiconductor labs – justified if I’m marking on productivity, but unfair because there just isn’t anything there to find. In the end though, I have to mark Flash Optimizer not on the quality of its interface or the high level of customisable options, but on the usefulness of the product, its importance in the development cycle and its cost, and for this reason…

2/10

Although it’s no secret that Amayeta and MDM are both owned by Jaspal Sohal (aka Gambini), I had until recently believed that Amayeta’s customer support was better than MDM’s. It wasn’t so much that Amayeta’s was especially good – after all, as I mentioned in the SWF Encrypt review their software is so simple that there isn’t really much that can go wrong (and yet the review still referenced a critical bug and two annoyances), but compared to the trainwreck that is MDM’s customer support, it had to be better. Right?

Jay Charles, a programmer from Virginia in the US doesn’t think so.

He bought and paid for Amayeta’s SWF Encrypt and was taken to a download page that didn’t work. His emails to customer support went unanswered, so he posted on the MDM support forums instead where he did get a reply – and was told to email support! A full six days later – after several progressively angry messages, he finally got his software.

A copy of the discussion has been saved here, just in case Jaspal goes on another thread-deletion spree. Please note that I have altered the image to take out my new username (my original account was banned for pointing out problems with MDM’s Zinc software), but everything else is 100% genuine.

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

Note: This review is for an outdated product. For a review of SWF Protector 3, see here.

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. I’d like to stress 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.

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.