Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (491)
Games in Android Showcase (112)
games submitted by our members
Games in WIP (556)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2 3
  ignore  |  Print  
  Open source and Preventing Cheating  (Read 15797 times)
0 Members and 1 Guest are viewing this topic.
Offline bakes_buns

Innocent Bystander




Java games rock!


« Posted 2002-12-03 05:55:56 »

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!
Offline leknor

Junior Member




ROCK!!!


« Reply #1 - Posted 2002-12-03 07:01:52 »

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

Be wise. Wink
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #2 - Posted 2002-12-03 07:40:58 »

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

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  Tongue

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Captain-Goatse

Junior Member




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #3 - Posted 2002-12-03 10:30:38 »

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
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #4 - Posted 2002-12-03 11:46:22 »

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 Smiley

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #5 - Posted 2002-12-03 12:07:23 »

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

Quote

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

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

Offline Golthar

Junior Member




;)


« Reply #6 - Posted 2002-12-05 05:41:39 »

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

come visit us: http://www.otf1337.com
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #7 - Posted 2002-12-05 07:36:55 »

Quote
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 Wink)

Offline larry

Junior Member




.. son of jor-el, kneel before zod ...


« Reply #8 - Posted 2002-12-05 08:49:27 »

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
Offline Golthar

Junior Member




;)


« Reply #9 - Posted 2002-12-09 07:19:26 »

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


Read my post again and note how I mentioned: given Microsofts track record 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

come visit us: http://www.otf1337.com
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline elias

Senior Member





« Reply #10 - Posted 2002-12-09 09:31:25 »

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

Offline MGodehardt

Junior Member




why does the chicken cross the road?


« Reply #11 - Posted 2002-12-09 11:37:02 »

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

Junior Member




;)


« Reply #12 - Posted 2002-12-09 12:09:37 »

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

come visit us: http://www.otf1337.com
Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #13 - Posted 2002-12-09 12:17:14 »

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

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


HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline Golthar

Junior Member




;)


« Reply #14 - Posted 2002-12-09 12:41:57 »

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



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

come visit us: http://www.otf1337.com
Offline cknoll

Junior Member




Flame On!


« Reply #15 - Posted 2002-12-10 15:56:45 »

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
Offline Captain-Goatse

Junior Member




I suck at teh 2D. XBOX IS BIG LOL!111


« Reply #16 - Posted 2002-12-29 10:11:56 »

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 Smiley



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

Junior Newbie




Founder of GameDev.net


« Reply #17 - Posted 2003-01-02 15:38:49 »

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

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #18 - Posted 2003-01-02 16:39:26 »

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.


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 Smiley

Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #19 - Posted 2003-01-02 16:48:03 »

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

Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #20 - Posted 2003-01-02 20:44:01 »

I'm struggling to see how this works. (Not the sharpest tool in the shed, me).

Cas Smiley

Offline JohnMunsch

Junior Newbie




Founder of GameDev.net


« Reply #21 - Posted 2003-01-03 02:02:40 »

Sorry. I didn't go into a lot of depth. Let me try again.

1: Inga's computer makes a list like so.

641253

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

Junior Member




ROCK!!!


« Reply #22 - Posted 2003-01-03 02:59:00 »

(I hope I can explain this clearly.)
What if:

  • Inga makes a list (or maybe already has one previously calculated)
  • "Encrypts" the list
  • Passes the encrypted form to Hans.
  • Hans picks a number and passes that choice back to Inga....

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

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #23 - Posted 2003-01-03 11:34:42 »

Ok, it wasn't that I misunderstood the process, but the application. The way I see it is in terms of computation cycles, bandwidth, latency, and communications.

'A' creates a list of 'n' numbers. ('n' operations)
'A' encrypts the list with a key. ('n' operations)
'A' sends encrypted list to 'B' (1 operation + 'n' bandwidth + latency)
'B' picks a random index from the list (1 operation)
'B' sends 'A' the random index (1 operation + 1 bandwidth + latency)
'A' sends the key to 'B' (1 operation + 1 bandwidth + latency)
'B' decrypts the entry to find out the roll (1 operation)

A: performs 2n+2 operations, uses n+1 bandwidth, and incurs 2 latency
B: performs 3 operations, uses 1 bandwidth,  and incurs 1 latency

This is a total of 2n+5 operations, n+2 bandwidth, and 3 latencies, to calculate one dice roll.

Plain old client server does this:

'B' asks 'A' for a random number (1 operation, 1 bandwidth, 1 latency)
'A' generates a random number (1 operation)
'A' sends the number to 'B' (1 operation, 1 bandwidth, 1 latency)

That's 3 operations, 2 bandwidths, and 2 latencies to generate a dice roll that's every bit as secure.

So keep explaining: I'm lost as to why I'd want to do it the first way...?

Cas Smiley

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #24 - Posted 2003-01-03 12:21:22 »

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.

Hellomynameis Charlie Dobbie.
Offline princec

JGO Kernel


Medals: 369
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #25 - Posted 2003-01-03 14:53:40 »

Ah, I see, it's for peer-peer multiplay rather than client-server.

So what's to stop A sending B whatever key it likes to fudge the dice roll? What's to stop A creating 6 different keys and cunningly sending B the key that always gives B a '1'?

Cas Smiley

Offline cfmdobbie

Senior Member


Medals: 1


Who, me?


« Reply #26 - Posted 2003-01-03 16:26:57 »

Yep, that's exactly the problem! Wink

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.

Hellomynameis Charlie Dobbie.
Offline JohnMunsch

Junior Newbie




Founder of GameDev.net


« Reply #27 - Posted 2003-01-04 11:38:22 »

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

Junior Newbie




Founder of GameDev.net


« Reply #28 - Posted 2003-01-04 11:39:47 »

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

"A difference which makes no difference, _is_ no difference."
Offline markuskidd

Junior Member


Medals: 1



« Reply #29 - Posted 2003-01-04 20:14:54 »

That *does* make a difference.
Pages: [1] 2 3
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Nickropheliac (15 views)
2014-08-31 22:59:12

TehJavaDev (23 views)
2014-08-28 18:26:30

CopyableCougar4 (32 views)
2014-08-22 19:31:30

atombrot (41 views)
2014-08-19 09:29:53

Tekkerue (40 views)
2014-08-16 06:45:27

Tekkerue (35 views)
2014-08-16 06:22:17

Tekkerue (25 views)
2014-08-16 06:20:21

Tekkerue (37 views)
2014-08-16 06:12:11

Rayexar (72 views)
2014-08-11 02:49:23

BurntPizza (49 views)
2014-08-09 21:09:32
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
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
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!