How to protect swf from hackers!!!

Flash runs on the 'client side', which makes it vulnerable. There are several ways to hack a Flash game - intercepting and modifying/faking communications with the server (ie, sending fake values to your 'highscores.php' or whatever, say using an app like Fiddler2), decompiling the .swf to see how it communicates with the server (and any encryption or obfuscation it might be using to try and protect communications), or even directly editing the memory being used by the game (ie, using CheatEngine to change your score directly, the speed of the game, etc). It's pretty hard to protect against all these, and usually takes more time and effort than the game is worth.

So the best rule is, expect your game to be hacked. Don't use it as a basis for giving away an expensive prize, for example (or at least, don't let it be obvious that the winner hacked the game or other players will get pissed off), unless all the logic happens on the server side.

But if you still want to try...

Let's say your game consists of three types of processes - Input (from the user), Logic (the app deciding what to do with the input), and Output (the result of the logic). Input and Output have to happen on the client side, or the user won't be able to interact with the game or see the results of their interactions - so these parts can never be fully secured, only validated as acceptable or not. However, the Logic (all or part) could be done on the server, where the user can't see it or modify it. The Flash game takes the user's input (maybe makes sure it's valid), and sends it to the server. The server checks that the input is valid, and if so performs the game logic, and sends the output back to the Flash game. If the input is NOT valid, perhaps silently keep that user (account ID or their IP address, for awhile) from adding to the high score list, or interacting with other players. Or boot them for 5 minutes, or something.

The main problem with this is (depending upon the type of game) lag in communicating with the server, and server load. If every little input/output has to go to the server, be processed, and then be sent back to the user, the game could run very slowly for the player; or if many people are playing at once, the server could crash. So you probably have to find ways to optimise this, and decide what should happen on the server, and what can safely happen on the client side (and be fairly well validated), etc.

Gambling-type and turn-based games are fairly easy to secure this way, though, since lag won't affect gameplay too much and there's not a lot of information going back and forth with the server. Say in a card game, the server tells the flash what cards to display for the user. The user can only choose which card to play - this choice is sent back to the server. The server calculates the results of the play, and the other players' moves, and then tells the flash what new cards/scores to display.

A real-time shooter, on the other hand? Even a game of Pong can be tricky. In those types of games, you could potentially send some data (user's x and y position, current health, ammo, score, framerate, etc) every now and then (maybe obfuscated, checksummed, compressed, via socket, etc) and the server can see if they should be 'possible' and decide whether to keep accepting input from the user, but that gets pretty tricky really quickly, and you'll probably get far more false-positives than catch actual hackers.