You have no clue what you’re talking about. I clearly used
rawget in the bypass which doesn’t fire the
__index metamethod, as @kerrmeet mentioned, so env hijacking would not work. Worst case scenario you change the
MaxFlags into a honeypot, but in a real game, your script would just be disabled or the detection (remote or kick) would simply be hooked.
Also, this detection gets even worse if you have lower fps. While testing, anytime I dropped below 15 fps while moving my camera I was kicked.
A lot of old school games used VRM as verication checks within their games and some were coded into library functions often requiring an abitrary call to the function for it to return a key. This could be utilized similarly. So it cannot be deleted if you use it as a verification check within a module anything is better than nothing! Edge cases are important but not impossible to address when the concept is solid.
The ego here is immense, it’s crazy it always comes from somebody posting exploit detections on the client.
As much as you say this can’t be bypassed, it can if it’s on the client and that is a fact.
(also I don’t exploit so please don’t ask me to go bypassing this as your defense.)
script.Parent = nil
script = nil, This odda shut all ya’ll client haters up realllll fast.
You should be using destroy instead, it’ll remove all references to the script which’ll break poorly made getnilinstances() functions.
Poorly made getnilinstances() are not really a common theme anymore consider how many are pasted from public leaks with good developers.
@NotBugle Just because you delete/reparent a script to nil does not make it impossible to find nor does it make it even remotely difficult. A major element that you are all forgetting about is upvalues, protos and script globals which can be found without even referencing a script. They are so easy to find that there are actually multi-tools embedded with them all over github.
I would love to see an aimbot/aimlock detection however you can also just spoof the camera position variables on the client and that will make it look like the camera is always at the default position in your script @Sinkl0z . Before you say this will break core scripts, it won’t because they have elevated access and you can just restrict un-spoofed read access to lower ContextLevel scripts.
Again as said above by @Serieko , I won’t bother honoring a request from you to go bypass this because it is simply not worth it for such a basic and useless script. You should really tone down the ego you have because you very clearly are not experienced with even intermediate exploiters. Cheers!
If you would’ve read the entire thread you would cleary have been able to tell that i specifically pointed out the fact that it doesn’t have any protection against disabling / deleting the script. If this would’ve been a “real scenario” i would’ve had handshakes and multiple other protection vectors.
It’s also possible to set a lowest fps limit.
I’d like you to make the bypass, I’ll gladly patch it.
This seems interesting. I might use this, though I might make a server-sided version too that checks for extreme aim snapping.
That’s all I can say that hasn’t been said before.
I’m not very well versed in how game-specific exploits work, but I’ve looked around a little and cobbled together this:
-- Functions taken from a very popular, paid exploit's API docs
-- Every RunService.RenderStepped (mouse inputs are processed before it fires)...
-- loop through the scripts
for _, Script in getscripts() do
-- get it's environment
local ScriptEnv = getsenv(Script)
-- is this the anti-aimbot?
if ScriptEnv.Data and ScriptEnv.Data.Booleans and ScriptEnv.Data.Booleans.Steady then
-- it only increments the number of offenses if this value is true
-- set it to false to prevent it from doing that
ScriptEnv.Data.Booleans.Steady = false
I’m just very interested in this stuff, I’m not trying to say that this resource is bad, but I just had to take on the challenge.