Cheating and the Cube Sourcecode

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

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   

#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

#65: Re: ..

by e:n:i:g:m:a on 06/13/2004 23:43, refers to #63

You're right... But there are those OH SO IRRITATING chatspammers and troublemakers... but a kick/ban thing would be a good solution to that...

reply to this message

#66: Progress: implementation

by rtf on 06/14/2004 10:07

It's mostly done, albeit without any "moderator" capabilities.

Features:

-Database interface is stuffed into a single Python class, for better or for worse. It'll be more efficient for multiple transactions, I believe.

-Uses pysqlite, probably the tiniest Python library I've ever seen, owing to SQLite's small size; it's something like 200kb.

-Accepts queries for relations, trust levels, and key lists.

-Keys are big: (62*40)! combinations to be exact, using ASCII lower case, upper case, and the digits for characters, which will give you a number in the thousands of digits IIRC. We'll never run out ;)

-Keys are safe: Even though the original implementation assumed trusted game servers, I wouldn't trust 'em :P So therefore there's also a password for each one, which can be sent from the client directly to the master server, and might come in handy if the server took on a larger role than just anti-cheat. The actual use of passwords can be made optional if I get argued out of my paranoia :)

-Trusting works: At the moment, everyone gets to set between -1 and 1 point of trusting per "relation" (and no more or less!). By default, you trust yourself, so you get a free point. This is the simplest system I can think of; maybe it'll work, maybe not.

Integrating it to a web interface still has to be done; that may or may not prove to be harder :P

reply to this message

#67: Re: Progress: implementation

by hungerburg on 06/14/2004 15:11, refers to #66

the proposed social "network" actually requires a central authority.

this very nicely fits the (x509) directory model. actually, one could - without changing the cube binary - proxy client/server/masterserver communication through stunnel (http://stunnel.org), and have identifiable users AND masterserver.

in this scenario, the masterserver would play the role of the certificate authority (think verisign) and authentication authority (think microsoft (passport)). it would hand out client certificates to the requesting community members. they (ie. we!) would then have to install them with the client. the default install would have to be bundled with a "guest" certificate. the servers would not need a certificate, if they just proxied client/masterserver authentication traffic.

WOULD be chief architect hungerburg
film at http://www.projectliberty.org/

reply to this message

#68: Stepping back

by rtf on 06/15/2004 04:13, refers to #67

The more I think about this, the more I think that trying to hide the system from the end-user is inefficent and only brings us part of the way to our goal; for social networks to reach their full effectiveness, we all have to know who we're dealing with, and that means giving them a full user identity and profile. With randomized keys that can anonymously declare each other trusted or untrusted, we have no form of marking identity. This means that the relationships formed are weak, impeding the proper use of the system. There's no association between the key and the player.

With a stronger identity mechanism, players will have an easier time spreading information about each other and forming groups to support or punish one another. Rather than saying "aD360cfDr2xK941fZ is a cheater" you say "rtf is a cheater" and people will be able to recognize who "rtf" is.

I already know what happens if you don't put things in a human-readable form like that. In Half-Life, oftentimes someone mean would say to vote-ban player #18, without saying who #18 was. #18, of course, turned out to be an innocent guy, when you brought up the user list and matched up the number with the name. But nobody looked! They're too lazy for that. The same thing would happen if you didn't provide a human-readable identification; some jerk would log on under the same nickname as an innocent guy(that one is VERY annoying), and you wouldn't be able to tell them apart unless there were a global username.

That means adding a few additional services - it's really going to have to be a site that serves the whole community, not just the technical aspects. Bulkier than we first thought, but there are enough benefits that I think it has a point.

reply to this message

#69: The current database code

by rtf on 06/15/2004 05:43

http://people.ucsc.edu/~jhofmann/sdb.py

Uses Python and PySQLite:
http://pysqlite.sourceforge.net/

Currently it takes arguments for commands or can be converted for importation. Probably clumsy in many places since I've never worked with any of this stuff before, and adding the "password" feature broke its existing test run, but that can be fixed by commenting out two lines.

After we've hashed out the design a little more concretely I might start work on it again; as-is, it isn't ready to communicate with anything else yet.

reply to this message

#70: Re: The current database code

by hungerburg on 06/15/2004 12:27, refers to #69

Im not saying I completely understand the code: there are two tables, one for the users (passwords) and one for trust relations (trusts); the trust a user enjoys is the sum of the trust, others gave her?

reply to this message

#71: ..

by rtf on 06/16/2004 01:10

Yes, that's how it works currently.

reply to this message

   Board Index