I have some experience with exploits and I can say this won’t work. InfYeild comes with a remote spy. It can read and modify remotes. For instance it can block remotes with stop remotes from firing. And with some code you can make a speed modifier. It will just block the script and fire every now and then. It is not the easiest but it could work.
This would work, but there is a loophole in which the creator can make. Even if you do manage to do it, running a sanity check on the server could work. Hell, just not even using the remote could work. You could then kill two birds with one stone.
The remote exist so that ping doesn’t matter. Normally developers do checks purely on the server side which is affected by ping so the allowed distance is usually very high. While with this method, the allowed distance is very low as ping doesn’t matter, it limits more cheats than a normal check on the server would do.
i.e, autofarming. Exploiters usually use tween (with like 2x the normal speed) to somewhat bypass the check on the server as the allowed distance is very high. With this, they can only use tween with the base speed (or slightly higher) to do so.
Stopping the remote from firing and then fire with their own settings once in a while is indeed very hard and pretty pointless. The magnitude check at the end prevents them from moving 20 studs away from the position + they have to take account in the anti noclip, firing it while behind a wall will cause the anti noclip to fire.
And again, I have say this to 2 people already, you’re moving on the server but not sending the data needed. There is definitely a way to detect that and ban you instantly.
While I personally wouldn’t say this is the best ever anticheat, this is a super cool start to a project and I’m super happy to see you employing a lot of concepts that many people miss. Ultimately there are still many flaws with how you designed this and how its ended up, but its clear that you have the understanding to polish it up.
It’s clear you spent a lot of time on this, and it’s clear you had fun, and it really reminds me of some of my favorite of my own projects in the past. I can imagine this being something you would like to be able to look back to in the future. 
You employ server side physics validation, which, in my opinion is awesome, and I am super happy to see another project doing this. You clearly have an understanding of why you are doing what you are, and you clearly have an understanding of why those things are effective.
Here’s a few areas I could come up with where either the code in general or the design behind the anticheat can be improved, and hopefully some ways you can solve some of them:
- You’re relying on the client telling the server certain critical information related to your checks, giving them an easy point of attack.
- There are a few potential loopholes because of this which you’ve partially addressed, such as taking advantage of numbers with
dt. One I noticed you haven’t addressed that looks like it should work would be passingNaNas adtvalue, which eliminates the checks in your lower loop since comparisons onNaNalways return false. - Similar to the above, If something other than a Vector3 was passed to
pos, it would cause an error to be thrown, but only after the player’s time data would be updated, allowing the exploiter to bypass checks by breaking them entirely. - Your code deserves a lot of cleanup, its very cluttered, and you have a lot of redundancies. First I noticed you use
task.waitin your client loop, but, you don’t do that in your server loop (which you definitely should). I assume that’s just an oversight. You should also avoid_Gpartly because its bad practice, and partly because its less performant when you could just use a couple local. Sinceos.clocknow exists, you should use it overtick.tickis better for things where you want to display time to the user, or if you wanted to base certain things by their timezone.os.clockis more precise & future-proof (well, if you don’t consider your code breaking in millions of years future-proof) and will be consistent when comparing the server and client (1 second is always 1 second, regardless of timezones and leap time) - I would also recommend trying to optimize your code more, and allowing it to check faster, such as per frame. There are a lot of things in it which would contribute to bad performance without needing to, such as excessively indexing things multiple times in the same place when you could make your code smaller and more readable with a local (while eliminating that extra performance cost). You’re also recreating objects you don’t need to (e.g. RaycastParams), and repeating a few calculations (even though they’re minor).
You can fix 2, and 3 by typechecking data received from remotes, as well as ensuring that dt == dt to avoid abusing NaN, but, I would personally not recommend relying on remotes at all (though there are definitely caveats to that as you brought up in an above reply)
4 and 5 are generally just organization and learning good styling and general programming habits, which, I’m pretty sure took me like 5 years to figure out even a bit of, especially with the resources I was learning from being strictly low quality free models. Personally I’m still improving in both areas yet I’m still mentioning it, so yeah haha.
Here’s an old GitHub project of mine which was an anticheat much like this one which I wrote for a game (neither of which unfortunately are likely to go much further). I’ve archived it at this point. You might find some useful stuff in it (you can also see a the issues and pull requests people made and get an idea of how the project changed while I was still developing it)
I don’t care how it or its code gets used, and I don’t even mind if people blatantly steal it at this point, so, if you find anything of value in it, I’d be really glad
9 Likes
This is not true. It depends on how you are using remote events and in this case I would consider the usage an attack point that’s not very well secured, and a weak one, but, the way it is designed is at its core pretty similar to what networking already is.
Saying that any usage of remote events = bypass is like saying that any usage of the network = bypass, which, is kind of true technically, but, it doesn’t really make sense to say that. It’s not about there being some kind of client authored communication, its about how that communication being handled properly and correctly.
@chessebuilderman The check actually doesn’t kick if the remote isn’t fired for 30 seconds, I think that was just a bad choice of wording. It is actually proper (though I think 30 seconds is too high) because the client is forced to advance a clock forwards (they can’t send 0, or go backwards). If they just advance it really slow, or don’t advance it at all, eventually their timer will be 30 seconds behind, and the check that was mentioned kicks the player.
Likewise, if they submit requests too fast or try to use giant dts for bigger thresholds, they’ll get kicked because their timer passes the server’s timer. This check gives a 1 second gap, but, this gap isn’t actually necessary at all since, well, the client’s clock should never ever be advancing faster than the server (unless you want to take into account special relativity I guess 
)
@CoinTheKit @0MRob I think you are missing some of the functionality in the script. I read it thoroughly, and, I can say that while I again disagree with this usage of a remote, at least a majority of the remote data is legitimately validated on the server at some point from what I could tell. That’s also including reported position not matching the replication position. The biggest concern with many of them imo is just thresholds that are too large, and, its a little bit spaghetti-ie. The anticheat at its core is robust, the execution is just not perfect.
@ScripterWaffle I did not follow 100% of the conversation so apologies if I misunderstood or missed something. While I again disagree with the usage of remotes here, the anticheat is not vulnerable to client sided spoofing from what I can tell, everything appears to be validated semi-correctly on the server, including spoofs. Again like I mentioned, biggest concern is probably thresholds being too large.
@wravager Checking stuff server side like Position, CFrame, etc can and does cause server lag, in fact this was something key brought up with the archived anticheat I wrote, which I mentioned above (GitHub - Hexcede/Hexolus-Anticheat)
@XaddyGoat I mentioned in more detail above, but, your assumption that disabling the client script would bypass this anticheat isn’t correct from my understanding, as the data is validated in a different location.
7 Likes
Just because you implemented something a certain way doesn’t mean it causes server lag if done correctly.
1 Like
Your AntiExploit keep kicking my players while they interact in the game!
There should be a message telling why it’s kicking. Can you give me it? Also, I update it alot make sure to use the new versions. (The kick message exist in newer versions)
I read through the script again and don’t really see a problem with all the 4 possible kick. Only the “Ran out of time” kick is possible without exploits. With the lastest version, make sure they don’t lag so bad that no data manage to be sent over for 25 seconds.
I thought that you meant that vector/CFrame operations do not cause server lag at all, which, is objectively false, but, I think I was just being dumb dumb.
CFrame ops are very slow in relation to pretty much all other ops, and, Vector3s used to be worse but recently received some really nice native performance optimizations (from my understanding they, among other things probably, take advantage of SSE now, in other words math can be done on all three components at once which is a bit cheaper).
CFrame and general vector operations are expensive, so, its pretty easy to cause lag with them with minor overuse or redundancy.
Of course, if executed well that’s not a problem because they can also be an extremely handy tool when it comes to actually optimizing physics stuff as well, that goes for pretty much anything that’s relatively expensive.
not fixed, I updated the script and it’s the same!
“Ran out of time” error
I have a good internet, no lag or something like that.
Maybe another script?
Can you tell me what is probably causing this?
I found a problem when loading in, if you were getting kicked after ~10 seconds when joining, that’s fixed now.
I actually love the idea that the client sends information, this has never been tried. However you must secure implement this.
One tip: you could use this Workspace | Roblox Creator Documentation for syncing stuff.
Also you should verify that none of the data is tampered with and that the client is sending data and not trying to brute force it.
Thanks for the feedback. The client doesn’t need to know the server time nor is there any syncing between the server and the client. None of the data can be tampered with on newer versions so you don’t have to worry about that. If the client tampers with the data they at least will trigger the anti walkspeed and at most, they will be kicked (almost every kick in the script should be a ban as it’s impossible to trigger them but that’s on the developers to implement).
Not for tampering reasons, but for ping adaptation the time syncing could be useful.
but like.. why on the client?
Because of filetering enabled. Of an exploiter changes their speed it only changes it on their screen. Not server. So u have to check on the client
i dont get it, if the movement replicates to the server, how dosent the speed replicate too? its too confusing
in the moment, if you want to make it serversided, you can use magnitude on the old pos and if the mag is too high kick the player. and do that every 5 seconds
I’m not sure if I set this up right but it just doesn’t seem to work for me. I’m using R6. The only edits I made were adding a ban function in place of where some of the kicks were.
It doesn’t it just gets the speed. But the walkspeed doesn’t change on the server. It’s confusing. Heres an example.
I change my walkspeed on the client.
here’s my walkspeed on the server.
as you can see the walkspeed didn’t replicate on the server. Which means it wouldn’t detect it on the server. Instead it changes on the client. The only thing that replicates is the SPEED NOT walkspeed. So you can only detect it changing on the client. Which is why the anti cheat is on the client and not server.
i’m pretty sure it only takes a few lines of code in order to develop a basic anti-walkspeed exploit on the server.