home home

downloads files

forum forum

docs docs

wiki wiki

faq faq

Cube & Cube 2 FORUM


Cheating & open source, revisited

by Aardappel_ on 04/27/2005 07:54, 218 messages, last message: 06/16/2006 17:23, 171865 views, last view: 04/16/2024 13:04

As you all know, cheating is a problem for Cube being Open Source. Noone likes the current solution of the incompatible binaries, and I am getting to the point where I see the usefulness of having other people continue to work on Cube whenever I don't have the time.. currently that is problematic and would be much easier if the source to the official game could be truely open.

Multiplayer continues to be an important aspect of Cube, so we can't ignore cheating and simply hope that people won't change 1 line of code to enable god mode or permanent octa-damage, because they will (tell me something about human nature and the people on the interweb).

The solution can't come in the form of "cheat protection", this simply isn't possible with the current cube, and even if the entire gameplay code was moved serverside, is still fragile. Don't even suggest it... make sure you understand the nature of the client/server gameplay code before commenting.

The solution for Cube I feel has to be a social one. As you may remember, I designed a solution before:
http://wouter.fov120.com/rants/trusted_communities.html
The problem with this particular design is that it is too complex to set up, and too centralized. I would like to come up with a solution that is simpler, less implementation work, and can work with any group of people, centralized or not.

This is the idea I came up with sofar:

Every player that wants to play in a cheat free environment, can use a command in Cube to generate a set of key files. A key file is simply a file of, say, 10000 random bytes. The player then hands out these files to players he trusts... or rather, players he wants to trust him. (why there are multiple files will become clear later).

A server can either be in untrusted mode (default, works as before), or trusted mode. It can be set to trusted mode by the server admin, or voted by the players until the server empties. It will show up in the server browser as trusted.

If a player A & B connect to a trusted server, A looks up B's nickname in his folder of key files. If he finds a corresponding key file, he chooses a few random file offsets and reads the bytes there. It now sends a packet to B asking it for the bytes at those offsets. If B really is B, it can simply read its own keyfile and return the values. A now compares the values, and if they match, it sends a "I trust B" packet to the server. The hud shows which clients you trust, and for each client how many clients trust him in total. You are now sure that B really is who he says he is.

On a trusted server, people that after exchange of trust packets have gained no trust, can be booted from the server automatically. This allows you to play games with trusted people in your community, and have external people unable to be join the game.

asking for random offsets guarantees that untrustworthy clients or even servers never get to sniff keys. "Trust" is evaluated locally and for you only, so can't be spoofed.

The one problem would be handing your key file to someone who later turns out to be untrustworthy. This person could now impersonate you and appear to be you to all your trusted friends. Hence the multiple key files, so you can give a different key file to different people (or groups of people). That way, if the person "goes bad", he can't impersonate you towards your friends, as he doesn't have the keyfile your friends have.

The system is not perfect of course. You can still have 2 cheaters join together and trust eachother. Luckily cheaters hardly ever come in groups, and there are more complicated ways to protect even against this.

The biggest issue is the inconvenience of having to exchange key files, and especially to require new players to find existing players on forums/irc before they can sensibly play. I think it is bearable though, as you only need to do it once, and Cube multiplayer is a fairly closed community. And if servers are by default untrusted, you can give newcomers the benefit of the doubt until they behave suspicious.

What do you all think? Please think it through thoroughly before commenting (I am talking to you, Jean Pierre! :). I am especially interested in "holes" in this system, i.e. ways that cheaters could abuse it if they really wanted to.

Go to first 20 messagesGo to previous 20 messages    Board Index   

#202: ..

by snesreviews on 01/13/2006 13:19

What's to stop somebody connecting with a cheat to give them 200 health every time they are respawned, though? Odds are nobody would notice because they do die eventually anyway.

I'm pretty sure stuff like this is going on at the moment anyway: Having armour and full health, running after some guy with a shotgun, hitting him three or four times at close range, then him turning around and killing you with one shot seems to be a relatively frequent occurence from my experience of the game... wallhacks would also probably go undetected anyway, regardless of the solution, unless the client literally doesn't know where the players are until the server decides it's time to send out the coordinates. A well coded aimbot would also go undetected, and it's not very easy to turn around and accuse somebody of cheating...

Keeping as much information as the bandwidth/load specifications can withstand on the server and the client is still the most secure way and convenient way to reduce cheating as far as I can tell.

Plus keys remove the plug-and-play online appeal of the game. I never would have played this game online if I required a trust key, and few enough people play this at any given time as it is...

reply to this message

#203: cheating

by beckers on 01/14/2006 19:36

Maybe you can integrate an external program that checks the md5 checksum of de cube.exe file, or maybe a program that checks the size of the file?

reply to this message

#204: cheating

by snesreviews on 01/14/2006 21:48

:beckers

You would still be relying on the client software to read the checksum, though, so it would probably still be hackable.

reply to this message

#205: ..

by Coxor on 01/15/2006 04:53

Make an option for how client-side or server-side you want your server to be?

Anywhere from each client sending coordinates and other things to each other client to each client sending input and the data in some files to the server and reciving an image of what your screen should look like?

Either that or let a server kick/ban and allow others to do the same.

Or ranks: You can kick/ban/assign a rank as high as your rank maximally to anyone with a lower rank than you.
Also, there'll be for and against commands(which should be binded), and a time from the last unique(made by someone who has not voted in the poll) command that the vote should end(say, 5 seconds).
To get the for and against scores, you add up the ranks of the people in the respective catigories.
If there's a tie, the vote fails. You're for it by default.

The server has a rank of infinity.

reply to this message

#206: rcon

by 1134 on 04/23/2006 04:20

I have a dedicated server running on a seperate computer from the one i play on but still on my lan. A few times, i have been locked out of my own server and have had to reset it by closing the server program. A passworded remote console to the server would be a good way to give the server owner and people of their choosing full control, but if no one with the rcon password is playing, the server would default to the mastermode type of control. The rcon password should also be able to be used to connect to a server in private mode.

reply to this message

#207: Re: rcon

by Aardappel_ on 04/24/2006 01:03, refers to #206

rather than that, I'd prefer to debug what can cause some to leave a server in private mode. The code is meant to reset the server state as soon as the last person leaves... no idea why this is not working...?

reply to this message

#208: Re: cheating

by CC_machine4 on 04/24/2006 23:47, refers to #203

lol, 5th time that has been suggested and counting...

can't you just make the server check the coordinates and the shooting of the players and if one player appears to have god mode or something... kick him? just an idea, would require quite a bit of server side code though...

reply to this message

#209: Re: rcon

by CC_machine4 on 04/24/2006 23:52, refers to #207

soz for duble post..
about leaving a server in private mode.. could you add something to the server code that would check if there are no players in the server like evey second and if so, reset to normal non-provate mode? how can this fail?

reply to this message

#210: cs style cheat prevention?

by Passa on 04/25/2006 02:26

if anyone has played CS they will know that alot of cheating accusations come from people watching that persons screen and seeing them have an aimbot or whatever

if you implemented a feature for spectator mode that let you see a player's screen, it would help determine if the player is a cheater or not, with the client sending the health and ammo numbers

reply to this message

#211: MasterMode stuck [was "rcon"] (actually this is OT)

by MeatROme on 04/27/2006 10:49, refers to #209

UTSL ... Use The Source Luke! ... with
Luke = CC_machine4.

The code does this check every time a user disconnects - instead of the overhead entailed in a time-based check.

Even if this spanks of hybris (with regard to Aardappels knowledge [http://cubeengine.com/forum.php4?action=display_thread&thread_id=566&start=200#26290]) - I can't imagine either why it's not doing what it's supposed to do ...

... it might serve as a hint that I have experienced servers that - upon connect - suddenly rapidly decrease the minutes left to play down to zero (from whereever they started off (not 10/15!)) ... and then trigger a map load.

So maybe this whole problem has something to do with servers going into a sort of limbo after the last client disconnects - time stops passing for them obviously, since they continue where they were left off and jump back to real-time when revisited - though as I understand the code this shouldn't happen.

A work-around could be to at least _re-check_ the settings every 1h (in the master-server update routine).

JM2CW

reply to this message

#212: Re: cs style cheat prevention?

by MeatROme on 04/27/2006 11:02, refers to #210

Yeah!
A Chase-CAM would really be a nice feature.

I've experimented with the code a little but have encountered difficulties.
Due to the fact that other players are not of the same structure as player1/camera1.
Simply trying to hook a thirdperson-viewpoint to another player entity doesn't work as well as with watching yourself :(

Another issue is for the CAM to move smoothly.
Even though packets arrive regularly (>30/s right? [for correct physics]) - simply repositioning the CAM will be jerky.
Calcing a diff-vector (which results in smooth movement) can be tricky.
For instance in corridors when the multiplayer-entity goes round a corner ... you would need to keep travelling vector and pitch in a time-lagged synch which looks good.

In the end it will certainly help a lot when health/armour and multiplayer-gun are implemented into the protocol.
I have already seen players take 2 rockets and a [full] MG assault ... and live - that might have been cheating, ... but might not have.

reply to this message

#213: Re: cs style cheat prevention?

by Passa on 04/27/2006 15:10, refers to #212

another simple solution, if you THINK someone is cheating, don't say anything

just leave

cheaters want attention, they want people to see their 'brilliant' hacks

if no-one hangs around to see them, its not fun for them at all

reply to this message

#214: Re: cs style cheat prevention?

by MeatROme on 04/27/2006 22:11, refers to #213

As has been sayed B4:
These skills could easily be benificiary to us all.
Then again I'm not so sure there are that many cheaters around as is often claimed or implied by this on-going discussion.
There are quite a few sudden network hiccups - my wager'd be it's _that_ instead of cheat-clients in ... let's see ... 92.7% of cases ... ;-)

reply to this message

#215: A Way to improve on this

by Andy on 04/27/2006 23:59

One way to greatly improve you verification scheme would be to use a digital signature. This would allow players to only have 1 set of keys, and would make it very dificult for another player to impersinate him.

Each player would create a pair of keys which numbers encrypted with one may be decrypted with the other, there are various ways to do this, the wikipeda can be consulted for more crypto information.

The player A keeps one key, his private key, and distributes the other key. Player B trusts player A and adds his key to his list of known keys.

In order to validate player A, Player B would send a randome number to Player A, then Player A would encrypt that number with his private key and send it back to player B. Player B would try to decryp the result with all his the keys of the people he trusts, if he gets the orrigional number back then he knows that player A is one of his trusted players and can verify him. Other wise he does not.

While this is somewhat processer intensive, it should not be a big deal as it only needs to be done when a new player logs in.

If intrested feel fre to email me about it at andyg314@yahoo.com

reply to this message

#216: Re: A Way to improve on this

by Aardappel_ on 04/28/2006 19:40, refers to #215

I suggested a scheme similar to this before. It's just a lot of hassle to organize, the current system is a lot simpler.

reply to this message

#217: Re: cheating

by lucilandeo on 06/11/2006 06:09, refers to #208

cheat code/Cube 1

reply to this message

#218: codes

by lucilandeo on 06/11/2006 06:10

..

reply to this message

#219: ..

by ef on 06/16/2006 17:23

How about running 2 processes simantaniously, one source that\\\'s the game. And one closed on that regulates player validation and status?

reply to this message

Go to first 20 messagesGo to previous 20 messages    Board Index   


Unvalidated accounts can only reply to the 'Permanent Threads' section!


content by Aardappel & eihrul © 2001-2024
website by SleepwalkR © 2001-2024
53666549 visitors requested 71432944 pages
page created in 0.096 seconds using 10 queries
hosted by Boost Digital