Using Secured SWFs as BEML Widgets

On April 1, 2009, in .NET, ActionScript, Brightcove, Flash, Flex, PEAR, PHP, by admin

This article describes how you can use SWF files as widgets in BEML that have been protected by utilities that prevent decompilation. Before we start, just a couple of things I’d like to point out:

This article is NOT a review of the effectiveness of SWF Protection tools, there are plenty of (endless) discussions on that topic on specialized forums.
This approach is NOT my recommended one for creating User Generated Content upload widgets. I still believe using a secured mid-tier upload server is a better model. Event with a protected SWF, a proxy tool like Charles or WireShark will give a hacker all the information he needs to get your token if you do not protect your sensitive Widget/Server communications.

Why would you do this?

The short answer is that the SWF format is a pseudo-compiled, documented file format. This implies that it is relatively easy to reverse engineer a SWF file. Just Google “swf decompilers” and look at the results. There are literally dozens of tools that allow anyone to retrieve the complete source code of a SWF. Regarding BEML Widgets, this may pose some security threats if for example you want to:

Create a video upload widget that uploads straight into your Brightcove account. Again, SWF protection by itself is NOT the approach I would recommend, as this requires including/sending a Write Token to use the Media API in your SWF.
Create a widget that interfaces with your backend and that contains configuration information you want to give some level of protection
Create a widget that represents a considerable investment or effort, and by consequence you want to protect from being duplicated

to name but a few.

How does it work?

There are mainly two kinds of SWF protection mechanisms: encryption and obfuscation. The better protection tools apply both mechanisms.

Encryption makes code completely unreadable, but requires to keep the decryption-key with the encrypted data. So, an automated tool could be created to decrypt the code, leaving the fully unencrypted, unobfuscated code in plain view.

Obfuscation is the concealment of the code’s meaning, making it confusing and harder to understand. It’s not encryption, but in the context of code, it might be better.

Note that not even the combo of encrypt+obfuscate is 100 percent waterproof. The goal is to make the process of reverse engineering extremely time consuming and painful so that it is not worth the effort.

The Widget Code

The widget we’ll use in this example is a simple Flex AS3 application:

<mx:Application xmlns:mx=“http://www.adobe.com/2006/mxml” layout=“absolute” backgroundColor=“#000000″ backgroundGradientAlphas=“[1.0, 1.0]“ backgroundGradientColors=“[#000000, #000000]“>
<mx:Script>
<![CDATA[

//Placeholder for BC Player Reference
private var BCPlayer: Object = null;

//Placeholder for VideoPlayer Reference
private var VideoPlayer: Object = null;

public function setInterface(player:Object):void
{
//Save the passed BC player Object reference
BCPlayer = player;

//Retrieve the VideoPlayer Module references
VideoPlayer = BCPlayer.getModule("videoPlayer");

//Add a listener for a video being loaded
VideoPlayer.addEventListener ("streamStart", streamStart);
}

private function ShowWidget(showIt:Boolean):void
{
//If widget is to be shown, go to player view mode
if(showIt)
{
VideoPlayer.goFullScreen(false);
}
this.visible = showIt;
VideoPlayer.setVisible(!showIt);
}

//Handler for videoLoad events from the content module
private function streamStart(evt:Object):void
{
ShowWidget(true);
}

private function ContinueVideo():void
{
ShowWidget(false);
}

]]>

</mx:Script>
<mx:VBox width=“400″ height=“180″ horizontalCenter=“0″ verticalCenter=“0″ horizontalAlign=“center”>
<mx:Label color=“#FFFFFF” id=“SecureMessage” text=“This widget shows how to integrate a secured SWF widget in BEML” height=“46″/>
<mx:Button label=“Continue” id=“ContinueButton” click=“ContinueVideo()”/>
</mx:VBox>
</mx:Application>

The BEML Code

The BEML with the widget plugged in looks is as simple as it gets:

Building a Secured SWF from your AS3 code

To make a secured version of your BEML widget, you will need a protection tool. For this article, I’ve used KindiSoft’s SecureSWF, as it has an evaluation version that is not limited in time or number of uses and allowed for easy highlighting of the minor tweakings you will need to do to get a protected SWF working as a BEML widget.

Download and install a demo version of this tool. Run it, and add your SWF file to the empty Project:

If you like, click “Protect SWF Files” and try running this BEML player with a protected version of your SWF, but it won’t work. You will see your browser making the load request, but the widget will not manifest. What’s going on here?

This tool uses the encrypt+obfuscate tandem mentioned earlier. This means that the original variable, component and function names no longer exists in the obfuscated ActionScript. The Brightcove Player you are pluggin this widget into tries to call the setInterface() function, but it has been obfuscated. So your secured widget is loaded, but it is not passed a reference to the player correctly.

Defining Identifier Renaming Exceptions

What we need to do is exclude the functions that the Brightcove Player needs from being obfuscated. To do this, select the Identifiers Renaming tab in the tool, and select your SWF in the treeview displayed on this page. Then uncheck the setInterface() and streamStart() functions. Now protect your SWF file again and try loading it into a player. It should work now.

I’ve deliberately taken an example where the widget is adding some listeners, in this case for the VideoPlayer.streamStart event. As you can see, this implies that the exceptions you need to define will vary from widget to widget. Basically, everything that adds a listener function must have the same name as the one you specify in the the event listener registration.

I’ve also found that in most cases you will need to disable the Additional renaming options (rename protected namespaces, remove function parameters) for a Widget to be manifested properly with a reference to the player.