Game/Server communication security

[neoskunk]

What stops someone from playing my game as an applet and then reverse compiling the classes and modifying the game to their advantage?

I recently put my game out on the net as an applet and I have been wondering about this.  It seems like it would be fairly easy for someone to do this.  Is there some way to program a secret passkey into my code that must be transmitted to the server on initialization?

[zoto]

You can't trust anything from the client. Any protection you put in the client will be disabled or circumvented.

Program the server to assume all clients are hacked. The client should only be able to make requests to the server, so for example just because the server is spammed with attack message it only attacks as normal.

[zammbi]

If this is a online game, Never trust the client.
Doesn't matter if its an applet or not, any game is easy hackable.

Games published by our own members! Check 'em out!

[neoskunk]

I was afraid thats what the answer was going to be .    Doesn't this put a large burden on the server though? 

[zammbi]

I was afraid thats what the answer was going to be .    Doesn't this put a large burden on the server though?

Depends on what the game is. Usually you avoid putting physics on the server. Or anything else that's just for looks.
Some games cheat a little and do some things client side  and then do basic checking on the server.
For MMO type games you want to check everything, for FPS you probably want to cheat a little.

[neoskunk]

Thats what I was thinking.  My game is physics related, similar to worms.  So i was thinking maybe just have the server "filter" what is sent from client to client.  As well as make sure that clients are in sync and all moves are legitimate(ie. character has not moved past a structure or through it).  However, i would also like to keep clients from hacking my game to always send perfect hits but I guess that can't be helped...

Is there anything that would at least make hacking the game a pain?  Some sort of deterant? 

[zammbi]

Well if your not supporting that many people or that its turned based then checking for everything wouldn't be that intensive.

[dbotha]

You could try adding some sort of checksum to all your messages. This should act as a very basic deterrent against the casual hacker who randomly change bytes in an attempt to reverse engineer your protocol. Also using a binary protocol for your packets and encoding data at the bit level (as opposed to byte boundaries) where possible may obfuscate things a little. You could attempt to encrypt every packet, although this as with the other suggestions probably will not pose too much of a problem for a determined hacker. Perhaps slow them down a little. If I remember correctly there is an article in one of the Game Programming Gems books that touches on this subject, I'll try dig it up and offer some further suggestions.

[DzzD]

Is there anything that would at least make hacking the game a pain? Some sort of deterant?

1) you can do server side validation on action, logic & network packet format, once a validation failed => logout the user and only enable him to log again after n seconds ( or 1 minute ), this is what will give the most pain to a guy trying to hack your game beacause each time he will try something wrong he will have to wait to make another try (he wont be able to do tests flood)

2) but the most secured way (that cannot work in all case, especially when a game requiering too much computation per client) would probably be to perform all the logic server side and only let the client act as a remote controller & passive viewer, this way your game may not be hackable (as long as your server itself is not hackable too), this is for example what is used for online poker game where a lot of money are engaged and in wich security is important, note that it can also be used in a not turn-based game, for example I use this in a game I am being working on at the moment wich is not turn based

3) = 1 + 2

[neoskunk]

ok this may be a little off topic but following from number 1 of your suggestions DzzD, how would i go about keeping someone from connecting for 1 minute?

Games published by our own members! Check 'em out!

[DzzD]

ok this may be a little off topic but following from number 1 of your suggestions DzzD, how would i go about keeping someone from connecting for 1 minute?

once gain it depend on your architecture, but if client have to use an account to login to the game you can keep last connection attempt (serverside) for this user and a flag indicating if it have to be delayed

[Eli Delventhal]

I was making a multiplayer racing-type-game and initially made it so that absolutely everything was done server-side: input was sent from clients and the server did everything else (sending entity updates back). This is obviously the most secure way to do things, but most games don't do this pure approach. The issue is that the player can then notice latency incredibly obviously - there is a big delay from when they press a button and see the result.

What I have been planning on doing but haven't had time to would be to have the client control the entity positions directly, sending updates periodically to the server. Then the server stores the timestamp of the last entity update it got, and if the distance change versus the time change is too high, they are considered to be cheating.

I think, in general, you've got to decide what sacrifices to make on which side for your game specifically. A turn-based game like Worms could almost definitely do absolutely everything server-side, but this won't work for live action games.

[zammbi]

The issue is that the player can then notice latency incredibly obviously - there is a big delay from when they press a button and see the result.

You can still have the server check everything, without that problem. Basically I would let the client have direct control over the movement, then the server will go towards the estimated current clients position. If the player was speed hacking/lagging the server wouldn't be able to catch up to the client (which will send a warp back packet if the distance is too far), but continue going towards the position. Well that's what I'm doing for my current game.