it also kicks the player if any of the script is disabled(sorry forgot to mention) its a really simple way of making a anti exploit.
A method we have previously used is this:
- On the server, we loop through all the players continuously. For each player we do the following:
- Raycast vertically down to find the floor/object the player is standing on.
- If no object is found, we do a subsequent set raycasts in a circle around the player, searching for thin walls/objects they may be hanging off/from.
- If no objects are found we assume the player to be floating/flying. We increment a “trust value” for that player by some amount.
- We continue to check players, increasing the trust value every time we fail to detect the floor.
- When a player’s trust value exceeds a limit, i.e. say 10 failed floor detections, we punish them. (kick, kill, anchor, snap to ground, etc)
The trust value helps reduce false positives, i.e. players being flung across the map, jumping off a building etc.
Hope this helps, any questions drop them below 
18 Likes
You’re accomplishing the exact opposite. What’s more suspicious, ChatScript or a bunch of random numbers?
No, it’s on the client, it can be spoofed, that’s it.
4 Likes
You are right, I wonder why Jailbreak scripts are named really weird like “2353-7436-3245-9324”, when I was looking at the dev console… But anyway, I am gonna try to make on server anti exploit instead of using client sided method.
1 Like
Raycasting would be your best bet. Raycast downwards to get the ground. If there’s no ground or the ray is too long then raycast in each direction (left, right, forwards, backwards, etc.). If one of the rays hits a part then don’t kick. This is to prevent the player from being kicked if jumping off of a tall building.
You can try sending exploiters to this simple game test I made for anti exploits, or if you can exploit, try bypass in there, it’s a decent anti exploit I wrote a few days back, it’s only a few days old but I’ve gotten a number of exploiters to stress test it already, I would say it’s a pretty solid anti exploit, the only false positive I have thus far is E888 which is just a server-sided error from the game’s script that I can fix.
Basically if your game have a simple anti exploit like this, you’re already protected more than enough really.
To answer the question on flight patch, I would recommend either a velocity check on character parts, a bodyinstance descendant check on the character. You can definitely do more with raycasting etc but I highly suggest using low memory when doing anti exploits, don’t sacrifice gameplay for security, you can read my post here to understand a tad bit of that mentality.
Another thing that I suggest for the debate on how to secure your anti exploit script from being deleted / stopped, I would suggest a server → client ping system every minute, and put the ping response in the AE script, you can either handle the ping via remote which is not that secured or create your own complex pattern via a network-owned part created in the server upon player entry. Understand how Network Ownership works and you’ll be able to do some client-server signals without remotes.
If you need any further explanation or understanding from my own humble experience in patching exploits and creating solid anti cheats for upcoming games, you can contact me via discord @ Zenuvius#2480
Exploits nowadays can just stop your scripts without disabling it, I would recommend doing server - client ping as explained here
Having the server send a request to the client is no different than the client sending a ‘ping’ to the server. Both can be emulated by exploiters. Both give you a false sense of security rather than actually being secure.
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