Dealing with cheating

[»Ceiu]

I know we talked about this before a bit, but I don't really remember what solutions (if any) were discussed.

 

How do you plan on dealing with cheating? In the abstract sense, you could just have the client act solely as a remote interface, but what about modules and such? I imagine some people will design modules for doing some client-side calculations and game manipulations. How can those be secured? Furthermore, how does one save themselves from a rouge module that is designed to do something malicious? Considering how zones are run and supported, all it takes is one power-abusing idiot like death+ to forcefully/secretly add a required module on a server that could !@#$%^&* several players...

 

I'm sure I've got more questions/ideas, but it's midnight and I haven't rubbed one out today. I'll post more later.

[Bak]

Here's the reply about cheating I gave in the comments section... let me know what part you want me to elaborate on:

I'm not so sure server side checking is so impossible, so that will be the first thing that I'll try. If that proves to be too much computation then my other idea is peer review of packets, where players will check each other for cheating. A combination of the two, which uses some heuristics to quickly do server side checks for obvious cheating and uses slower peer review checking to catch more subtle cheating looks promising.

Also, parts of the game may have to be slightly changed... for example it wouldn't be hard to drop a portal and then detect client side when you're about to die and instead warp to where the portal is at the last splitsecond. For things like this I think we could have a delay between when you press insert and when you actually warp... so like you'd press insert and 0.5 seconds later it would warp you... of course that would be a setting so if a server owner didn't think it was a problem they could use a delay of 0.

 

 

Furthermore, how does one save themselves from a rouge module that is designed to do something malicious?

In some sense, any time you're running arbitrary code on your machine whoever wrote that code could do anything they want. I've kicked a few ideas around my head about this. One thing you could do is have digitially signed modules such that if the server is sending you a required module, it must be digitally signed with a trusted key before it loads into Discretion. You could have a directory with all the digital signatures that you accept such that if the owner of the signature pulls a Priitk and disappears, some other trusted person / group of people could take over.

 

Another option is to use Java .class files to interface with Discretion run through a virtual machine with a Security Manager that allows you to do nothing (think of the permissions Java applets are given when you run them through your web browser). This way you could interface with the Discretion interfaces to display images and react to keypresses, but not do silly things like delete files off your harddrive.

 

Both options could be used with performance sensitive code being signed and written in C/C++, and individual server specific modules written in unsigned Java.

 

As for client-side calculations and game manipulations, the only thing we can do is provide any benefitional ones to all the players with Discretion so that people are on a fair playing field. I'm skeptical as to how benefitial these will actually be, as I think given resonable settings a human can outplay an AI hands down. I mean currently with Continuum you can have things like prox squares (for hockey zone) and lines showing you where you're aiming by changing your ship graphics, but they don't seem to make much, if any, of a difference (at least in my experience).

[»Ceiu]

Ok, I remember the cheating thing, but your example of the warp mod brings up a valid point:

 

Why not allow mods like that? Maybe even directly support it through a kind of system similar to the "programable" AI in games like FFXI. That in itself would add a degree of skill and logic to help save peoples !@#$%^&*es in game. Using the same example, so long as it doesn't byp!@#$%^&* things like anti-warp or simply not having a portal, it shouldn't really be a problem, right?

 

 

Regarding the module thing:

Could you explain the digital signature thing a bit more? Would the signature be part of the module? If so, how possible would it be to spoof such a signature? Also, would there be a mechanism for zones and clients to exchange version information (or even a hash of the module) to check for newer versions and/or check for cheating attempts?

 

Also, with Java I'd assume you'd use JNI for the interface? What kinda performance impact are you looking at with that? I haven't used Java with any non-java application yet so I dunno how exactly it works in regards to loading the VM or using a kind of mini-vm, etc. Another concern with that is the versions of the VM. Java is for the most part backwards compatible, but I've found a couple instances where version differences can and will perform slightly differently.

[Bak]

yeah death+ is a cool cat.

 

anyways, the digital signature thing would use public / private key encryption. I (or a trusted party) has a private key which I can encrypt a hash of the .dll or .so file. Then, anyone can use the public key to check the signed hash versus the actual hash executing code from the module. For more on digital signatures you can read up on wikipedia: http://en.wikipedia.org/wiki/Digital_signature

 

Version checking will have to be done to make sure everyone's using the version of the module that the server expects. If there's some bug in a module that may compromise your computer, I could even use the private signing key to issue a recall on a module version so that your copy of Discretion will prevent servers from making you use the compromised version of the module.

 

I actually haven't been successful with getting a java virtual machine to run out of a C/C++ program... although I have used JNI before. I think java's speed will suffice for things that occur on the order of seconds or even tenths of seconds. We'll see what happens when we actually implement it, but if that doesn't work I could make a simple safe scripting language for Discretion that would get the job done.

[»Ceiu]

yeah death+ is a cool cat.

 

Yikes. I strongly disagree there, and suggest you read the log referenced in my signature. However, this is a debate better left entirely for a new thread somewhere in the "spam" or "trash talk" forums (Got that, attraction?).

 

anyways, the digital signature thing would use public / private key encryption. I (or a trusted party) has a private key which I can encrypt a hash of the .dll or .so file. Then, anyone can use the public key to check the signed hash versus the actual hash executing code from the module. For more on digital signatures you can read up on wikipedia: http://en.wikipedia.org/wiki/Digital_signature

 

Ok, got that, but here's where I'm stuck:

I assume it will work similar to the system seen in IE where active x controls are digitally signed and the user is asked if they want to trust the organization the control belongs to. Ignoring the user interaction for a second, who will be able create these signatures and exactly what information will be present? If anyone can create a signature, what's to stop someone from signing their own module? Even if there is user interaction, what's to stop this same person from using a commonly trusted name (say "SSC") from fooling users into clicking "OK"?

 

Version checking will have to be done to make sure everyone's using the version of the module that the server expects. If there's some bug in a module that may compromise your computer, I could even use the private signing key to issue a recall on a module version so that your copy of Discretion will prevent servers from making you use the compromised version of the module.

 

Cool. Kinda like a built-in blacklist that is auto-updated when you connect to the directory/game server?

 

I actually haven't been successful with getting a java virtual machine to run out of a C/C++ program... although I have used JNI before. I think java's speed will suffice for things that occur on the order of seconds or even tenths of seconds. We'll see what happens when we actually implement it, but if that doesn't work I could make a simple safe scripting language for Discretion that would get the job done.

 

Well, runtime speed isn't really my concern. We both know Java will easily handle most every task this game can throw at it. The initial startup delay and memory usage on the other hand may cause issues. You'd almost have to load the VM in the background after the main menu is displayed to keep the entire process transparent (or close) to the user. Plus, you'll have to account for another ~20mb chunk of memory gone. Granted, most people have tons of memory these days, but it still shouldn't just be thrown away hap hazardly.

 

Also, have you seen the topic on MGB's forums regarding the mervbot creator? Maybe it would be better to use a system similar to that for an alternative to the module system you've already implemented.

[Bak]

The way I see it work is that you put any trusted public keys in a key directory, which by default comes with just my key. When a server sends you a module, it checks to see if the public key is in your keys directory, if not the module is rejected, no prompt just a message saying the module is not trusted and may be malicious. You could of course disable this with a setting for testing modules and such. We will probably need an extra precaution perhaps the first time a key is used give a scary message to make sure they know that accepting a signature from a malicious party could result in windows being deleted or even the signature of a nonmalicious but careless party which releases buggy code should be treated as an equal threat to security.

 

Anyone could make their own key, which is a good thing. Say I decide to disappear and only come back once every 2 years. In order to continue development, another trusted party could take over and start signing modules.

 

As for Java using too much memory, that will be dependent on the quality of the module used. If server owners code them poorly and users get a poor experience they'll stop playing that particular zone.

[»Ceiu]

Well, I was refering to the VM itself, which is rather large.

 

And "ok" to all that other stuff.