What if a Player lags out? Wouldn’t they get banned by the server for not getting a response?
I assume probably, I disabled speed anti-exploit based on “walking” speed, which gives false positive, when player glitches out into void/or space xd
I would do it like this: I would add a localplayer a boolvalue and localscript in which should be coded next: a boolvalue which is constantly on true when player is touching terrain if player is not touching terrain turn it to false I would also include a loop for a several times or/and a wait and if value is still false for several seconds it would FireServer() and on server script get a localplayer OnServerEvent:Connect(funciton(plr) and plr is localplayer and simply you include a player kick script which server kicks player out of game. If you need help feel free to DM me here.
I hope this helps. 
1 Like
Oh no, in no way am I saying that it cannot be manipulated, there is no such thing as an ultimate anti exploit or an ultimate exploit, but as a developer, I’d rather have a gate on my house than to leave my doors open for intruders to mess around.
With networkownership, it is very possible to make it a painful experience for exploiters to emulate your ping, the only way they can emulate the same patterns is by decompiling the source script if they can find it ( in which there are many different ways to secure, again, not saying it is the ultimate security, such as obfuscation, decoys, having everything on the client obtained via local references and then renaming everything into a randomized sets of numbers to throw exploiters off further ), furthermore, with the new lua vm, decompilation have yet to make a breakthrough back, again however I am not saying that it is impossible to decompile scripts now
Now going back to the topic of security, the idea of an anti exploit that cannot be bypassed is simply a myth, if you’re making security, it’s about making intruding a painful experience, if you reject security simply because it can be bypassed, you’re not going to achieve what you’re out here to do. As I was saying, I’d rather have a gate in my house with a locked door than to leave it open without anything protecting my property.
The same mentality is best taken with game security, you’ll never make something that no one can exploit, but if a security patch will thwart someone while not affecting gameplay, I’m adding that to my games.
2 Likes
For a solid minute though?
I would say it’s a green light from me to force-rejoin them, my anti exploit don’t ban players, it just makes them rejoin the same server back, announces in that server that so-so was force-rejoined for so-so while also notifying me on my website of the username, userid, user profile, the reason they were rejoined and other additional info I may need.
I’ve also tested this security on a few smaller games that got 20-40 thousand visits a day, tested the client-server ping via network owned part patterns, not a single false positive since a month ago, thus why I plan to add it into the anti cheat.
I don’t really invest into Anti-Exploits that deals with “Physics” as much because it’s pointless and risky.
It shouldn’t be our job to come up with ways to prevent something like this in the first place, something that has always been a problem for years.
My recommendation/something I would do; is create a Vote Kick system for “Physics” related exploits.
You might be better off taking a step back and looking at it another way finding a new approach.
6 Likes
I include some information about anti-exploits in my post here.
This doesn’t focus on your case specifically so I’ll explain a little more in depth on how I would do this. Kicking the player is what I call an “agressive” anticheat and for movement based exploits it’s not as effective as a passive anticheat because there will always be false positives no matter what you do.
The RunService.Heartbeat event runs after physics calculations so you’ll want to connect to this and check for flight. If you think about what flying is, the player is either using a BodyMover on their client which properly sets Velocity as well as CFrame or the player is setting CFrame directly. You’ll want to account for both situations.
Firstly, you need to know if the player is above the ground. You can use the FloorMaterial property of the character’s Humanoid to check if the player is on the ground (less performance cost, more accuracy). A raycast can be done from around the middle of their feet straight down (if you place the ray’s origin at the bottom of their feet you’ll get more false positives if the player hits the ground). If the player tips over this won’t get triggered since their feet rotated the origin of the downwards ray. Next you’ll perform the raycast to get the hit point if the player isn’t on the ground. This point is the “floor” point. Now you want to use the Y component of the character’s HumanoidRootPart CFrame and the Y component of the floor point and compare them each Heartbeat. If the player’s Velocity is static or its Y value is increasing and the distance is too large you can reset the player’s CFrame to that point (offset enough so their feet touch the ground).
Finally you can check for teleportation using the method I suggest in my post and this will prevent the CFrame method. Note: You won’t be able to teleport players server-sided without modifying the lastCFrame variable. To teleport them I just set their lastCFrame variable to where I want to teleport them and they’ll be teleported there. You can store this value in a table and the index is the Player Instance. That way a script can require the module whenever it wants to teleport players and simply set their lastCFrame value to the target location.
The moment you said local, that botched the reliability of your method. An exploiter can modify the traffic to always fire a truthy value back to the server. The client should not be relied on, especially considering that in the case of fly exploits it’s physics manipulation and the client is authoritative of their own physics as well as parts they have network ownership of.
2 Likes
how do they exactly disable it then
It’s the client’s machine, they can do anything they please. Disabling a script is only the easy way out but it’s definitely not the only way of halting your code from executing. I’d assume most exploiters don’t even touch properties, they terminate the threads themselves.
There are many ways for an exploiter to counteract your attempts to constrain their machines.
then how would you properly make a “anti exploit” that cant be spoofed
You don’t. Not when it’s on the client.
how would you exactly make a “anti exploit” in the serverside , i would like to have a clear explanation if possible cause i dont know how to detect exploiters activities on serverside since they do it on the client.
I think the replies above are worth looking into, at least the ones that don’t use the client as a dependency or point of truth. For me personally, in terms of fly exploits, I’m sure that checking player positions on the server-side and finding an average should work well enough. I don’t usually make code against exploiting explicitly until I have enough content in my game, so prevention of physics-based exploits is out of my range.
2 Likes
First of all you need a way to check if someone is on the ground. The Humanoid.FloorMaterial property is excellent for this. Next you want to think about what “flying” means.
The characters velocity will either have magnitude 0 or they will be moving. If they aren’t on the ground and their velocity’s Y is remaining constant or 0 for at least a few seconds (I’d say 1.5 is a good value however you might do 2 to be safe) they are most definitely flying. If their velocity is negative and becomes positive they are definitely flying.
Next you need to know when to check. You should use Heartbeat. This is fired after physics take place. Stepped is the alternative and its fired before physics and because of this it isn’t useful for this situation.
Finally you need to know how to stop flying. You shouldn’t punish the player for movement exploits unless your script is confident they are exploiting (it’s up to you to decide) but rather prevent them. To prevent flight you can teleport the player to the ground with a RayCast.
Similar ideas can be applied to speed/teleporting. You can check if the player moves faster than their velocity times the heartbeat step give or take a few SPS. Velocity.Magnitude is their total speed (for walking it’s almost exactly equal to their WalkSpeed), (position-lastPosition).Magnitude is how far they moved. You can finally check if their velocity is too fast. Their max positive Y speed is their JumpPower and their max x and z speed is their WalkSpeed. Their max negative Y speed is infinity so you shouldn’t use negative Y. When you detect this you can set this to their last position and last velocity optionally added to step times their velocity to get their predicted position.
You should read my article for more information about anti exploits and some tips: How you should secure your game - A beginner guide for secure networking and developing anticheats
9 Likes
Sorry for the bump post. The way that I do it is that, in addition to what people have already mentioned, you can get the height of your lowest point in the map and the highest point in your map and check if the player’s humanoidrootpart (if it exists) in constrained between those numbers. If not, the player is outside the map. This is an older method that I use but, I have found it to work and be simple. However, if the player doesn’t go beyond your min and max constraints, that player could be flying, which is where this method has its pitfall. Most of the time though, they tend to go beyond the constraints.
I made an Anti-Fly script which checks player to make enoguh mistakes that we can count that as exploiting, take a look at this thread:
how do you check if the event in the script doesn’t respond when the server fires to the player.