Destroy won’t stop the script, neither will .Disabled = true if it has managed to spawn another lua state (e.g. with coroutine.wrap)
How would you run Dex or delete the script if you can’t inject your exploit?
An injector can update to patch this, and it is possible.
Bro, you cannot inject, and delete the script after. The script will ban you before you can even execute
tip: until it’s patched, do while task.wait(.1) do as it still runs when the script is disabled not destroyed (known bug) but it will be patched soon anyway but use this temporarily cuz dex people will delete it
How long do you think this will work for before the developers of script injectors find a workaround?
Dex people cant use dex, cuz it detects them before they even injected lol
So what’s making the people think it can be bypassed? This one localscript is a legend. The people who said localscripts are not good we’re false! Haha!
this is pretty damn impressive
took me a while to understand how it worked. taking advantage of the call stack is something I never thought about. it’s kinda risky but smart at the same time. well done
It can be bypassed by the people who actually make the script injectors themselves. By this I mean the developers of script injectors will be quick to add a system that renders this check completely useless.
Relying solely on localscripts to prevent exploits is never going to be a be all end all solution to anti-exploits because the client is the player’s computer, not a computer that you or Roblox are in full control of.
That’s very true and I have nothing against it, I guess we will just use this as a temporary solution
hahaha you can wait, soon everything will be, I will do better =)
Adding on
It is possible to disable client sided kicking, however it does require injection.
Lua also has rawset
and rawget
which allows you to bypass __index
and __newindex
. Meaning that people who have experience won’t be too too affected.
Though it isn’t a bad resource and could help get rid of some exploiters
Edit: See reply from @TopBagon
I think you misunderstood something. this script detects an injection and kicks right away
Which is impossible if you can’t inject in the first place.
people who have experience in C++ and can write their own exploits*
I’d suggest playing around and analyzing the code for more details. it can only be bypassed by the exploit creators, not people with just lua knowledge.
please don’t reply with “but it’s impossible to detect an injection…”
I’d like to mention the default string number formatting had not been changed since the introduction of Lua and then over night a change to it broke many games.
He is right. You are relying on undocumented observations and it will likely have consequences.
I don’t think you understand the point of this script. This prevents exploits from injecting as most exploits and scripts to use with them hook the Instance __namecall method. They have no time to hook the Kick function and if they do, you can always just crash the client using while true do end
which is far more difficult to prevent. As for rawset
etc, these do not work on userdata and if they did, this would break normal behavior of instance properties.
If tostring() adding one extra digit somehow broke your game I think it’s fair to say your code was not perfect to begin with.
I’d just like to make a meme.
People: local scripts for anti cheats are useless and can be bypassed easily.
this one dude: makes an anti inject local script which actually prevents exploiters
That is irrelevant. The fact is your assertion is wrong and it doesn’t matter how long something is established for. Luau team has made huge changes before to behavior for performance reasons.
@regexman this doesn’t prevent anything more than any older methods of detection. They prop up, they get patched, the cycle repeats. When people criticize client anti cheat it’s for a good reason.
Sure, one day an exploit is gonna patch it, but use this as a temp solution as it’s actually affective for now