Cheating and the Cube Sourcecode

by RvB on 05/30/2004 13:06, 71 messages, last message: 06/16/2004 01:10, 32903 views, last view: 05/18/2024 21:45

Hi.

I think the sourcecode of Cube should really contain a network protocol that is compatible with the binary release, because incompilance of the network protocol does not prevent cheating at all. There are much easier ways to cheat, like playing a huge wall-less map with lots of items instead of the map that all others are playing. This can already be observed by people who join servers and do not know about "/getmap".

The release of a compilant sourceode would however have some advantages:
- One could compile Cube for some uncommon platform - like IA64
- One could modify the server to have for example a fraglimit or a different time limit without being incompatible. Also, serverside-only mods could be made without the need for a special source-built client
- Cube would get a higher acceptance from Linux distributors and could be included in their distros, which would help spreading the game
- No one would think you included Backdoors in the binaries ;)

   Board Index   

#1: ..

by Thalion on 05/30/2004 13:12

This sounds reasonable. Funny, but it never occured to me that, since Cube doesn't do any resource checks, you could just tweak a map for yourself and run through walls etc. Now code hacking allows for some more subtle hacks, but seriously, if a person is really determined to cheat, rather than just toying around, non-code hacks can be just as annoying and hard to detect.

All in all, I'd say, let it go =)

... and then I can finally compile a normal FreeBSD client =)

reply to this message

#2: not gonna happen

by Aardappel on 05/30/2004 19:48

it will make it trivial for anyone to have godmode or insane damage etc in multiplayer. it will kill multiplayer.

Yes I would like for the thing to have the actual source open sourced. In fact, I would like to make it an community project like sauerbraten. But this can't happen without killing multiplayer. Another solution has to be sought.

reply to this message

#3: Re: not gonna happen

by RvB on 05/30/2004 20:24, refers to #2

Hm ... how does Sauerbraten handle the cheating-topic?

reply to this message

#4: Re: not gonna happen

by Thalion on 05/30/2004 20:45, refers to #2

As was already pointed out, killing multiplayer is pretty trivial, as it involves pretty simplistic map editing (e.g. remove all walls) - which is especially easy with Cube's ingame editor. However, there seem to be no cases of serious cheating.

Godmode/insane damege? That would be too trivial and easy to spot, and then people just stop playing with cheaters. At least I always thought this is the best anti-cheating measure in relatively small communities, such as Cube players. And anything more subtle than that would not give that many benefits, more like resource editing.

reply to this message

#5: Re: not gonna happen

by Aardappel on 05/30/2004 21:13, refers to #3

sauerbraten right now just inherits cube's networking & game code. But there is no reason why this shouldn't be replaced by something more secure.

reply to this message

#6: Re: not gonna happen

by Aardappel on 05/30/2004 21:14, refers to #4

just "not playing with cheaters" is not so easy in practice. it still ruins your fun when people like that keep joining the servers you are having a fun game on, and you repeatedly have to discover they are cheating.

I am actually working on a way to combat cheating in cube in a more serious way... will present it here soon.

reply to this message

#7: ..

by makkE on 05/30/2004 22:15

please aard keep the gaming as clientside as it is now, otherwise the many happy 56kers will lose the only game they can enjoy.
what could be done is to compare maps and gamefiles to spot modified stuff.
I think there is no cheater problem right now, since the comunity is small, and most of those that want to cheat will use a game where someone else has already coded cheats.

reply to this message

#8: Re: not gonna happen

by Thalion on 05/30/2004 23:13, refers to #6

> I am actually working on a way to combat cheating in cube in a more serious way... will present it here soon.

This would be great. And if it would also allow to open the source (although I personally don't see how it could work without putting most of the stuff on the server), it would be even better =)

reply to this message

#9: Re: ..

by Thalion on 05/30/2004 23:16, refers to #7

> what could be done is to compare maps and gamefiles to spot modified stuff.

This is not really any different from what we have now. Since the comparison must be performed on the client, as soon as you hack the code (or the protocol), you can tell the server anything it wants to hear...

reply to this message

#10: GPG

by RvB on 05/31/2004 00:37

GPG/PGP signatures would actually fulfill a very good job for these consistency checks. They can not be cheated.

The client could send an MD5 sum of his map and a signature of the md5 to the server. The server checks the signature against the md5 and compares the client's md5 with his own and if both checks succeed, the client can play. The signature should be created by map authors. Problem: the server would need the authors' public keys of the maps that are going to be played. And the other problem: all map authors would need GPG/PGP keys (which would be a good thing anyway though)

reply to this message

#11: Re: GPG

by pushplay on 05/31/2004 01:03, refers to #10

The client could always keep track of two maps: 1 for making md5 sums and another for playing. Cheat protection is very hard, or I'm sure iD would have figured out a better solution by now.

reply to this message

#12: Re: GPG

by RvB on 05/31/2004 01:12, refers to #11

This is of course correct. :/

But I still think that releasing the compatible network source code would not kill multiplayer because of the already mentioned reasons ... additionally: few people of a game community are able to code. Those who can use their skill for i.e. mods. The problem is, if those few, who use it for cheating, provide their hacks to others, though.

reply to this message

#13: ..

by rtf on 05/31/2004 05:30

OTOH, I think one of the reasons that cheating is prevalent in existing MP games is because the target is relatively static - you can ALWAYS count on the server binaries being identical, because it's closed.

If it were entirely open, the situation would change. As cheats were developed, so too would defenses appear. Individual server admins would(in theory) be able to create new server versions that contain additional protection - or if necessary new client binaries. With a setup like that, where every target becomes a new hack, cheating would become unfeasable.

That point of view boils down to technical details though - whether or not the server will be able to sufficently detect cheats, whether or not players will be willing to get new client binaries and deal with the issues, whether it's easier to create or to bypass protection, etc...

reply to this message

#14: a simple server side mode?

by Waw on 05/31/2004 06:07

i was just thinking a server side way of preventing insane damage without bandwidth going up would be for the server to be given ranges that damage could be in for a weapon and then checking every once in a while (like maybe a 5 sec period every 30 secs) to see if they are in normal values

reply to this message

#15: preventing alternate map cheating

by Waw on 05/31/2004 07:01

to prevent people from using blank maps you have a number placed inside the map everytime a map is saved. For example:

take a number from the system clock
divide it by two
add 76
divide it by 45

then embed it in the map. the server will have this number and will check this number against joining games. if they are different it could be resolved accordingly

reply to this message

#16: Re: GPG

by Thalion on 05/31/2004 07:25, refers to #10

> GPG/PGP signatures would actually fulfill a very good job for these consistency checks. They can not be cheated.

They can. You just strip away the md5 and md5 signature from the original map. Even no need to keep the map around, in fact.

reply to this message

#17: Re: preventing alternate map cheating

by RvB on 05/31/2004 10:46, refers to #15

Well ... you can make the client send just about any number. :)

reply to this message

#18: Re: ..

by hungerburg on 05/31/2004 11:40, refers to #13

your scenario reads like an arms race; quakeworld and quake2 are plagued with that. in other news, trusted clients is *very* hard to do, cf. tcpa and palladium. sorting this out will make you a billionaire (if you can afford the patents).

people are free to create their own parallel cube mp universe: server, masterserver and client. is there a masterserver for plain OSS cube available anywhere?

reply to this message

#19: ..

by Thalion on 05/31/2004 14:56

> is there a masterserver for plain OSS cube available anywhere?

Masterserver is extremely easy to write as long as you have the server code; and we do

reply to this message

#20: Re: ..

by hungerburg on 05/31/2004 19:08, refers to #19

I started a masterserver today - its only the http part though: udp communication is missing - so no number of players, map name, game mod etc. test at http://www.myzel.net/cgi-bin/cube/masterserver - download at http://www.myzel.net/hungerburg/masterserver

this is in the hope that it might be useful, no warranties whatsoever apply.

reply to this message

   Board Index