These are bypassed by an experienced cheater, you may be able to stop unexperienced but then you could just use a simple one. If you are making anything client sided it should maybe be some baits that ban them besides that don’t trust the client. Make a server sided one instead, I can let you read some of my server sided anti cheat code.
2 Likes
Explain at least somehow, or demonstrate how you can get(object:GetFullName()) if you deleted this object.
I created this topic for a reason, I was trying to do it, but it didn’t work, which led me to conclude that this is the perfect protection
In this case there is nothing to protect/verify, it is an empty script, the point of which is to demonstrate that it cannot be deleted, deactivate - yes, delete - no
I do not have a game that needs Anti cheat code.
I create, but there are all the scripts on the server, so far local did not have to create.
This topic, my 25+ hours of excrement with LocalScript, and so far the experiments have ended at least a little bit successfully
1 Like
This still can be deleted, they can send their own remotes. Though this is great for possibly stopping script kiddies
As I answered everyone above:
impossible to send (object:GetFullName()) if you delete this object
I created this topic for a reason, I was trying to do it, but it didn’t work, which led me to conclude that this is the perfect protection
I see your purpose here. Though, they could keep their humanoid deleted, and also this with more then one script wouldn’t work too well.
Another thing to add, why would you protect the script? Exploiters can hookfunctions and metatables and change what functions do. On top of that they could disable the script, but create their own that is sending the name over even though it is disabled. And they can do this simultaneously.
Good luck with this, cool idea in though definitely will stop non experienced exploiters, but say it was to be a game, once one script gets released to pass it, everyone has it.
1 Like
Yes this defense does not stop anyone, maximum as you said “script kiddies”
This protection does not make sense to apply in the real game, because:
- we disable LocalScript
- we send to the server (LocalScript:GetFullName())
code example:
script
local Lscript = game.Players.LocalPlayer.PlayerGui.Script:GetChildren()
local event = game.ReplicatedStorage.RemoteEvent
local a
workspace:IsA()
for _, obj in pairs() do
if obj:IsA("LocalScript") then
a = obj
end
end
a.Disabled = true
a.Changed:Connect(function()
event:FireServer(a:GetFullName())
end)
As I said, this is purely an experiment.
And although the LocalScript can’t be removed. That doesn’t make sense.
It can be, they can create their own local scripts to replace them, causing them to still pass the check but remove the script.
local script = Instance.new("LocalScript")
script.Parent = blabla
script.Source = 'while wait(1) do print("HI") end'
2 Likes
If I read this simply, you have a local script that you send to the client from the server, then the server generates a random ID, and updates the name of the script to the random ID, and the local script sends the full name back to the server once it detects a change.
Yeah, this won’t work. An exploiter could just create a client side script that waits until the local script is added disable it, wait until the name is changed and then create a spoofed event back to the server which looks (real) but isn’t. The server won’t be able to tell because the server cannot tell where client side data comes from.
In essence, yes, you have wasted your time.
Because this has been said so many times.
You cannot trust the client.
And it has been this way for decades.
I will say this, and I cannot stress this enough:
you CANNOT create a fool-proof client side anti-exploit
People, way way way smarter than me or you have tried, and they haven’t succeeded, because it’s literally impossible.
All functions are stored in a metatable when called. If you know where this is going, you’ll know what I’m going to say next.
Even if you connect events that detect changes of the parent and name those can easily be unhooked by the exploiter! basically a forced “:Disconnect()” without using the original script.
And yes you can also spoof all the information that the server requires by simply replacing the function you called with a spoofed version using metatables.
This can be easily bypassed by very popular exploit script writers. 
1 Like
They can’t do that.
For by this logic, they create a script (object) that only exists locally with this player, but then tethered to it real? By literally changing the script on the server itself, so you can change the local script to any player, and manipulate the game of other people. This is nonsense and definitely not possible.
It’s impossible to create something locally, and make that local object, be linked to the real one, so to speak, replacing its original.
I get the feeling that I’m not making myself clear, or you’re trying hard not to understand me
I will repeat 100 times what I wrote in the post itself:
I said from the beginning that this protection does not make sense, as my script can simply be disabled.
Once again: I never said it would protect LocalScript in general, I said it would protect it specifically/only from deletion.
You can disable LocalScript, and give a fake signal, but you can’t REMOVE LocalScript.
Just in case, one more time:
Disable, and signal artificially - YES
Delete/Replace, and signal artificially - NO
Yes, the protection has no practical use, but I didn’t say it made sense to use it in the game.
It was purely an experiment, which although it has results, it doesn’t make sense.
I hope you’ll stop explaining/proving to me what I admitted in the beginning
Yes, since the defense has no real application, you could say that I wasted my time anyway.
But so far, no one has been able to remove LocalScript, and continue to report the right data to the server.
That is, my protection really works, but meaningless in the real game
How do they disable all server-side checks? The local script only tells its location.
I don’t know what metatable is (probably in terms of terminology)
If you mean they can disable the local script and signal artificially, then read my answer above
I mean they can replace the script by changing the code in the local script.
1 Like
- read the script, and understand that the replacement is not possible (delete/transfer the original, and replace it with another that was locally created)
- is it fun for you all to respond without reading the topic/responses, but by reading only the title?
To quote my reply:
Quotle
I think an exploiter can switch local scripts and delete the real one
1 Like
Just skimming through the server code, but I’ve just noticed that if someone has a ping spike, they could get kicked because a remote could end up firing late, AFTER the server has already changed the location of the localscript.
An exploiter could totally just stop the actual code of the localscript from running and just have the part of the code that stops them from being kicked run, so it’s still the same localscript, just with different code, no deletion or use of .Disabled
What do you mean switch?
if you mean that you can create a local script, and replace it so that it would go from the fake to the status of the original, it is not possible
I explained why:
Qoute
But the thing is that the “real” local script is still a local script. The firing of remotes can be messed with and the server can think the fake local script is the real one by the exploiter. So the server will never actually know the “real” local script.
1 Like
By the way about what you said (now that you mention it) how can you leave some code on the local script without disabling/removing/moving it?
This is just for the sake of example:
here’s how do you stop data being sent to the server?
How do you stop a function from running, or anything else?