As indicated in the title of this post, the basic idea here is simply to embed your actual SWF within another “shell” SWF. It is this “shell” SWF that you will then deploy/distribute.

MainShell Class
To embed a SWF within another SWF, you can use a document class like the one below:

package 
{
	import flash.display.Loader;
	import flash.display.Sprite;
 
	public class MainShell extends Sprite 
	{		
		[Embed(source="ActualSWF.swf", mimeType="application/octet-stream")]
		private static const bytes:Class;
 
		public function MainShell()
		{
			Loader(addChild(new Loader())).loadBytes(new bytes());
		}
	}
}

When this “shell” SWF is run, it will
(i) create an instance of flash.display.Loader;
(ii) add that Loader instance to the display list;
(iii) instantiate an instance of the embedded SWF as a ByteArray; and
(iv) load that ByteArray into the Loader instance.

This will work in the same way as loading an external module SWF into a host SWF, but in this case the module SWF is embedded inside the host SWF. This is different from loading external SWFs because any external SWF can still be easily obtained from the browser’s cache and decompiled separately.

This set up will be completely transparent to the end-users – it will look as if the actual SWF has been run.

How This Works Against Decompilers
This protection method assumes that decompilers cannot automatically identify, extract and decompile the embedded binary object as a SWF. Therefore, the assets (classes and symbols) in the “ActualSWF.swf” will no longer be directly accessible by decompilers.

I tried this embedding technique against the trial versions of a couple of decompilers (Sothink and Trillix) and the assets of the embedded SWF (ActionScript classes, artwork, movieclip symbols, etc.) are safely hidden from view.

Since this cost nothing and is so easy to implement, I would suggest you try it out and decide on your own the effectiveness of this. Wrap one of your SWFs in a “shell” SWF as described above, and try to decompile it using one of the decompilers out there. Perhaps the non-trial versions and/or other decompilers I have not tried may be able to defeat this simple layer of protection, but even if they do…

Taking Things Further
While it is possible that makers of decompilers could eventually implement a feature to properly identify, extract and decompile embedded SWFs, you can take things further and make the protection more difficult to overcome.

Instead of embedding the SWF directly, you could run it through some encryption and embed the encrypted SWF – it is mime type “application/octet-stream”, so you can really embed any binary file (even invalid file types). Subsequently, the “shell” SWF will decrypt the ByteArray before feeding it to the loadBytes() method of the Loader instance.

To be very clear though, the intention here is not exactly encryption. The real objective here is to intentionally “corrupt” the embedded SWF, so that even if extracted, decompilers cannot easily identify and run/decompile it as a SWF standalone.

For the purpose of corrupting the SWF, there are countless ways – using simple encryption, bytes transpositions, append/prepend useless bytes, etc. well, you get the idea… basically anything that make the SWF file invalid, no longer executable as a SWF. You can even split the SWF into two or more binary blobs and join them back during run-time.

Since there are so many different possible algorithms to corrupt the SWF, it is then practically impossible for decompilers to automatically identify the way to reconstruct the corrupted embedded SWF.

Disclaimer
Needless to say, if you decide to corrupt/encrypt the SWF, you must be able to reconstruct, in the “shell” SWF, the embedded binary object into a working SWF. As a result, while we may be able to prevent automated decryption (primary objective here), do take note that this provides no protection against determined hacking (decompiling the “shell” SWF, getting the decryption logic, extracting the embedded SWF manually, decrypting it and then running the reconstructed SWF through the decompiler).

FlashDevelop
For users of the FlashDevelop IDE, you are probably aware of its SWF assets browser (unlike decompilers, SWF sniffing is used here ethically, and beautifully, for the purpose of implementing code completion, etc.). If you attempt to browse the “shell” SWF within the FlashDevelop’s Project Manager panel, you will not see the assets (classes and symbols) in the embedded SWF. This can be used as a way to quickly verify if a SWF is protected using the “embedding technique” discussed above.

In my opinion, the native right-click context menu is an odd legacy from the Flash Movies days. It may be useful when Flash is used as a video player, for animations and cartoons, in the absence of any proper custom UI.

If you are developing Flash applications, you should consider always hiding the native right-click Flash Player context menu’s built-in items. Sure, you cannot get rid of the context menu completely, but you should at least hide the built-in items. It makes the application look a lot more professional because the long list of built-in items are mostly irrelevant.

If you don’t do anything about it, when end-users right-click on your Flash application, the pop-up context menu will show “Zoom In”, “Zoom Out”, “Show All”, “Quality” (and sub menu), and “Print…” – all of these should be done in-application via properly designed user interface if the application allows these features to begin with.

For example, allowing end-users to zoom in/out without designing the application to handle these adjustments properly can be detrimental to the user experience. And if your application handles zooming in/out, it should have the proper UI to convey the feature to end-users rather than depending on the right-click menu.

Likewise, “Quality” adjustment is something that should be done in-application via a proper Options dialog where graphics, sounds, and perhaps other application-specific options are made available.

For multiple-frame SWFs (such as would be the case if you have a preloader frame), the built-in context menu items will also include, in addition to those mentioned above, “Play”, “Loop”, “Rewind”, “Forward” and “Back” – none of which should be of any relevance to RIAs. Letting the end-user activate any of these frame-manipulation actions can potentially mess up your application.

HTML
You can get rid of the built-in context menu items via the HTML container page, by defining the Flash object’s “menu” parameter as “false”. If you are developing using the Adobe Flash IDE, you can generate the proper HTML page by unchecking the “Display Menu” option in the File -> Publish Settings dialog (HTML tab). If you are developing using FlashDevelop, the “menu” parameter is already set to “false” by default.

However, using this method, you are depending on the HTML container page to tell the SWF to hide the context menu’s built-in items – if the SWF is run outside the HTML page, the menu items will no longer be hidden. If you cannot guarantee that the SWF will be run within the HTML page you have generated, this method will not work well. For example, if you are developing a Flash widget whereby only the SWF itself will be distributed, the menu items will not be hidden if the SWF is ultimately shown standalone, or within a HTML page where the “menu” parameter of the Flash object is not set to “false”.

ActionScript
You can hide the built-in items of the native context menu by inserting just two lines of code:

contextMenu = new ContextMenu();
contextMenu.hideBuiltInItems();

You would typically insert the code into your top-level AS3 class as follows:

package 
{
	import flash.display.Sprite;
	import flash.ui.ContextMenu;
 
	public class Main extends Sprite 
	{		
		public function Main()
		{
			contextMenu = new ContextMenu();
			contextMenu.hideBuiltInItems();
		}
	}	
}

Note: the “contextMenu” property is implemented by the flash.displayObject.InteractiveObject class.
Main -> Sprite -> DisplayObjectContainer -> InteractiveObject

In the above code, you are setting the “contextMenu” property of the top-level Main class instance to a new ContextMenu instance (where the built-in items are hidden).

Using this method, the instructions are internal to the SWF itself. Whether the SWF is distributed and run standalone, or run within a HTML page, the built-in items will be hidden. Also, regardless of the value of the “menu” parameter of the containing HTML page, the built-in items are going to be hidden (ie setting the “menu” parameter to “true” in the HTML page will not override this).

With the built-in menu items hidden, when the end-user right-clicks on your Flash application, the pop-up context menu will show only two items – “Settings…” and “About Adobe Flash Player…” – concise, sleek, a lot more professional looking.

When using FlashDevelop, building a Project (pressing F8 or CTRL-ENTER) compiles a single SWF using the AS class file that has been flagged as “Always Compile”. If you are building an application that consists of a host SWF and multiple module SWFs, FlashDevelop does not automate the job for you.

Use Multiple Projects
One way to build modules in FlashDevelop is to set up a different Project for each module, with each Project using the same assets but different build configurations (the module class in each Project is flagged as “Always Compile”). The Project for a module class would be set up such that duplicate classes are excluded (via compiler options). However, this can get troublesome and difficult to manage/maintain.

Use Quick Build
What you can do is stick to a single Project – when building the Project, the resulting SWF will be the main (host) SWF. Modules are built using the Quick Build command, accessed via the menu -> Tools -> Flash Tools -> Build Current File (CTRL-F8). This compiles the currently open class file, so you need to open the module class you want to compile and then press CTRL-F8.

The Quick Build command ignores your Project settings, so in order for this to work, you need to insert build options into each module class file. At the top of each module class, insert the following:

/**
* @mxmlc -o=bin/ClassName.swf -external-library-path=AspireUIStandard.swc
*/

The above is only an example, you can also specify other MXMLC options (optimize, default-size, etc.). In the above example, we exclude the classes in the AspireUIStandard.swc from being compiled into the module SWF. If you are using other libraries that are going to exist in the host SWF, remember to exclude them too.

To make testing easy, you can do the following:

/**
* @mxmlc -o=bin/ClassName.swf -l=AspireUIStandard.swc
* //@mxmlc -o=bin/ClassName.swf -external-library-path=AspireUIStandard.swc
*/

-l is alias for -compiler.library-path
Use that when you want to compile the module for testing standalone.

“exclude.xml”
Instead of using the -external-library-path option, you can also use an “exclude.xml” file and the -load-externs option.

Generate an “exclude.xml” from the main Project – in the project settings, compiler options, under “Additional Compiler Options”, add the following:

-link-report exclude.xml

Now build your project (CTRL-ENTER). Verify that the “exclude.xml” is generated and is in the root folder of your Project.

With the “exclude.xml” file generated, you can now use the -load-externs directive for your modules:

/**
* //@mxmlc -o=bin/ClassName.swf -l=AspireUIStandard.swc
* @mxmlc -o=bin/ClassName.swf -load-externs=exclude.xml
*/

This is recommended if the host SWF may not include all the classes in the libraries the modules are using.

uiSWF
Once you have created the module SWFs, you can have your host SWF load them using the uiSWF component (Aspire UI Standard Edition v1.2+). This control is a subclass of uiPane, making it suitable to be plugged in as the content of a uiScrollPane instance (in which case the module should not implement its own wrapper scrollers).