Cheating and the Cube Sourcecode

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

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   

#32: ,.,

by Gilt on 06/02/2004 03:30

Yeah, social engineering is definitely the right approach. However a big problem with the proposed system is that it seems that the 'trust' values are absolute, rather then relative. This means people are going to try to game it - especially the cheating/griefing type.

'trust' should be relative. It should tell the server, "I like this guy", rather then "he's a cheater". (This is how it'll most likely be used anyway). This removes the problems mentioned, such as counter-"not trusts" or clan "not trusts", since now all they're saying is "we don't like each other", which is true!

So you can have these different sub-communities, where the members 'trust' each other, yet at the same time they can also 'not trust' or ignore whole other sub-communities. newbies can now form their own communties with other newbies, while cheaters are still most likely going to be ostracized by all communities.

Servers could be neutral, making a decision based on the sum aggregate trust that those currently playing have towards a client requesting to join. and if a player, bob, doesn't know the joining player, then the master server could check to see if any of bob's friends have trust values for the player.

Or else the servers can themselves be part of all this, and have their own trust values for players, if the site admins want.

reply to this message

#33: Re: have a read

by e:n:i:g:m:a on 06/02/2004 03:57, refers to #23

Well, I really don't trust "Communities" online. lol

Personally, I'd rather have some anonmyous form of authentication like this:

Have the server know the MD5 sum of it's binarys and the client's binarys.

Then, when a client connects, it downloads the binary that the client is running, MD5 sum's it, and if it's stored sum doesn't match the one that it has, then kick the client.

And, if the client sends two binarys, then kick the client (to prevent hackers from sending a second client through packet-engeering software).

That way, there is no possability of the client hacking a MD5 sum: they have to have the correct binary.

Second: when you choose a map, have the client automatically "getmap" but don't overwrite the version of the map that they have, that way the client HAS to play on the server's map.

And when a client issues a "sendmap" command, only accept it if it has it's own name or if the admin accepts it.

Third: include a feature where a client can be kicked from the server or kicked by a majority vote from the other connected clients

Those thing would be rather easy to implement and wouldn't require much power. The binarys are only around 150 KB, so there's no speed concern there. And if you play on the map that the server is using, there is no map cheating either.


That would be the easiest way to ensure **NO** cheating, I think? Are there any holes that you can see??

reply to this message

#34: ..

by Thalion on 06/02/2004 04:37

> That way, there is no possability of the client hacking a MD5 sum: they have to have the correct binary.

Nah. I just send the server the binary it expects to see (and btw it will take quite some time as well).

You have to understand one thing: ANY client-side checking can be beaten with relative ease. No matter what you do, your client still has to send some data to the server - and the client can ALWAYS be modified in such a way it will send what the server expects to get.

reply to this message

#35: ..

by pushplay on 06/02/2004 05:16

e:n:i:g:m:a:
Here's how my hacked client does that:
When a client connects, it sends the server the official binary, which bears no relation to my super-hack binary. I then enjoy my hacked game of everyone looking like bunnies.

The challenge and response model doesn't have a chance.

Pxtl:
You can take that a step farther into Program State Code Protection http://www.pbs.org/cringely/pulpit/pulpit20040219.html . But that's a hell of a lot of work. Re-inventing-computing-as-we-know-it kind of work.

Aard:
I liked the article. I wouldn't say it's a good idea, but it is possible to have users buy signed keys with computing power. Use the power for some worth-while cause like finding a big ol prime and give new users a free, time-limited key. Actually I think this is a pretty good idea, but not for a game.

I don't like the idea of having to trust servers. I like being able to hop around unknown servers when I see people.

reply to this message

#36: ..

by D.plomat on 06/02/2004 11:02

Pxtl:
> Unless a name is an investment (either through patience, through personal contacts, through labour, or through cold hard cash) then users will be able to create and destroy names as they see fit.

That's why there should be some registration for an ID on a web server that takes 10-15minutes... eventually this can be made useful for newbies, like having them learn info about Cube, FAQs, tutorials so that the first registration isn't a waste of time, but cheaters would find very boring having to pass through all this to make new IDs... still this has to be protected by something like antibot(program that generate text a bit deformed on a gif, user have to type back the word on a text input box to prove he's "human", there's probably some opensource/free similar thing somewhere) to avoid cheaters with script kiddies skills to obtain multiple IDs quickly.
Eventually that could be doubled by human control -yes, i think that is the really only efficient control, IMO where technical can protect let's not waste human resources, but there will always be a need for human control- for those really insisting, like mailing the admin if an IP whose x% of accounts have been closed registers too often.

> fully server side executable, play it through a text console or something like that.
??? text-mode Cube renderer, like aaquake? ;)

Gilt:
Agree. Another problem is that circle of ppl trusting each other also add more value to have multiple IDs.
I think there should be some checking done by the server to detect situations that "seems like" "circular trusts" or "not-trust wars", but the decision should always be human, because those situations can probably also occur for legitimate reasons. Random examples: If i make 5 real-life friends know about Cube and we decide to make a small LAN party, of course we'll set trust-eachother relations.
Or a cheater is set "not-trust" by 4-5ppl. He already have registered 5 accounts, and sets back "not-trust" on other ppls to make this looks a "not-trust war".
Those are 2 situation that an admin can solve easily with some chatting with concerned ppl, where a program would have made false accusations against innocents.
Again the point is to have the less monitoring work possible for the admin, and to have human intervention only when a program cannot tell for 100% sure.

All:
agree totally on "classic" technical protection methods, client binary validation is one of the easiest things to defeat, think about so many "uncopiable" copy-protected programs(those protections are *very* similar)... and movement and fire heuristics is an arms race that consumes ~10x more time of a coder to add a supplementary check than a cheater to defeat it, it's something only affordable for a commercial game where they can afford a full-time coder on this, and even then it's not very efficient(try to tell the difference between someone with very good aiming skill and one with a not-100% precise aimbot from a server point of view...).

Eventually some naive technical protections can be added only if they don't have disadvantages and don't cost much programming time, but they are only here as a deterrent for not very experienced coders, and just to make others lose some time while trying to cheat, but will be useless when Cube community will be big enough to contain also unloyal skilled coders ("mercenaries" for clans?).
That's an added bonus of social approach, this doesn't attract "i_know_how_to_crack_every_technical_protection" coders like new copy-protections on software attracts crackers, as the security earned against average-skilled by enhancing complexity is lost by the "challenge" appeal for the skilled ones.

Of course some will always take it as a challenge to defeat it, but then the community coherence and trusts is something much more robust than any technical hack.

reply to this message

#37: when does the ship sail?

by hungerburg on 06/02/2004 13:55

the 95% of work - namely a community site - is already done: unfortunatley advogato is still down (bad sign?); the google cache takes 5minutes to load, if you are curious, take the time. its an OSS apache module; the doc discusses attacks mentioned above.

http://www.google.com/search?q=cache:69NW0wgSlhsJ:www.advogato.org/trust-metric.html

The one difference is: advogato is only one site, while cube is many servers - and I agree with pushplay on "trusted" servers.

Actually, Aard, your proposal must still verify the client: though this time, its not, that it hasnt been tampered with, but that the player is who she claims to be. Which is a solved problem (see openssl).

reply to this message

#38: Re: ..

by e:n:i:g:m:a on 06/02/2004 16:45, refers to #35

>When a client connects, it sends the server the official binary, which bears no relation to my super-hack binary. I then enjoy my hacked game of everyone looking like bunnies.

Except for that you don't have the Cube network code... haha. Then how do you send a binary if you don't know how...

erm, besides, isn't there a way fo the server to check the code that a client is running??

reply to this message

#39: Re: ..

by e:n:i:g:m:a on 06/02/2004 16:56, refers to #38

And besides, my method DOES prevent map hacking on ANY ordinary binary.

And it prevents those chatspammers and other annoyances too...

erm, Perhaps some form of netcode that is encrypted? Yeah.

When you connect to a server, you always get a different (Randomized) encryption key. Even still, make it so that the length of the key is randomized too (perhaps 256 bits to 128). Then if you want to hack the netcode, you need to decrypt the transmissions every time you connecct. Then don't include the encryption code or the netcode with any binary release

Then, when (and if) you hack a binary, you need to know how to decrypt the server's packets (so you can cheat), and you need to figure out how the netcode works when you try to hack it.

Of course it's STILL not completely secure, but it can also be added with sending the binary ENCRYPTED with the new key to the server.

erm, there you go.

reply to this message

#40: Well then...

by Pxtl on 06/02/2004 17:05

The server sends you the key? Then you just use the key when you receive it. Only solution would be closing the key-transmission protocol so the coder has difficulty knowing that they even received the key at all.

reply to this message

#41: Re: ..

by Thalion on 06/02/2004 18:46, refers to #39

Debugger+packet sniffer, and a few hours of work, and I've got your "secret" key, the transfer protocol, and all that.

Forget it.

reply to this message

#42: Exactly.

by Pxtl on 06/02/2004 18:58

Simply sending an encryption key does not work, unless you can find a way to send the encryption key itself in a hidden format. And so we have a recursive problem.

Now, the kernel is here: either way, we only have to slow them down so that it takes longer than a single game to hack in, and the process must be restarted with each game. A heavily obfuscated binary dll file that is recompiled to be totally unique to the given round and has a unique encryption key for that round. Then again, it might still be possible to trace through the file and find the key, and generate a procedure to extract the key for any file.

Essentially, if there's a technological solution, it is beyond the scope of this project.

reply to this message

#43: enigma

by pushplay on 06/02/2004 23:22

> Except for that you don't have the Cube network code

But the whole point was that Cube was open sourced and thus I do. Other wise you're relying on security through obscurity, which is exactly what Aard is doing right now.

I've thought about it and I've decided that the whole endevour is hopeless. Any automatic, strong anti-cheating system like we're hoping to see here relies on attaching a cost to cheating. But this cost has to be applied to newbies or else cheaters will constantly cycle through new identities. I for one got into the game after a quick play through. I could easily have deleted it five minutes in (and would have had I not found people online to play with).

I'm thinking that a mild form of the arms race (ie: more server side) is less work, and good old fashioned vote-kick will clean up the crumbs.

reply to this message

#44: ..

by makkE on 06/03/2004 01:43

yepp.. a kickin option would be good...
btw I think that cheating isn´t a problem in cube right now.
Luckily noone bothers enough about making cheats... imho we should discuss anti-cheater stuff when the problem is there...
but I´dont think there will be a problem since cube is still small (and that´s good) and until now i haven´t met a cheater in cube (only some invulnerables that were surprised themselves and they reconnected right away, when told so...)

reply to this message

#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

   Board Index