Craig Mattson (Personal Website)
Home - Blog, News, About MePrograms - C#.Net, Java, VB6MusicWebsites

Viewing News Article

High Scores and Hacking (04/01/2009 05:49:06 PM)

Ever wanted to create a High Score system, but couldn't think of a way to prevent (or at least, deter) hackers from submitting fake scores? It's something I'm facing at the moment, and I have developed a few theories with Advantages and Disadvantages below. Hopefully it may be helpful to you!

PHP Script using Challenge (Public/Private Validation)

1. Client requests challenge from Server (i.e. random value between 0 and 100, lets say 3 in this example)
2. Client processes using own algorithm (i.e. 3 / 22)
3. Client responds with result (i.e. send 3 / 22)
4. Server validates the result (i.e. checks to see if a request was made by an IP, then checks itself using the same algorithm - 3 / 22 == 3 / 22)
5. Server waits for score (encrypted of course)
6. Client submits the score (i.e. 500)
7. Server checks the score is within reason (i.e. below 1000) and stores it

The problem with this method is that it relies on a server that accepts any input. What is stopping me reverse engineering a client and obtaining the algorithm? All I have to do then is query the server for that value, calculate it myself, then send it a random score.

A replacement for an algorithm based problem could be an image validation problem. If I make my own image format up (which could be cracked), I could display it in the program and request manual input. May not be ideal on mobile phones or PDA's, but a PC based game could utilise it. Be creative! Algorithms don't specifically mean an equasion.

Direct connection to the database in a client

1. Client requests password from server (encrypted of course)
2. Client connects to server
3. Client runs SQL Code

Secure right? Wrong... If it's decrypted in memory, it can be seen. You could obfuscate it by declaring lots of variables, but at the end of the day, some function has to restructure it. Also, what is stopping a protocol analyzer detecting the password when it is sent to the server?

Capture User Input and Validate

1. Game Starts with an Array for moves declared
2. On each game update, add to the array a move type
3. Compress and weed out unimportant data (a couple of kilobytes per update at 60 frames per second can be in excess of 1MB per 10 seconds!!!)
4. Send to Server the Array with Score
5. Server validates all input
6. Server stores the results

This is probably one of the most secure ways but at an expensive bandwidth cost. You can reduce the updates to just each keypress at a given timestamp (pending your game is programmed not to skip frames), but as soon as you remove data - there's room for doubt which must be factored in. It would still be pretty hard to predict most of the game output. In something like Tetris however, you could seed the time and pass that to the server. This almost makes for a foolproof way, as a PHP script could detect an applications output.

Maintain a persistent connection

Basically it just involves one of the following methods:

  • getUrl() in Flash (or whatever is the equivalent now)
  • WebClient in .NET Framework
  • Url in Java
  • wget in Unix/Linux
  • javascript in HTML

The URL to request would be a heartbeat monitor which naturally would have a threshold as to what is an appropriate delay in respect to the internet. For instance, a gap of 2-3 seconds may be appropriate, or if you're really smart, use a Ping request to get the maximum delay and multiply by 2. This doesn't exactly solve a memory hack problem unless used in conjunction with the above.

- - - - -

So with that all out of the way, it's clearly evident that the best security is a big problem in regards to usability. This isn't practical, in particular in a game that has more than just a player update. What if we look at a phychological approach?

- - - - -

If any of you know me when it comes to security, you know I love honeypots (a mechanism to isolate "caught hackers" in a play pen to simulate a real target). For a honeypot to work properly (and not catch legitimate traffic), what needs to be done? We need to check the process.

Lets assume a .NET game at this stage. We use a php script to collect a score at We use the first method described as normal (i.e. numbers / compute the challenge etc...). Unless the server (or client) is dodgey, this challenge should always register true. You know something is wrong if many logs start appearing from all sorts of IP addresses. What we can do is check for normal application use. That is; lets say the game is delayed 30 seconds from replaying packets. We can use this to our advantage as a hacker may try multiple times rapidly to log a score.

What we do is instead of going "HA HA! YOU'RE A HACKER AND YOU'VE BEEN BLOCKED" (which would only result in a more determined hacker), we simply black list the hackers IP address (or username if applicable), and still post the score with a mark next to it. In a getscores.php file, you would read that blacklist and if the hackers IP address exists, then return all scores (otherwise return a clean set of scores). The hacker thinks he is successful when in actual fact - all you're doing is simulating the scores he wants to see.

After a few days, you could run a clean up and simply ban any user with a blacklisted IP address. Simple as that. (The reason I would use IP addresses is the hacker may log out / in and check the scores are right. You would also want to blacklist any usernames at the time too!).

This method isn't 100% secure either. If the hacker gets wind of this, the system is ruined (which is why a closed source server is the only protection).

- - - - -

At the end of the day, there's no one method that is always going to work. Everything can be spoofed, so all we do is make it harder. Some hackers like the challenge, others will go for an easier target with more damage. For instance, what type of hacker is going to spend 6 hours trying to crack a Tetris High Score list, when he could spend that same amount of time getting money in Habbo Hotel?

Anyway, this is just some food for thought. Good luck!

- - Craig Mattson

[Print View]