Using ES4 to Protect Your Code

It is widely known that if something can be downloaded to a client machine, then it is hackable. Someone who is dedicated enough can rip apart the file and do things like:

• Decompile the application to get at the code.
• Modify the code and recompile.
• Steal the code.
• The person can just extract assets such as images and audio.

There is nothing you can do to guarantee the protection of your file. But you can take measures to make it very difficult for people to mess with. For instance, obfuscating code makes code unreadable.

With ES4 there is something else that you can do to help protect your client-side Flash application. ES4 fully supports a true binary protocol. ByteArrays can be exchanged between the client and the server. Any binary file can be represented in a ByteArray.

The idea is very simple.

• Put the important SWF somewhere non-web-accessible, but where ElectroServer can get at it.
• Have another Flash client (one whose code you can stand to lose) connect to ES4.
• This client then requests the SWF file from ES4. The SWF is streamed to the Flash client over binary socket as a ByteArray.
• When the load has completed, the Flash client uses the Loader.loadBytes() technique (see Flash help) to convert the bytes to an actual MovieClip.

So what does this buy you? Well, now it is is substantially more difficult for someone to grab the SWF file that you are trying to protect.

This is just another layer of security. A person can still intercept the client-bound stream using some other tool and, if they understand the complex ES4 protocol, they can extract the specific SWF bytes.

Obviously you can add another layer of security in here by encrypting the byte stream so that anyone just grabbing the bytes still can't do anything with them, short of knowing encryption information.

Flash Player Security Changes in FP 9,0,115,0

Adobe has just released a new update with some Flash player security changes. These changes can keep people from successfully using existing applications that load external data (applications that work with older players). Thank you Adobe.

The good news for ElectroServer 3 and ElectroServer 4 developers is that you will likely not be affected by this change. The changes in the security model take pages to explain and can be read here:
http://www.adobe.com/devnet/flashplayer/articles/fplayer9_security.html

To sum it up succinctly - Policy files are always required for socket-driven applications. Since ES automatically serves up a policy file on connection, and since ES4 loads a policy file by default, then ES4 developers should be the only Flashers out there not sweating right now!