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!
1 Like
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
3 Likes
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.
4 Likes
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…”
1 Like
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.
1 Like
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.
1 Like
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
3 Likes
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.
@geometricalC2123 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.
1 Like
Sure, one day an exploit is gonna patch it, but use this as a temp solution as it’s actually affective for now
1 Like
A lot of them already did after this, and a lot more did in the past before this post
If you are (quite understandably) paranoid about this false flagging players, simply make sure the namecall function can be retrieved properly and check the maximum call depth using pcall in a similar recursive function at the top of the script before using it in the second one. People have been using hacky CoreGui detection vectors for years now and if anything this is far more reliable.
Doesn’t make sense to use something as security then it gets breached in a matter of days or weeks.
People would place this in their game as some long-term or permanent alternative to combating exploits. They’d even use it now then months past when their game releases, this method would have been patched already and they’d have exploiters evading them.
Many companies like Google use AES which is a type of encryption method. If they expect that to be breached in a matter of months afterward then they wouldn’t use it.
You know you have no better argument when you have to compare an encryption algorithm such as AES to an exploit detection. You can claim client side checks are useless, yet all the top Roblox games often targeted by exploiters have implemented client-side anti cheats. In reality, most exploiters have no clue what they are running or how it works, and will be deterred by even the simplest checks.
Edit: you mention Google using AES, yet forget that their reCaptcha service uses obfuscation on client-facing javascript, performing the equivalent task as a client side anti cheat in our case.
LOL, did I compare it in any way?
Did you read what I said?
How did I compare an encryption method to an anti-exploit?
I literally said if Google used AES and it got breached in a matter of days or months afterward, and they KNEW it would be they wouldn’t use it.
The same argument goes for here
Doesn’t make sense to have something in your game PROTECTING IT if it’s gonna be breached in days or months.
The difference is encryption has to last forever or will become pointless in the future, while exploit detections only have to work until the player’s client closes and have no real consequences of failing to detect exploiters (at least over having no detection whatsoever).
Why are you comparing both of them then coming after me for it??
You still don’t get the point I’m saying: