Protecting/Encrypting Flash 9 SWF Files

[f-zero]

Hi guys

Does anyone have any solutions on protecting SWF files written in AS3?
I've tried some trial software but they didn't seem to do very much.

Its sad when a developer spends months developing an app/game only to have it stolen, edited, recompiled and sold by some moron without principles or ethics.

Does anyone have any suggestions on how to protect AS3 code?

[sphoenixee]

I too am looking for such a thing. Unfortunately, Flash decompilers seem to be able to decompile quite nicely. I know for sure Flash IDE's protection doesn't work. Have not tried others at the moment.

I wouldn't call them morons without principles or ethics though...the system simply just...allows it (ie we can't protect our work).

[5TonsOfFlax]

I've never used any of the available tools for this, but I believe amayeta claims to have an effective encryptor/obfuscator.
http://www.amayeta.com/

Personally, I'd encourage you to change your business model if you can stomach it. Get paid for the service of creating the software, not the product. The industry isn't really set up for that right now though.

Also, I agree that those that claim your work as theirs without attribution are without principle or ethics.

[sphoenixee]

I wonder how much that decreases performance. (Maybe it's very little; I do not know though). Anyone know?

[Schfifty Five]

I've never used any of the available tools for this, but I believe amayeta claims to have an effective encryptor/obfuscator.
http://www.amayeta.com/

Personally, I'd encourage you to change your business model if you can stomach it. Get paid for the service of creating the software, not the product. The industry isn't really set up for that right now though.

Also, I agree that those that claim your work as theirs without attribution are without principle or ethics.

I tried the trial of Swf Encrypt 5, and it didn't seem to do much... the code was fairly easy to understand when I decompiled it. Maybe it was just a one-time thing though, or had something to do with the trial.

I wonder how much that decreases performance. (Maybe it's very little; I do not know though). Anyone know?

I think the performance decrease is negligible, and you won't notice it, but you should test it anyway after it's been encrypted.

[f-zero]

I tried the trial of Swf Encrypt 5, and it didn't seem to do much... the code was fairly easy to understand when I decompiled it. Maybe it was just a one-time thing though, or had something to do with the trial.

Its funny you should mention that cos thats the encryption software I tried. I downloaded the latest trial version (5.0.0.1) which has a few new encryption options since v5.0.0.0. I tried it on different settings and pretty much got the same result every time. It encrypted 2 or 3 variables, added a few weird comments... and that was it. Most people who understand AS3 could easily reconstruct those variables in no time. The site claims the trial version only has 50% of the strength of the full version. But I think even at twice the strength, the code would still be very easily readable and around 90% intact. I'm sure it does a great job encrypting AS2, but I don't use that at all. *sigh* Its really sad cos its reasonably priced and I was hoping to buy a copy!

As for performance - it was the same for me. My game runs slightly slower on my machine than its supposed to. If encrypting it was going to make a difference I would have definitely noticed it. Or maybe it ran at the same speed because it didn't encrypt the SWF very well... who knows. I really hope the guys at Amayeta sort this issue out.

I also tried a trial version of something called Irrfusicator which encrypts .AS files - I'm sorry to say it did even less! Either that or maybe I used it wrong.

There's got to be a rational solution for this problem... somewhere!

[DevilMayCry]

So basically you are all saying that there's no protection for AS3 code!?

Very not good

[Schfifty Five]

So basically you are all saying that there's no protection for AS3 code!?

Very not good

I just found this:
http://www.ambiera.com/irrfuscator/downloads.html

It obfuscates your class files (.as), and not the swf itself but it seems to do a decent job. The trial works for 30 days, and as far as I know, it has all the features of the full version.

[neznein9]

If it's that critical, why not put in some code to link the swf to your domain or use a checksum in the loadvars or something?

If someone can decompile your swf, they are either going to change superficial things (in which case they arent looking at the code so it doesnt matter) or else they probably already know how to code what you're doing so they could figure out the obfuscation regardless or just rebuild parts of it.

To make your final code harder to read, you could try some of the less well known code shortcuts, like the ternary (?) operator for if...then...else, or bitshifting (>> <<) instead of multiplying. And you can always nest function calls and math equations into one giant line...

[5TonsOfFlax]

All right, I've been kicking around this idea for a while, but I doubt I'll ever find the time to implement it since I have other more fun things to think about. Anyone, please feel free to take this and run with it.

Have a wrapper swf, which gets a key from the html page (via flashvars or ExternalInterface or whatever), requests an encrypted version of the target swf from the server, and decrypts it, then loads the decrypted swf with Loader.loadBytes.

The decryption can by handled by the as3crypto package, and the encryption by whatever serverside tech you prefer. php has mcrypt which looks like it should work. The key can be dynamically generated based on requesting ip and time of day, or anything else, and the server can encrypt and send the target swf on the fly. It's more than a little overhead, and it's still defeatable by carefully examining the wrapper swf and the page it was loaded from, but it's better than any of the "solutions" I've seen bandied about.

Of course, this does depend on a server-side component which rules out most portals.

[Schfifty Five]

All right, I've been kicking around this idea for a while, but I doubt I'll ever find the time to implement it since I have other more fun things to think about. Anyone, please feel free to take this and run with it.

Have a wrapper swf, which gets a key from the html page (via flashvars or ExternalInterface or whatever), requests an encrypted version of the target swf from the server, and decrypts it, then loads the decrypted swf with Loader.loadBytes.

The decryption can by handled by the as3crypto package, and the encryption by whatever serverside tech you prefer. php has mcrypt which looks like it should work. The key can be dynamically generated based on requesting ip and time of day, or anything else, and the server can encrypt and send the target swf on the fly. It's more than a little overhead, and it's still defeatable by carefully examining the wrapper swf and the page it was loaded from, but it's better than any of the "solutions" I've seen bandied about.

Of course, this does depend on a server-side component which rules out most portals.

Another option to confuse people who are decompiling your swf would be something like tonypa suggested:
http://board.flashkit.com/board/showthread.php?t=731822

You could convert your main swf into a ByteArray, encrypt it, convert that ByteArrayto a png, and then create a wrapper swf with that png in its library.

The wrapper swf would then get the BitmapData of the png in the library, convert the BitmapData into a ByteArray, decrypt the ByteArray, and then use Loader.loadBytes() to get the original swf back

I'm sure that sounded confusing as hell and I didn't really word it well, but I'm sure it'd stop a lot of people trying to decompile your swf since they'd just see a single image and a few lines of code when they decompile it.

[5TonsOfFlax]

That is pretty cool. It's essentially the same idea without the serverside component or changing keys. To do that approach right, you'd really have to split your encrypted swf among several assets and steganographically embed the parts into innocent looking stuff. It's almost worth trying just for the wtf factor.

[Schfifty Five]

That is pretty cool. It's essentially the same idea without the serverside component or changing keys. To do that approach right, you'd really have to split your encrypted swf among several assets and steganographically embed the parts into innocent looking stuff. It's almost worth trying just for the wtf factor.

I might have to try it sometime

I'm not sure how long it'd take for an average sized swf though (~1mb)...

[DevilMayCry]

Ah, thanks guy's! For a moment I felt sick. To think all this coding could be taken away just like that. Not good.

Further more:
- that bmd could be chopped into few little pictures
- one big with some trash data before and after it, so you have to pass a number where real data starts
- use copyPixels and seed data all over normal pictures
- what are reversible color filters that could be applied to that bmd
- normal picture with swf data in transparent alpha channel

I'll post more if I think any more. I think we are on something wonderful

[5TonsOfFlax]

Bear in mind that although you can make the code arbitrarily obfuscated, you can NOT make it theftproof. You can't because you're trying to give it to and keep it from the same person: The end user. If you're looking for an ironclad means of protecting your swfs, you just won't find it. It's the same reason DRM is fundamentally flawed.
You don't want to be like the record companies, do you?

[neznein9]

I agree with Flax 100%

Also (and I'm far from an expert) it seems like you could do something cool using binary not or xor to invert your entire byte array in a way that would be easy to get back but look incredibly daunting to a decompiler...

[DevilMayCry]

I don't follow you 5TFlax... I don't want to give a code to end user. And he/she doesn't want it anyway.
I want to give them .swf. That's what they really want

But to make it as hard as possible for theft, yes please

[5TonsOfFlax]

The bytecode that the flash virtual machine uses is inherently decompilable. There's just more data there than just the machine instructions you get when you compile C or another native language. So, in order to give the user a swf, you have to give them something that can be decompiled to some degree. It's just how flash works. It would have been entirely possible for the compiler to strip out identifiers and alter variable names, but the class reflection capabilities make that very hard to do in a guaranteed non-destructive manner.

That's a bunch of fancy words to essentially say that you are giving your code away when you give away swfs. You are NOT legally giving up your rights to said code, and from a legal perspective having some level of encryption in there lets you invoke the DMCA if you can ever find out who's trying to rip you off (in the US). It's a terrible law, but at least you can abuse it just like the big boys.

This is not legal advice, and I am not a lawyer. Consult your physician if symptoms persist. Professional driver on closed track. Do not attempt. Etc.

[691175002]

It is comparatively easy to make your swf absolute hell (On the dozens of hours of pain and frustration level) to steal. The majority of stolen games have very little or no protection. Something like xor encrypting your flash into several pngs and then obfuscating the loader would be so unusual that I would be surprised if someone figured it out.

On the other hand, if your swf actually turns out to be popular enough, people will try to break it, and eventually someone smart enough will come along. The best plan is to have a business model that can handle (or benefits from) the flash being stolen. Otherwise you will just have to take solace from the fact that it probably took 60 hours and several mental breakdowns to crack.

I also think the power of decompilers has been oversold here. In my modest experience, anything of complexity will come out as garbage that is almost impossible to understand and even if it compiles without errors, will fail to work properly.

[sphoenixee]

The converting to picture idea sounds very very cool. I would image overhead is quite high though. But it definitely sounds cool.

Like Flax insinuated, I also think often getting the code pirated (perhaps not stolen and made into smtg else, but directly pirated) has benefits. Namely, the benefit is it'll increase in popularity, which can be ridiculously substantial. I personally am working on some legal education/training software and would not be (too) sad if 10000 bar examinees came and pirated it. That'd just make my product more attractive for next year's bar exam, increase my sway with the corporations (who shell out the big bucks anyhow), etc. Of course, this all depends on business model, so very much YMMV.