Yea, thats a good idea but if I would invisible blocks, lets say someone gets fling and touches that that wouldn’t be great butt the rest I will try.
1 Like
humanoid.StateChanged:Connect(function(old, new).
if old == Enum.HumanoidStateType.Freefall and new == Enum.HumanoidStateType.Jumping then
player:Kick("Cheating is not allowed here.")
end
end)
This worked, thank you!
1 Like
This script is prone to exploiters. I mean, if they wish they can change or disable the script, as @EssenceExplorer mentioned above. But you can sustain your script with some of the scripts stored in ServerScriptService, it will detect if the exploiter is disabling or removing it.
local list = {}
while true do
wait(5)
table.clear(list)
for _, player in pairs (game:GetService("Players"):GetChildren()) do
table.insert(list, player)
end
local function kickPlayer(player)
local playerGUI = player:WaitForChild("PlayerGui")
local DoubleJump = playerGUI:FindFirstChild("DoubleJumpScript")
local DoubleJumpDisabled = DoubleJump.Disabled
if not DoubleJump or DoubleJumpDisabled == true then
player:Kick("You have been kicked due to exploit.")
end
end
table.foreach(list, kickPlayer)
end
I don’t know if this works.
Haxors could destroy values but it still is inside of him since he can destroy it only locally. If the server check the value, it will still be here.
Actually, since the character is controlled by the client (or some other reason), roblox gives network ownership of the character to the client, thus allowing the client to make limited changes (including deleting descendants of the character) to the character, which will reflect on server.
Here’s a link to network ownership if you want to check it out 
1 Like
That is true, however, such client-side checking approach presents an obstacle almost negligible for an exploiter.
Since clients hold network ownership over their characters, server can detect when player removes a certain part (not insert). If I were to check whether animate script is present in game on server and remove it on client, the server would detect changes.
Nevertheless, exploiter could simply disable the script, and changes wouldn’t be visible to anyone else. Values such as script.Disabled status do not replicate. There are only certain exceptions that do replicate with filtering enabled (FE), which are listed in the image I’m appending.
@ProBaturay had a good idea, which sadly doesn’t work, because .Disabled property doesn’t replicate. Furthermore, even if it did work, clients would find alternative ways to disable script functionality, e.g. disconnect active .StateChanged connection. The saying “my machine, my rules” describes the issue almost perfectly.
That’s the reason why exploits are so hard to patch, why they exist in the first place, and why all the solid anti-exploits are installed on the server. Adding client-side security scripts as side-kicks is indeed useful sometimes, but in this case ineffective.
EDIT @EmeraldLimes I am fully aware that you understand replication and client-server model. This post is meant to be an extention of yours. Your post was not confusing at all.
Have a great day! 
1 Like
I am aware of the limitations of what an exploiter can do with FE and network ownership, but thank you for pointing that out. I meant for the checks to be made on the server, but I didn’t specify, sorry about the confusion. Good point though, such a solution with values would be ineffective.
1 Like
The answer would be: You can’t. Any player (client) has access to everything in their machine.
You cannot detect this either because they can quickly detect what you are using to detect it with.
If that’s not good enough, they can also cancel the kick packet being sent to their client if you attempt to kick them locally.
Although this is partly true, I don’t think it’s impossible, more or less how well you can do it/how experienced a hacker/exploiter is
It is impossible, as long as the client has full access to everything happening on the client-side.
You may deny this, however that is the truth.
Please note: I mentioned that this is impossible on the client, not the server.
And if you do create it on the server, it might have false positives as a lot can cause delay, which will result in innocent players being detected.
Ah, I see. I still think the matter of whether or not it’s “impossible” is about skill and methods though, but, agree to disagree 
Then that’s your opinion, if you actually knew how exploits work and how the client has access to everything on their machine, you’d say otherwise.
I do understand how exploits work, but I’ll still stick with my opinion 
@Syclya the fact is that client can access almost anything on their machine. Like said before, exploiters can modify any code, run any code on their end, or stop any active processes. No way to counter that. However, @EmeraldLimes has a point. Client sided checks aren’t impossible, but they are avoidable by the exploiter. Both of you are right, as even though clients can disable hidden local anti-cheats, those can and really do work as a - at least temporary - side kick to server anti-cheat system.
Many cheaters are inexperienced Roblox players that often don’t know anything about programming, leave aside game architecture. They learn how to download and install script executors by watching YouTube “tutorials”, and/or repeat steps described on forums that border to grey area.
Clients sided anti-exploits can be easily bypassed, but that doesn’t mean everyone will know how to bypass them, albeit the ones who do know the ways will eventually release them publicly.
Long story short, a glass fence may not be able to stop a bear, but that doesn’t mean smaller animals can break it (until they perhaps find the right tool).
Nothing is wrong with adding some small anti-cheats and honeypots on client. But more importantly, a solid general server anti-cheat and good game architecture are a must.
EDIT @Syclya @EmeraldLimes
That’s the key sentence. The more popular a game is, the faster will exploiters find local security checks and disable them. Once they find the scripts, it’s as easy as disabling them. The only thing one can do to counter that is update the game and change the local anti-cheat, or hide it elsewhere etc. Perhaps hide it in other scripts. It’s often considered ineffective, because regular updating is demanded. A step forward would be implementing polymorphism and self-relocating, but that requires a lot of work and is most likely not worth it nor, again, as effective.
For the reason explained above, there are also no effective “injection detectors”. Besides, exploiters don’t even have to inject scripts, but rather run executors, which run in memory without attaching any objects into the game environment.
1 Like
I agree. To add onto why I think client side checks are worth a try, if you make it strong enough, than (hopefully) only experienced hackers can crack them. Chances are, they’ll offer it for a price, which (I think) will reduce the number of exploiters that can get past it significantly.
You can keep improving your system until the only scripts that can get past it are offered at high prices, or, maybe no one can get past it. Who knows? 
Just a theory, of course. I’ve heard of a game that was able to detect an “injector” when it was “attached” to the game, and was able to kick the exploiter
I have also heard about a game that can detect injections, however that is most likely from a CoreScript used by the admins, a CoreScript has the highest (don’t see why not) permission level, they can even change your in-game volume if they want to:
I wouldn’t waste my time implementing something that can be removed within a few seconds, I don’t see myself doing so much work when it’s easily bypassable by the client.
You will however get rid of a lot of exploiters as most are inexperienced, but you will never keep out the ones that knows what they’re doing, that’s why I don’t want to implement client checks in the first place.
Literally anyone can bypass it if they want to, so in the end it doesn’t matter how skilled they are because most exploits has a lot of built-in functions that can help the user bypass whatever they want.
Never trust the client.
Once they find the scripts, it’s as easy as disabling them. The only thing one can do to counter that is update the game and change the local anti-cheat, or hide it elsewhere etc. Perhaps hide it in other scripts. It’s often considered ineffective, because regular updating is demanded. A step forward would be implementing polymorphism and self-relocating, but that requires a lot of work and is most likely not worth it nor, again, as effective.
They don’t even need to find them in order to completely remove them.
They can access nil and every localscript in the game:
pcall(function()
local GetDescendants = game:GetDescendants()
for i = 1, #GetDescendants do
if GetDescendants[i]:IsA('LocalScript') then
--
end
end
end)
-- Synapse X (and very likely other exploits that looks similar when accessing nil)
local GetNilInstances = getnilinstances()
for i = 1, #GetNilInstances do
if GetNilInstances[i]:IsA('LocalScript') then
--
end
end
As long as the localscript exists in the client’s memory, they will be able to find it, regardless.
This is pretty hard to implement, as latency can cause a lot of false positives. In fact, it was easier for me to create an autoclick detector than it is to create a working version of this. I’m not sure if Roblox needs improve the reliability of HumanoidState’s or if this will always be like this.
Hi! Yes, I understand that, thank you. I think I mentioned everything when I said that client-sided anti-cheats may often be ineffective, but may still sometimes serve as side kicks for good general anti-cheat system along with good game architecture.
What you said is true, but again, not everyone knows programming and not everyone will know how to remove/disable for instance an unnamed local script that has a hidden anti-cheat inside lets say character controller. An inexperienced player won’t know how to remove the anti-exploit without fataly spoiling their game experience. Not effective, not completely ineffective.
@BuilderBob25620 those auto-click detectors work, but can be easily bypassed by using the methods already mentioned in this topic. However, it’s important to do server checks if server actually has to process those clicks.
I don’t know why HumanoidStateType is still in question. It’s a good idea, but runs client-side. I’ve assambled some basic raycasting code right at the top of this topic:
About false positive results:
@Syclya and @BuilderBob25620 the negative effect of potential false-positives is almost negligible with this server-sided anti-high jump, because it depends on set jump limit. If players can jump 7.2 studs high, we can set the limit to 30 studs. Besides, we can store attempts. Each time player passes the limit, teleport them to the ground, but keep score on how many times it happened and so on.
The odds of players jumping 40 studs high multiple times (not falling) while being limited to 7.2 are very low.
You’ve both made some fair points.
Not really. I built a system where any click you did HAD to be processed by the server for any clicks to work. Otherwise if you were trying to press a button or something and it wasn’t being sent through the server then it wouldn’t work. And it only sent the bare-miniumum of information, meaning it just fired whenever the mouse was clicked and provided the player who fired the remote event on the server-side by default. Everything else like timing and interval detection was handled on the server. I also made it gave a minimum amount of time you were allowed to click fast enough to be within the interval, because in real life a human clicking very fast will wear down with time but a computer can keep on going. I believe I set the allowed time around 10-15 seconds.
Despite this, I realize my autoclick detector could still be bypassed if the clicks were setup to be random and varied. Still, in those cases it wouldn’t matter because the main reason I created it was to prevent inhuman clicking, not people staying on the server too long.
1 Like