In my opinion, this is a horrible method of checking whether an exploit has been injected since the chance of a false positive is really high and, spikes in memory may be due to game scripts. When an exploit is injected, usually, the amount of memory being used will spike for a short while, I can’t say this is how all “anti executor” scripts work but, one way is to calculate the difference in memory within a given interval and, if the difference in memory is larger than a certain value or is a certain value, it will kick the player. Again this method is not viable for anti-exploit as many exploits just get around it either way, and exploiters can even just turn off your client-side checks. It seems to me like they might be using this type of method or similar to detect changes in CoreGui left by certain exploits. It contains a lot of arguments on how you shouldn’t be relying on this method. I’m not entirely sure if it’s still valid but definitely check the post out and read through the thread.

This game of cat and mouse is relentless and we have very little tools.Īnyways after further research, I found this thread from 2018 saying how you can’t access CoreGUI from a local script, but you were able to detect via a workaround if a GUI was added to the CoreGui. Fake remotes will be found and shared, encrypting doesn’t matter as clients don’t look at your code they look at what your code is doing, and WalkSpeed doesn’t actually replicate the number if changed on the client - you have to calculate the velocity manually.

I just find that hilarious that the ones you happen to mention are also some of the least effective methods out there. The only methods of anti-exploit that I have found somewhat effect are: fake RemoveEvents, encrypting your source code or otherwise, ‘spaghettifying’ your code, and having minimal server-side checks such as: if > 16 then and so on so forth.

Free script executor roblox 2018