Gareth Jones

I was asked a few days ago by a father of two if it was worth buying the PSPgo. He already had a PSP 3000 which his eldest had commandeered and wanted another so that his youngest could play as well.

The PSPgo was released in Europe and the US on October 1st, 2009 as an alternative – not a replacement – to the recently released 3000. At launch the unit price was £250 – around £100 more than the 3000 – though due to the substantial resulting backlash many retailers were discounting the machine to around £225 from day one.

The Go has exactly the same hardware specifications as the 3000 except that it can’t play traditional UMD games as it lacks a UMD drive and it has a smaller screen due to the console itself being half an inch smaller and 43% lighter than the 3000. Depending on who you ask, the smaller size is sometimes a positive and sometimes a negative – yes it’s easier to fit into your pocket but yes a larger screen is always better than a smaller one.

Sony’s decision to launch the original PSP back in 2005 with a UMD drive was quite controversial. Back in 2005, solid state memory was pretty expensive and the UMD allowed a cheap method of providing up to 1.8GB of storage space for its games which would have cost almost as much as the console itself in solid state. However, the drive was slow, it drained the battery and as soon as your games collection surpassed the grand total of 1 you had to find another pocket for your (cumbersome and delicate) UMDs. Some cases allowed up to 3 UMDs to be carried with the console but quickly got bulky – anything more than 3 and you were looking at a bag.

The UMD format shouldn’t come as a surprise to anyone though as Sony’s history with bespoke formats is long and colourful. Among the success stories are the CD, the Memory Stick and Blu-ray, but on the flip side are BetaMax, DAT tapes and Mini Disk. Cynics were adding the UMD to the latter list as early as 2006.

At the beginning Sony seemed to have high hopes for the UMD format. As well as providing the medium for the PSP’s games, the UMD was also used for PSP versions of the latest blockbuster movies (the original PSP came with Spiderman 2) though this aspect was actually poorly thought out.

Firstly, a UMD movie could only be watched on the PSP – a rumoured UMD set-top box that would allow UMDs to be watched on your living room TV never materialised. Secondly, this PSP-only version of the movie often cost considerably more than a DVD copy that you could watch on anything. It was even possible to rip DVD movies to memory card and watch them on the PSP at no extra cost, though Sony artificially crippled the resolution of movies played back this way to 320×240 as a way of forcing people to watch their movies on UMD – which could use the system’s 480×272 screen to its full potential. With custom firmware removing this limitation however and UMD movie sales slumping, Sony eventually removed the limitation from their own firmware in revision 3.30 as part of a larger drive to try to stem the flow of custom firmware installations.

So, the UMD failed as a movie format and here in 2010 you can get memory cards of a higher capacity for next to nothing, so surely the PSPgo is a no-brainer and everyone should upgrade from their PSP3000, right? Sadly not, and the reasons are all down to yet more stupidity on Sony’s part.

Read more…

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

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

Company: Kindisoft
Product: SecureSWF
Price: From $99

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.

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

Company: Eltima Software
Product: Recover PDF Password
Price: From $39.95

Shortly after my SWF Protector 2 review, Eltima Software contacted me and asked me if I’d be interested in reviewing their Recover PDF Password software in exchange for a license. I required the services of such a tool just a couple of months back and at the time I used a 50-use trial from another vendor, so I knew that this was something that could come in handy.

I installed the application without any problems, though as it uses the same registration format as SWF Protector 2 it’s probably susceptible to the same issue if you happen to not put in the correct serial.

When the interface opened up, I was surprised to find that this tool is actually a brute-force password cracker rather than a password removal tool like the one I used a couple of months ago. Why would you need to spend time guessing a password if it can simply be removed? How curious!

The answer as I discovered after a little research (I don’t tend to use PDFs much in my line of work) is that PDFs have different layers of protection. There’s a “user password” and an “owner password”, and the “user password” protects against the opening of a file, printing and even copying and pasting of text and graphics, whereas the “owner password” protects against making changes to the document.

The PDF I unlocked two months ago only had protection against copying text – I was able to open and view the file without any problems, so obviously that aspect of the “user password” had not been used and as such the file was not encrypted. Because the file wasn’t encrypted, the tool had been able to simply change a couple of bytes to disable the requirement for a password and had unlocked the printing ability for me pretty much instantly. However, had the file been protected against opening – and therefore been encrypted (128-bit AES encryption by default) then this tool would not have worked and the only way round this is by brute-force – which is where Recover PDF Password comes in.

I created a PDF and set the “user password” as “t3st”. I opened it in Recover PDF Password and as I knew the password was made up of lower-case letters and numbers, I selected numerals and lower-case letters from the options. Of course, if I really needed to use this tool the chances are I’d have no idea what the password was and as such would have to tick every box on there (including upper-case, special symbols and spaces), which would dramatically increase the time taken to crack the password as the number of potential combinations sky-rockets. The default length of the password to crack was 1-8 so I left it at that.

On an Intel Core 2 Duo laptop clocked at 2.2ghz, the password was cracked in just over a minute. A popup window informed me that the password had been cracked and it also told me what it was. It then asked me if I wanted to save a new version of the file that had the password removed.

I decided to test again but with every combination ticked to see what difference it made to the time, and as expected it was significantly higher at 58 minutes.

It’s important to note that the fact that it takes so long to crack a password this way is not down to any shortcomings with the software – there are just so many combinations of passwords that it naturally takes time to check them all. Even a password of 4 characters in length has over 78 million possible combinations when using all of these different characters (as a comparison, when using just lower case letters and numbers there were only 1.7 million possible combinations), so that the password was cracked in just 58 minutes is actually pretty impressive as it gives us a rate of around 22,500 password tries every second (maximum, though the real value will most likely be less as it’s unlikely that it had to try every single combination before arriving at the actual password).

There are more advanced options as well, such as being able to specify patterns within your password such as “pass??rd” where only the question marks are tested, but again this would only be useful if you already had a good idea of what the password was but I’m suspecting that in most cases you won’t.

I personally use much longer passwords than my test 4-character example when I’m trying to protect something though, and in the event that I’d have to brute-force my way into one of my own files I’m guessing it would take several days if not weeks. Again, that isn’t a problem with the software – it’s a problem with the method used, but when a file is encrypted with 128-bit AES encryption this method is really your only option.

After your file has been cracked it’s added to a history tab so that you can keep track of your passwords without having to have them cracked again, assuming of course that you don’t simply save the cracked version instead.

So, to round up if you have a PDF that you can open but it has limitations like not being able to print or copy/paste the text, your best way forward is to use a simple password removal tool as there’s no point trying to work out a combination on a lock if you can just break it off. On the other hand, if your PDF won’t even open without a password then a brute-force crack is your only option and in this case you need Recover PDF Password from Eltima Software.

Marks out of 10? Well, the software does exactly what it’s supposed to do and does it well. Brute-force cracks are always time-intensive due to their nature so it would be totally unfair to mark a piece of software down for not being instantaneous (though from experience this is what a lot of people expect from their software no matter how complex its task, simply because they don’t really understand what’s going on behind the scenes). Perhaps on a geek level it would be nice to know exactly how many combinations the tool had attempted before your password had been cracked, and there are a couple of instances where the software would have benefited from proper translation (when you save the cracked file the message says, “The file is written down successfully”), but for a tool that works through 22,500 password combinations every second in an effort to reunite you with your work, these are very minor gripes.

9/10

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

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.

Company: Amayeta
Product: SWF Encrypt 6.0
Price: £75 / $145

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.