Maybe another approach on anticheating?

Post Reply
saavedra29
Member
Posts: 28
Joined: Mon Mar 06, 2017 00:19
GitHub: saavedra29

Maybe another approach on anticheating?

by saavedra29 » Post

I was about to make public a server i'm preparing the last days with focus mainly on realism, survival and PvP. But this is suspended (or maybe cancelled) as i discovered suddenly how rediculously easy to create a cheat client. I read some threads on the server about anticheating, and all of them focus on anticheating through modding. Also read that with the CSM that is now introduced already existing cheating opportunities are now more exposed.
I think this is a wrong approach becouse it would end up bloating the server with high CPU overhead and even more in server with many clients connected. Also saying that the core developers should work on giving the core more control and "responsibilities" is easy to say but not to do. So could we instead consentrate on the approach of authentication and "software integrity/authentication" through public key encryption? So here is my scenario:
The server side generates a public and private key. Creates a unique version of the client, compiled with the private key inside and an internal mechanism of signing and decrypting with this key. The server on the other side keeps secret the public key and uses it to encrypt the data it sends to the client. The client responds signing the data with the private key. This way we ensure 1) that the data (which contains also data used for cheating today) won't be read by someone before entering the compiled client 2) that the server will know that is "talking" with genuine client.
This assumes that for each server one should have different client. But for someone who wants to play in 1-2 servers seriously and without cheating and getting cheated this is not a big deal. Also i don't know if the processing and delay for the data encryption and decryption will be higher than what a "serious anticheating" mehanism would cause. And i don't know how difficult is for reverse engineering to reveal the private key.
Do you think that this is implementable or maybe i have missed something very basic? I'd like to read your opinions.

User avatar
burli
Member
Posts: 1641
Joined: Fri Apr 10, 2015 13:18

Re: Maybe another approach on anticheating?

by burli » Post

My opinion is, that I never start a public online server because of this reason. The only way I see is, that it is possible to compile a binary with a private key and only allow to connect to the server with this unique version of the client. But even this is not 100% secure.

As long as it is possible to compile own clients with builtin cheats I don't start a public server

User avatar
Linuxdirk
Member
Posts: 2501
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Maybe another approach on anticheating?

by Linuxdirk » Post

The problem isn't an altered client or the integrity of the data (having it encrypted would be a nice-to-have anyway) that is transferred from or to the server or the client. The problem is that it's quite easy to compile a client that allows cheating the whole game or create a CSM that allows cheating some parts of the game.

How exactly would your idea work? Either I missed something or you did not mention what exactly would happen after the server generated a custom version of the client. Will it be downloaded? How will the server decide the target operating system and architecture? How does a custom client prevent CSM?

I agree with you that server owners should be able to control gameplay relevant parts of the client. That means mods (which already is like that because that's how the client/server model of MT works) and CSM (which currently is not controllable at all).

Server owners should be able to set a flag that disables CSM while connected to the server. Yes, it is still possible to alter the code and compile a client that ignores this flag but that is much harder than copy-and-pasting a folder into another folder and clicking a button.

And instead of outsourcing more and more functionality to the client the server should gain more control. The client should be as dumb as possible. In the ideal state the client only displays what the server tells it.

saavedra29
Member
Posts: 28
Joined: Mon Mar 06, 2017 00:19
GitHub: saavedra29

Re: Maybe another approach on anticheating?

by saavedra29 » Post

Linuxdirk wrote: How exactly would your idea work? Either I missed something or you did not mention what exactly would happen after the server generated a custom version of the client. Will it be downloaded? How will the server decide the target operating system and architecture? How does a custom client prevent CSM?
Sorry, when i said data integrity i meant the integrity/authenticity of the software that is connected to the server. Not the data transfered.
The server side writes the code for the client. It's written in a way that to the CSM api is exposed ONLY data that can't be used for cheating. Then includes the private key and a mechanism (i guess ssh) to sign and decrypt data with this key. The public and private key stay both secret on the server-side. The code is compiled on linux and windows machines and realeased for the users to download according to their operating system.
The client user downloads the client and uses CSM only according to the client rules. How can the client-side cheat?
The key is that no unencrypted data should be accecible by the client user. That only the compliled client should have access to this data and filter what to expose to the api user. Again, i don't have the experience to know if this is really implementable because i don't know the mechansim behind "public/private key embedding inside the client".

User avatar
Linuxdirk
Member
Posts: 2501
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Maybe another approach on anticheating?

by Linuxdirk » Post

saavedra29 wrote:The code is compiled on linux and windows machines and realeased for the users to download according to their operating system.
So you will provide a build environment for Linux users, Windows users, Mac OS users, and Android users in both 32 bit and 64 bit x86 and ARM architecture (= a minimum 16 build environments/scripts)? Will you static link the external libraries or will it be done by dynamic linking? And against which version of the libraries you want to compile? Will you provide a version that can be installed? Will you create apk files for Android users? How does the user get the file?

You see: "compiling and sending to the user" sounds nice, but when you look closer there is a shitload of stuff to consider. And since compiling takes some time this would discourage users to visit random servers.

But let's say this would really work in some weird and complicated way: How does this prevent "CSM cheating"? Will you alter the client so CSM is not available?

saavedra29
Member
Posts: 28
Joined: Mon Mar 06, 2017 00:19
GitHub: saavedra29

Re: Maybe another approach on anticheating?

by saavedra29 » Post

OK, let's forget about CSM. Say it never existed, no flags, nothing. And let's assume that the admin knows how to compile the code for the operating systems he wants to support.
The source code is published in Github in a way where before running the compiler command you have to set the private key in a flag. Or put it in a variable in the code. Then compile the code normally according to the target OS. I don't understand where is the difficulty with static-dynamic libraries and all these details.. maybe because i lack knowledge. Just compile against 32-64 bit Linux and Windows. Now if some admin wants to support more operating systems he will have to do extra work. It's up to him.
Linuxdirk wrote: Will you provide a version that can be installed?
Yes, installed according to the official documentation of Minetest since the compilation will have been done according to the same documentation.
Linuxdirk wrote:And since compiling takes some time this would discourage users to visit random servers.
That's true and a disadvantage, but as i said i don't think it's a big deal. Someone who really wants to play a survival game without been cheated and cheat won't bother installing once, see if he likes the server and if not just delete the client. The incentive to play on a non-cheating server is big enough (at least for me).

User avatar
Linuxdirk
Member
Posts: 2501
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Maybe another approach on anticheating?

by Linuxdirk » Post

saavedra29 wrote:OK, let's forget about CSM. Say it never existed, no flags, nothing.
You can't solve issues by ignoring them :)
saavedra29 wrote:That's true and a disadvantage, but as i said i don't think it's a big deal.
In my opinion a much better solution would be making the client dumber and not smarter as it is currently done. For example: Drowning. If there is nothing in the code that manages drowning there is no way to make the client ignore it. Same with health, tool wear, etc.

And if the client is noting more than an interface to the server, the devs could think about how they best implement data transfer integrity (there are already several different widely supported ways to do that, the most common might be TLS which is mostly used for HTTPS for example).

saavedra29
Member
Posts: 28
Joined: Mon Mar 06, 2017 00:19
GitHub: saavedra29

Re: Maybe another approach on anticheating?

by saavedra29 » Post

Linuxdirk wrote:In my opinion a much better solution would be making the client dumber and not smarter as it is currently done
Sorry but this doesn't make sense to me since anybody can change the client code :) I think you wanted to say:
In my opinion a much better solution would be making the server smarter to expose less data to the client and control more actions. Or something like this. You know on 99% of the discussions people mean the same thing but think they disagree because they say it differently. So giving the absolute control to the server means i.e. that almost nothing wll be loaded on the client and for every single node that i will dig, a new packet will have to be transfered through the network. For the simplest action the user does big amount of network traffic will have to be generated.
We see it from different point of view. You propose a "separation" of client and server while i propose a "merging" with the blessings of encryption. I agree with your approach but with the assumption that i have a super duper P.C. desktop and a very fast and reliable connection :)

Byakuren
Member
Posts: 816
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri
In-game: Raymoo + Clownpiece

Re: Maybe another approach on anticheating?

by Byakuren » Post

It would be a violation of the LGPL to send a client binary with the private key unless source code is included (this would include the private key, as it is used to create the end binary).

And anyway, a dedicated cheater could extract the private key from the provided binaries. Ways to prevent this fall into the realm of DRM.
Every time a mod API is left undocumented, a koala dies.

User avatar
Linuxdirk
Member
Posts: 2501
Joined: Wed Sep 17, 2014 11:21
In-game: Linuxdirk
Location: Germany
Contact:

Re: Maybe another approach on anticheating?

by Linuxdirk » Post

saavedra29 wrote:Sorry but this doesn't make sense to me since anybody can change the client code :)
What does not matter if there is nothing on the server side that accepts whatever a modified client sends. If it sends “This usage of the tool did not cost any wear points” the server simply ignores it and removes one use from the possible tool uses. Or when drowning and the client says “I am not in water” the server knows that this is not correct and removes one air bubble.
saavedra29 wrote:In my opinion a much better solution would be making the server smarter to expose less data to the client and control more actions.
Don’t expose any data at all. Just send render information (direction, movement, position, etc.). Anything should be handled completely by the server without the possibility to change it from user side except key presses are transferred to the server.
saavedra29 wrote:For the simplest action the user does big amount of network traffic will have to be generated.
Yes. The network code has to be optimized, of course.
saavedra29 wrote:We see it from different point of view. You propose a "separation" of client and server while i propose a "merging"
Yep. We have different opinions on that. :)

User avatar
rubenwardy
Moderator
Posts: 6087
Joined: Tue Jun 12, 2012 18:11
GitHub: rubenwardy
IRC: rubenwardy
In-game: rubenwardy
Location: United Kingdom
Contact:

Re: Maybe another approach on anticheating?

by rubenwardy » Post

Client side prediction and server side reconciliation will solve almost all cheating, except that which is informational

See this and the next chapter: http://www.gabrielgambetta.com/fpm1.html

Having a dumb client is a stupid idea, that's not how you make a good multiplayer experience.
Linuxdirk wrote:The problem is that it's quite easy to compile a client that allows cheating the whole game
False, you can only cheat with some movement mechanics (eg: flying) and information (eg: reading mapblocks for ore info) as they're controlled and available to the client. The former would be solved by CSP/SSR, the latter solved by not sending ore information until the client is close enough (although I'm not keen on this)

Byakuren
Member
Posts: 816
Joined: Tue Apr 14, 2015 01:59
GitHub: raymoo
IRC: Hijiri
In-game: Raymoo + Clownpiece

Re: Maybe another approach on anticheating?

by Byakuren » Post

Once upon a time when I played on a Bukkit server, they had a plugin that would reveal an entire ore vein once one ore from it was visible. Maybe that would reduce the number of updates that would need to be sent when mining, in case the "expose ores exposed to air" thing is done.
Every time a mod API is left undocumented, a koala dies.

saavedra29
Member
Posts: 28
Joined: Mon Mar 06, 2017 00:19
GitHub: saavedra29

Re: Maybe another approach on anticheating?

by saavedra29 » Post

Byakuren wrote:It would be a violation of the LGPL to send a client binary with the private key unless source code is included (this would include the private key, as it is used to create the end binary).

And anyway, a dedicated cheater could extract the private key from the provided binaries. Ways to prevent this fall into the realm of DRM.
You know what's fun at this situation? It's possible that no member of the core development team will have problem if this tiny violation is going to give new life to Minetest and the playing quality it deserves, but some other people who haven't written a line of code in their lives will be annoyed by the "offender" and take measurements against him/her.
At least that's how i would see it if i was developing Minetest. But laws are laws..
About obtaining the public key with reverse engineering, i thought it would be more difficult than how you describe it (with some obfuscating) but I have no knowledge on the topic to insist :)
Linuxdirk wrote:What does not matter if there is nothing on the server side that accepts whatever a modified client sends. If it sends “This usage of the tool did not cost any wear points” the server simply ignores it and removes one use from the possible tool uses. Or when drowning and the client says “I am not in water” the server knows that this is not correct and removes one air bubble.
Ok, now i understand what you mean. Then yes, sending only the key presses is the best solution that comes to my mind. Unfortunately i can't see a solution in the middle. Either breaking the laws of the license or sending only the key presses.
But i hope someone will have a third proposal to surprise us :)

saavedra29
Member
Posts: 28
Joined: Mon Mar 06, 2017 00:19
GitHub: saavedra29

Re: Maybe another approach on anticheating?

by saavedra29 » Post

rubenwardy wrote: See this and the next chapter: http://www.gabrielgambetta.com/fpm1.html
Good article, thank's! Actually i found it difficult to understand the 3rd and 4rth chapter but got a basic idea.

User avatar
sfan5
Moderator
Posts: 3892
Joined: Wed Aug 24, 2011 09:44
GitHub: sfan5
IRC: sfan5
Location: Germany

Re: Maybe another approach on anticheating?

by sfan5 » Post

Security doesn't exist, DRM is breakable.
This won't give new life to Minetest and the playing quality, people will mind license violations.

This idea is not practical, the end.
Mods: Mesecons | WorldEdit | Nuke & Minetest builds for Windows (32-bit & 64-bit)

User avatar
Beerholder
Member
Posts: 199
Joined: Wed Aug 03, 2016 20:23
GitHub: evrooije
In-game: Beerholder

Re: Maybe another approach on anticheating?

by Beerholder » Post

sfan5 wrote:Security doesn't exist, DRM is breakable.
This won't give new life to Minetest and the playing quality, people will mind license violations.

This idea is not practical, the end.
Exactly. A binary with the key inside is dead easy to crack. Been there, done that, got the t-shirt. A couple of coders did that at one of the places where I worked in a role that included security (a bank of which I will not disclose the name). Seriously pissed me off at first but then laughed my ass off too because it gave me unfettered access to production web services. You know, the ones you're not supposed to have access to.

Rip the key, hack the client, make sure it sends a forged authentication signature and/ or use it to encrypt the traffic of the hacked client. Whatever crypto scheme you come up with, it will fail when you have the binary with a crypto key or signature inside it. The hacked client will just pretend to be a proper one to the server or pass signature verification at all time when integrity is checked on the client side when doing the crypto on the application blob.

Plus, this is an open source project for which there are contributors who are so nice to provide us with binary build for various platforms using various options. Centralizing the build will most certainly be a big step backwards, as every binary release would have to be either compiled or the binary signed by a central security admin. You know how much trouble it would be for a single admin to maintain a compatible build that builds against continuously updating dependencies? On multiple platforms?? What about new contributors who would like to create builds? And what about forked code with special features or binaries thereof that now must be signed by the central admin? Who says these are not hacked? Need to do a code review of the submitted build? Need to decompile or even more fun, disassemble, the binary for review?

You can't solve this by distributing the key to the builders. Worst.. Idea... Ever... There is a reason you need to keep one of the parts of a key pair secret. And I am sure the Minetest build team can be trusted, but from a security point of view this type of trust is not gonna fly, a breach waiting to happen. Anyone could leak the keys. I would for the sole reason to make a point, to show you the flaws of this trust model and to make sure you will stop believing that crypto is the silver bullet that solves it all.

The only sane model is, like rubenwardy says, the tried and tested client side prediction and authoritative server combo. Cryptography might delay things for closed source proprietary code, but in the end it is just delaying the inevitable... And then have a server that is non-authorative just because we wanted to get rid of network traffic and blindly put our faith in cryptography?? Hackers rejoice ... -_-

This flawed crypto scheme is not going to help here, like sfan5 says, not practical, the end. Let's not put effort into something that is a complete waste of the devs time and focus instead on improving the code, building features, make things more efficient, building even better moddability, and improve end user experience that way.

red-001
Member
Posts: 205
Joined: Tue Jan 26, 2016 20:15
GitHub: red-001
IRC: red-001

Re: Maybe another approach on anticheating?

by red-001 » Post

Linuxdirk wrote:
saavedra29 wrote:In my opinion a much better solution would be making the server smarter to expose less data to the client and control more actions.
Don’t expose any data at all. Just send render information (direction, movement, position, etc.). Anything should be handled completely by the server without the possibility to change it from user side except key presses are transferred to the server.
Why would you ever want that? At that point you are probably better off just watching a video of someone playing, at least you wouldn't get horrible lag.

Why are you so concerned about cheaters anyway? With a decent server-sided anticheat they only gain a small advantage over non-cheaters. Next thing you know we will be adding ways to limit FOV, FPS and ping.

User avatar
Fixer
Member
Posts: 895
Joined: Sun Jul 31, 2011 11:23
IRC: Fixer
In-game: Fixer
Location: Ukraine

Re: Maybe another approach on anticheating?

by Fixer » Post

Server-side damage

red-001
Member
Posts: 205
Joined: Tue Jan 26, 2016 20:15
GitHub: red-001
IRC: red-001

Re: Maybe another approach on anticheating?

by red-001 » Post

Fixerol wrote:Server-side damage
IIRC Nerzhul is working on that and the next release will have server-sided lava damage for new clients.

User avatar
sorcerykid
Member
Posts: 1282
Joined: Fri Aug 26, 2016 15:36
GitHub: sorcerykid
In-game: Nemo
Location: Illinois, USA

Re: Maybe another approach on anticheating?

by sorcerykid » Post

I developed a fairly comprehensive cheat analysis script for my server. It tracks several types of suspicious activity and generates a comprehensive report each day, allowing me to weed potential suspects.

Altho it doesn't catch small-time offenders (which is fine since there's a higher risk of false positives), it's great at detecting the more egregious cheats. I've been spared many hours of wading through log files.

saavedra29
Member
Posts: 28
Joined: Mon Mar 06, 2017 00:19
GitHub: saavedra29

Re: Maybe another approach on anticheating?

by saavedra29 » Post

sorcerykid wrote:I developed a fairly comprehensive cheat analysis script for my server. It tracks several types of suspicious activity and generates a comprehensive report each day, allowing me to weed potential suspects.

Altho it doesn't catch small-time offenders (which is fine since there's a higher risk of false positives), it's great at detecting the more egregious cheats. I've been spared many hours of wading through log files.
Could you send me the script? If you don't want me to have the code just send me a binary. For linux 64. I don't search for something special, just detect the basic cheats. People who have the knowledge to cheat beyond the basics usually are serious people who won't spend their precious time trying to gather or the gold that exists in a server :)

User avatar
sorcerykid
Member
Posts: 1282
Joined: Fri Aug 26, 2016 15:36
GitHub: sorcerykid
In-game: Nemo
Location: Illinois, USA

Re: Maybe another approach on anticheating?

by sorcerykid » Post

Sure, I will upload it and PM you a link once I complete a merge and testing. It's currently written in Lua, so it requires command line interpreter to execute. I plan to port it to Perl which is much more efficient at parsing very large text files. The script is obviously a WIP, but it's still robust enough for most uses, so I hope you'll find it useful.

saavedra29
Member
Posts: 28
Joined: Mon Mar 06, 2017 00:19
GitHub: saavedra29

Re: Maybe another approach on anticheating?

by saavedra29 » Post

Thank's sorcerykid. I'm looking forward to it. Then i have chances to run the public server i was preparing :)

Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest