Richard Leggett on New Media

So following on from the first part of this discussion I was asked to look at creating a 10 day trial Flash Lite application. The theory is sound, you either contact a server and pass it the IMEI (best option), or work out a way of storing some information on how many uses have taken place locally on the phone, either using plain-text, a hash or some real encryption.

In Flash Lite 2.0, we can do this with Local Shared Objects, this is also great to keep the information from prying eyes as you have to know where to look for the SO's in order to try and crack them, the down side is that a little bit of digging a while back showed they look fairly similar (if not the same) as desktop Flash Player SO's and therefore there are already tools available to read them. Either way, they are a boon to Flash Lite development for many other reasons.

However, we aren't able to use SO's in Flash Lite 1.1, so we are going to use a very simple EXE bundled with the app to write to and update a text file, "config.dat".

The first step is to create a new Flash Lite 1.1 FLA, and create a sub-folder in it's directory called "config". Into this we put our EXE, Christian Halbach's flash2file (for which the source is available), and a plain text file named config.dat, which contains the following text:

uses=295

You might think that it's strange to set the number of uses to 295 to start, but this is because we are piping that number through a formula to figure out the real number:

Figure to store = 300 - (3n^2 + 5)

Where n is equal to the number of uses so far. So with that in mind, we can visualise a table to suit:

Now that we can "hide" our number of uses in a not so obvious manner, we can go about hooking up our Flash Lite app with flash2file to read and write this value. On frame 1 I have the following code:

fscommand2("SetQuality", "high");

// Load in number of uses so far
uses = -1;
loadVariables("config.dat", "/");

On frame 2 the following:

// Loop until number of uses has loaded
if(uses != -1)
{
// Convert figure to useable value
// i.e. find x where x = 300 - (3n^2 + 5)
numUses = 300 - uses;
numUses = (numUses-5)/3;
numUses = (numUses==0) ? 0 : int(Math.sqrt(numUses));

// Display usage information
gotoAndStop(5);
}
else gotoAndStop(2);

...and finally on frame 5:

// Display number of uses
usesTxt = numUses add " uses so far";
if(numUses>=9) usesTxt = "Demo expired";

// Path to flash2file.exe
appname = "c:/documents/flash/flash2file.exe";

// Path to the file to write to
path = "c:/documents/flash/config.dat";

// Update numUses
numUses++;
uses = 300 - ((numUses*numUses)*3 + 5);

// Text to write to file
txt = "uses=" add uses;

// Update number of uses to text file
argument = appname add "," add path add "," add txt;
fscommand("Launch", argument);

As you've probably guessed, I've got a textfield with a variable name of "usesTxt", and not much else apart from the code. That's it. Now you could either exit the app, or display a nag if numUses is >= your desired figure.

Now we are ready to copy it all to the phone in order to allow flash2file to do its job... So our directory structure that we will mirror on the phone is as such:

- 10daytrial.swf
- config.dat
- flash2file.exe

Finally, copy the SWF and config folder to the phone's c:\documents\flash\ folder, and test the SWF. Ideally you would package this up as a SIS installer and get it to install to a non-public folder to better hide your config file.

You can download the finished project here - I have not included flash2file.exe as Christian has requested that you contact him for the latest version.

Summary:

This method is inherently insecure. The reason for this is that we are using some incredibly weak protection, simply using ord() and chr() to mask the number of uses is not really acceptable, but even if you did take the time to port md5 to Flash Lite 1.1 the SWF is still accessible, decompilable and crackable. There is nothing we can do about this, it happens on the web all the time. On the web we like to let the server deal with the security. On a phone we can do the same, but that might annoy the end user, so instead we need to look forward to some DRM integration and standardisation across the handset manufacturers in order for Flash Lite to leverage this functionality. One plus point is that mobile content is dirt cheap, it has to be; and it is therefore not usually worth the time it takes to crack even the simplest form of protection we might employ. The ringtones and mobile downloads industry is still booming even though people are able to bluetooth items for free.

Note if you are using the Flash Lite 2.0 player:

If using the FL2.0 player you will need to change the paths to c:\Nokia\Others or e:\Others for the Flash Lite player to pick up your SWF and for the app to function correctly.