Use Flash Communication Server to protect Actionscript from decompilers?

[JLiu1369]

I've been trolling the web almost non-stop for the past week trying to figure out if there is some way to protect ActionScript code from SWF decompilers. (Obviously the answer I came up with is a resounding no.) Some forums that I visited seemed to imply that by using .ASC files on a Flash Communication Server and using Flash Remoting, that you can have Flash movies run ActionScript code server-side, thus preventing any web browser clients from accessing the ActionScript source code. Is this really true, or am I just starting to hallucinate? Basically, I am wondering if there is some way to place all of the classes that I have created for a Flash project in server-side ActionScript, so that anyone who visits and manages to decompile the SWF cannot see the actual ActionScript code? Since this project is for a corporate business, I guess you can assume that I have "infinite" bandwidth at my disposal.

[Curly Brace]

Well, I think that ASC files are used to store FlashCom specific code. I heared people changed some bytes of SWF file to make it unreadable to decompilers, but still readable for Flash player. I've never done it myself, but I think this tool can help you doing this: http://flasm.sourceforge.net/.

[rachel_f]

You can protect your Actionscript by encrypting (http://www.dcomsoft.com/products/dcom_swf_protector.html) it. I tried this method and I can say that it really works

[mike_eci]

Encrypting it is only a temporary solution (as unfortunately decompiler companies will update their products after a while to decompile any new protection).

It's definately a good idea to keep critical code on the server if possible - whether that is possible in your case depends much on what the code does - and whether the output it produces is in a format that can be transferred back and forth without interrupting the user experience. You wouldn't be able to e.g protect the physics and collision algorythms in a platform game, but would be able to migrate e.g a question and answer quiz logic to the server.

You could use amfphp in certain circumstances, but Flash Media server does have some interesting additional capabilities (e.g the server side Client.pageUrl to check where the incoming connection is from, and the capability to authenticate and verify connecting swf files (if player version > 9 update 3))
Bear in mind that server side actionscript is limited in features compared with client side as3, you might have to consider integrating other server side languages to achieve what you want.

[arpace]

Just assume, right away, that your code can be and will be read by anyone that really wants it; all an individual with real programming skills would need is the inclination.

So, this encrypting code nonsense is pretty stupid.

I mean, come on, even if you encrypt the code, there still has to be a process for which a section of the code sends the data to the just-in-time compiler, in order for the program to actually work; thus, the decryption scheme is available in the code itself, if it is truly encrypted.

It is very similar to capturing streaming data.

If it is just obfuscated, it is even easier. People using the Hungarian Warts* method have been screwing with their employers for years, in order to insure code was unmaintainable; to the point where changes that needed to be made, would require the employer to go back to the programmer who initially coded everything or hire someone to write everything from scratch; thus, code analysts created programs to beautify code and to analyze every call at compile time and rename it. The programs that actually do a good job of this cost quite a bit; yet, if your code does something so fantastic you think it needs to be protected you can be sure your competitors will pay whatever cost is necessary to remain competitive.

As well, if someone was to attack your server, exploiting flaws that haven't been patched, gain access to your server, and locate the folder where your code is stored, the attacker could get any server side code they want; any script kiddie can do it, with all the 0 days that are popping up like weeds in spring.

So here is the conclusion: Separate your business logic from your interface, by saving any sensitive data, like the calls to a db on your server, and do as much as possible to secure that server. The client should really only be for the display, unless you are creating a desktop application; in which case you are screwed.

*Hungarian Warts (http://www.google.com/search?hl=en&q=hungarian+warts&btnG=Google+Search)