Minetest: Detection of dirty clients

[shivajiva101]

Currently servers have no way of validating a client is vanilla. It's time minetest validated clean clients and gave server owners the choice of refusing dirty clients. Whilst it's not the ultimate protection it will stop the majority of script kiddies making a few simple changes to the client, recompiling and causing havoc. Simply passing the version is inadequate and easily fudged, minetest needs something more complex and I believe this should be considered for the 0.5 release.

[red-001]

not really feasible for open source software.

[Calinou]

This is problematic to me because the whole "build purity" concept undermines the vision of open source software; it screams "proprietary software mentality" to me.

Some open source games have attempted this in the past (any id Tech 3 game, Warsow, Cube), in more or less intruding ways, but it makes fixing engine bugs, adding features and porting to more operating systems impossible for the clients. It basically has an high chance of effectively turning the game proprietary for anyone playing multiplayer.

And yes, it does bring practical issues, since compiling from source will likely mark any build as "dirty", even if the source code was not modified – which can also make playing using development builds impossible. It's not like it's very hard to falsify hashes of any kind sent to the server anyway…

[azekillDIABLO]

i'm dead, i have a hacked builtin lua. :skull_and_crossbones:

This is problematic to me because the whole "build purity" concept undermines the vision of open source software; it screams "proprietary software mentality" to me.

i totally agree with this :+1:

[shivajiva101]

okay let's just leave the servers vulnerable without any attempt to protect them, after all it's not like dev actually run servers so ultimately it doesn't affect them...

As for "proprietary software mentality" what is wrong with some level of protection, does this go against FOSS principles? Hacking the client for using in a local server isn't the issue here, there is no desire to impinge on the learning curve only a desire to make using a hacked client on a public server that finds this kind of activity unacceptable a bit harder to accomplish.

[octacian]

There's nothing that can really be done about this while still keeping the open source mentality, as Calinou mentioned. And honestly, I've not had many issues with hacked or modified clients whatsoever, and I'm currently working on my second server (will be public soon).

[Ezhh]

I'm in two minds about this.

I am honestly sick to death of people using modified clients to not take damage or to fly/noclip on my survival server. It spoils the game for other players and it's become increasingly common. This is not just something I am saying - it is an actual issue on the server. I have banned people for it after receiving complaints from players.

On the other side of things, I have previously needed to use a modified client just to be comfortable playing the game.

So the question for me is whether there is another solution. If there is, great - would really appreciate seeing it implemented soon. If there is not... then yes, I would like to see this added as an option - though specifically not as the default.

[paramat]

Yeah the way this might stop players using dev builds is an issue, so any server enforcing stable-only would be taking a risk of losing players, but then, i think a server has the right to that choice.
As c55 writes the design of MT is to give servers all possible control.

Would this detect changes to Lua files? I thought 'dirty' only detects C++ changes that need compiling.

The FOSS / proprietry argument seems an overreaction, but yes disallowing dev builds means clients cannot take part in dev work and test on servers, but then maybe a server has the right to choose that?

[stujones11]

So long as the source code is available there will always be hacked clients, this is true for any open source client-server based game. IMO the only way to tackle this problem is by improving cheat detection and good server moderation.

[paramat]

i'm dead, i have a hacked builtin lua.

azekillDIABLO, what does your hacked builtin make possible? i'm interested.

[shivajiva101]

Nobody is denying the availability of the source allows for hacked clients but let's raise it above the level of deleting code and altering returns from functions please

[stujones11]

I would suggest that many of what you perceive to be 'hacked clients' are in fact unofficial android clients that possibly charge for such privs as fly and noclip. I can assure you that no amount of effort will ever stop those.

It's not like it's very hard to falsify hashes of any kind sent to the server anyway…

[Ezhh]

I have been running servers long enough, talk to players enough, and have also compiled enough "hacked clients" myself to not get confused too easily. There is also no way the "VIP" payments some players tell me apps ask them to make would cover some of the things I've seen.

From what I understand, the unofficial clients that charge still require the server to grant the priv as well. If that's not the case and they just give you the priv on any server, it's only reinforcing the need for a suitable method for server owners to deal with this.

I'm not specifically in favour of blocking all "dirty" clients, but something is needed, and no alternatives seem to be offered.

[tenplus1]

It would be nice to have a way of detecting which type of client is connected to server, not only for stats but to give the server owner the ability to control which clients can run on there own server.

[stujones11]

Given the open source nature of this project it is nigh on impossible to do this in any way that could not be easily circumvented. I think it would be more productive to focus on improving the anti-cheat mechanisms, instead. Surely it can't be that hard to detect if someone is flying or noclipping?

@tenplus1 Again, easy to fake, so can't be relied upon.

[paramat]

unofficial android clients that possibly charge for such privs as fly and noclip. I can assure you that no amount of effort will ever stop those.

I hope we can find a way.

give the server owner the ability to control which clients can run on there own server.

I agree.

[octacian]

give the server owner the ability to control which clients can run on there own server.

So, essentially a whitelist that only allows you to join if you have a specific client? Please no. Open source is supposed to be open, for that matter, just make the server invite-only. IMO the concept is nearly as bad as just outright disallowing mobile clients, which would cause most servers to lose huge numbers of players.

Seriously, I don't understand where you guys are coming from on this. I've moderated on the HOMETOWN server, which nearly always has 20+ players online, for around 1 month now and played since it was a few weeks old. And during that time, I've never once seen someone who actually had a hacked client. Don't get me wrong, I'm familiar with hacked clients, have written one myself, but from my personal experience, I think that the issue here is being way overexaggerated. I understand that it is an issue, but I think this is way out of proportion.

[rubenwardy]

:-1:

[shivajiva101]

Title is 'Detection of dirty clients' and giving server owners the choice...yea a whitelist for clean clients, not version detection

[red-001]

I somehow doubt this is ever going to be added if people where up in arms at the very suggestion of adding a way for a mod to check the servers version string not that long ago.

[raymoo]

Only way I think to fix movement cheating for good is to change network so that the server has authority over player physics and the client just does prediction. This would be a lot of work, though.

Also any client-side player movement mods would need a server-side component that assures the server that the client is moving properly (maybe by applying the same movement changes on both the client and server).

EDIT: "Assures" is a bit incorrect, I just mean that movement changes on the server would have to be changed as they are on the client.

[ghost]

It's time minetest validated clean clients and gave server owners the choice of refusing dirty clients.

I’m very positive about this. If it’s an option it is absolutely fine in my opinion. The problem is: how will you determine a clean client? You could pass a faked hash on request, like you can pass a faked version number on request. As much as I like the idea of a reliably identifiable client: it’s impossible with open source software because you coulkd always modify the identifying functionality, too.

All you can do is making the server the 100 percent autoritative instance checking all actions the client sends for validity (movement, position, damage, nodes mined, nodes placed, nodes moved from or to inventories, etc.). This won’t prevent hacked clients but it would make them useless.

[paramat]

'Open source' doesn't mean 'a server is open to any player'.

the concept is nearly as bad as just outright disallowing mobile clients, which would cause most servers to lose huge numbers of players.

That's not a bad option if a server doesn't want mobile clients. on average mobile clients are more of a problem and some servers find there are too many of them, many being scam or license-breaking forks of our official Android app.
It's unfortunate there may be no way to distinguish them.

[Ekdohibs]

As it was already mentioned, I'd like to remind that since this is open-source software, there is no way to prevent hacked client from connecting to the server - anything that needs to be faked can be so; and it would also greatly harm development as developers could not even test their code on a public server, since they would be using a non-vanilla client. So, :-1:.

[Ezhh]

Sorry in advance for the long reply:

@octacian I'm glad to hear hometown doesn't get these issues, but I can assure you it can be very rough for servers that do. I used to think it was a non-issue as well, until one of my servers was targeted by a hacked client user (or, based on their own words, a group) who was able to also change IP address to ban dodge. I was waking up to server chat full of spam, most of it being insults against my moderators who had tried to help, and complaints from players that people with extra privs were killing them. In the end, I had to do something far worse than block dirty clients - I blocked ALL new players. The last time I lifted this restriction was friday. That night I got more player complaints. I confirmed the player was able to do things they should not have been able to before banning them.

As for this request being bad because "open source is supposed to be open"... this doesn't mean it should be open for abuse.

@Ekdohibs Please don't take this the wrong way - I usually welcome developers to my servers to test anything they want - but don't assume you have a right to test on my servers, or a right for my servers to be run in a way you find specifically useful for testing purposes. My servers are not test servers. They are servers for people to use to play the game. It's also extremely unlikely that every public server would enable this if is was a non-default option, so it should have minimal affect on your ability to test. (if every public server did choose to enable it, that in itself would tell you something...)

---

There also seem to be a lot of assumptions regarding what server owners want that are off the mark.

1 - This is not about banning mobile app users. I have refused outright to take the usual approach of banning names ending in numbers, because I want my servers to be as open as possible.
2 - Those of us asking for it do not want to need to use it. We want it for when we encounter issues like the one I explained above, so that we don't need to take the more extreme course of blocking practically everyone.
3 - We don't expect it to be 100% fool proof. We don't expect hacked clients to be completely, miraculously, removed as a threat. We do understand what open source is about and how it works. What this is about is raising the barrier. If it's not the 'right' way to do so, then please offer an alternative.

[ghost]

As for this request being bad because "open source is supposed to be open"... this doesn't mean it should be open for abuse.

Yes, but just because it shouldn't doesn't mean it isn't :frowning_face:

The reason why "hacked clients" exist is the same reason why hacked client detection can't exist. All you can do is try to detect malicious/illegal/invalid behavior on server-side and force those changes to be made or not made ignoring what the client wants or does.

[bigfoot547]

M*t will kick you for "Invalid Session" sometimes...

Also, as simple as it is to fly hack, it is to make your client non-dirty. also, if you do a git pull, then recompile, then your client is dirty! And my actual hacked client is not dirty because I didn't use git.

[shivajiva101]

'dirty' in this context is a modified client, determining it would require a crc of the files that constitute the source code at compile time for instance so it can be compared at the server for known clean matches, we haven't arrived at a consensus other than open source will always be defeat-able and servers are thought of as somewhere for dev to test their code changes...

[raymoo]

@Ezhh If they actually had extra privs then it was probably the worldedit GUI bug that affected many servers. It did not need a modified client to exploit, so the feature discussed in this issue would not have helped.

@dsohler

All you can do...
Ruling out the possibility of server-side player physics simulation?

@shivajiva101 How about this: if this feature gets in then I will make and distribute a client that sends a fake CRC, or whatever is sent for verification, along with priv ignoring for lazy cheaters to use. This will guarantee uselessness.

[Ezhh]

@raymoo The server had fully up to date WE, so that was not the case.

Also noted that you wish to assist cheaters.

[shivajiva101]

@raymoo whilst you are entitled to do as you wish, it proves nothing except that attitude doesn't belong in an open source community project...mnmnh

[stujones11]

servers are thought of as somewhere for dev to test their code changes...

I think this is a little unfair, from what I have seen many server operators are happy to test in-dev features and there will usually be some prior agreement in advance. Also I do not understand why you think that faking a CRC check is any more difficult than granting yourself movement privs, especially given that the code is freely available, as would be the git commit that included it.

[raymoo]

@Ezhh @shivajiva101 My point is that it doesn't matter if it takes some effort to fake the bad client detection, because anybody who makes the effort can make it no effort for everybody else. I thought you would care more if the argument was made more concrete.

What I am saying is that requiring a CRC of the source tree will do little to prevent cheating.

[octacian]

hmmm, After reading over @Ezhh's statement, I suppose that I have to agree that something should probably be done about this. My personal suggestion is that the server and client compare some sort of hash, which although it could possibly be faked, would make things much harder. I'll give this some thought, I'm sure that there is a fairly solid solution somewhere.

[raymoo]

@octacian It would not make it much harder, it would just require replacing the value sent to the server with a hardcoded hash of a good client.

[stujones11]

I'm sure that there is a fairly solid solution somewhere.

Then I think you are very naive :) The only remotely solid solution would be for a server to distribute its own proprietary binaries but that would be very much frowned upon and also quite possibly illegal :P

[sofar]

@shivajiva101 You are effectively asking for DRM.

[shivajiva101]

@sofar Nope, effectively I'm asking for it to be made more difficult to make and use a hacked client, something above the current level, in whatever form that takes

[stujones11]

@shivajiva101 Security by obscurity simply does not work.

[sofar]

DRM is a technical term for restricting the capabilities of software and preventing unwanted copies of code from interfacing with services, APIs etc..

It is exactly the same thing as what you are asking for.

[shivajiva101]

Digital rights management (DRM) is a systematic approach to copyright protection for digital media. The purpose of DRM is to prevent unauthorized redistribution of digital media and restrict the ways consumers can copy content they've purchased
You seem to be redefining it to suit...

[sofar]

Yes, content in this reference is "the minetest world you are hosting" (digital content). "copy" is just another way of saying "access".

It's exactly the same thing. Controlling access to digital goods by only allowing certain software to access it.

[red-001]

This sort of stuff just barely helps closed source software in the game of cat and mouse with cheaters. It will do very close to nothing for open source software where everyone can see the source code. Think what would you do if you are a cheater and you get a "Bad client hash" error. Of course you will look for that function and hardcode it to return a value the server is ok with.

[shivajiva101]

okay let me close this as a waste of time, thanks to everyone for your comments :)

[paramat]

Sorry shivajiva101, it was me who encouraged you to open this issue, i was not certain whether this suggestion was possible.

[paramat]

@bigfoot547

And my actual hacked client is not dirty because I didn't use git.

What does your hacked client make possible and what do you use it for?

See https://github.com/minetest/minetest/issues/5915#issuecomment-306641437 the 'protection against CSM' issue, where you wrote:

If this gets implimented, that is when I tell my client to ignore the server packet telling me what to do.

Suggesting you will hack your client to avoid server CSM restrictions.

[paramat]

@azekillDIABLO

i'm dead, i have a hacked builtin lua.

azekillDIABLO, i ask again, what does your hacked builtin make possible and what do you use it for?
If you don't answer some may assume the worst.

[bigfoot547]

@paramat

What does your hacked client make possible and what do you use it for?

My client does this: Fast, fly, noclip, and drawing all light levels fully bright.

[shivajiva101]

@paramat

You have nothing to apologise for, as one of the more coherent devs who doesn't force his agenda and tries to diplomatically resolve a situation, giving all parties a fair hearing, you can hold your head up.

I expected resistance to the idea, so it was no surprise, even the buzzword use of DRM to provoke strong negative reaction wasn't unexpected.

The biggest concern it raised for me was how contributors feel it's their right to bypass anything they see fit and distribute the 'hacks' as a viable means of controlling this project.

I'm in a better position to assess the landscape now that illusion is out of the way. Lets just say I'm quite disappointed in the outcome and the way some members of the community expressed themselves.

[shimmark]

Some people seem to consider it unethical to modify software running on your computer so that it obeys your wishes instead of those of a server administrator and to distribute the modifications when you disagree with decisions made by a software project.

Others correctly recognize this as proprietary software mentality.

[shivajiva101]

let's not talk about the ethics of cheating and wilfully destroying a server content, spamming inappropriate content, causing crashes...

As has been said before open source doesn't mean open to abuse, if someone is kind enough to devote resources so people can play, should they not have the choice about what is allowed on their server?

Proprietary software mentality means enforcement, I requested it as an option, a tool to use when a server is having problems instead of locking it down completely.

The issue has been closed. Thanks for your comments.

[sofar]

I've opened up a forum thread for those who want to discuss alternative solutions to defeat CSM mods like oredetect, without resorting to DRM-like restrictions.

https://forum.minetest.net/viewtopic.php?f=53&t=18079

[Ezhh]

@sofar None of the issues I have flagged here are CSM related and from what I understand, options will be put in place to handle the CSM concerns.

What I'm concerned about is people who compile their own clients, or otherwise acquire adjusted clients, that give them unfair advantages in game, resulting in normal, rule abiding players, either being attacked in ways they can't counter in PvP environments, or resulting in the "cheaters" having other unfair advantages. This is what I want a solution to. Oredetect is a very minor issue compared to this.

[paramat]

mark-otaris

Some people seem to consider it unethical to modify software running on your computer so that it obeys your wishes instead of those of a server administrator

Leaving ethics out of it, doing so goes against how MT is designed to work, the server has control over things that can affect the server and the fun of other players. Those who hack their clients or use CSM cheats cause problems and frustration for server owners, and ruin the server for everyone else. These hackers are the most disliked users of MT and are not welcome here.

It's like spending lots of money and time preparing your house for a party, then bravely opening it to the public, only to have some nasty people come and trash the place and assault the other guests.

It has nothing to do with a 'proprietry attitude', only the method of the solution could be a 'proprietry
attitude'.

I notice you are one of those who disapprove of #6091 along with some other hacker-types, server owners support it.
It's interesting how many players are admitting to being hackers, if you use these hacks to disrupt servers you are not welcome here, go away.

and to distribute the modifications when you disagree with decisions made by a software project.

Doing so is distributing hacked software to disrupt a project and servers, and is also a disgusting thing to do that has nothing to do with a 'proprietry attitude'. Doing so causes problems for MT devs, server owners and players.

[paramat]

bigfoot547

My client does this: Fast, fly, noclip, and drawing all light levels fully bright.

Do you use these abilities on servers that do not want you to?

[paramat]

sofar the ideas in your forum thread for dealing with oredetect may be ok for a very few server owners, but most do not want to radically change their server and 'give in' to CSM cheating.

I've opened up a forum thread for those who want to discuss alternative solutions to defeat CSM mods like oredetect, without resorting to DRM-like restrictions.

What DRM-like restrictions are you refering to? The CSM flavours PR is not at all DRM.

From the forum thread;

This is not a rant thread to discuss CSM. Discussions about CSM are not on-topic and will be deleted.

Your thread is about CSM. Objections to your solutions are on-topic and will have to mention CSM, so you essentially want to delete any post you feel llke. I seem to remember you were given forum moderator powers on the understanding that you would only use them in extreme situations.

The goal is to come up with elegant and creative solutions that are constructive, and not destructive.
Constructive solutions include solutions that result in better value for all parties: more players, happier players, happier server owners, less complaints, more game features, etc..
Destructive solutions include solutions that take away features, result in players not being able to do certain things anymore, server owners losing certain players, server owners giving up.

It is not destructive to:
Take away cheats and hacks that disrupt a server.
Stop hacker players who ruin a server from cheating.
Remove such players from a server.

Server owners will not 'give up' as a result of using server-restrictions on CSM, such as the CSM flavours PR. Server owners are likely to 'give up' if they do not have such restrictions, and one of our most respected server owners has expressed that if they lose long-running server controls they might leave MT.

It is not 'constructive' to have:
More players because cheating players are welcome.
Happier cheaters.
Less complaints from cheaters.

I am concerned about your attitude to CSM, which seems to be: let it run wild and unrestricted and all server owners can radically change their servers and give in to it. This is against what MT is about and against celeron55's design for the project, his quote which sums it up well is:

"The barriers to cheating we've had until CSM are fine. As long as cheating requires C++ changes, we're pretty much where we've always been. Current CSM is bad.

The design of Minetest is to give all possible control to servers."
https://github.com/minetest/minetest/issues/5915#issuecomment-306424066

[rubenwardy]

I don't have much time to write a long response. I am very opposed to this, and I'm not even a freedom zealot. This prohibits unofficial porting, forks, and development. It is not a good fix to the problem, and it would hurt normal users way more than malicious users, as they could just workaround the code. They're modifying CPP already.

[Ezhh]

@rubenwardy How? It was requested as a non-default option for servers that are suffering attacks. Not as the default or only way a server can position itself. I fail to see how this would ever prevent a fork, or hinder development.

[paramat]

Although i'm not opposed to anti-hacker efforts (as you know from the fuss i make about CSM), i do agree with Ekdohibs in that this is simply not possible, unfortunately, hackers would get around it in minutes.

[ghost]

So instead of trying to validate the client we should focus on validating the user's actions on the server.

[shivajiva101]

It's fair to say that this issue was driven by the fact the server isn't validating a users actions

[bigfoot547]

Do you use these abilities on servers that do not want you to?

No, not usually...

[red-001]

maybe add a prompt when compiling along the lines of Have you modified the source code to gain an unfair advantage? It would be about as efficient.

[sofar]

@paramat if you don't want to discuss in the forum, fine, but don't expect me to answer on this thread either.

[shimmark]

@paramat

There is nothing clients can do to affect the server and the fun of other players that cannot be prevented on the server. Preventing it on the client is bad design[1][2][3] and would still be bad design even if it was the solution favored by @celeron55, though I haven't seen him say that it is.

There are two solid solutions to cheating in networked multiplayer games. The cat-and-mouse game against cheaters can lead to either of them:

1. Pay a lot of money to Intel and make servers require all clients to run verifiably in a trusted execution environment.
2. Make servers rather than clients authoritative on player movement and all other player actions. Minimize unresponsiveness but keep the server authoritative with client-side prediction and server reconciliation.

One of these solutions is very good and the other is very bad. There are a few other cat-and-mouse games like this in technology; among them are digital rights management, computer bots, and ad blocking. People aren't drawing analogies with these out of thin air. The issue these situations have in common is trusted client software.

Never trust the client.
Never put anything on the client. The client is in the hands of the enemy. Never ever ever forget this. (The Laws of Online World Design)

Hackers have written computer bots that assist play for some of these games, particularly Quake and NetTrek. The idea is that the bots can react much quicker than a human; the player becomes much more effective with their assistance. An arms race has ensued, as the game designers try to disable these bots and force fairer play, while the hackers continue to make the bots more clever.

These games are relying on trusted client software, and the hacker community has managed to break every trick the game designers have thrown at them. I am continually amazed by the efforts of hackers to break through security. The lesson is twofold: Not only is there no reasonable way to trust a client-side program in real usage, but there's no possible way to ever achieve that level of protection. Against the average user, anything works; there's no need for complex security software. Against the skilled attacker, on the other hand, nothing works. And even worse, most systems need to be secure against the smartest attacker. If one person hacks Quake (or Intertrust or Disappearing Inc.), he can write a point-and-click software tool that anyone can use. Suddenly a security system that is secure against almost everyone can now be compromised by anyone. (The Fallacy of Trusted Client Software)

Making it inconvenient to cheat has not historically made cheating less widespread. Security through inconvenience and security through obscurity acquired a bad name because they weren't effective even just to a non-negligible extent, not because they weren't 100% effective. Case in point: the proprietary online game Roblox has had problems with cheaters since its public release in 2006 and the problems have not noticeably decreased in scale at any point despite measures against cheating, on the client, going much farther than what is discussed here. Checking client hashes and detecting debuggers were done early on. The binaries were obfuscated in all ways possible. The developers removed the code from the Lua VM that wasn't necessary to run bytecode, since most exploits allowed cheaters to run arbitrary Lua code on their client, but cheaters injected their own Lua VM in their client and cheating was just as common as ever, despite having been made much less convenient. The cheating has just increased proportionally with the size of the user base.

Anything less than the two solid solutions I described is not going to be significantly effective, even if the code for client-side mods is removed and Minetest is made proprietary. I support anti-cheating efforts that are correctly designed, but take issue with any anti-cheating measure that is implemented on the client and not on the server because such measures have disadvantages and no advantage.

[Ezhh]

@mark-otaris Server owners would be quite happy to see correctly designed anti-cheating measures.

Where then is the developer willing to implement them?

[shimmark]

@Ezhh

At #3894, #4951 and #3822.

[Ezhh]

@mark-otaris All from last year. I have not claimed there was never any attempt to help with these issues, but who is looking into it now? It's the present and the future that I'm interested in. The current state is known after all, and in terms of anti-cheat isn't meeting the mark.

[shimmark]

@Ezhh

I think we agree.

[bendeutsch]

So… time to get to work?

I have (at least) two pull requests in concept that will add to or change minetest motion, but I've got the impression that we'd better solve this first?

I agree with @mark-otaris that any successful solution will at least need the server to be able to reproduce each client's motion and actions, whether it's just to detect cheating or to fully take over "the game". But this requires that, as a first step, the clients send everything that the server needs to do this.

So what's the current state? Does anyone know? Is everything theoretically there, or do we need to add things to the client network side so that it has a chance to eventually spread through the install base?

[raymoo]

@bendeutsch Mainly what needs to be sent is the player's movement inputs, and at a higher rate than is currently done.

[paramat]

See http://irc.minetest.net/minetest-hub/2017-07-17#i_5011681 onwards for discussion and comments by c55 about what more can be done serverside, specifically validation of fly and noclip.

[bendeutsch]

Well, (if you don't mind me continuing a discussion on a closed issue), I'd be willing to look into the anti-cheat system. Can't promise much, but I'll try. Also see how far #3894 gets or still needs to get.

As for a much higher rate on the movement inputs, how about an "audit log" of player movement, from client to server, appended to the "player position" network packet? That would allow the server to verify the player movement after the fact, at least. I'm guessing the best that anti-cheat could do is to build up "probable cause of cheating" and occasionally teleport players back to known good positions. Yes, with false positives, so nothing drastic.

I'ma look into this a bit more.

[raymoo]

@bendeutsch yes, you could have a lower send rate and just send a log of all the newest movement inputs, that would achieve the same thing except the server would need a larger delay before calculating player movement.

[beyondlimits]

Keep in mind one simple principle: this is my computer, I own it and I will decide of how it works.

Anyway, I thought open source is when it doesn't suit the needs of a particular user, an user is free to make modifications to it. But nooo, now you want to make it hard!

[shivajiva101]

@beyondlimits Lets analyse your thoughts for clarity... If your particular need is hacking and cheating I don't think you are welcome in any FOSS community.

If you want to add a missing feature or fix a bug and be gracious enough to share it with the community by making a PR all well and good. It is your computer, you do own it and you will decide how it works.

FOSS and security are not mutually exclusive, you are welcome to degrade the security of a Linux kernel installed on your computer but spitting the dummy out when Linus refuses to adopt your compromise would be crazy.

Are you saying you wouldn't play or contribute if the developers make it harder to cheat on a public server?

Are you asking the developers not to be diligent so it's easier for you to modify for hacking purposes?

As you felt the need to contribute to the conversation perhaps you could enlighten us :)

[beyondlimits]

Are you saying you wouldn't play or contribute if the developers make it harder to cheat on a public server?

Are you asking the developers not to be diligent so it's easier for you to modify for hacking purposes?

I have not asked for any of that, although I like to have full over my computer, and don't like when developers make it hard to modify their software to suit my needs.

Don't think much about preventing cheating on client side - it might be hard to bypass for user, but is never going to be 100% bulletproof. Your server may think it talks with clean client, but you can never be sure. As in web development, we know to never trust the validity of data entered by user.

Think about doing it server side, where user has no control.

• Moving too fast - First let server and client synchronize their times. This can be current UNIX timestamp, server uptime or whatever increments at constant rate. Then everytime the player moves a little, client sends their new position with timestamp, so that server can determine whether the movement was legal and bring player back to the last valid position. Timestamps are here so that it should work well with no-clip enforcement even in case of lags.
• Peeking through walls - Does this constitue a cheat at all? Map chunks are sent as a whole and client receives full information of completely covered rooms. Minecraft does the same, and I currently have no idea how to handle it other way.
• Interacting through walls - Along with the interaction, a player's position, yaw and pitch should be sent so server can determine whether it was really possible to interact with the object.
• Passing through walls / flying - What cheating we're talking about? It was ~f'd up~ something that should be done at the beginning of development of this game.
• Invulnerability - F'd up. Without strikethrough. Player health status was implemented client-side (yikes! who does that?). I think it was fixed recently. If so, "finally" is a good word.
• Lighting - Sorry, you have no control over how it is displayed on user's screen. Even if a client had to prove it is legitimate, an user can still tweak his monitor settings. Isn't that an overkill. Devs already made this game painfully dark at the times, so I had to modify the lightmap in binary using the hex editor. It was fun to play (and the "cheat" even mitigated some graphical atrocities), until next version came out.
• Ores - back when I played Minecraft, on some servers there was an anti-cheat module that efficiently prevented players from searching ores by non-legitimate ways (like X-ray). The map chunk was sent to the client, but every ore occluded from all 6 sides was sent as stone. When an user dug one of the neighboring blocks, server sent a packet to change previously hidden stone into ore. Many servers however had a frustrating version of this mod, where random stones appeared as false ores.
• Looking inside chests of other players - Server along with chunk sends metadata that contains list of items in locked chests. It's in Lua scripts, not in C code. Plus of this solution is that an owner of the chest can see their items without waiting until lag passes. Minus however is that technically anyone can see what's inside.

[shivajiva101]

Nice to see a constructive response, remember this simple premise...

It's my Server, I own it and I will decide how it works.

It cuts both ways, but I'm not fencing it as an ethic. Lets give server owners a reasonable chance, regardless of when it should have been conceptualised, it should be prioritised and not forgotten

[paramat]

Keep in mind one simple principle: this is my computer, I own it and I will decide of how it works.
Anyway, I thought open source is when it doesn't suit the needs of a particular user, an user is free to make modifications to it.

although I like to have full over my computer, and don't like when developers make it hard to modify their software to suit my needs.

We're not, we're trying to protect others from harm caused by hackers. You can do whatever you want locally and would still be able to do so, but without being able to harm others.
The request of this issue is server detection of altered clients, this has no effect on what you can do locally, you could still alter your client any way you want.

Don't think much about preventing cheating on client side

Correct and we're not, and this issue does not, because anything clientside can be hacked.

Devs already made this game painfully dark at the times,

This is due to how lighting works, we didn't make it dark on purpose. We have a new light curve in 0.4.16 that is brighter, and there is a PR for a custmoisable lightcurve.

[rubenwardy]

we're trying to protect others from harm caused by hackers.

This proposal doesn't, however

---

This has been talked to death, and isn't going to be added. It's not worth wasting any more time on this.

[shivajiva101]

I don't think it's been a waste of time, we now have a clearer view of the priority of security within the project and where development versus server owners stand on the issue.

[sfan5]

It is a waste of time to discuss this because the FOSS nature of Minetest makes a reasonable implementation impossible.

[raymoo]

What the client does doesn't change how the server works. The player is free to modify their client and the server operator is free to modify their server.

[red-001]

I would suggest moving discussion of how to implement server-side anticheat to another issue.

[paramat]

Yes i have bumped and labelled this for that reason #3822 please continue there.
The request in this issue is no protection as a hacked client can fake clean / dirty, even if it was some protecton i still dislike the idea for the reasons given by others above.

[beyondlimits]

Yet my five cents to the old thread,

Keep also in mind that a determined cheater's target might not be client itself, but the communication between client and server. A semi-transparent proxy bound to localhost that connects to real server and allows the player to alter specific packets?

You got the point.

[ghost]

I am shocked,
to shelter our servers from violating RULES is not against Open Source like some argument.

It IS possible, and also a bit build in like detecting "moved too fast" as server is resetting the position of too fast gamer.

So it just need to check if a gamer got fast, fly or noclip by the servers rules (gamer privs safed on server) if the wanted action of client is true, or false (cheat).
Where is the problem about this ... they can see the code, no problem, open source, but they should not be able to bypass our server rules.

[beyondlimits]

@Minetest-One: You're 100% correct, #3822 - all we need to convince core developers that this feature is really needed or make it ourselves. Minecraft just did it right and from very beginning.

Anyway, the subject in general (Detection of dirty clients) was talked to death. It's a hopeless battle between those who understand the logic behind client and server in computer games and those who don't. Why dig up the old thread?

EDIT: One brave soul tried to fix this. #3894

[paramat]

we need to convince core developers that this feature is really needed

You don't need to, the core devs consider serverside anticheat features very high priority.

[ghost]

why linked : as it was linked in another forum thread I found, and made me realize that this issues is more old than I thought even ... and still not solved,

so paramat: are you sure ? I doubt it - but, as my daughter and friends stopped play on minetest as too often angry of this .. I can wait now, she and here friends are on Roblox, it took too long for anticheat,

Have fun with it, when available

[paramat]

Yes i'm sure, you can look at the high priority labels on the issues and PRs #3822 #3894 #6219 #7220
It is one of the highest priority issues. It is delayed mostly by the severe lack of core dev time. But i'll bump the PR too for attention.

[Ekdohibs]

I repeat, it is not possible to detect modified clients. The solution, but which is complicated to implement, is server-side anticheat, such as noclip enforcement. However, detecting modified clients is simply impossible, because the code is open-source and there is nothing preventing someone that modifies the client to make it pretend to be a normal, unmodified client.

[ghost]

I repeat, I don't look for modified clients, all what I am looking for is there behaviour on our minetest servers !
So clear easy, the auth.dat does not include fly, as fly is not an starting privilege, so no gamer can have fly, if it is not in auth. He can only use the starting privs, of nothing else set.
So same for fast or no-clip ... a server controls, and if the gamer client want something that is not in the auth - it should not be possible to use.

[Ekdohibs]

That is server-side anticheat and is planned, but hard to do. Either be patient while it is done, or implement it yourself and submit a pull request.

[beyondlimits]

I can see at least one commit every few days, but core dev time always gets short when it comes to bring essential features like this.

[ghost]

so far there are inicators as I have posted in forum, and still see this also in 5.1.0-dev

• moved too fast = also can come by lag or high ping, wifi, phone
• tried to access from too far (just again today two gamer same ip same time in From USA), tried distance 12, instead of 4 to get open something/get something ...
  So if just for beginning these actions (i try myself) can be watched (may be I change protocol level or post in new cheater.log) and proof if it is bug, lag or MADE by changed client

[paramat]

beyondlimits that's ridiculous cynicism.