How can I prevent false score reports to global highscore tables?

Question

Browser and mobile games commonly have global highscore tables. It's also common for those tables to contain scores of 2,147,483,647 — where people have figured out the webservice call that reports scores and used it to record a fictitious score.

For simple puzzle games, we can defend against this by including a record of every move the player made (and any random seeds used to generate the level) with the score-reporting call. The entire game can then be reproduced and verified on the server.

However, this quickly becomes infeasible for anything larger than Pac-man.

How else can cheating of this kind be prevented?

Answer 1

The internal system we used for Moblox (later replaced with OpenFeint) worked like this:

• Send a JSON message over plain HTTP (not HTTPS). Include a MD5-hash of all fields plus a magic string.
• On the server, check the integrity of the message with the same operation.

To crack the system, you'd have to find this magic string. It is possible with reverse engineering, but painful.

OpenFeint, ScoreLoop and CocosLive all use the same trick, but with HTTPS. Very easy to implement.

Answer 2

While you're right that it's not always feasible to send entire replays to the server for complex games, a similar system can be used by having the server periodically (and semi-randomly) ask the client for some part of its state, while the game is running.

For example, in an FPS, every minute you could ask "How many kills do you have?", "Where are all the enemies?", etc. If the client doesn't come back with a reasonable answer to a challenge in a reasonable amount of time, they are cheating.

Of course, this only works if the game is online during the entire play session. Since the goal here is to be able to upload to an online leaderboard, I think that's reasonable - don't kick the player out of the game if they answer wrong, just don't let them on the score list.

I would encourage you to reconsider sending replays however. All you really need is the initial random seed and timestamped input. This should really be a few hundred KB at most. Many arcade games do this already to save replays for player review purposes; having your server validate these might not be trivial, but it prevents all kinds of cheating except botting.

Answer 3

You can limit the most flagrant of abuses by monitoring the highest results in the top score table. Depending on your game, you may have a "perfect score," above which any score must be fraudulent. If not, you can calculate the lowest "impossible score;" can the player shoot 10 shots per second, the game lasts 1 minute, and each killed enemy is worth 100 points? Then any score higher than 60,000 must be fraudulent.

You can also help mitigate the problem by sending along some metadata; not the full game history, as you describe, but just the components that make up the score. Say: score 60000, 500 enemies killed, and one bonus item grabbed. You can then perform simple checks. This is "security through obscurity," and therefore not secure at all, but it helps eliminate the most naive of attackers.

Answer 4

Ultimately you can only rule out impossibly high scores, because the rest are (by definition) merely implausible, and thus might be a legitimate (and awesome) player.

Otherwise you have to rely on obfuscation techniques (such as encryption, and sending other stats beyond just score).

You could also send the score periodically as the game is being played, which would add another level of complexity to cheating - i.e. the server can decide if the game has been played long enough to warrant a particular score, and also ensure that enough intermediate reports were received during the play-time (just don't make it 100% or the train going into a tunnel on my way home will result in my throwing the phone out the window).

Ultimately someone will find a way to break it though, so don't kill yourself trying to stop them.

Answer 5

I added a quick/dirty high score table to a project of mine a while back and not being at all versed in internet security/etc it turned out sort of flawed. Surprisingly, with nearly 1,200,000 recorded scores, I've only had maybe 5 or 6 occasions of batches of blatantly incorrect scores reaching the top of the board. Most of the scores even looked more like a glitch in the game, than a true "hacking".

So I guess an important point is: make sure your game's scoring system is airtight, or at least do some really good score feasibility checking; now, this game I'm talking about was a Ludum Dare 48hr entry, so it wasn't the most stable thing around.. but on the whole I think it's often more likely that the casual player will discover/exploit an ingame glitch than having someone directly "hack" the leaderboard.

That said, I'm working on a rewrite of this project right now, and I'm going all out with the obfuscation. I won't go into too much detail, but I basically have all scores submit a key value based on a bunch of random values and hashing and a magic string, then any score that passes that check and is high enough to make the actual "Top X" leaderboard has to pass another round of validation (this time with an expiring key value generated on the server end, and more thorough feasibility checks).

I'd also advise using a packet tracer of some sort to test out what sort of things are visible (I was originally doing a much simpler verification that meant someone could use a packet tracer to find and duplicate an uploaded score's http request, without knowing the magic string or anything (meant you needed a legit score first, but you could send duplicates of that score as much as you wanted..)). I used Wireshark for testing this.

Huh, this turned out a bit long, but hopefully it helps...

Answer 6

I am not an expert in this field but if I were you, I will try to encrypt the score with an key embedded in the your code. Those people will need to apply reverse engineering over your code instead of the plain text used for the web-services.

Answer 7

Speedruns are basically recording of every keystroke, and they are recording about a WHOLE game. So, yes, you can record the whole game, it's not unfeasible. Any other way to do that is crackable through reverse engineering (I can't stress it enough: you're not adding security, you're adding obscurity).

Still, even if you do it this way they could actually submit a speedrun. You can do nothing to prevent that.

Answer 8

While you're at it, there's the question of whether a high score is simply a player who found an exploit (for example, if some things in the game give a score penalty, and a bug causes a negative score to "wrap around" to become highly positive... or just a player who finds a certain game condition like a safe spot on the board where they can just sit there and not have to worry about losing, indefinitely).

In order to tell the difference between a hack and a game exploit, uploading at least some play data would be good. It'll help you fix the exploits, at least.

For some games (particularly turn-based ones), you can actually have the game played through the server, where all of the game logic exists on the server side and the client is just an interface. This not only makes score hacking a lot harder, but it also enables you to log all player actions on the server trivially, and thus replay any game at any time. I realize for something like a twitch action shooter, this might be impractical.

Answer 9

Make all randomness origin from one seed and store the input for every frame. Whenever you have a claimed high score (say top 50), send the seed and the full input to the server. Replay the game on the server and update the leaderboard if you get a high score.

If you consider this unfeasible for more sophisticated games because of the size of the request, take a look at this example.

Say the game has 8 button input (1 pad and 4 buttons) and runs at 60fps. A one hour game input can be transmitted with 3.6KB without compression. Your session will probably have less than one hour and compression should shrink that by a lot, because human input has a lot of redundancy.

The challenge is making the game deterministic, playable from recorded input and executable on the server.

Answer 10

Never implemented this before but...

Send scores incrementally with timestamps. This gives you a log to see how often the score improved as well as a way to trace the highscore's "momentum".

You would then set milestones/criteria for your scores.

For example: A score greater than 20,000 can not arrive in first 20secs of a game. An score greater than 250,000 can not arrive without an entry greater than 200,000.

This is not exactly the same as sending a game state, but close to it.

Side Benefit: Think of all the useful game play statistics you would get from this. Someone would prob pay good money for that.