Unfortunately, I was disappointed right after I had a look at the bytecode of a SWF file protected by the new DComSoft software. I am not sure if the industry is changing, but it was my understanding that a major version update should at least either introduce a new feature or rework an existing one. I am sorry to say that the new version of SWF Protector is a complete joke! DComSoft are walking down the same path as Amayeta (see my Review of Amayeta SWF Encrypt).

SWF Protector 3.0 protection is the same as 2.0 with only a single byte added to the beginning of each method. Yes, only one byte in the same location over and over again. The new byte is 0×02 and it stands for a NOP instruction. For those who are not into assembly, it is an instruction that does not do anything!

As Amayeta SWF Encrypt last update, DComSoft were trying to expose bugs in SWF Decrypt rather than implement an actual protection method. But Amayeta was at least discreet about it by naming the new releases 6.0.6 and 6.0.7. DComSoft, on the other hand, choose to use a major version update to deceive everyone (reviews can be found here and here) into thinking they did major changes. Fixing your software to parse Flash 10 files correctly and exposing a bug in SWF Decrypt is not a major change. Most of the change in the new version, in my opinion, is replacing Eltima’s EULA and changing the version number.

The new version of SWF Decrypt (v1.2 if anyone cares) fully recovers SWF files protected by the latest releases from Amayeta and DComSoft. They had more than three months to implement actual code obfuscation methods and they failed in every way. If you are still unable to see that those companies are just ripping Flash developers off by now, then I don’t know what well.

But none of these companies did anything. They didn’t update their broken software, they didn’t notify their users about this very important security issue, and they didn’t even contact me.

While I’m very pleased by the very positive feedback and the little buzz SWF Decrypt is getting, I am a bit disappointed by some of the reactions. For example, swftools.com rejected SWF Decrypt submission while is a perfectly legit SWF tool. At least, it is as legit as the 22 decompilers they are listing. And Emanuele, one of my favorite bloggers, blocked my comments on his recent SWF Protector review. Why are they trying to hide the truth and block it from reaching their readers? Any ideas?

Another interesting thing happened since the release. Some people thought that since I recommended SecureSWF and IrrFuscator then I must be working for them. Gareth Jones winked that I might be a new hire at KindiSoft. There is a reason why I would recommend those two and attack the other two. SecureSWF and IrrFuscator are actual ActionScript obfuscators. They do what other obfuscators for every other language are doing. They rename the classes and variables to make decompiled code harder to understand. But SWF Encrypt and SWF Protector do not do that. They are just rip-offs. If they rename anything, then SWF Decrypt will leave it renamed. It is not possible to revert to the original names. SWF Decrypt works in the same way for any SWF file and removes the few junk bytes it can find.

It took me a weekend to write SWF Decrypt, but by today Amayeta and DComSoft had over two weeks to fix their software. SWF Decrypt had proven to work very well and thanks to everyone who helped spread the word, it has been downloaded over 2,320 times. Why neither Amayeta nor DComSoft issued an update yet? I know DComSoft are at least trying.

Update: Amayeta is also “working on it”.

For years, Amayeta had charged developers $145 for SWF Encrypt. Last week, I’ve put it to the test and SWF Decrypt was born. While at it, I took a stab at SWF Protector from DComSoft, newer but gaining popularity, and reversed their protection too. I’m publishing SWF Decrypt to share my findings and help spread awareness. I do not think it is an unethical or a hacker tool. I’m just uncovering what many people thought was protecting their work from Flash decompilers.

I also hope that SWF Decrypt will encourage the authors of SWF Encrypt and SWF Protection to implement real code obfuscation methods. Until they do, I can recommend to use other solutions that at least can rename classes and variables. If the software that you are using can rename classes, then you can tell it is using at least one code obfuscation method that works. Notice that SWF Decrypt does not recover renamed variables by Amayeta. There is no way to recover that. But from what I hear, their variable renaming method does not work for most people.

SWF Decrypt does not specifically target SWF Encrypt and SWF Protection. It reverses the lame techniques they use and probably used by other products as well. I didn’t test all the products available in the market yet. But I encourage everyone to share their findings in the comments section here.

SWF Decrypt is a freeware and can be freely distributed. I did not make it open source yet to prevent Amayeta and DComSoft from knowing how I managed to easily reverse their protection.  I plan to mess with them for a while