Ideas for securely sending score to a central server

#1 One solution would be to use a short life encryption pad, so the encryption is only good for a few minutes.

There's a lot of trust involved when you're allowing the entire game to be in the hands of the player.

For the Score Logging MOD I did for Marbleblast I had checks for if people had enabled the cheat mode, if they were running another MOD, the scripts were only in .dso format, and I sent the mission file to the server to run an MD5 sum on it to compare it to the origional files from MarbleBlast.

#2 Hmmm - good idea. Maybe I should do something like:

Game Client                         Game Server

Starts game
   Sends start game command ---------> Creates one time session encryption key
                            <--------- Sends key back             

Plays game

Game ends
    Send various file md5 checks ----> Verify MD5 sum and record it for the session

    Use session key to encrypt score
    Send score              ---------> Verifies session key
                                       Checks that its not used before
                                       Checks that time from creation of key
                                       to now is less than x seconds
                                       Records score

(Sorry for the lame ascii art)

Add in a few challenges and that might be "secure enough"


Another way could maybe be to run part of the game on the server side, with the client only being render agent (as you implicit suggest). Since this is a single player game with potentially hundreds of games running at the same time, then some changes will be needed on the server though - if I dont want to run tons of game server instances

#3 Is the server in control of users or the service providers?

#4 The central server to record the scores would always be in control of me/ISP. If this was to be made using a game server hosted at an ISP, then I'm unsure how to handle all the instances I need to run it all. The footprint of a server isnt that big, but the pool of game servers would need to be quite large.

#5 I guess my point is, how do you prevent untrusted servers from faking scores?

#6 That brings up a more interesting subject besides a single player game with a single score server.

Multi-player game servers and how do you ensure those scores are not fake.

With Americas Army they will only allow servers they run or servers leased from a company they have certified register scores on their master database.

While that would mostly be impractical for an Indie project I think you could take that idea and work with it.

If someone wants to run a "sanctioned" server that can send scores to the central score server, they would need to register their server. At that point they would have a GUID issued. Use the challenge response method discussed earlier, including the random MD5 sum check to verify the communication with those servers and also record the GUID of the server with the logged score. If that server is ever found to be possibly faking scores, you have a way of removing those scores from your master server.

#7 One possibility there, is to have a remote server command that can "dump" information about the server. So basically, you can request random file information, random script function/variable naming etc.

Essentially, you need the server to run a script which can be then altered by the master server such that it can alter the checks it does (so if someone patches it, you can unpatch it, or detect the patching).

One of the great things about scripts is thier on-the-fly execution.

#8 Yep, I used the script regeneration to re-write the scripts for the ScoreLogging MOD for updates, etc.

#9 Good responses - thanks.

Ben: In the case of not comming up with a 99.999% secure plan for letting the clients run the game, then I would separate the client from the server and I would be the only one running the game server instances. That way I can be fairly certain that the score is real - but it adds a lot of problems.

Easiest for me would be to have a system that can trust the client - I know thats almost impossible, but thats why I ask for ideas ;-)


But as Harold points out, this has the dimension of how to trust scores in general. The technical problem/solution is the same.

When you put up high scores, some ppl _will_ try to cheat. Anything from cheating the game to hacking the protocol.

So how can we trust a client (in case of the game server being "secure") or the game server (if that is unsecure)

An encryption scheme only secures the communication - not the content at sending time. The encryption key will have to be present on the client at some point in time (hard coded or sent to the client), which makes it "easy" to grab the key, put in faked content and send it off encrypted. So this will lead to false security.

MD5 checksums on files - client can fake this if its not a random query. As suggested by Phil you need the server to query random files. Else a client could just pre-calculate the correct MD5 for his files and send that number back on request - while having modified files.

Recording demos and sending them to either a server for automatic verification or manual verification by a human. Might work, but adds a tremendous amount of manual work to verify the score. All it verifies would be that a game HAS been played with a particular score, but it would not verify that the user hasnt cheated in some way (e.g. autoaim scripts or something similar)

Server could have a build in "max score vs time played" calculator. E.g. if you can create a linear function of the maximum score you can obtain within a certain time, you could use it for verifying that the demo/score send in doesnt have an unrealistic score. If your function is maxscore = time * 10 points/min, then a 5 min game has a maximum score of 50. If the client sends in a score of 500 you know its a fake.

Maybe some combination of the above+other checks could be deemed "secure enough"?

Other ideas?

#10 "Other ideas?"

Yes, make something worth cheating at first...

#11 Well - in my case the score will determine who gets cash/items of considerable value - that should be "something worth cheating" for.....

#12 Here is your original question:

"Does anyone have good ideas for how to secure the communication, so that no one (easily) can hack the protocol and send in fake scores for themselves?"

The word easy in this sentence is directly related to the value of these cash/prizes. I mean, if hacking your game nets me $10k, a couple hundred hours spent hacking would be worth it.

Here's a secure solution: You pick a number, like 1-10 ... People email you guessing the number ... the 1st email with the right number wins cash/items of considerable value.

#13 @Josh: Normally, discussions like this are something I shy away from, however, I can vouch for Thomas being competent at what he does - and this is a discussion that has some value for me and the projects I'm involved with.

@Thomas: The matter comes down to trust. You can set up a secure connection and transmit stuff down the wire and have trusted people run game servers... If you're looking at cheat detection stuff, there's a lot to be learnt from the Halflife community and from sites like Neopets.

#14 Yep - I am dead serious about this Josh. I'm not a n00b 10 year old coder who wishes to make Doom 4 within a month - if thats what you think.

Cheat prevention and who to trust is a serious thing for all of us - online gaming or in my case single player but with a score I need to be certain is correct. And personally I dont want to go the way of punkbuster and similar programs. They can only react to cheats known - not prevent them.

From what I can read from the above there is no way to trust the clients for anything. And even just having them as input/output agents cannot be trusted (autoaim, script exploits, things like the ATI wireframe GL driver)

So its down to having minimal capabilities in the client, run servers on trusted hosts only. And even then try to incorporate some of the measures mentioned above

#15 "And personally I dont want to go the way of punkbuster and similar programs. They can only react to cheats known - not prevent them."

It's my understanding that PunkBuster uses active memory scanning to insure that outside influences cannot alter your game without detection. Using a hacked .dll to see through walls or something of that nature would be caught by punkbuster because the graphics that are loaded in memory would not match the checksum they were supposed to. Using outside scripts to assist the game would do the same thing. PunkBuster need not know the script exists, it would recognize that an outside source was trying to alter data that it is tracking.

There is a certain amount of intimidation that can be used as well. If your game is free, but useless without an account lets say, then the purchase a customer makes is for the right to use an account with the provided game interface. Setting forth in the agreement that any cheating will result in account termination will keep most cheaters looking for a game that won't cost them money if they get caught. And of course, if you got some idiot that just cant help himself, you can always sell him account after account after account till he decides that it's just to much money to be an idiot with your game and moves to somewhere else. This would allow you to authorize users before they can reach any server to play, and would also allow you to remove any suspected cheat servers from the master list that is sent to the players client.

#16 Of course, punkbuster can be defeated by kernel-level attacks, but that's beside the point. There is a place for punkbuster, and there is a place for strong design. The two approaches complement one another.

And, remember, these are games. We don't need to kill all cheating, just make it not worthwhile. Punk buster, intimidation, and strong design all combine to do that - and social solutions are generally more effective than technological solutions anyway.

#17 "And, remember, these are games."

Exactly. But the very nature of a game is NOT to have fun like some would claim, but to compete, be it against ourselves, a clock, or another player. The fun comes from the thrill of competing, but there is no point in playing at all if your opponent is cheating. Therefore any game that has cheating going on is doomed to failure. Cheating should be a top priority for any programmer in my opinion. I've spent so much time eliminating exploits from code that I can see and correct an exploit before it can be exploited. But if your not looking for stuff like that, then your going to be repairing it all the time when it's being abused.


Cheating is not the only thing you should consider either. As strange as this sounds, when I'm looking at my work, I look at it from an "assholes" point of view. Meaning, how can I piss people off? I do this because an A-hole can ruin your game pretty fast as well. Tribes 2 was a perfect example of this. None of the people involved in T2 development were A-holes, so they didn't know there were going to be incredible numbers of problems when they put all different types of folks into the game who each have their own ideas about how to play. Take the vehicals for example. Eventually changes had to be made to keep someone from stealing the shrike you just purchased. The reason the change had to be added was simply because no one who was building the game would have ever considered stealing his buddies shrike. But we all soon found out that once it was done the first time, it spread like wildfire across the servers and chaos was the norm. So a fix was made. I'm not saying everything can be forseen, but certainly a lot of obvious stuff can be eliminated long before it's even played.


My partner and I have already decided that we are going to beta test our game with a select group of people that we have determined to be the most likely to find any cheat that exists simply because they are well known for cheating and exploitation. Most of them are jerks and scriptors as well so they will be able to offer us valuable insight into how well our game is actually constructed and what kind off problems a self-minded individual could cause.

It really is a shame that we have to consider these types of things at all, but I have seen how cheating can destroy a good game and I for one wil do everything in my power to ensure that players in my game get a fair and fun environment. Nothing is fun about being cheated.

#18 I am working on a secure way of doing something similar right now on the massively multiplayer engine we are building.

These books have been very helpful

* An Introduction to Cryptography
* Introduction_to_Cryptography_With_Java_Applets
( even appliciable to non-Java programs the principals are the same )
* Modern Cryptography
* Handbook of Applied Cryptography
* Writing Secure Code

our current site implementation is not secure ( someone else wrote it ) and we have lots of problems with hackers mucking about with peoples accounts after tricking them into revealing their session id. So having a more secure site is one of the primary goals for our development of a new game server engine.

There are mainly two separate problems to solve.

1. Secure Authenitcation ( is the client who they really say they are ) - SHA1
2. Encrypting the data sent across the wire. - PKI

If you can prove that the client is who they say they are and fingerprint the contents with something like a SHA1 hash you don't really need encryption of the payload if it is ok for people to see what the contents are.

The most important thing is to write secure code to begin with. No bufferover runs, no .dll's, no plain text in untrusted code, all client side code must be considered "untrusted".

On the other hand if the contents are private then you need encryption.

Since I am very big on not reinventing the wheel consider SSL. Every web server worth using supports it, and you could publish a webservice that any SOAP or XML-RPC client could connect to. If you just want to send stats securely that would probably be enough.

#19 I am working on a secure way of doing something similar right now on the massively multiplayer engine we are building.

These books have been very helpful

* An Introduction to Cryptography
* Introduction_to_Cryptography_With_Java_Applets
( even appliciable to non-Java programs the principals are the same )
* Modern Cryptography
* Handbook of Applied Cryptography
* Writing Secure Code

our current site implementation is not secure ( someone else wrote it ) and we have lots of problems with hackers mucking about with peoples accounts after tricking them into revealing their session id. So having a more secure site is one of the primary goals for our development of a new game server engine.

There are mainly two separate problems to solve.

1. Secure Authenitcation ( is the client who they really say they are ) - SHA1
2. Encrypting the data sent across the wire. - PKI

If you can prove that the client is who they say they are and fingerprint the contents with something like a SHA1 hash you don't really need encryption of the payload if it is ok for people to see what the contents are.

On the other hand if the contents are private then you need encryption.

Since I am very big on not reinventing the wheel consider SSL. Every web server worth using supports it, and you could publish a webservice that any SOAP or XML-RPC client could connect to. If you just want to send stats securely that would probably be enough.

The biggest thing is to write "secure code" to begin with. No buffer over runs, .dll wedges, or plain text in untrusted ( client side code ).

Half-Lifes problems were multifaceted in that none of the client code was secured. All the hacks are .dll wedge attacks and the like. None of their "anti-cheat" measures were effective because the client code was defective as such a base level.

The CSS in DVD's was "broken" by some dumb ass leaving a passphrase key in plain text in an executable. Once that was out, they were able to pass that key to all the DVD's and thus DeCSS was born.