Nov 13 2009
This post is a supplement to “Applying ROT128 Encryption On ByteArray”.
Some time back, we posted a simple technique for hiding assets and AS3 code from prying eyes by embedding one SWF within another SWF. In this post, we revisit that topic and look at how ROT128 can be used to provide an additional layer of protection.
Sep 03 2009
By domain locking (or site locking), we are restricting the SWF to be run only from a certain domain, ie the SWF should execute normally only if it has been viewed from a certain domain. If it is loaded from other domains, the SWF should execute in an alternative manner – perhaps not run at all, or run with limited features (as the developer deems appropriate). This is usually done to prevent unauthorized re-distributions of SWF files.
Aug 21 2009
The technique discussed below is fairly easy to implement and will cost nothing other than a few minutes of your time. You can use this method in conjunction with code obfuscation, encryption or whatever other protection methods – this just adds another layer of protection. While this isn’t going to be a 100% foolproof protection, it is nevertheless better than no protection at all, and should help to deter most if not all casual decompiling.
Aug 05 2009
UPDATE: You may also refer to Domain Locking SWFs, because by domain locking (site locking) a SWF, you would prevent it from running locally as well.
The Flash platform is a client-side platform. As a client-side platform, it is fairly easy for end-users to get a copy of online-deployed SWFs from the browser’s cache. There are also browser plugins that make this even easier (often requiring only a few mouse clicks), saving end-users the hassle of looking through the browser’s cache for the right file(s) to copy.
Depending on your application, having end-users run your online-deployed SWF locally may not be what you want.
Adobe Feeds