Gareth Jones

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.