you can try an actionscript obfuscator, like this: http://www.genable.com/aso.html, but this only makes it harder to get to your code, not impossible.
Another way could be to have so called dynamic libraries: compile the code into a seperate swf and load this swf into your main movie on runtime with loadMovie(). That way it should be safe from decompilers, but you have to make sure it can only be loaded from your main movie, not directly by pointing the browser to the external swf. This involves special webserver setup, I guess (didn't try it myself yet).
Finally, kglad posted another way to encrypt actionscript in this forum, search the forum, it was a quite long thread. I'm not sure if it was totally finished, but it was an interesting way to do it, maybe you can make use of it.
> Another way could be to have so called dynamic libraries: compile the
> into a seperate swf and load this swf into your main movie on runtime with
> loadMovie(). That way it should be safe from decompilers,
...no. The loaded movie will still appear in the user's cache, from where
they can retrieve and decompile...
Remove '_spamkiller_' to mail
That darn cache... Peter is right, so forget about that option.
I'm pretty sure it was SWF Encrypt that I was able to get into script
protected by them very quickly. Whoever it was said on their web site that
they wanted to hear from anyone who was able to break their 'encryption'. I
told them and heard nothing back, and the claims remained. So don't believe
If this is indeed the SWF Encrypt I looked at, the SWF's they produce are
actually INVALID swf files that just HAPPEN to work with current players ..
that is why decompiles can't directly decompile them. It is quite likely
that future flash players will NOT be able to play SWF's made by that
progrma BECAUSE they are invalid.
Be very wary of such products
Also be very wary of obfuscators. The problem with them is that methods and
classes and variables and literal strings are all just strings in the SWF
file .. and you cannot obfuscate literal string and method and classes etc.
Eg. Sometimes strings contain vairable names etc and if the obfuscator
changes the variable name, your code won't work. It is very easy for
obfuscation to break a SWF. I tried an obfuscator only a couple of months
ago on a fairly simple swf I had already made (that had three ball bounding
around the screen) .. and the obfuscated version did not work properly at
all. Unfortunayely, you won't knwo there is a probem until you happen to
get into the part of the code where it has stuffed up .. so if you use an
obfuscator, you need to test and retest thoroughly every time you obfuscate.
Another point to realise if that with recent Flash script compilation, local
variables get copiled into registers (which is just as efficient at
obfuscating code as anyhting else) .. so even if your source actionscript
has nice meaningful names, these are optimised away by the time they get
into the SWF .. so there is less need to obfuscate.
And another point is that all these products will be useless once Flex 2 and
Flash 8 are out, as they use completely different compiled script in the SWF
I know this is a very old thread. But someone (LockLizard.com) is linking to this post as a (misleading) testimonial. This information was probably true in 2006, but things are different now. ActionScript 3 came out, and changed almost everything about decompilers and obfuscators. Sophisticated obfuscators for ActionScript also came out (such as our product secureSWF, and even a competitor irrFuscator).
Renaming identifiers is the only code protection mechanism that is 100% impossible to reverse; the original names no longer exist! Everything else, with enough time and effort, can be reversed. Even a "AES 256 bit encryption" (who cares how strong the encryption algorithm is if you are also passing the decryption code and decryption key with the encrypted data to the attacker?).
Sophisticated obfuscators, such as secureSWF, analyze your code first to make sure it doesn't break after obfuscation. With ActionScript 3, the Flash player will display an error message if something goes wrong after obfuscation. And it's always a matter of a couple of clicks to fix it.
If obfuscation is still a troublesome process, then how come large projects such as Scribd’s iPaper, and Disney’s Club-Penguin are using it?
One last thing, I assure everyone that obfuscated files by secureSWF are 100% complaint with the SWF file format specs and will work with future version of the Flash player the same way they are working with the current version, and the same way un-obfuscated files will work with new versions. We don’t do any tricks to break decompilers, we just remove the information they need and the Flash player doesn’t.
Tokaos provides obfuscation for ActionScript 3 only... but ActionScript 2.0. is still popular, so please be aware of this... Additionally tokaos provides protection for "source" codes only.
But if you want to protect compiled SWF file so there are several solutions like SWF protector from DComSoft, secureSWF from Kindisoft and SWF Encrypt from Amayeta software. I do have investigated/tested them all and the conclusion is following:
- SWF Protector - as for me it is pretty nice and reliable, simple/user-friendly and cheap. So that is why I am using it;
- secureSWF - reliable and very professional, but as for me - complicated, more expensive of course ;
- SWF Encrypt is very expensive for me and actually I don`t know why... maybe there are some powerful algorithms... I have checked the code using decompiler and found nothing except some cycles. Although I am not a very good programmer.
Maybe someone knows anything about this?
As for the encryption... I can say that it is useless because it means that the key which was used to encrypt the code should be placed inside the same protected swf file, so you can simple decrypt it. Of course you should know something about cryptography :)))