Protecting a swf

In my training courses I often get asked about protecting swf movies. There’s two sides to this – one is encrypting the code to make it hard for others to decompile and use, and the other is limiting where the swf can be used from so that users can’t simply place your swf on their website.

There are a number of commercial and free obfuscating and encryption tools to help protect your code, three of which are ASO, SWFEncrypt and SecureSWF, so I’m not going to say any more about them (maybe in a later post). Here’s a few ideas for how to limit where the swf movie may be used.

What domain is the swf running in?

The swf can check to see what domain it’s running in and exit if the domain isn’t allowed. You can do this with a function like this

function isDomainAllowed( allowed:Array ):Boolean
{
    var lc:LocalConnection = new LocalConnection();
    var domain:String = lc.domain();

    for( var i:Number = 0; i < allowed.length; ++i )
    {
        if( domain == allowed[i] )
        {
            return true;
        }
    }
    for( var i:Number = 0; i < allowed.length; ++i )
    {
        if( domain.substr( - ( allowed[i].length + 1 ) ) )
                        == "." + allowed[i] )
        {
            return true;
        }
    }
    return false;
}

This function receives an array of allowed domains and checks the domain in which the movie is running against the array. If the swf is running in any of the domains or a subdomain of any of them then the function returns true, otherwise it returns false.

You use it like this

var domains:Array = new Array(
    "bigroom.co.uk",
    "example.com",
    "localhost"      // allow local testing
    );
if( isDomainAllowed( domains ) )
{
    gotoAndPlay( "content" ); // play the movie
}
else
{
    gotoAndPlay( "forbidden" ); // display some error message
                                // - more about this later
}

What flash player is the swf running in?

In the previous method, the localhost value in the array is to allow testing of the movie locally, in the Flash development environment or in a local web page. It also allows users to download the swf and run it locally or to load it into a projector. If you want to ban all local use of the swf then you can just remove the localhost value from the array of allowed domains. However, if you want to restrict the local use to some instances only (e.g. the Flash IDE only) you need to test what flash player the movie is running in. That works like this

function isPlayerAllowed( allowed:Array ):Boolean
{
    var player:String = System.capabilities.playerType;

    for( var i:Number = 0; i < allowed.length; ++i )
    {
        if( player == allowed[i] )
        {
            return true;
        }
    }
    return false;
}

The possible values of System.capabilities.playerType are

  • ActiveX - the active-x control used in Internet Explorer
  • PlugIn - the plug-in used in other web browsers
  • StandAlone - the stand alone player and projectors
  • External - the test movie mode in the Flash IDE

So the isPlayerAllowed function is used like this

var players:Array = new Array(
    "ActiveX",
    "PlugIn",
    "External"      // allow local testing
    );
if( isPlayerAllowed( domains ) )
{
    gotoAndPlay( "content" ); // play the movie
}
else
{
    gotoAndPlay( "forbidden" ); // display some error message
}

Load a file from the server

A third option is to try to load a file from your web server. If the load fails, abort the movie. Something like this

function testWithServer( callback:Function ):Void
{
    var receiver:LoadVars = new LoadVars();
    receiver.onLoad = callback;
    receiver.load( "http://example.com/testswf.txt" );
}

Which is used like this

function testResult( success:Boolean ):Void
{
    gotoAndPlay( "content" ); // play the movie
}
else
{
    gotoAndPlay( "forbidden" ); // display some error message
}

stop();
testWithServer( testResult );

This is quite basic - The file can be an empty text file - it needs no content. The function succeeds if the file can be loaded and thus is dependent only on the cross-domain policy for the domain hosting the test file that's loaded. If the policy allows the movie to load the file then it succeeds. The advantage to this is that we can update the allowed domains for our swf simply by modifying the cross-domain policy file on the server - there's no need to touch the flash movie. (More info on cross-domain policy files here)

It's important that the url is not a relative url - that would enable someone to bypass the security simply by placing an appropriate file on their own server.

There are many ways that this method can be enhanced, for example

  • by sending the domain to the server and recieving a response that indicates whether the domain is allowed (and logging any disallowed domains)
  • by generating a unique id each time the page containing the flash movie is loaded and passing it to the movie via the FlashVars. The swf then passes this back to the server when asking permission to run. The server allows each id to be used once only.
  • by using encryption in the query and response (see ASCrypt for some actionscript encryption code).

But the basic system of an absolute URL and one or more (you can give each swf a unique policy file that it loads via the System.security.loadPolicyFile() method) cross-domain policy files is enough in many cases.

Conclusion

Each of these three ideas can be used individually or all together. Personally, I like the way that the first two are contained within the flash movie and require no special content on the server. Alternatively, the last method lets you update the allowed domains without editing the flash movie itself so each have their advantages. Note that if your source code can be decompiled then all these tests can be circumvented by simply removing the test altogether, so you may want to take another look at those encryptors and obfuscators.

What to do if playback isn't allowed?

If your test reveals that the movie shouldn't be allowed to play, then what should you do? There's two basic policies you could turn to

  • Tell the user what's going on - display a message like "This movie/game/whatever can be viewed at http://example.com/funkyswf.html".
  • Cause the player to crash - a simple while( true ); creates an infinite loop to achieve this.

I choose between these options based on specific circumstances. The second option gives a potential thief fewer clues as to what's going on, but you could use the first option to tell the thief where to legitimately obtain the swf (and how much it will cost).

I hope this is useful to you. What security techniques do you use?

4 thoughts on “Protecting a swf

  1. Another idea is to database-enable the application and use the database to store various constants which are then loaded in to variables at run time and used with the application.

    If this is then obfuscated with one of the tools you mention, it would be very difficult to firstly figure out what’s happening and secondly, successfully capture valid values for each variable and prepopulate in a route which replaces the db functionality. More effort, in fact, than it’s likely to be worth!

    Mind you, setting this up in the first place is quite a task in its own right!

    Jamie.

  2. Great article, thanks a lot everybody. I tried all and I must tell Flash Secure Optimizer rocks! It also can add domain lock itself with only one button. Later I will also try the server variable loading which Jamie suggested. Regards everybody.

  3. Nice article. Especially the “playerType” thing – I didn’t know about that. But one typo though, the domain prop of a LocalConnection is a field, not a method.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>