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.

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.

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.

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.

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.

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!

As I said it sounds great in theory, but I am concerned that perhaps they’re spending too much time chasing headlines instead of spending their time on fixing the stability issues with the Flash IDE. Flash CS3 was buggy and crashed often – Flash CS4 is worse. CS4 even crashed at the pre-launch demonstration that I attended in Manchester earlier in the year, and the Adobe rep asked everyone to please forget what they just saw. What he should have said was to get used to that screen because as CS4 users you’d be seeing it a lot.

I really hope Adobe doesn’t mess this one up because having iPhone development available in an environment that so many people are already familiar with – and one that DOESN’T crash every 30 seconds – would be great and would lower the barrier of entry to iPhone development even further, which would naturally result in even more applications and games finding their way to the platform.