Some games I’ve Played, When testing, Auto Kick you when you have and Executor Even if you’re not using it. Now I’m curious how I can implement these Executor Detections into my games. Also, I would like to know how Executors Exactly work?
This Knowledge would not Just be good for me, but Good for anyone wanting to prevent Easy Script exploits.
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 player.Character.Humanoid.WalkSpeed > 16 then and so on so forth. Anti-exploiting has become a game of cat and mouse putting the pressure on us developers to only simply mitigate these petty exploits.
Ok, but why do some games kick you when use an executor?
I just find that hilarious that the ones you happen to mention are also some of the least effective methods out there. 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.
This game of cat and mouse is relentless and we have very little tools.
Anyways 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. I’m not entirely sure if it’s still valid but definitely check the post out and read through the thread. It contains a lot of arguments on how you shouldn’t be relying on this method.
It seems to me like they might be using this type of method or similar to detect changes in CoreGui left by certain exploits. 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.
An executor isn’t detectable, but some of exploits are detectable. I think they secured there remotes well and detect the things they can detect like fly and fling. I am trying at the moment to acces the CoreGui to detect things like MrSpy.
I should have said ‘to name a few’ and also highlight the word minimal. But yes you are right, these mitigating checks will work for the script kiddies that make up 99% of the exploiters. 
Hello,
I have a few thing I would suggest to prevent people from exploiting.
Tips
This only helps with very Basic Hacks, Easily Avoidable.
Yes maybe that but they’re the ones used the most and as I said make it so when things get printed that aren’t from your scripts so it kicks people.
No they are not, “the ones used most” at all. Hackers love to use Executers to fire remote events, to trigger something on the server. and use client Sided hacks in shooting games.
Another thing would be make the scripts Server Sided, most exploits cannot bypass Server Sider scripts.
They don’t insert anything into CoreGui… Exploits usually are their own standalone programs. There is no way to detect it at all, since it doesn’t have to insert anything into the datamodel.
You have to detect the effects of an exploit; you can’t detect the exploit itself.
As true as that is, server scripts can’t detect changes on the client if they aren’t replicated. An exploiter who inserts btools into their inventory can’t be caught if checks are not done on the client because tools created on the client do not replicate.
What do you mean? I made a system that kicks people the second they insert btools.
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. 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.
Some client sided security isn’t a bad idea since it should prevent most exploiters from (changing their speed)/flying/etc but, some exploiters can bypass client sided security; instead of relying purely on client sided anti-exploits, it’ll also be a good idea to have some server sided checks. If an anti-exploit ruins user experience, don’t use it since the number of players that are going to exploit is probably going to be pretty low, instead you should focus on securing remotes first.
Your system would have to be client-based then, and that won’t be that helpful because at the end of the day, the client controls the client and therefore, you cannot block some client-based exploits like this.
@ffancyaxax12 Because an executor is an exploit and exploiting is against Roblox’s terms of service.
I know this thread is dead, however there is one slightly finicky way to detect the injection of a dll. When a dll is injected into roblox the frame rate will drop, usually for a single frame to somewhere between, 1/10 of the original frame rate to 1/2 of it. If you can find an effective way to filter out other frame drops such as lag or gpu usage from these frame drops you might be able to detect a dll injection and prevent the malicious player from executing any code at all.
How would you do that? I almost always get random frame drops on certain game, I don’t want to banned because of it.
You would have only act if the player loses frames for a single frame, and fine tune any bounds your using to detect frames to minimise false positives. As I said its a finicky way of doing it, but you might be able to find differences between frames lost to a dll injection and lag. (and of course kick players rather than ban them just to be safe)