Open source and Preventing Cheating

I am half way through writing an online game which I would like to make open source so that others can build upon what I have done and add new features. The problem is that the game is an adaption of a turn based board game using dice, and if people can modify the source code and build their own version they can use this to cheat by modifying the game to always make favourable dice rolls.

Can anyone suggest ways to tackle this?

The online game uses a client server architecture, I though of moving all the dice rolls to the server but for performance reasons its much better done on the client.

Is it possible to somehow verify the version of all the class files to ensure they haven’t been modified when playing on the server??

Ideas, thoughts, comments welcome!

No. It’s not possible, it will never be possible. A secure system is not just about software. A secure system starts with software, goes through hardware, and ends with people. Unless you control all three, and probably others, you cannot make a secure system.

People have thought long and hard on this and there are no solid answers.

If you control the sofware, control the server, and can trust youself then you can make the dice rolls fair.

Anyway, it’s just a dice roll. A slow 386 could simulate enough dice rolls to keep a large city happy for hours on end. Get your priorities straight. You can either A) design a flawed system and eventually run all your users off because of not being able to control cheating. Or you can B) do the extra work to get things right and keep your users coming back indefinatly.

I don’t mean to sound harsh. I’m just trying to save you some time in the long run.

[quote]“There are three kinds of people in the world:
The dumb ones who don’t learn from their mistakes,
The smart ones who do learn from their mistakes,
and the wise ones, who learn from other people’s mistakes.”
[/quote]
Be wise. :wink:

I’m afraid, Leknor is basically right.

If you need to make sure (e.g. when money is involved), throw the dice on the server.
This might be annoying and ugly and oppose network overhead that might be significant - but at least it solves THAT problem.

We have the same topic. For us, we CANNOT do much on the server (performance, bandwidth and playability-wise).

One thing I thought off was to download and run a Java class from the server (e.g. at startup and/or from time to time, maybe using WebStart) that reflects the running client, checks wether certain classes are loaded, wether they have the right methods and fields, wether some variable contents are correct, wether the classloader is the one expected … and so on.
The class then sends a checksum to the server where it can be checked against the expected value. If it failes, close line, ban the player forever (hopefully you have his credit card number :slight_smile: ).

Of course, this class has to change frequently and unpredictable.

In the end, this can be one of the things making cheats harder - yet not impossible. This might be sufficient if you have a mean to punish cheating attempts, like banning a credit card, keeping money a player had to pay upfront (oh oh, legal issues). This would make cheating dangerous for the cheater.

For our thingy here - we don’t expect it to be very popular and THAT easy to cheat that it won’t be fun to do.

We’d never sacrifice an optimal software design with low bandwidth and server resource needs to these damn cheaters…

But we also don’t want to make money with it :stuck_out_tongue:

There has been this thing called packet sniffing since 95 when the online games came. It basically makes everything very hard.

If you want to learn something about cheating, go to www.myg0t.com

Packet sniffing can be defeated by encryption - and wouldn’t help anything against the approach I described.

Anyway, for an opensource client, there are much easier ways to find out whats going on the line :slight_smile:

It isn’t possible to make all online games secure, however
most board/card games can be made as secure as the server connected to, by keeping all the game logic on the server.

There is no such thing as Client Security - and there never will be, even with DRM (Digital Rights Management).

No, It can make it more difficult to interpret the sniffed packet s…

Like others said, having a server run the logic is the best you can do.
Until Microsoft implements Paladium and brings in hardware based security that is (and with Microsofts track record, who can be sure it works) we are stuck

[quote] Until Microsoft implements Paladium and brings in hardware based security that is
[/quote]
There is NO SUCH thing as client security - end of discussion. DRM/Palladium will not solve this problem either.
Granted, DRM will make it much more difficult to crack a platform, however there will always be people that can crack a platform.
The only way to make a platform secure is to have complete control. You do not have control of a computer, that is placed down the line of you T1 (BeOS reference ;))

Yep - I agree with most, dont waste time on implementing a complex client security protocol.

Rather focus on the Server. Sending dice rolls for a turn-based game requires little bandwidth. Its real-time multiplayer games that suffer from thin-clients!

A suggestion could be to generate dice-roll seeds on your server during handshaking/initialisation with the client. The client can then do the rolling from then on.
This in effect, lets the server control the business logic and provides the user, with the impression that its actually been done on the client.

The server can already estimate what the forthcoming rolls should be on the client, and if a client doesnt dice-related state doesnt correspond, its kicked out of the game !

Larry

Read my post again and note how I mentioned: given Microsofts track record :stuck_out_tongue:

Still best way to run a secure game is to do everything on the server and send this to clients, whether you use open source or not

erhm running the dice rolls on the client would be a very very bad idea - not because you can hack the client, but because a player will be able to foresee the dice rolls (like server when sending seeds). So I’d say that making the rolls on the server is the only way, no matter if you can trust the client complety.

  • elias

I do all dice rolling on the server otherwise player will leave because pppl cheat.

i created a online card Game called “Doppelkopf” its like bridge and the server validates all moves, so nobody can cheat, thats the only way u can do it. POINT. thats the art of professional game development. POINT.

have u ever heard about ultima online ? the use encryption and ppl hacked the client and cheated, so if the server isnt validating everything against valid bounds, they kill your server and kill your company.

client handles all GUI things and ask server if he can do a specific action, its only a VIEW of the entity living on your server. i prefer sun enterprise E450 for servers, yes they are expensive, but they rock! u also need a cable with 2 or 4 or better 6MBit/sec, yes this is expensive 2, but thats business.

The problem is, how can a good open source game with no funding find the hardware and pipeline you are talking about?

This is generaly a problem with open source, not only that its easier to hack the client, but because most of the time people expect the stuff to be free as beer too; You cant aford the server

(MGod - non-Germans say PERIOD, not POINT AFAIK :slight_smile: )

IMHO, in computer development there never should be sentences ending with ‘period’. Period.

Esp. there never should be statements like ‘Use the brute-force method! Period.’

‘The art of professional game development’ has provided us with cheatables games only so far?! Or with games that suck network-wise. So we should head for something better.

Depending on the goals, it’s often possible just to scale down the requirements a bit and achieve a big win from that. So, if the security requirement are not that high, e.g. for a non-commercial project, some simple cheat-avoidance is good enough. Then you can do things most elegant on the client and come along with an ISDN connected PC as a server.

BTW, yes, Sun-servers are expensive, maybe reliable, but not very fast…
We have a $50000 Sun box here, but computations/compilations … are better done on a powerful PC ($2000). ;D

[quote]BTW, yes, Sun-servers are expensive, maybe reliable, but not very fast…
We have a $50000 Sun box here, but computations/compilations … are better done on a powerful PC ($2000). ;D
[/quote]
And you can buy a lot more of those powerful pc’s :wink:
I agree though that basic cheat avoidance should be ok for open source / free games.
You get what you pay for :wink:

MGod is right. If you want to have a secure game, your client is only a view to a game board that exists on the server. There’s nothing for the client to cheat with because no information is given to the client that he shouldn’t know already. This doesn’t rule out the possiblity of ‘eavesdropping’ on a neighboring client, but as other postsers pointed out, that’s what encryption is for. This isn’t to say send all information to all clients (ala Starcraft) encrypted, this means only send information to the client that the client can see. However, this invovles a lot of extra network overhead, as you can’t afford to send 100 clients their own individual messages about a game board (bandwidth just won’t support it) but I think there are ways around this limitation.

In a secure system, it doesn’t matter if people can see how the communication is done, because the system is not secured by ‘obscurity’ (a concept mastered by Microsoft). Systems are secured by proper design, and a hack-proof game consists of having the server control the entire game mechanics, verifying actions submitted by clients and rejecting those actions that don’t pass.

There was a discussion on this in the old forums, and someone did bring up a good poitn about client bots, that are playing the game by the rules, but are precisely calcuating their moves, actions with computer percision. Is this hacking the game? I would say no if the bot is performiong completely legal moves. It is abusive tho, so there may be things that you need to do to check for bots (response time of commands, accuracy, propted responses, etc). Games like Starcraft SHOULD have been made hack proof, but peer to peer nature of the game design made it impossible…even with the server controlling everything, the game host could still cheat against the players that join his game (which is no fun).

-Chris

[quote]Packet sniffing can be defeated by encryption - and wouldn’t help anything against the approach I described.

Anyway, for an opensource client, there are much easier ways to find out whats going on the line :slight_smile:
[/quote]
In fast paced FPS or mmorpg I don’t think there is really time for encryption. Most encryption algos are very time consuming processor wise and I don’t think many games can afford 200ms extra delay due cheat protection.

With encryption, the game must also have a key somewhere and I don’t think there really is many algos that are also fast and secure. If the key is in the app, then it can be uncrypted, which means the cheaters win again.

In this situation the dice rolls can be sniffed, and the only reasonable sollution would be that the dice rolls were made on the server, but with packet sniffing this can be hacked too. When the roll is returned to the application, the packetsniffer replaces the servermade roll with a good roll, such as natural.

Thats why there’ll always be OMG lol headshots and maphacking.

Jesus Christ! It’s good to see that people here are doing such thorough research…

No. It’s not possible, it will never be possible.

People have thought long and hard on this and there are no solid answers.

Crap. Absolute crap. For at least the two player peer-to-peer system, how to roll dice is a well known problem. It takes about three steps and it boils down to this:

Inga: I’ll generate a list of all the possible numbers on a die in a random order and write them down on this piece of paper. Then I’ll lock it in this box and hand it to you.

Hans: No problem. Now, I’ll pick a random number between 1 and the maximum value of the die. Then we open the box and look at the list to see what number that corresponds to. You can’t cheat because I’ve got the list you used. I can’t cheat because you don’t give me the key to the box until I’ve picked a number.

Inga:Let me have your baby you algorithmic stud!

In practice, Inga just generates the list of numbers and sends it to Hans. She doesn’t send the encryption key over for that list until he picks one. The whole negotiation can be hidden behind a die rolling class and it would take a very small fraction of a second. It would work just fine WITHOUT using a server.

The only time it has problems is when there more than two players. Then it is possible for the other players to get shafted by collusion between Inga and Hans. In practice there are probably ways to deal with that problem too.

[quote] Crap. Absolute crap. For at least the two player peer-to-peer system, how to roll dice is a well known problem. It takes about three steps and it boils down to this:
Inga: I’ll generate a list of all the possible numbers on a die in a random order and write them down on this piece of paper. Then I’ll lock it in this box and hand it to you.
[/quote]
Lets assume I need to make a roll. I make the list, you pick an index. Who is going to prevent me from making a list with all 6’s ?

The only way your approach is going to work, is by guarenteeing that a client doesn’t cheat in generating the list, which you can’t.

[EDIT]
scratch that - need to read through - missed the part about sending the key aftwer the selection :slight_smile:

ok, so your dice example works in that case - but in MOST cases client security doesn’t work.