Cheating and the Cube Sourcecode

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

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   

#45: ...

by Aardappel on 06/04/2004 04:20

Gilt: I don't see how that is useful. The "don't trust" should be a strong accusation since its sole purpose is denying people access to servers, which is the whole goal in the first place.

I have been intensively part of the qw community for 5 years for example, and have seen its social structure form and change. Trust me, the is a LOT of "not like" going on between different groups and people at any one time. It is a useless metric. There are always players and clans not liked for their cocky attitudes etc. It doesn't help the system in evaluating anything.

Yes it is possible to restrict votes purely to trust, but that relies on the friends of a cheater to drop trust as soon as they hear he is a cheater. That may be hard to find out, and in the mean time he is wreacking havoc.

Yes people will try and play the system... that's why you have moderators. I think playing it is hard, and easily nullified.

hungerburg: I am sure I am not the first to come up with this idea... but saying its done is not true either. We'd need something rather game specific and in implementation, Cube specific.

pushplay: well, maybe for a future game, maybe for sauerbraten... but Cube's clientside gameplay is part of its design, and its not goin to change. If you think you can just add a little bit on the server side and it would be effective, you are very naive about how big the cheating problem potentially is. It would basically be a complete rewrite of all Cube's game related code, and then it would STILL be very cheat sensitive just because its open source. Quakeworld is opensource, has fully serverside gameplay, and has to rely on closed source proxies to have any kind of hope of fair gameplay. You will NOT win such an arms race.

reply to this message

#46: Re: ...

by pushplay on 06/04/2004 05:36, refers to #45

Yeah, I was mostly talking about Sauerbraten.

I don't expect the arms race can be won, but a few protections can act as a deterrent.

Is there something wrong with using an ip as identification?

reply to this message

#47: Re: ...

by spentron-postcrash2 on 06/04/2004 07:05, refers to #46

Is maphacking still allowed? There should be at least protection against basic non-code hacks. Protect the basic map reperitoire, don't allow forever to getmap (within allowing normal functionality).

As to my idea of functional checks you're calling "heuristic", I don't see that as an arms race, it's pretty clear-cut what you can catch. Minor differences are moot, but so is probably the whole thing on further thought. The part of it with use of clients as consensus for map data might be useful.

reply to this message

#48: Re: ...

by Aardappel on 06/04/2004 22:28, refers to #46

yes, most people's IP changes everytime they connect to the internet. For me that is every day or so, sometimes more often.

reply to this message

#49: ..

by e:n:i:g:m:a on 06/06/2004 00:43

I believe maphacking is still possible...

But you can stop it by forcing a "temporary" getmap every time the map changes when playing online

reply to this message

#50: Re: ..

by hungerburg on 06/06/2004 05:28, refers to #49

the server doesnt have the map. is sendmap/getmap peertopeer?

reply to this message

#51: Re: ..

by e:n:i:g:m:a on 06/06/2004 07:53, refers to #50

Well...

According to my understanding, the server HAS to have the map. if you and the server don't have the map, someone else has to "sendmap" before you can "getmap"

So no, it is client/server, not p2p

reply to this message

#52: ..

by anonymouse on 06/06/2004 22:23

Maphacking and aim-bot style hacks are inevitable in any open network game. As a server, you have no control over what the client does, all you do is take in data and broadcast a message to the clients. The best approach for cheat protection server-side is to perfrom regular 'sanity-checks' which verify that everyone is playing by the same sort of rules, i.e. no walking through walls, no flying through the air, no moving really fast, no god mode, etc.

That's all you can really hope for in a client server scenario.

reply to this message

#53: ..

by Lacrima on 06/07/2004 19:52, refers to #52

the question is if there is any use for an anticheat protection.
Yes the code and the whole gamestyle are vulnerable but who whats to cheat. Cube is not a a mainstream-game like eg CS where everyone wants to be better than the other 100 players at their school (just an example). Who plays cube these days has no interest in cheating !
this is just my opinion :)

sorry i'm german but i hope you got the point :)

//Lacrima

reply to this message

#54: Re: ..

by D.plomat on 06/07/2004 20:30, refers to #53

I agree a bit, but at least it needs some protection so that cheating isn't trivial, it's a small community but i already saw bad behaving ppl online, like edit-ruining the maps or flooding the chat-lines with obscene insults, so i doubt those ppl would refrain from cheating if technically they could...

Moreover, it's a small community but growing a lot, so it's better that the game is ready before cheaters come-in, so a very efficient innovative trust system without bloating the code (like heuristics) can only be a good thing :)

reply to this message

#55: cheating if technically they could...

by pushplay on 06/09/2004 13:39, refers to #54

If you can't cheat at this point then you just can't cheat.

reply to this message

#56: Re: cheating if technically they could...

by D.plomat on 06/09/2004 18:42, refers to #55

indeed, because actually the few bad behaving ppl have low tech skills, but as the community grows the probability of having some with better technical skills and willing to cheat will increase

reply to this message

#57: Re: ...

by __gilt on 06/09/2004 19:14, refers to #45

Maybe I can explain it better.

In a sense, right now your idea is kind of like a global semi-private set of servers. I was thinking that instead of making it global, it should be semi-private in terms of the people currently playing on the server.

In other words, it turns a public server into a 'protected' server, which can be accessed if you're a friend of the people currently playing, or a friend of a friend, etc. Just like the global model, this makes it easier to get into then a private server, while still having most of the protection that private servers can offer.

But with the global model, there is only one set of friends, so you're either in or you're out. With this model, there can be multiple groups of friends, each of whom can ignore the rest as they play on different servers, and so their implicit votes don't affect everyone like it does in the global model.

reply to this message

#58: Re: ...

by e:n:i:g:m:a on 06/09/2004 19:59, refers to #57

Uhhh, that's like REALLY complicated, and may send beginner players away from cube unless the trust stuff is done automatically by votes in-game...

But it would be nice to be able get someone off a server by a majority vote or admin...

reply to this message

#59: Re: ...

by Aardappel on 06/09/2004 21:00, refers to #57

its not in or out... every server can have its own level of privateness. I don't see the point of having these friends groups... again its about anti-cheat, not social clustering.

reply to this message

#60: Re: have a read

by rtf on 06/13/2004 11:54, refers to #33

The client can send the server the wrong binary. :P Getting around that trick would take some horrific memory-management voodoo; I wouldn't even want to think about it.

Reposting the link again since it got a bit buried:
http://wouter.fov120.com/rants/trusted_communities.html

The social system is really the only long-term solution that doesn't involve an arms race - in those final victory would only come by completely exhausting one side. They've been shown to work in Wikis too - Wikipedia is an absolutely amazing site and gets better daily. And as Aardappel said eariler, "Playing the system" with a social network is possible but requires a diligent attitude and constant wariness - that means the people left over are relatively deserving, because even if they aren't good at the game they're good at seeming like they are ;)

If we wanted to extend the concept, we could turn the master server into a clone of Valve's Steam....minus the bad/commercial aspects. Things like the buddylists and IM system were pretty convenient as I recall, though they were never necessary. A "maybe someday" feature, like voice-chat and other such nifty things.

Well, the direction needed has been mostly decided anyhow so maybe someone should start development on the backend? :) I have experience with Python, am most comfortable with it and it's applicable to the Web interface and database aspects - though I'd have to work at it since I've never touched those libraries before nor do I have experience in those areas. But the implementation seems pretty straightforward, although there are a significant number of features needed to make it really pleasant to work with:

-Interface to add/remove keys, adjust trust lists, moderate and invite players, and any other needed admin functions.
-History and tracking functions. (so that mods can investigate without needing to rely on fallable written statements) (or is there a privacy issue in this?)
-Recalculate and query keys' points; Recalculations can be done as trusts change.

Performance shouldn't be much of a problem, as long as everything is done in a relative fashion(statistics, trust calculation...) - the exception being trying to calculate a different value for each person's trust, which is a problem that can only be resolved by setting an "anchor" key at various point levels, and isn't really necessary in any case. We can do OK by leaving it at 1 per person, I think, and leaving the rest to moderators. That part needs some thought still, though.

reply to this message

#61: ..

by Lacrima on 06/13/2004 18:05

i think all that is too much work with less use.

All these methods are very complex at the todays status of cube.

Just think about a kick / ban function. Either by name (perhaps to simple) or by something linke a cubeID or something similar.
(sorry i'm german)

//Lacrima

reply to this message

#62: Re: have a read

by rtf on 06/13/2004 20:23, refers to #60

I just noticed I replied to a really old post. But the point stands. I'll look into doing a little something to start it today.

reply to this message

#63: Re: ..

by makkE on 06/13/2004 22:05, refers to #61

yes i agree.. as i said earlier, cheating in cube is no big problem... and having a "social system" way of fighting cheaters would scrare off pll to get into cube I think. IMHO most ppl that like cube ain´t the kind of ppl that would try to cheat...

reply to this message

#64: Progress: DB options...

by rtf on 06/13/2004 22:37

http://www.hwaci.com/sw/sqlite/

It's a SQL database striving for simplicity, under a public domain license. Sounds like Cube doesn't it ;) After doing some calculations, I found that it'll fit our requirements quite well; with a key length of just 8 bytes, we get 1.26*10^89 possible keys, and even with a million players each with 10 relations, with each row of the table containing two keys and a relation-marking, the database should be only at most 240,000,000 bytes in size(~228mb if I calculated right). My only worry would be whether the transaction load might become a bit high, since every player connecting to a server would require a new query+sum to get a value.

Well, if it gets to be too much I guess the system could move the summations to a seperate DB and so balance out the load.

reply to this message

   Board Index