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.

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.

Back in the Flash Studio Pro days, MDM hired Xtrabass (Jethro Grassie) to make their first OSX-supported software, Zinc 2.0. Jethro disappeared after that and OSX support started to falter with no-one there to support it.

MDM then hired Kevan Harriman as their lead developer (according to a news item on their website), and he worked on the Windows and OSX rewrites which gave way to the now infamous Pandora/Zinc V3. Kevan disappeared from the forums about a year ago and now runs Deep Cove Software (according to DNS records for deepcovesoftware.com), and it’s these guys that have built Inferno for MDM. Inferno, MDM’s newest application, was developed outside of MDM because MDM currently lacks the development capability in-house. For a company that sells software, this is a serious problem, the results of which we are seeing today with Zinc V3 being so bug-ridden.

Anyway, Viper (Matthias Davis) disappeared from the MDM forums over a year ago and his website (fatal-exception.co.uk), which used to be full of Zinc-related posts, has been completely overhauled. I don’t know if Matthias was doing development or just support but that pretty much left Peter and Gambini holding the fort at MDM.

The departures of Jethro, Matthias and Kevan have had a big impact on the level of support at MDM and Gambini himself has been distracted doing stuff for his other venture, Amayeta. With no in-house expertise in the technology it’s not surprising that support sucks and they can’t get bugs fixed in a timely fashion, and with Inferno being developed externally you can bet there will be support issues with that software too.

By all accounts from people that I have spoken to, Gambini has managed to alienate pretty much everyone he’s ever worked with. It will be interesting to see if he can hold onto a decent developer long enough to fix the issues with Zinc V3 once and for all, though his other option is to do what he did with V1 and V2 before it and just ditch the software overnight and launch a new version and charge everyone an “upgrade” fee for continued support.

Think I’m making this up? Check out their forums from about 2 years ago.

Consider yourselves warned.

Send a copy of your Zinc registration email to support@northcode.com and put “Zinc Sucks” as the subject, and they’ll send you a coupon code that will give you a $75 discount on a SWF Studio V3 Professional license.

It’s worth pointing out that I’m not getting any commission or anything else for posting this offer – it’s just the right thing to do since SWF Studio works and Zinc V3 doesn’t. Update: here’s why.

We have currently suspended new Bug Submissions whilst we compile and validate existing entries. Thank you for your patience.

Evidently, the only way MDM is able to reduce their bug count is to prevent people from being able to report them in the first place. Likewise, the only way they’re able to have a forum of satisfied customers is to delete every negative post as it comes in. Let this serve as a warning to anyone thinking about buying anything from MDM.

On the positive side, the entire conversation was saved before it was deleted by Gambini and is provided here for posterity: Page 1, Page 2.

As you can see, Gambini seems to be of the opinion that if a large organisation has been sucked in by his false advertising, the ridiculous bug level of his software is irrelevant. He also seems to believe that unless you have a multi-million selling product that your opinion on software that you’ve paid good money for is worthless. Furthermore, should you dare to ask questions about this, you will be banned.

Is this is a company that you want to support?

I first started using Zinc around 6 years ago, back when it was called Flash Studio Pro (1.9.x). The software was pretty flaky but was good enough for the small projects that I was working on at the time. Soon after though, support for the software vanished as MDM released a new product called Zinc V2 which provided a new GUI and a load of new commands. I upgraded like most of MDM’s users, only to find that Zinc V2 had just as many bugs as FSP and that MDM was just as slow to fix them.

Some time later, support for V2 again dropped off the face of the earth as the company excitedly announced the release of Zinc V3 – a cross-platform application that was built from the ground up, no less. MDM made lots of noise about it being the most stable version of the software yet, thoroughly tested and that it would only be released when it was absolutely bomb-proof thanks to an extensive beta phase. Another thing that I remember from this time was disgruntled customers who had just bought Zinc V2 being told that their product was no longer supported and that if they wanted to move to V3, they’d have to pay an upgrade charge. The V2 forums were also locked, making it difficult for people who didn’t want to “upgrade” to V3 discuss and resolve issues collaboratively. So much for looking after your customers.

Anyway, fast forward two years and here we are. The bugs that are to be fixed in the next version (the 17th for those keeping count) include fixes for such basic functionality as being able to export JPEGs, read and write to the Windows registry, resetting event handlers, broken AS3 support, broken MAC mask support and a load of other things that should have been resolved before launch let alone before the software’s 2nd birthday. There are even bugs on there that were once fixed but have since been re-introduced in later “updates” thanks to the poor level of testing they do over there. A full list of the open bugs is helpfully available on their website here.

I never upgraded to V3 myself. Having seen first-hand how painful it was to come up with workarounds to V2′s bugs after jumping from V1, I decided to sit out the next ride and wait for the inevitable bugs and other issues to be resolved before taking the plunge – yep, despite MDM’s bullish claims of QA this time around. I also didn’t see any major benefits in V3 seeing as I hardly ever need to develop for Macs or Linux-based PCs (just as well as the support for these two OSs is patchy and inconsistent), so I was in fact more than happy to watch from the side-lines until the dust settled. The problem was that the dust never did settle and two years on V3 users are still having to put up with an insane bug count. V2 was bad sometimes, but nowhere near as bad as V3.

Despite not having taken the plunge for V3 myself, I would still visit the forums occasionally, sometimes helping out a newbie or two with some Flash/Zinc related questions and sometimes just watching in amazement as the bug reports continued to come in thick and fast – bug reports for standard functions that showed quite clearly that were was next to no testing going on at MDM between releases. As the bug count continued to rise and MDM continued to clumsily release hit-and-miss updates, I thanked my lucky stars for not having given them any more of my hard-earned cash.

Finally it was the 2nd of December 2009 and I took another look at the forums – hoping that by some miracle V3 was in a usable state by now. What I found in Gambini’s post (that they were “aiming” to fix some of the bugs but couldn’t make any guarantees) just floored me and so I started asking awkward questions and suggested that perhaps a 2-year-old application that had over 70 known bugs is actually a load of rubbish and that hey really needed to sort themselves out. Other users agreed but stopped short of venting their own frustrations as openly as I – surprising really since they had paid good money for V3 while I had not. MDM responded by offering some pretty lame excuses (we’re a small team, there’s lots to do, we’ve had lots of things go wrong this year, blah blah) and totally failed to explain why 2-year-old software that they charge good money for should still be on the shelves with over 70 known bugs.

Rather than admit Zinc’s problems, Gambini (or Jaspal Sohal to give his real name) tried all kinds of tactics to divert attention from the software by – among other things – accusing me of not caring about MDM and being there only to start arguments. While I don’t really care for MDM either way (why would I? And why is that even relevant?), I do care about having access to good software and I do dislike it when honest, hard-working people are ripped off when buying faulty goods.

Anyway, for making my thoughts known, I was banned. I haven’t logged back in to see what they did with my posts, but I was there long enough to see that they deleted some other posts that didn’t reflect too kindly on themselves or their products.

In short, anyone who owns Zinc V3 and is unimpressed with its bugs should be prepared to be banned from the forums if they dare raise their concerns with the administrators. Anyone who is looking to buy some decent (i.e. working) software on the other hand would be wise to seek out some alternatives! The one that I’ve recently started using again is Northcode’s SWF Studio. I had used SWF Studio in the past but was never 100% happy with the script language, but having been forced to search for an alternative to Zinc due to V3′s ridiculous bug count, I found that the latest version of the software (SWF Studio 3) has a brand new scripting language that is much more intuitive – but most importantly it actually works!