Maybe another approach on anticheating?
-
- Member
- Posts: 31
- Joined: Mon Mar 06, 2017 00:19
- GitHub: saavedra29
Maybe another approach on anticheating?
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.
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.
Re: Maybe another approach on anticheating?
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
As long as it is possible to compile own clients with builtin cheats I don't start a public server
- Linuxdirk
- Member
- Posts: 3219
- Joined: Wed Sep 17, 2014 11:21
- In-game: Linuxdirk
- Location: Germany
- Contact:
Re: Maybe another approach on anticheating?
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.
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.
-
- Member
- Posts: 31
- Joined: Mon Mar 06, 2017 00:19
- GitHub: saavedra29
Re: Maybe another approach on anticheating?
Sorry, when i said data integrity i meant the integrity/authenticity of the software that is connected to the server. Not the data transfered.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?
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".
- Linuxdirk
- Member
- Posts: 3219
- Joined: Wed Sep 17, 2014 11:21
- In-game: Linuxdirk
- Location: Germany
- Contact:
Re: Maybe another approach on anticheating?
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?saavedra29 wrote:The code is compiled on linux and windows machines and realeased for the users to download according to their operating system.
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?
-
- Member
- Posts: 31
- Joined: Mon Mar 06, 2017 00:19
- GitHub: saavedra29
Re: Maybe another approach on anticheating?
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.
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.
Yes, installed according to the official documentation of Minetest since the compilation will have been done according to the same documentation.Linuxdirk wrote: Will you provide a version that can be installed?
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).Linuxdirk wrote:And since compiling takes some time this would discourage users to visit random servers.
- Linuxdirk
- Member
- Posts: 3219
- Joined: Wed Sep 17, 2014 11:21
- In-game: Linuxdirk
- Location: Germany
- Contact:
Re: Maybe another approach on anticheating?
You can't solve issues by ignoring them :)saavedra29 wrote:OK, let's forget about CSM. Say it never existed, no flags, nothing.
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.saavedra29 wrote:That's true and a disadvantage, but as i said i don't think it's a big deal.
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).
-
- Member
- Posts: 31
- Joined: Mon Mar 06, 2017 00:19
- GitHub: saavedra29
Re: Maybe another approach on anticheating?
Sorry but this doesn't make sense to me since anybody can change the client code :) I think you wanted to say:Linuxdirk wrote:In my opinion a much better solution would be making the client dumber and not smarter as it is currently done
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 :)
-
- Member
- Posts: 818
- Joined: Tue Apr 14, 2015 01:59
- GitHub: raymoo
- IRC: Hijiri
- In-game: Raymoo + Clownpiece
Re: Maybe another approach on anticheating?
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.
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.
- Linuxdirk
- Member
- Posts: 3219
- Joined: Wed Sep 17, 2014 11:21
- In-game: Linuxdirk
- Location: Germany
- Contact:
Re: Maybe another approach on anticheating?
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:Sorry but this doesn't make sense to me since anybody can change the client code :)
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:In my opinion a much better solution would be making the server smarter to expose less data to the client and control more actions.
Yes. The network code has to be optimized, of course.saavedra29 wrote:For the simplest action the user does big amount of network traffic will have to be generated.
Yep. We have different opinions on that. :)saavedra29 wrote:We see it from different point of view. You propose a "separation" of client and server while i propose a "merging"
- rubenwardy
- Moderator
- Posts: 6978
- Joined: Tue Jun 12, 2012 18:11
- GitHub: rubenwardy
- IRC: rubenwardy
- In-game: rubenwardy
- Location: Bristol, United Kingdom
- Contact:
Re: Maybe another approach on anticheating?
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.
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.
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)Linuxdirk wrote:The problem is that it's quite easy to compile a client that allows cheating the whole game
-
- Member
- Posts: 818
- Joined: Tue Apr 14, 2015 01:59
- GitHub: raymoo
- IRC: Hijiri
- In-game: Raymoo + Clownpiece
Re: Maybe another approach on anticheating?
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.
-
- Member
- Posts: 31
- Joined: Mon Mar 06, 2017 00:19
- GitHub: saavedra29
Re: Maybe another approach on anticheating?
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.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.
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 :)
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.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.
But i hope someone will have a third proposal to surprise us :)
-
- Member
- Posts: 31
- Joined: Mon Mar 06, 2017 00:19
- GitHub: saavedra29
Re: Maybe another approach on anticheating?
Good article, thank's! Actually i found it difficult to understand the 3rd and 4rth chapter but got a basic idea.rubenwardy wrote: See this and the next chapter: http://www.gabrielgambetta.com/fpm1.html
-
- Moderator
- Posts: 4095
- Joined: Wed Aug 24, 2011 09:44
- GitHub: sfan5
- IRC: sfan5
- Location: Germany
Re: Maybe another approach on anticheating?
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.
This won't give new life to Minetest and the playing quality, people will mind license violations.
This idea is not practical, the end.
- Beerholder
- Member
- Posts: 199
- Joined: Wed Aug 03, 2016 20:23
- GitHub: evrooije
- In-game: Beerholder
Re: Maybe another approach on anticheating?
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.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.
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.
Re: Maybe another approach on anticheating?
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.Linuxdirk wrote: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:In my opinion a much better solution would be making the server smarter to expose less data to the client and control more actions.
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.
My mods: Mute, Extra TNT blast effectsnyancats_plus and More charcommands
Example CSM mods:Chatlog and Formspec editor
Example CSM mods:Chatlog and Formspec editor
Re: Maybe another approach on anticheating?
Server-side damage
Re: Maybe another approach on anticheating?
IIRC Nerzhul is working on that and the next release will have server-sided lava damage for new clients.Fixerol wrote:Server-side damage
My mods: Mute, Extra TNT blast effectsnyancats_plus and More charcommands
Example CSM mods:Chatlog and Formspec editor
Example CSM mods:Chatlog and Formspec editor
- sorcerykid
- Member
- Posts: 1847
- Joined: Fri Aug 26, 2016 15:36
- GitHub: sorcerykid
- In-game: Nemo
- Location: Illinois, USA
Re: Maybe another approach on anticheating?
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.
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.
-
- Member
- Posts: 31
- Joined: Mon Mar 06, 2017 00:19
- GitHub: saavedra29
Re: Maybe another approach on anticheating?
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 :)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.
- sorcerykid
- Member
- Posts: 1847
- Joined: Fri Aug 26, 2016 15:36
- GitHub: sorcerykid
- In-game: Nemo
- Location: Illinois, USA
Re: Maybe another approach on anticheating?
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.
-
- Member
- Posts: 31
- Joined: Mon Mar 06, 2017 00:19
- GitHub: saavedra29
Re: Maybe another approach on anticheating?
Thank's sorcerykid. I'm looking forward to it. Then i have chances to run the public server i was preparing :)
Who is online
Users browsing this forum: No registered users and 21 guests