what goes about preventing cheating in forms of sending false highscores? I have had some ideas about preventing the client from simply decompile the classes and hardcode a score to send to the highscore server, but i've always found easy ways to break this.

any ideas? what's the common thing to do? one of the problems is that the highscore server is customizable to suit all games, not just one (read my game).

You can NEVER trust the client. The only way is that if you have a game server(that you have full control of) that calulates the highscore and send it to the highscore server and configure the highscore server to only accept messages from you game server. Can't come up with any other ideas.

1. the client starts a new game2. the client sends some message to the highscore server that he has started a game -> timestamp stored3. client plays for a while and game over4. client sends highscore to server5. the server checks the time elapsed (currentTime-startTime) and checks in some whay that the score is possible to get for the elapsed time.

for instance, say I get 1000 points when playing 5 mins (normal play), then getting 10000000 points in 2 seconds is not possible.

this should work pretty well. as stated before, it's easy to break. how? start the game, leave it running for a day in the background, send fake score to server -> tada!

The only way is that if you have a game server(that you have full control of) that calulates the highscore and send it to the highscore server and configure the highscore server to only accept messages from you game server

That's basically the same thing as sending it directly to the hiscore server as far as cheating is concerned. I'd still be able to send bogus scores to the game server.

Quote

for instance, say I get 1000 points when playing 5 mins (normal play), then getting 10000000 points in 2 seconds is not possible

No, but nothing prevents me from sending 2000 points after 10 mins, or 20000 after 100 mins. Or deactivating collision detection or whatever.

<edit> Oops sorry, you pointed that out yourself already </edit>

Bottomline, you can never prevent cheating if you depend on the client for score calculating. You can complicate things a little at best. The only way is to let the game and scoring happen on the server, not the client and then you'd still not be fully safe.

maybe a little encrypted native library as the score submitting client that only accepts the full serialized game objects which it validates somehow and from which it subtracts the score which (if validation was ok) it sends to the server.

That might be a little demotivating to hack but of course still not fully safe.

That's basically the same thing as sending it directly to the hiscore server as far as cheating is concerned. I'd still be able to send bogus scores to the game server.

Maybe I wasn't clear enough on what I meant. The game server shall contain all game logic and from it create the highscore. The client only sends "move left", "fire", etc to the server and the server checks if the fire hits the opponents and register this to the score and sends back a message to the client that he hit the bad guy. Without control of the game logic you can't trust the highscore.

But if you think of the amount of time you can add on your game on the subject of preventing cheats and the number of possible cheaters in your game I quess that the easiest solution is that you check the highscore yourself every day or so for scores that looks like cheating.

Yes, very true.My own hiscore server is completely unprotected (don't tell anyone ) but there's no need to invest time in that yet, as nobody seems to play the game anyway let alone hack it.First priority is to make the game fun I guess and then *if* cheating becomes a problem, deal with that then.

exactly... no need to spend hours and hours on something noone will ever try to do... concentrate on your game and the gameplay... worry about cheaters later... but try to have a little thought that it may come up in the future so that you code your game in a direction that allows you to add anti-cheats.

If anyone comes up with a neat solution to the hiscores problem I'd be especially interested as we're going to run a Million Points Prize promotion for Alien Flux when it's launched, and we need to make sure no-one's cheating because the prize is going to be pretty nice, like an Inspiron or something.

I toyed with the idea of recording the whole game but apart from being detrimental to performance it might also be rather bloody large.

why not? The game events themselves should be quite small - key and mouse events take up little space. Push it through a zip stream or something and you could end up with a small log of the entire game. Playing the game for 3 hours gives me 3*60*60*60*event_size = 648000*event_size uncompressed, if there's one new event per frame. And if you only let the winner(s) send in their logs, the online highscore might be wrong, but not the result.

Replaying the log shouldn't be a problem - either do it yourself on a client or let an offline server do it without the gl calls, assuming alienflux gamestate doesn't depend on opengl.

Recording will be tricky, for sure, because it'll require much thinking It would make it more or less a waste of time to try cheating that's for sure. The timestamp method is probably pretty easily figured out and hacked.

I'll investigate recording and see what it comes out like. It should zip up very, very small indeed.

I have implemented event recording in my current project, so saving and loading an event log is easy. If for nothing else, it really makes those intermittent bugs easier to find.

Anyway, to make it possible you have to record all game state altering events, including time. That last part is a bit trickier, but I guess you more or less do it already knowing that your game loop runs in a fixed 60 Hz. The article that inspired me is this one, found on gamasutra, describing some of the pitfalls of creating a reproducable engine:

You've yet to show how the simple algorithm I explained, one that can be found in any competent encryption textbook (alongside other algorithms that will show you how to do a fair coin flip or fair deal of cards between two parties), will not work.

You were right in part of what you said, "People have thought long and hard on this..." but you were wrong on all the rest. People have thought long and hard on this and they came up with some simple answers. You are simply choosing to ignore them.

You've yet to show how the simple algorithm I explained, one that can be found in any competent encryption textbook (alongside other algorithms that will show you how to do a fair coin flip or fair deal of cards between two parties), will not work.

Well, it would certainly make it hard to cheat, but it doesn't prevent it, due to the very fact that *in theory* you can generate six different keys, then when the other player picks an index, present the key that provides the number you want in that position.

Add to this the facts that (1) you could just generate two keys and pick the better result and (2) you're dealing with a short fixed-length plaintext, and it becomes more and more likely that there will be a mathematical oddity in any algorithm you try that makes it exploitable.

In any case, in this situation as presented you could have a process running off-line for months before a game generating all the keys you need. You only need to guarantee the outcome of a few important rolls, so it's not the processor-intensive task it first seems.

mill: All you need to do is restructure your entire game so it is expressed in terms of dice rolls and then implement JohnMunsch's suggestion. Then you need to restructure your High Score board as a peer and you'll be set.

Back in reality....JohnMunsch: We're never gonna agree on this so this will be my last response to you. Either you're missing the big picture or I'm missing the details. Either way you claim to have a grasp on the problems at hand so I'll patiently wait for a secure, cheat-free gaming experience provided by you in the near future. You could make a lot of money providing perfectly secure computing enviroments, everything from games to online voting could use your skills.

mill: There seems to be two realities here. John's and mine. Mine is other than a server side solution, you are wasting your time trying anything else. If you don't like that, pick John's.

I might have the IQ of a horse's arse but I completely fail to see how this dice roll example would apply to submitting a high score to a server.

I don't know about recording input too. It seems an awkward solution and I think I would (if I were to hack it) alter the client to be able to play back the recorded input and continue playing (and start recording input again) just before I made a mistake for example.

Actually, yes, recording a game isn't even foolproof because it would be technically possible to write a 'bot' to control the player's ship and essentially have perfect reactions (shield on just at the right time, instant rescue of blobs, etc)

I think the best way, for me, is to have a no-frills unencrypted hi score server and leave it at that, and stage an actual physical competition at GDC2004, IGDC, EGDC etc.

> I might have the IQ of a horse's arse but I completely fail to see how this dice roll example would apply to submitting a high score to a server.

He wasn't serious. There are algorithms for fair die roll, coin flip, and card shuffling. Those are probably sufficient to handle what the original poster (way back on page one asked for.

The more recent stuff about high scores is a different matter. I don't know a way for a normal algorithm to prove that you did what you say you did when all activity is confined to your machine and it only has the opportunity to look at the final result of a game playing session.

imagine each client has "computational unit" which receives blocks of initial data, computes something and sends results back to the server. server doesn't compute itself - it only dispatches packets of initial data and results between cliens(customers).

yes, you need great "dispatching" system, evaluation of concrete client's power, bandwidth and so on... but such a system could support really "massive" and "greed-for-processing-power" games based on the computational power of clients' computers.

as far as i know, many players usually simply chatting, so their 80% of all clients' computers could compute battles for 20% others who really playing. (maybe percents are different for different kinds of games).

If anyone comes up with a neat solution to the hiscores problem I'd be especially interested as we're going to run a Million Points Prize promotion for Alien Flux when it's launched, and we need to make sure no-one's cheating because the prize is going to be pretty nice, like an Inspiron or something.

I toyed with the idea of recording the whole game but apart from being detrimental to performance it might also be rather bloody large.

IME, you can get an awful lot of mileage out of "record each game", but in most cases there is absolutely no need to record a large amount of data. I've lots of suggestions - but it all depends on your threat model and sec policy.

It REALLY depends what cheating you want to prevent!

I was writing a different reply to this topic, but I might as well use this as a case study. First thing you must do is create a security policy and a threat-model; without those, no-one can help you.

Threat-model is a list of all the different ways you think someone might want to cheat, try to cheat, be capable of cheating, etc. It's rather like a requirements document in Software Engineering.

Security Policy describes stuff like the precise invariants you wish to maintain ("no player may ever submit an unrealistically high score"). Preferably it should state which security breaches are tolerable, and which are intolerable. A little similar to a specification document.

...then I can offer suggestions on ways to achieve the policy, in the presence of all the threats. Otherwise, we're all shooting in the dark / pissing into the wind / whatever pointless and slightly dangerous activity you care to choose .

PS: Although I agree with leknor's statement in general (in general, it is impossible to prevent cheating, unless you TRUST [control is never necessary - only trust is] the client environment), there are several successful solutions that work by redefining the problem. JohnMunsch has already talked about one solution to a particular set of problems - Leknor, you should really think about the bit that says "Works for two people; doesn't work for more", and John should really not make statements like "this doesn't work for more than two, but other things solve that" - it's too much handwaving to help.

For another example, I saw some guys @ GDC2003 with a system that let you run a game without the server-bandwidth, and at the end if you SUSPECTED someone was cheating (you didn't need to bother otherwise), you could get a check on their die-rolls. I wasn't much excited by it, because it was pretty simple - but if you had the right kind of game, it works brilliantly.

I actually skipped a question on my finals paper on this topic, because I knew of several cases which show that there is NOTHING you can do if you want to completely prevent cheating without any server logic on a large scale. My answer would have said something like the following:

Anyone can write a program that peeks at the memory locations and identifies the point where you have a decrypted copy of the score, in order for you to add points to it (or whatever you want to cheat on). They pause the program (using a live debugger) every time that memory changes, and edit it to suit their fancy. Voila.

Note: this has been done before for at least one commercial game; IIRC, it was what brought Diablo to its knees, security-wise, in the end.

This kind of threat is valid for most situations where you have any data that the client is going to alter, and then act upon.

Recording the whole game won't work for all the reasons already covered. The only way to run such a contest and be guaranteed of no cheating is to run it in a closed and controlled environment.

I wrote a cheat for minesweeper - I had a program that read the screen bitmaps and sent mouse clicks to the app. Other than being played very well and very fast, the minesweeper program had no idea it was being cheated.. it was all the original code - no hacking needed, and it could do whatever it wanted to send highscores to a server.

Recording the whole game won't work for all the reasons already covered. The only way to run such a contest and be guaranteed of no cheating is to run it in a closed and controlled environment.

Ahem. Indeed. To quote myself: "in general, it is impossible to prevent cheating, unless you TRUST [control is never necessary - only trust is] the client environment....", but "...you can get an awful lot of mileage out of [recording]".

Equally, without a sec policy and threat model, your statement and your anecdote are misleading (even if accurate). Without these two sets of information, there is no conversation to have here - leknor said it all in his first post.

I tried to point out that recording actually is a very useful technique, as it appeared that people were already on the verge of giving up on it. I didn't highlight any other security measures, simply because there isn't enough info to do so.

The system I'm running with for Alien Flux has been nailed down now as follows:

Rather than recording the whole game I am recording a very large number of game statistics:

Score

Lives lost

Level attained

Shots fired

Shots which hit aliens

Smartbombs fired

The number of frame-ticks elapsed whilst the player was alive

The number of shield-ticks the player used

The player's registration code

Indirectly of course, I also know the IP address of a hiscore submission and the time I received it

It is of course trivial to spoof these values but I suspect it's less than trivial to spoof all of them at the same time to the point where I can't detect scores that fall outside two standard deviations from the mean after collecting a lot of real hiscores. I can improve and refine my analyses over time.

My two intolerable security breaches are that 1) unregistered users are using the hiscore server and 2) that people are faking hiscores

What I'm left with then is a multi-pronged approach to preventing security breaches.

Firstly, someone has to want to cheat in the first place, and believe it or not, 90% of users don't actually want to cheat to obtain hiscores, even if I'm offering petty prizes.

Secondly, someone has to bother hacking the code or the protocol and this will eliminate 50% of the 10% of users that want to cheat because it's nontrivial for non-technical people or beyond a lot of people's laziness to bother doing.

Thirdly, I can detect the registration code, time, and IP address of a hiscore submission and in a very short space of time I can tell if it's a hacked code and block it on the server, after giving the official registered user a new registration code.

Fourthly, by analysing statistics from trusted sources (ie those players known to be playing for real) I can build up a graph of correlations between pairs of data and flag scores as suspicious when they fall outside of the range of acceptable values and acceptable correlation. Once a suspicious score has been registered I can flag a registration code as suspicious as well and scrutinize the statistics even more carefully. Although I will never block a valid registered user from using the hiscore table I will reserve the right not to post hiscores when I have determined someone to be suspicious. Or perhaps post them on the Suspicious Scores table.

All of which will add up, I think, to an acceptable level of hiscore security.

Also by clearing the online hiscore server every week I'm hoping that cheaters will get bored of the game rapidly once they start cheating and stop playing it, thus removing themselves from the hiscore tables of their own accord.

All to be determined, of course...

<edit> Oh, and there's an interesting side-effect of hiscore tables that I can take advantage of too: if you're not playing to win, ie. get the no. 1 hiscore, I don't care if you're cheating or not. Indeed, if you cheat but don't get the no. 1 spot, what's the point in cheating? It's a lot of bother to go through to get second place and not win the prize. The conclusion I can draw from this is that I can ignore cheat analysis on anything other than the no. 1 hiscore.

What might help too is not to give feedback if the hiscore has been accepted or not until the contest is closed so that the cheater will think his/her score is accepted and not bother to really hack it.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org