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??

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."

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 ).

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.....

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

Until Microsoft implements Paladium and brings in hardware based security that is

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 !

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 )

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

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.

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.

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).

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).

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

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.

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.

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.

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

It is a random ordered list of the possible values for the die she is supposed to roll.

2: She encrypts the list using a key she randomly generates. It is a one-time-use key. After she uses it for encrypting this one die roll, she'll throw it away and generate a new one the next time she needs to roll.

key: 5791233243234

encrypted list: 114143

3: She sends only the encrypted list to Hans. She keeps the key on her machine.

4: Hans picks a number from 1-6. He sends that number over to Inga.

5: The die roll is now settled. Inga reveals the key to Hans. His PC decrypts the list and confirms that every number that was supposed to be on the die is in the list and appears only once (i.e. she couldn't just generate a list of all 6's). Her machine can independently figure out what he rolled just by looking up the value from the list using his choice.

In order to know what the die roll result was, Hans and Inga pick the nth element out of the list Inga generated, where n is the number Hans picked. So, for example, if Hans picks '3', then when the list is revealed to him he sees that the third element in the list was '1' so that's the result of the die roll. Inga can't influence which one he picks and he can't influence what will appear where he picks. And it's in the best interests of each side to be as random as possible in the generation of the list and the picking. If either side can predict what the other side does then he/she can take advantage of the bias.

Essentially it's the same thing as a fair coin flip. I'm allowed to flip, but you are allowed to choose heads or tails. Neither of us can cheat the other unless I can change the coins position after you pick. The encrypted list that Hans keeps in this case ensures that Inga can't change the list ex post facto.

The algorithm works for any size die and even for a coin toss (because a coin is effectively a two sided die). You could even roll multiple dice at once using a single encryption key with Hans making multiple choices (i.e. Inga sends 523164 231564 425631 (encrypted of course) and Hans picks the fourth element from the first group, the second from the second, and the first from the third group before Inga reveals her key). When rolling multiple dice that will result in less key generation, less network traffic, and faster encryption/decryption.

Now if Inga is very familiar with the encrypted list and the results of the many possible keys. She could keep a list of which keys decrypt to which result sequence. Once she know's Hans' choice she could go trough all the possible results and pass the "key" back to Hans that will give her a roll that she wants.

Now you could solve this by letting Hans require that his own key be put in the list as part of the encrypted process so that it will be present in the decrypted form to verify that the list isn't stale. Now Inga could still brute force an attack on the encrypted list to influence the result but she would need a whole lot of CPU power.

You can complicate the procedure all you want but all you're really doing is making it computationally undesirable to cheat. And that is the best you can do when you don't control the system from start to finish.

Also, JohnMunsch, please avoid religious swearing, the content of your post is enough to get people's attention without offending them.

I think the idea is that B doesn't trust A. And, in fact, A doesn't trust B. The problem here is coming up with a communications protocol between two parties where they can both agree on a random number without necessarily trusting one another.

If you're opening your code I expect you have to calculate everything on the server in parallel with the clients and kick any client that deviates from your expected state (note you don't have to track everything, tracking one variable will do, as long as it's accurate and noone knows which one you're tracking).

I get the impression that the peer-to-peer system just isn't possible yet. It's a situation that hasn't to my knowledge been researched much (if at all), and seems to require an unrealistic amount of resources to properly implement.

>So what's to stop A sending B whatever key it likes to fudge the dice roll?

Plenty. See encryption algorithms are designed to be very one-way things. In fact, the public key systems we use every day (e.g. e-commerce over the web) are a perfect example of that. Even though, you, the client has both the public key for a site _and_ an example of an encrypted and decrypted message, you still can't work backward to figure out what the private key was that was used to encrypt that message.

Trying to work them backwards to generate a key that produces a particular message is nigh on impossible. What you are suggesting is that Inga is clever enough to make a message that can decrypt six different ways with six different keys (which any message does) AND that each of the messages makes sense and is a different valid ordering of the numbers 1-n. Sorry, that's not going to happen. And even, if by some miracle, she has set a computer to calculating a set of keys + message that gets this result, she blows the whole combo on one die roll.

If she keeps sending the same message more than once then a more sophisticated client can easily detect the cheating. If she doesn't send the exact same key for the same message then he knows she's cheating. If she sends the same message and the same key then he's in a perfect opportunity to cheat by sending a specific return value to choose the roll rather than just randomly select it.

> You can complicate the procedure all you want but all you're really doing is making it computationally undesirable to cheat. And that is the best you can do when you don't control the system from start to finish.

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