Mercury supports a great number of interactive and customisable elements that come together to create a rich learning environment for learners. Video, audio, animations, drag and drops, click and reveals, images, quizzes and assessments are all on offer.

Included in the price are 12 months’ updates and enhancements as and when they are made available.

Interested? Head over to madewithmercury.com for a live demo.

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

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.

The word “obfuscate”, as defined by Chambers Free English Dictionary, is:

1 to darken or obscure something.
2 to obscure something or make it difficult to understand.
3 to bewilder or confuse someone.

So, keeping with the theme, what’s the most bewildering or confusing thing that’s ever happened to you, or that you have ever inflicted on someone else? It can be on any subject – doesn’t need to be related to writing code or anything like that – and be no more than 500 words. It’s not an easy task, but then this prize is worth £40 so I don’t think I’m asking too much of you!

The best (most interesting or amusing) account by 12pm GMT on Monday the 12th of April gets a free copy of SWF Protector 2.

My girlfriend will be the judge, so you can be assured that the results will be totally fair and impartial. The judge’s decision is final and there are no cash alternatives to the prize. The winner will be announced right 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. 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.

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.

The whole process took just under two weeks from initial discussions to delivery, with lots of play-testing and adjusting in-between to get the optimum experience.

Head over to the game page at Quak Multimedia for more information.

For more information either check out the launch post at Quak Multimedia or check the Mercury website directly, where there is even a demo of the software showcasing some of its capabilities.

Mercury is viewed as a live product that will evolve and adapt over time with the needs of our clients, so this won’t be the last time I mention Mercury on this blog I’m afraid!

As well as the software itself, we’ll also be offering a development service where we will either help clients develop their eLearning or develop it all ourselves for an extremely competitive rate.

Any questions? Feel free to ask.

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!

Perhaps our resources were just too forward-thinking for such an organisation?

Not to worry. We’ve had such good feedback on the resources that we’ve decided to make our own portal, called Learnalot, which will be at www.learnalot.co.uk. The resources that Bowland turned down – plus a lot more besides – will find a home there instead.