Most flash developers at one time or another have run into the requirement of transporting data between the client and the server unmolested. As simple as it sounds this is a surprisingly difficult hill to climb with no perfect solution. There are tons of methods for safely moving data, some much better than others. I’ve put together a list of 8 of the best here.

Warning: Even if you employ all 8 of these methods, it is still possible for your data to be tampered with but there will be a much smaller population with the ability to do so.

What we’re up against

It’s difficult to understand why we need to go through so much trouble without knowing a little bit about some of the common tools the other team uses.

Tamper Data is a Firefox plugin that allows users to view and modify HTTP/HTTPS headers and post parameters (any data we send to the server).

Cheat Engine is a windows utility used for memory scanning among other things. It allows users to change variables stored in the memory of an open flash movie.

SWF Decompiler converts SWFs into FLAs.

The Checksum Method

To check whether or not any data has been modified in transit, append all the data to a single string and hash it with a salt before sending.

md5(name + score + currentTime, salt);

Don’t forget to include the hash when you send the data. On the server, rehash the data you receive with the same salt and compare the two hashes. If they don’t match, something has been modified in transit and you should discard the data.

Encrypt and Send

Fairly self explanatory, encrypt all data before sending and then decrypt on the server to prevent data tampering en route. XML-RPC is a good option.

Server Based Calculation

This is by far the most complicated method to implement and is really only useful for flash game score submission. The idea is to use the server to track any action the user makes that would effect the score and calculate the score on the server where it’s safe. For some games this is simply not possible and for others it’s too time consuming to build to make it worth while. When it’s possible and worth while it’s one of the most secure methods and it can easily be paired with cheat detection algorithms on the server to prevent the user from simply submitting actions.

Variable Verification

The above methods are great for preventing tampering while transferring the data but they do little to prevent local tampering. Variable verification is just recording any important variables in several locations. This can be made more secure by offsetting the variables.

var points:Number = 0;
var vpoints:Number = 345;

function addPoints(p:Number) {
    points += p;
    vpoints += p;
    if(!verifyScore()) {
        //cheating detected
    }
}

function verifyScore() {
    return (points == (vpoints - 345));
}

If you looked into Cheat Engine at all you probably saw that the variable editing is done with memory addressing which makes it pretty difficult for less experienced hackers to get past even basic defenses like this one.

Dynamic Memory Addresses for Variables

Allocating a new variable each time you update something important will cause the memory address to change making more work for people using memory scanners.

var tmp:Number = score;
score = new Number(tmp);

Obfuscate Variables

Memory scanners will usually be looking for a specific variable type. Preventing this is sometimes as easy as casting a variable as a different type.

//to obfuscate
var score:Number = 200;
var o:String = Math.random() + ":" + score;

//to de-obfuscate
score = ((o.split(":"))[1];

You also get the benefit of overwriting whatever was stored in score so it won’t matter when they change the variable.

Encrypt Variables

Another self explanatory method. Using whichever two way encryption you prefer, keep all important variables encrypted except when you’re actively working with them. This has more overhead than the obfuscate variables method but is more secure.

Encrypt the SWF

All of these methods can be gamed by a skilled, determined hacker because decompiling the SWF is an option. Although SWF decompilers are getting more sophisticated they still don’t generate easy to read, easy to sort through code and even after sorting through the code, the hacker still has to get around all of the methods you’ve used to prevent data tampering. As a final measure of precaution, SWF files can be encrypted with tools like the one found at Amayeta.

None of these methods offer perfect security, but through a combination of them you can drastically reduce the amount of people with the skill to tamper with your data.