SWF Encryption Uncovered

Removing the few junk bytes Amayeta and DComSoft charge you for

It has been a while since I updated SWF Decrypt. The main reason was, of course, the much anticipated SWF Protector 3.0 from DComSoft. In other words, the lack of updates from DComSoft. They promised a complete rework of their protection algorithms that implements “Proper protection algorithms for AS3.0″ more than three months ago. And I was really looking forward for the new update because, after all, the main goal of this effort is to uncover the cheap tricks Amayeta and DComSoft are doing with the hope that this will encourage implementing proper obfuscation methods for ActionScript.

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.

Last week, I dug some dirt on DComSoft and Eltima and I got them really pissed off. This week is dedicated to Amayeta.

Known for providing the worst customer service anyone can expect, Amayeta started after MDM acquired Flashincrypt in 2005 (Amayeta and MDM are the same company too). Back then, a few developers wrote Flash applications that required any sort of protection and Flashincrypt was the only usable software. A more powerful software was in the make called ASO from Genable Labs. While it was never officially launched, I had the chance to test ASO and it was very promising. But Genable disappeared, all of a sudden, and I wasn’t able find any resource that said what happened. Their website just went down one morning and never got back up. Prior to the disappearance, Genable announced that they sold ASO Lite version to a CA company and they will continue to develop ASO Pro version. But that was their last announcement.

So how is that related to Amayeta? Well, Genable released a utility very similar to SWF Decrypt before disappearing called FINI that reversed Flashincrypt protection in November 2004. Flashincrypt was temporary discontinued until, by mid 2005, MDM acquired it and created SWF Encrypt. So, SWF Encrypt was born of a useless software to begin with :)

When SWF Encrypt 3.0 was released, it looks like Amayeta did not give Flashincrypt’s users a free upgrade as anyone would expect. They treated their users as if they were upgrading from a usable version looking for improved and additional features. You can see it on this page that I pulled from internet archive. They were clearly asking users to upgrade for a fee.

I am not sure when SWF Encrypt 3.0 got bypassed, but when Amayeta released SWF Encrypt 4.0 they literally said “The Encryption Technology used to protect your ActionScript are up to 1000 times stronger than previous builds.” as you can see here. But it didn’t take long for ASV to bypass their protection and show the world again that it is just a useless piece of junk. At that time, I was using SWF Encrypt 4.0 and I paid $125 for it. I saw my Amayeta protected SWF files decompile in ASV as if they were not protected at all! Even worse, I contacted their customer support a couple of times and never received a response. That was early 2007.

If SWF Encrypt 4.0 was “up to 1000 times stronger” than 3.0, then what on god’s earth was SWF Encrypt 3.0 doing?! What were they charging people for?!

Every release of SWF Encrypt was pretty much bypassed. Since 2004, anyone who had a look at how they did their protection was easily able to figure it out and reverse it. Authors of FINI and ASV both said it took them just minutes. I’m definitely not as experienced as they are, so it took me a weekend. If you still doubt that SWF Encrypt is just a scam and Amayeta is absolutely not a trustworthy company, check out swfdump and try it on your files before and after using SWF Encrypt. Let me know how long does it take you to figure out how stupidly their protection works!

I think this should be really interesting to everyone who paid to get SWF Protector. It is clear to me that Eltima, the company that makes Flash Decompiler Trillix, one of the most popular Flash decompilers, is behind DComSoft (makers of SWF Protector). While I do not have, in my opinion, any solid proof, there are a couple of things that clearly point that way:

DComSoft accidentally used one of Eltima’s products’ EULA

Recover PDF Password EULA in SWF Protector DGM

As you can see in the screen shots, SWF Protector for Mac comes with Recover PDF Password license agreement. Recover PDF Password is one of Eltima’s products and you can also see Eltima’s name at the end in the screen shot below.

Eltima Software

I can think of only one excuse for this, DComSoft copied the packager for Mac from Eltima’s and forgot to change the EULA. It can happen :)

More Proof

Eltima immediately contacted Gareth Jones after reviewing SWF Protector. While it could be a coincidence, Gareth says from the correspondence it is clear they are the same company. It can also be that the same marketing guys are working for both DComSoft and Eltima.

I also noticed the following while visiting both websites:

  1. Both have translations to only French and German… Exact match!
  2. Copyright notice says 2000 – 2010 on both websites while the domain name dcomsoft.com was created in 2005.

Conclusion

While I do not think that any of this is a solid proof and there still exists a small chance that all of this is just a coincidence, it does mean one of two things:

  1. DComSoft is indeed the same company as Eltima and it is completely unethical and totally crosses the line to sell a Flash decompiler for years then come up and sell another software, under another company name, that protects from the decompiler they originally made!
  2. DComSoft is a very low quality company that copies content from Eltima and makes completely worthless software.

That’s what I think. Let me know what do you think in the comments section.

Update: Another post about the subject can be found here.

It have been two weeks since I released SWF Decrypt to point out that some SWF encryptors  are worthless. While I didn’t directly contact Amayeta and DComSoft, I made sure they’d be among the first to know by explicitly mentioning their names, following them on Twitter, and posting comments on blog posts they commented on earlier. I have no doubt they knew about SWF Decrypt since the first day.

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”.

Not all protected SWF files. But the AS3 ones that are claimed to be protected by SWF Encrypt from Amayeta and SWF Protector from DComSoft. This should be really embarrassing to some people, but an eye-opener for the rest of the community.

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 :)