Readability could be maintained by just putting it in a script that every other script relies on in some legitimate way. Sorta like a keystone. Depending on how it’s done, it could be made in a way that would force an exploiter to rewrite half the code to do their nasty hacker business–which would deter even professional exploiters.
Exploiters wouldn’t have to rewrite any code. Again, I can’t talk about how or why on the public sections, but there is something clever hackers have at their disposal that you’re not thinking of and likely don’t know about.
Hey, that’s what the other options are for. A hacker can’t make itself speedy to all clients without it being possible for the server to notice with the methods I suggested.
For walk speed you could determine if someone is walking faster than the games currently set walk speed.
Development support isn’t public though.
Nevermind, since when is it public?
1 Like
To combat exploiting, all of your checks need to be on the server. Furthermore, they need to check only the position of the player, as almost everything else can be spoofed by the exploiter.
In theory, an exploiter can change everything about their client, including removing and replacing your exploit-checking code but reporting to the server that everything is OK. They can even report a Velocity of 0 while they’re moving, report a WalkSpeed of 16 while using 200, or report touching parts they aren’t touching. Fun fact: the server listens for the client to say it touched parts in some cases, so exploiters can spoof touched events! You need to do magnitude checks for those on the server.
The most reliable way to combat the listed exploits – which are all character movement exploits – is to check the HumanoidRootPart’s position on the server every frame.
Here are some checks you can do using the last frame position and current position:
- Did they walk through a
CanCollide = truepart between the last frame and current frame? (use raycasts) - Did they move impossibly far between the last and current frame (e.g. 100 studs), such that they must have teleported?
- Log when they’re on the ground using raycasts. Is their current position too high from their position when they were last on the ground? If so, they’re jumping higher than possible for their JumpPower.
- You can calculate their velocity using
(current pos - last pos)/frame time, then…- Are they hovering in the air without a negative Y velocity? Have they been doing it for a few seconds?
- Are they walking faster than their walkspeed? Have they been doing it for a few seconds?
These checks cover…
- Noclipping
- Teleporting
- JumpPower changing
- Flying
- WalkSpeed changing/Speed hacks
You will sometime get false-positives. This can be because the client has high ping or because the server isn’t checking often enough. You should only punish the player if they trip these checks often within a short time period. Your punishment should also not be severe: respawning or teleporting the player back to the last valid position is enough to deter exploiters and not harsh enough to deter real players in rare false-positives. Kicking or banning is too severe and not necessary. Exploiters won’t want to exploit anything if their exploits just don’t work.
107 Likes
10/10 Remember to quote this man ppl
1 Like
While a good post, a lot of your suggested security measures can be repeatedly tripped off by laggy players, which can be extremely annoying to get constantly teleported back. A reasonable number of you players will be playing from Brazil, know that.
2 Likes
Afaik this is what PF does, except as punishment they switch off damage.
I don’t think this will be an issue if you set your thresholds high enough.
None of these should trip instantly, or if they do then their individual thresholds should be fairly high. For example, passing through 5 parts, teleporting 200 studs, or flying for 10 seconds. No high-ping player should activate those, but exploiters probably will.
If you have low thresholds individually, then you need to be looking for multiple trips instead of activating on the first one. For example, only punishing the player if you get 4 trips in 10 seconds.
How tightly you check for these things will need different values per-game. It’s probably not going to be a single set-and-forget. You’ll need to tweak it such that it doesn’t catch high-ping players but does catch exploiters. There’s a lot of variables to mess with to get it right.
Fun idea: adjust the thresholds with the ping. Low-ping players get tighter thresholds. This will prevent low-ping exploiters from taking advantage of the high thresholds. I’m not sure how this would work out with high-ping exploiters, or exploiters that intentionally increase their ping, but I’m confident that with the right tweaks it will work well enough to deter exploiters without affecting legitimate players.
4 Likes
I have created a RayCast from the last position to the current position every frame, and sometimes the ray gets registered when they walk super close to a wall, any way to ensure it was an exploiter to filter out those that just touched the wall?
If you’re raycasting from the last center of the HumanoidRootPart to the current center of the HumanoidRootPart, then that should only rarely happen on corners if the player has high ping.
That is one such case where you need high thresholds. Either only trip on 2 parts between last and current or only trip if the user passes through multiple parts in a short timespan.
One workaround I can think of – if you don’t want to increase thresholds – is to calculate the “depth” that the user walked through. You can do that by casting from last -> current and from current -> last and getting the distance between the hit positions. You can also look at the surface normals and see if it’s a corner.
If both casts hit something, then the user passed through something and is on the other side. You can set a threshold for what depths/distances you’re okay with here.
If one cast results in a hit and the other does not, then the user is or was probably inside a part.
Legitimate players should never be inside a CanCollide = true part.
If you want to take it even further, you can check which sides/faces of the part were hit and where on the part it was hit. If it’s near an edge or if the faces/angles are like an edge, then it’s probably just a player passing by a corner.
I would try just increasing the thresholds first. The above can take a bit of work. Maybe increase the thresholds then do the above if that leaves too much room for exploiters.
11 Likes
Don’t exploiters also fly by repeatedly jumping by changing the sitting value of their humanoid, or has that been batched? You should probably check for that too.
I’ve added some checks in the past but I would think that having the server check all the players every frame with multiple raycasts could get heavy? On top of that, it probably won’t work for that long. Smart exploiters can just make themselves have a tiny advantage, cheating the system. (If you took out people with those tiny changes, you’d hurt lots of people that experience lag)
You can try having local scripts that check for these changes so that it doesn’t lag the server.
I know that now you’re thinking that an exploiter can easily remove them, but most won’t go a long way if it’s too much work.
Can’t you just have multiple local scripts in different hierarchies that detect if the others have been removed, and another that gets placed into the PlayerGui on spawn, but after connecting the events the local script removes itself? It would be too confusing for most exploiters, I would assume.
1 Like
Patched. Roblox’s method was actually interesting though. Jumping immediately after sitting takes you out of sit mode without propelling you upwards like a normal jump. By the time you have sat long enough to allow upwords propulsion by jumping, you’ve already fallen considerably, so that method is dead.
1 Like
This is already checked for.
If the player is doing this, their position will be too high off the ground for too long.
There is a reason I advocate for checking just position. The client could actually sit and jump repeatedly while the server-side Humanoid says false for both sitting and jumping the whole time.
This is true. I would still go for the reliable, impossible-to-workaround fix first. If it would catch legitimate players then the exploiter can’t be doing any better than some players could do.
I put the checks I mention in the category of “sanity checking”.
I put the client-side checks many people are mentioning in the category of “security through obscurity”. I say this because they can always be worked around by a determined exploiter. Most exploiters just aren’t determined enough to work around them.
“Security through obscurity” never works 100%. It’s certainly a great deterrent, but it shouldn’t be your first step. “Sanity checking”, on the other hand, always works 100% for the situations it’s designed to catch. I would suggest implementing sanity checking first, then the “security through obscurity” client-side checks last if you still have an exploitation problem after implementing sanity checking. This makes your worst case “exploiters are slightly better” instead of “exploiters destroy everyone”.
Certainly for most, but if anyone is determined enough to break through it, then they can give out or sell their exploit. Then you still end up with many exploiters instead of one.
You can change your anti-exploit method to make the exploiter redo their work, but you still had super-powered exploiters flying around your game for a while. Wouldn’t it be better to have slightly-better-than-normal exploiters in these situations instead of having super-powered ones?
I’ll reiterate that client-side checks are not bad, but they are not a guarantee, unlike server-side sanity checks. I think it makes the most sense to implement the reliable method with a guarantee before the unreliable method that can be bypassed.
1 Like
It’s always more reliable to have server checks, but I was pointing out that it seems excessive.
You’re checking for everything every frame for every player, I haven’t ran that many checks so I can’t speak for the performance but I assumed it was heavy for the server.
That’s why I suggested just keeping the checks for those exploits on the client, and that if set up correctly it would deter almost all exploiters.
Of course it can be bypassed by the advanced, but under that worst case scenario; the game still has FE and correct server-client relationships (or I hope). These cheats don’t have to always be looked at since they usually don’t affect other players, but some games decide to check them.
I just thought it would be best to check the client so that it is not heavy on the server, and that it’s fine to just check the client since it will stop nearly all exploiters for these little exploits. But if you’ve ran this with lots of players in game I’d be interested in knowing if it has an effect on latency or not.
Whether or not this will be excessive depends on players per server, map complexity, and your thresholds.
If raycasts are your main performance concern, then I can tell you that I can support casting 200 random, length-50 rays at 30 times per second in Crossroads at around 55 FPS. That’s 6000 rays per second.
That would support between 50 to 100 players, if the Lua checks are not considered.
Worst case scenario, you might have to check less often and up your thresholds a lot. Having some sanity check for player positions is still better than no sanity check. I think sanity checks are an important part of “correct server-client relationships”, and Roblox does no sanity checks on player position by default. Player position is still part of the “server-client relationship”, even if it’s mostly programmed for us already.
That depends on the game. I think the ability to walk through walls, fly, and teleport affects most games. It will affect most action games, which are many of the games on the platform. The main games I can think of that it won’t significantly affect are social games, driving games, and games that don’t use the Roblox character at all and have their own sanity checks for these things.
I sadly have not. I have implemented a form of this in an unreleased game, and it hasn’t caused any issues. I also implemented a rudimentary version years ago that only checked for flying, and I did not see any performance issues.
1 Like
Really depends on how much the exploiter cares. It’s not impossible to pattern match packets and remove information you don’t want sent.
Also, funneling all your traffic through a single remote event/function is not worth it from an organization point of view. Just make your code secure in the first place.
Always assume the client is lying. You can usually stop script kiddies by obscurity which is the whole point of doing client sided checks, but hackers can only be stopped by air tight server code.
Er, security is not why you do client side checks. It can be a neat bonus to having them, but you have them for instant response when the client tries to do something they can’t.
2 Likes
Ye, that’s what I’m sayin