Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
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 15511 times)
0 Members and 1 Guest are viewing this topic.
Offline Matzon

JGO Knight


Medals: 19
Projects: 1


I'm gonna wring your pants!


« Reply #60 - Posted 2003-05-12 13:56:29 »

but then people won't compete as much...

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #61 - Posted 2003-05-12 13:57:00 »

Quote
I can ignore cheat analysis on anything other than the no. 1 hiscore.

What if the no.1 *and* no.2 highscores are fake?

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #62 - Posted 2003-05-12 14:00:06 »

Oh, wait. Never mind... -move along-  Roll Eyes

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #63 - Posted 2003-05-12 14:18:55 »

By the way, in another bit of canny business nous that my wife has demonstrated which reminds me once again I didn't just marry her coz she was a babe, we have removed the online hiscore display from within the game and simply got a button to open a browser to our online hiscores webpage.

But, you're thinking, this sucks, why not display the scores in the game?

Because we want to make sure there's a steady stream of visitors coming back to our site to see what's up, that's why.

Even pirates who crack the game will end up there and who knows, maybe they'll buy our next game.

She's sharp, Charlotte is Smiley

Cas Smiley

Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #64 - Posted 2003-05-12 14:40:43 »

Quote
we have removed the online hiscore display from within the game and simply got a button to open a browser to our online hiscores webpage.

But, you're thinking, this sucks, why not display the scores in the game?


Nice idea, but unfortunately it can backfire; a significant proportion of people dislike having their game interrupted by a switch to a web-browser. I say this based on a couple of years spent trying to increase communities uptake of their website - and even when there were thousands of pounds at stake (with a very high chance of getting some of it), lots of people didn't like having to go to the website for anything, though they had nothing against the website itself.

So, I'd suggest you include either the top 5 current scores, or the five surrounding the player's current best, inside the game. If they get to see one of those two, and know they have to go online to see the other, then you have a better chance of them doing so. The psychology of this is that you have got them to invest some of their interest, and hence some of their motivation, by giving them a little of what they want - if you can't get any of something you want, there is a tendency to not bother; if you can get half of it easily, few people can resist getting the other half.

I'd personally show the top 5 scores in-game, so that they can see high-scores in game, and know that if they were REALLY good, they'd not need to go to the site (but in reality, once they're that good, and that hooked, they'll be going to the site anyway). But the lure of seeing themselves on *a* scoreboard should be enough to then push them to go to the website.

Shrug. Just a thought. Smiley

malloc will be first against the wall when the revolution comes...
Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #65 - Posted 2003-06-19 13:29:52 »

I just saw this.. thought it was interesting.  Could it have been prevented, or would the needed safegaurds be impractical to implement?  I personally suspect that such things can not be prevented without making sacrificews to the games efficiency.. I think the approach they took here, where they were quickly able to restore a valid games state from just prior to the attacks is a reasonable compromise... until the attacks become to frequent and no progress can be made...

http://www.wired.com/news/games/0,2101,59034,00.html

Offline Athomas Goldberg

Junior Member




Grrrrrr...


« Reply #66 - Posted 2003-07-21 18:26:06 »

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

so, neither client knows what data it processes. and server needs not huge computational power.

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.

I think it's interesting that this post was never addressed. I assume it's because the topic had moved on to hi-score cheating from the original post regarding die-rolls. This is an area I've given some thought to, but am interested in hearing the opinion of the group before diving too deeply into it.

Athomas Goldberg
Project Lead / Wildcard
Game Technologies Group
Sun Microsystems, Inc.
Offline bmyers

Junior Member





« Reply #67 - Posted 2003-07-21 18:40:36 »

We have thought about it for our game, since we have a lot of advance-planning AI that could be broken out into manageable "packages" and that can work perfectly well autonomously.

Our thinking was to send out a computation/planning packet to a bunch of clients, and then do a "tell me 3 times" approach on the results.

The business side is trickier, though, because I think you need to let users "opt in" on this approach, otherwise it could easily backlash on you.  We were thinking of giving users a discount on the subscription if they let us use their CPU.

Offline swpalmer

JGO Coder




Where's the Kaboom?


« Reply #68 - Posted 2003-07-21 20:42:01 »

Quote
The business side is trickier, though, because I think you need to let users "opt in" on this approach, otherwise it could easily backlash on you.  We were thinking of giving users a discount on the subscription if they let us use their CPU.


I don't think that is necessary.  You aren't collecting personal information and the user must choose to run your game.  They can't expect to run the game and use no CPU time.  Obviously computation of some sort MUST be done on the client and results must be sent to the server no matter what you do.  This is not so special as far as the user is concerned.

Offline Athomas Goldberg

Junior Member




Grrrrrr...


« Reply #69 - Posted 2003-07-21 21:13:21 »

Quote

Our thinking was to send out a computation/planning packet to a bunch of clients, and then do a "tell me 3 times" approach on the results.
This is the solution SETI@Home uses to counter users trying to "improve" on their data analysis algorithms. By thowing out the result that falls outside the standard deviation they manage to keep things kosher. If all three results are way off (statistically improbable, but not impossible) they throw out the result and resend the data.
As long as the players don't know who's processing whose packets you should  be safe from cheating/collusion.

Athomas Goldberg
Project Lead / Wildcard
Game Technologies Group
Sun Microsystems, Inc.
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Athomas Goldberg

Junior Member




Grrrrrr...


« Reply #70 - Posted 2003-07-21 21:25:59 »

Quote
I don't think that is necessary.  You aren't collecting personal information and the user must choose to run your game.  They can't expect to run the game and use no CPU time.  Obviously computation of some sort MUST be done on the client and results must be sent to the server no matter what you do.  This is not so special as far as the user is concerned.

If you only want to borrow CPU time while the player is actually playing the game, then I completely agree with you. You've got to assume something is happening on your computer while you're playing.

I think the issue only comes up when you want to get access to idle CPU time while the player is off doing something else (mowing the lawn, walking the dog, going to work, etc)  In that case there is probably some value to providing added incentive to the user. Mind you, I don't think you need much incentive.  SETI@Home uses a ranking system where users who contribute the most CPU time get listed on the site. For broadband users  idle CPU time costs nothing, so a discount scheme based on donated CPU cycles would probably be a pretty easy sell.

Athomas Goldberg
Project Lead / Wildcard
Game Technologies Group
Sun Microsystems, Inc.
Offline zaal

Junior Newbie




Java games rock!


« Reply #71 - Posted 2003-07-21 21:39:43 »

Quote

I think it's interesting that this post was never addressed. I assume it's because the topic had moved on to hi-score cheating from the original post regarding die-rolls. This is an area I've given some thought to, but am interested in hearing the opinion of the group before diving too deeply into it.


Smiley At last! Smiley  

Well, we want to use this approach soon. So, will see Smiley
Offline Athomas Goldberg

Junior Member




Grrrrrr...


« Reply #72 - Posted 2003-07-22 04:41:08 »

Quote
I just saw this.. thought it was interesting.  Could it have been prevented, or would the needed safegaurds be impractical to implement?  I personally suspect that such things can not be prevented without making sacrificews to the games efficiency.. I think the approach they took here, where they were quickly able to restore a valid games state from just prior to the attacks is a reasonable compromise... until the attacks become to frequent and no progress can be made...

http://www.wired.com/news/games/0,2101,59034,00.html


This should be a caveat to all those out there claiming that client-server is the only way to prevent cheating. Until someone develops a provably unhackable client-server architecture your games will be susceptible to these kinds of attacks. No matter how you design your game client-server or peer-to-peer, the best you can ever do is make it really, really hard to cheat, which is all JohnMunsch was claiming.

Part of the reason why peer-to-peer solutions will have a much harder time taking hold is that the game itself has to be made secure, not just the hardware on which it runs, which requires a far greater understanding of network security than most game developers have. The fact that server security is largely someone else's problem, leads many game developers to naively believe (at their peril) that they are somehow immune to cheating.

That said, it's always amusing when people claim that something "can't be done" simply because they can't think of a way to do it.  The fundamental assumption in all serious peer-to-peer computing work is that the individual peer cannot be trusted, and a significant amount of work is being done to address this issue by experts in network security who are too well paid to be making games. I have no doubts that if and when a secure peer-to-peer gaming solution does appear it will be largely based on work done outside the community.

One of the most promising aspects of p2p is that in a well-designed, fully decentralized architecture it's impossible to significantly compromise the game without compromising a significant number of nodes. The larger the population of nodes, the larger the number of nodes you have to compromise to effectively cheat. In a client-server architecture, all you have to do is hack the server, and you control *everything*.

Of course, as soon as you make the game "administerable" you've given away the keys to the kingdom anyway  Smiley

Athomas Goldberg
Project Lead / Wildcard
Game Technologies Group
Sun Microsystems, Inc.
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #73 - Posted 2003-07-22 12:01:30 »

Quote

This should be a caveat to all those out there claiming that client-server is the only way to prevent cheating. Until someone develops a provably unhackable client-server architecture your games will be susceptible to these kinds of attacks.


Are you trolling? There are plenty of well-known "unhackable" client-server architectures. Someone here even pointed out a "provably" unhackable p2p architecture IIRC. It depends what your application is. I don't believe that an unhackable FPS architecture exists, because one of the requirements for those games is that you cannot use aim-bots. OTOH, it's easy to make an unhackable RTS. This is basic security-engineering: know what it is you're trying to prevent, and often you find you can.

...or am I misunderstanding your point? Do you perhaps mean that it needs to be proved that the total sum of the software, the OS, the hardware, and the random interaction of cosmic rays (which cause random changes in RAM) and other acts of god when put together form an unhackable system?

Quote

Part of the reason why peer-to-peer solutions will have a much harder time taking hold is that the game itself has to be made secure, not just the hardware on which it runs, which requires a far greater understanding of network security than most game developers have.


And also because of several other side-effects such as every player needing large amounts of bandwidth. Broadband isn't enough by a factor of 10 for some of the games I've seen proposed using P2P.

And probably also because so many serious developers are put off by the idiocy of some of the P2P evangelists who think it's the Holy Grail. This debate has been going on for two decades. P2P solutions aren't anything new, although recent CPU advances and internet connectivity are finally making them more viable.

Quote

The fundamental assumption in all serious peer-to-peer computing work is that the individual peer cannot be trusted, and a significant amount of work is being done to address this issue by experts in network security who are too well paid to be making games.
...
One of the most promising aspects of p2p is that in a well-designed, fully decentralized architecture it's impossible to significantly compromise the game without compromising a significant number of nodes. The larger the population of nodes, the larger the number of nodes you have to compromise to effectively cheat. In a client-server architecture, all you have to do is hack the server, and you control *everything*.


No, no, and no.

You're looking at it like a mathematician - assuming that the only way people will want to cheat is by having full direct control of their cheating. This is a fatal assumption, due to not fully realising the problems at hand. It is enough for cheaters to be able to merely probably alter the outcome - even in a random way. They will find ways to turn this to their advantage. A simple example is to repeatedly go up against a monster far too powerful for their character (or even, perhaps, invulnerable), and just hope they manage to corrupt one of the calculations for that battle. It might be enough. With hundreds of thousands of players, there's actually a worryingly high chance of one of them pulling it off.

So the number of nodes you need to compromise doesn't necessarily come into it at all.

And any client-server architecture where hacking it once gives you full access has been desigtned by someone who probably deserves to go bankrupt. It's a stupid idea. The concept of multi-level security has been with us for several decades. The standard server hacks mostly rely on cracking one security level at a time - and the hacker can be effectively stopped at any one of the levels.

malloc will be first against the wall when the revolution comes...
Offline Athomas Goldberg

Junior Member




Grrrrrr...


« Reply #74 - Posted 2003-07-22 14:42:26 »

Quote
...or am I misunderstanding your point? Do you perhaps mean that it needs to be proved that the total sum of the software, the OS, the hardware, and the random interaction of cosmic rays (which cause random changes in RAM) and other acts of god when put together form an unhackable system?

I was simply in responding to the number of posts suggesting that p2p would *never* be viable (from a security standpoint) because you can only make it really difficult to cheat, not impossible. My point was this was always going to be the case whether you were dealing with P2P or Client-Server, and therefore was not a valid reason for immediately dimissing p2p.

Quote

And also because of several other side-effects such as every player needing large amounts of bandwidth. Broadband isn't enough by a factor of 10 for some of the games I've seen proposed using P2P.


Bandwidth requirements all depend on the game of course, but I completely agree that while p2p may buy you scalability, it doesn't necessarily buy you performance.

Quote

And probably also because so many serious developers are put off by the idiocy of some of the P2P evangelists who think it's the Holy Grail. This debate has been going on for two decades. P2P solutions aren't anything new, although recent CPU advances and internet connectivity are finally making them more viable.


I  agree with you on all counts here.

Quote

You're looking at it like a mathematician


Damn! I knew that fine arts degree would get me in trouble! Smiley

Quote

- assuming that the only way people will want to cheat is by having full direct control of their cheating. This is a fatal assumption, due to not fully realising the problems at hand. It is enough for cheaters to be able to merely probably alter the outcome - even in a random way. They will find ways to turn this to their advantage. A simple example is to repeatedly go up against a monster far too powerful for their character (or even, perhaps, invulnerable), and just hope they manage to corrupt one of the calculations for that battle. It might be enough. With hundreds of thousands of players, there's actually a worryingly high chance of one of them pulling it off.


Agreed, but this isn't limited to p2p architectures.

Quote

So the number of nodes you need to compromise doesn't necessarily come into it at all.


Once again, this is largely dependent on your game design and the p2p architecture. As you've pointed out p2p architectures have been around (and maturing) for years. There are a number of techniques designed to reduce or eliminate the effects of corrupted data and rogue peers in much more security-conscious domains than games. In most of these architectures, it's not that you need to compromise a significant percentage of nodes to have a significant impact, but that you need to compromise a significant percentage of nodes in order to have *any* impact at all, so the number of nodes makes a huge difference. This is, however, a much larger discussion.

Quote

And any client-server architecture where hacking it once gives you full access has been designed by someone who probably deserves to go bankrupt.


You did read the article that prompted this post, right? Well, then the folks at UBI Soft and Wolfpack Studios deserve to go bankrupt. Smiley

Quote

It's a stupid idea. The concept of multi-level security has been with us for several decades. The standard server hacks mostly rely on cracking one security level at a time - and the hacker can be effectively stopped at any one of the levels.


Multi-level security systems still get hacked. Games still get hacked, (as do banks, major corporations, intelligence agencies, etc) Yes, it's getting much harder, but as long as it's possible for someone to legitimately access and administer a system, it will be possible to exploit that capability. We can only make it really, really hard and keep trying to make it harder. Which was my point all along. To think there's some magical security system that's going to make you completely immune from cheating (client-server or p2p) is hopelessly naive. There are plenty of arguments for why an architecture may be suitable (or unsuitable) all of which should be taken into account when designing and implementing a game. I'm merely questioning the validity of the security argument in immediately discounting one approach or the other.




Athomas Goldberg
Project Lead / Wildcard
Game Technologies Group
Sun Microsystems, Inc.
Offline Jeff

JGO Coder




Got any cats?


« Reply #75 - Posted 2003-07-22 18:47:57 »

AT and I debate this a lot around Sun.

IMO There are a few thinsg that are true:

(1) As long as humans are  in the loop no system is perfect.  Most servers get hacked due to pilot errors  on the part of those with legitimate access.

(2) You CAN however raise the bar high and perhapse make it too difficult for at least your average script kiddie.  The simplest (and only proven) way to do this is with server-side logic in a well designed and security audited backend.

(3) Unfortunately the best solutions for good-gameplay tend to be diametrically opposed to this.  (Moving functionaliy close to the player perceiving it).  This is a fundemental tension in online game design and balancing it is the job of a good technical architect.

(3) Cheating is a much bigger issue then most people realize.  Having managed a commercial online evnvironment (DSO) let me throw a few things out most people don't think of:

(A) Cheaters collude.  Naive cross checking thus can fail.  Related to this is the fact that only one guy in a  group of cheaters needs to be smart enough to break your security as long as his solution can be replicated through scripts or simple instructions.

(B) It often isnt necessary for cheaters to actually go undetected or even effect the "game state."  Cheaters will resort to remarkably primative means if it gets them their goal-- up to and including just crashing the system.  That goal can be as simple as annoying others or as complex as stopping the game because they are  in a  losing position.

This is another problem with destributed computing solutions. I don't have to UNDERSTAND the data in order to crash out the system.

JK
 

Got a question about Java and game programming?  Just new to the Java Game Development Community?  Try my FAQ.  Its likely you'll learn something!

http://wiki.java.net/bin/view/Games/JeffFAQ
Offline Athomas Goldberg

Junior Member




Grrrrrr...


« Reply #76 - Posted 2003-07-22 19:46:34 »

Quote
AT and I debate this a lot around Sun.

and we're bound to debate it here in the forums as well. Smiley

Quote
IMO There are a few things that are true:

(1) As long as humans are  in the loop no system is perfect.  Most servers get hacked due to pilot errors  on the part of those with legitimate access.


Very, very true.

Quote

(2) You CAN however raise the bar high and perhapse make it too difficult for at least your average script kiddie.


Absolutely, and most folks working on secure P2P architectures have set the bar *much higher than your average script kiddie. (like military and corporate espionage)

Quote
The simplest (and only proven) way to do this is with server-side logic in a well designed and security audited backend.


I agree that this is the simplest way to do it, which is why it's also the most popular, and by proven, I assume you mean "tried and true" A number of techniques have been developed for securing various types large-scale p2p systems from abuse, but they are not simple solutions and may not be readily available until more mature p2p infrastructures emerge.

Quote
(3) Unfortunately the best solutions for good-gameplay tend to be diametrically opposed to this.  (Moving functionaliy close to the player perceiving it).  This is a fundemental tension in online game design and balancing it is the job of a good technical architect.


True, and unfortunately most currently viable, secure P2P architectures are more about making use of the network of CPUs rather than moving priviledged functionality closer to the client accessing it. In most cases the number of hops are the same, so the benefits of P2P tend to be in scalability, not performance. There is some interesting work being done in military applications for securing true p2p networks where all computing is done locally, but unfortunately my NDA prohibits me from saying more.Wink Needless to say, this won't be immediately useful to game developers, but may be more so in a few years.

Quote

(3) Cheating is a much bigger issue then most people realize.  Having managed a commercial online evnvironment (DSO) let me throw a few things out most people don't think of:

(A) Cheaters collude.  Naive cross checking thus can fail.  Related to this is the fact that only one guy in a  group of cheaters needs to be smart enough to break your security as long as his solution can be replicated through scripts or simple instructions.


Yep, and most secure P2P solutions assume this. As long as I know who's processing my data I can cheat. This was the issue with the die rolling example for more than two players.  The key is reducing or effectively eliminating the possibility of knowing who's processing your data. Not easy, but doable as demonstrated by the SET@Home project (yep, people tried to cheat there too, some out of a desire to "improve" on the data analysis algorithms, others for less savory reasons)

Quote

(B) It often isnt necessary for cheaters to actually go undetected or even effect the "game state."  Cheaters will resort to remarkably primative means if it gets them their goal-- up to and including just crashing the system.  That goal can be as simple as annoying others or as complex as stopping the game because they are  in a  losing position.

This is another problem with destributed computing solutions. I don't have to UNDERSTAND the data in order to crash out the system.


True. This is also a recognized issue in secure p2p development and one where the self-healing qualities of the network actually serves as potection against these kinds of attacks. By eliminating a single point of failure, you can prune renegade nodes without disrupting the system. Mind you, this all depends on the specific design of the game and the type of p2p architecture you employ. Most of the p2p architectures I'm talking about are brokered (mediated by one or several protected servers, whose role it is manage the communication and behavior of nodes on the network)

Athomas Goldberg
Project Lead / Wildcard
Game Technologies Group
Sun Microsystems, Inc.
Offline Athomas Goldberg

Junior Member




Grrrrrr...


« Reply #77 - Posted 2003-07-22 21:54:53 »

Further note: For those of you wondering where all this p2p security work is happening, take a look under "Mobile Ad-Hoc Networks" also known as MANET's. Most of these applications assume that  a) any node (as well as the routes between nodes) may be compromised at any time, that b) multiple nodes may be compromised and collude to fool (cheat) or disrupt the system, and that c) there may be no central mediator to prevent these attacks. There is quite a bit of money (especially military money) going into this research (certainly more money than the gaming community can afford at this point) and a number of interesting solutions have been developed.

Whether any or all of this work will be applicable to gaming remains to be seen, but as it shares many of the same concerns, I'm optomistic that some number of categories of online games will benefit from this work.

Athomas Goldberg
Project Lead / Wildcard
Game Technologies Group
Sun Microsystems, Inc.
Offline William

Junior Member




No Exit


« Reply #78 - Posted 2003-07-22 22:07:53 »

Great! I was just going to ask about literature on the subject, but Google seems to bring up enough stuff when one does a search for "Mobile Ad-hoc Networks". You wouldn't happen to know of any book for an engineer, rather than a researcher, on the work that has been done in the area though? (I'm thinking of something like Bruce Schneier's Applied Cryptography but for MANETs)
Offline Athomas Goldberg

Junior Member




Grrrrrr...


« Reply #79 - Posted 2003-07-23 13:11:17 »

Quote
Great! I was just going to ask about literature on the subject, but Google seems to bring up enough stuff when one does a search for "Mobile Ad-hoc Networks". You wouldn't happen to know of any book for an engineer, rather than a researcher, on the work that has been done in the area though? (I'm thinking of something like Bruce Schneier's Applied Cryptography but for MANETs)

I'll look through my notes, and ask around.  I'm pretty sure I've seen at least one recently.

Athomas Goldberg
Project Lead / Wildcard
Game Technologies Group
Sun Microsystems, Inc.
Offline gregorypierce

Senior Member




I come upon thee like the blue screen of death....


« Reply #80 - Posted 2003-08-12 03:24:44 »

Any non-trivial system can be exploited if you are allowing user input. A paramount principle of computer security is that once a user has access to the code and physical access to the machine, preventing them from hacking a client side system is impossible because you have no way of knowing the state of the client side system. Even Microsoft discovered this with Paladium. At best you can minimize exploits, but any complex system has complex interactions and the combinatorial explosion of possibilities means that exploits are just waiting to be discovered.

http://www.gregorypierce.com

She builds, she builds oh man
When she links, she links I go crazy
Cause she looks like good code but she's really a hack
I think I'll run upstairs and grab a snack!
Offline Athomas Goldberg

Junior Member




Grrrrrr...


« Reply #81 - Posted 2003-08-21 20:56:57 »

Quote
Any non-trivial system can be exploited if you are allowing user input. A paramount principle of computer security is that once a user has access to the code and physical access to the machine, preventing them from hacking a client side system is impossible because you have no way of knowing the state of the client side system. Even Microsoft discovered this with Paladium. At best you can minimize exploits, but any complex system has complex interactions and the combinatorial explosion of possibilities means that exploits are just waiting to be discovered.



I completely agree.

The approaches used in MANETs assumes all this, and asks the question, how do you make with the assumption that not only can people cheat, but that some number of users *will* cheat? Many of the approaches make the assumption that while you can't trust any one user not to cheat, if you assume that a simple majority of users aren't cheating, there are ways to make the network secure. There are costs, of course, and they may be prohibitive for gaming, but it can be done. If you can't trust the *majority* of users you have other, more significant,  problems.  Smiley

Athomas Goldberg
Project Lead / Wildcard
Game Technologies Group
Sun Microsystems, Inc.
Offline sbridges

Senior Newbie




Java games rock!


« Reply #82 - Posted 2005-01-16 16:16:51 »

Quote


I havent read everything in the thread because its way too long, but Im facing basically the same problem with a turn based strategy game, and would appreciate comments on my solution.

The problem is to generate dice on a client and a server in such a way that neither side needs to trust the other.

Im using an algorithm like this, A is the server and B the client.

A generates a secret key, dice
A encrypts the dice with secret key
A encrypts a common known value (0xCAFEBABE in this case) with the secret key.
A sends the encrypted dice and the encrypted known value to B.

B recieves A's encrypted values
B generates secret key, dice
B encrypts the dice with secret key
B encrypts a common known value (0xCAFEBABE as well)
B sends its encrypted values to A

A receives Bs encrypted values, sends B its Secret key

B recieves A's secret key,
B decrypts A's encrypted known value to ensure the key is correct, then decrypts A's dice.  The dice are now the xor of A and Bs dice.
B sends A its secret key

A recieves Bs secret key.  
A uses Bs key to decrypt B's encrypted known to ensure the key is valid.  The dice are then the xor of A's and B's dice

The encryption method Im using is DES.

Can anyone comment on how easy this is to crack.  Its not foolproof  in that the server can still cheat.  But the client can check that the dice are correct, and can verify the game (even if it is a labour intensive process).

The code is written for triplea, (triplea.sourceforge.net).

You can view the source through cvs, the relevant packages are

games.strategy.engine.vault.*

and

games.strategy.engine.random.CryptoRandomSource
games.strategy.engine.random.RemoteRandom

Offline bitshit

Junior Member




Java games rock!!


« Reply #83 - Posted 2005-01-16 21:40:47 »

Damn, I wish I found out about this post a earlier! Would have saved me a lot of brain teasers / unsolvable situations to come to the conclusion this subject is real crap... uhhh I mean is a challenging subject!  Tongue

What i've done is a combination of client sided obfuscation and server sided cross checks... make it as difficult as possible for hackers by:

1.) mangling all client sided logic, have the important score variables etc split into various "blocks" to prevent people using a runtime debugger from changing them as much as possible.
2.) inserting an checksum object into the client after initialisation. Client only knows the interface, object's implementation is only known on server (and differs / is initialized random every gamesession). Hackers would need to decompile / extract right values from this object for every play they want to hack.
3.) server sided checks, global game logic that defines max scores, play times per elapsed time. keep record of keepalives with which we send referential temp scores and other data

I've put some efford in the security as some of the games can be played for prizes.

Quote
I havent read everything in the thread because its way too long, but Im facing basically the same problem with a turn based strategy game, and would appreciate comments on my solution.


Im not sure if I missed something from your story, but why not trust the server in your case? Is it another player, if so, you could apply the technique JohnMunsch outlined in his post...
Offline sbridges

Senior Newbie




Java games rock!


« Reply #84 - Posted 2005-01-16 22:44:15 »

I read the thread and there is a slightly simpler solution a few pages back, but its basically the same idea.

In my case the server is playing the game as well, and the server has access to the source code (TripleA is gpl'd) so obfuscation is not an option.
Offline mastergaidenGT

Junior Newbie




Java games rock!


« Reply #85 - Posted 2005-02-16 15:43:23 »

If u are not cheatin ur not trying
Offline mastergaidenGT

Junior Newbie




Java games rock!


« Reply #86 - Posted 2005-02-16 15:45:17 »

Quote
If u are not cheatin ur not trying

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.

Riven (20 views)
2014-07-29 18:09:19

Riven (13 views)
2014-07-29 18:08:52

Dwinin (12 views)
2014-07-29 10:59:34

E.R. Fleming (31 views)
2014-07-29 03:07:13

E.R. Fleming (12 views)
2014-07-29 03:06:25

pw (42 views)
2014-07-24 01:59:36

Riven (42 views)
2014-07-23 21:16:32

Riven (28 views)
2014-07-23 21:07:15

Riven (29 views)
2014-07-23 20:56:16

ctomni231 (60 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!