We here at Squidder often work on sites that tease new information and images through a cool flash interface. You know: you’ve got to unlock x by doing y and then you get rewards z.

One of the biggest challenges we run into when doing those sites is how to keep people from getting that information before we’re ready for them to. Sure we could just load all that junk into swfs and hope that people don’t decompile it. But that’s runs counter to how we usually like to develop things: lots of little, external files, loaded on demand.

But of course, that presents it’s own problem: You, the clever public, can just look in your activity monitor and access the files directly without jumping through all of our cool little hoops.

The solution: ncrypt our external assets and then decrypting them after we’ve loaded the byte data into the flash. Well, that’s easy enough to write a encrypt/decrypted tool using something like as3crypto. But we here at the big S like to be a little lazier. We don’t want to have to decrypt our xml files (or our images, for that matter) to edit and them and then reencrypt them when we’re finished. We’d just rather make the changes and have the encryption only appear on demand when you’re accessing the file from a web browser…

That’s why we were so excited when we found this article over at Zedia Flash Blog, which provides an easy way to encrypt something via PHP and decrypt it via Flash (or the other way around).

So you’re thinking “Ok that’s easy, I’ll just  make a php script that gets passed a file via GET or POST that returns the encrypted file like this one”:

<?php
require( "Crypt.php" );
$crypt = new Crypt();
$crypt -> init( "TESTTEST" );
echo $crypt->encrypt( file_get_contents( $_GET[ "fileToEncrypt" ] ) );
?>

Then I’ll just request all my assets like this “encrypter.php?fileToEncrypt=info.xml”.

But that only takes us so far. Sure, you could post that variable, but users could still easily figure out where the “fileToEncrypt” file lives and access that directly.

So that’s where our last ingredient comes in: our friend the .htaccess file:

RewriteEngine On
RewriteCond %{REQUEST_URL} ^/.*xml$
RewriteRule ^(.+)$ encrypter.php?fileToEncrypt=$1 [L,QSA]

As you can see, the server takes all requests for xml files and routes them through the encrypter.php file, which returns the encrypted php file.

As far as the user can tell, the file is well and encrypted on the server. But you, the site owner, can go and make changes to your hearts desire and not worry for a moment about having to re-encrypt anything.

Finally, what makes this the business is that you can auto-encrypt ANYTHING. Swfs, jpgs, pngs, xml, whatever. If you’re loading byte data, all you need to do is load them in via a URLLoader and the use Loader.loadBytes. All you need to do is modify the .htaccess as so:

RewriteEngine On
RewriteCond %{REQUEST_URL} ^/.*xml$ [OR] %{REQUEST_URI} ^/.*jpg$ [OR] %{REQIEST_URI} ^/.*swf$
RewriteRule ^(.+)$ encrypter.php?fileToEncrypt=$1 [L,QSA]

Obviously this puts more of a strain on your server. So it really only makes sense for things that are constantly changing. And of course, someone can just decompile your flash and grab the private key. But if someone’s doing that, well, then we’ve already engaged them in the teaser more than we could have possibly hoped.

Enjoy responsibly.