Anti Executor
The five executor checks, what each one ships as, the reason codes they write into a ban, and how to narrow one down without switching the whole detection off.
Anti Executor looks for cheat executors and injection tools running inside or alongside the game. It is five independent checks under one switch, it replaced the older AntiOverlay detection, and a whitelisted moderator is not exempt from it.
What it ships as
Every check is on in the box and a hit bans. The five Types are what you actually tune: each is a separate check, and turning all five off stops the detection even with Enable still true.
| Setting | Ships | What it does |
|---|---|---|
Enable | on | Whether the detection runs at all. |
Action | ban | What a hit does. Kick is the safer starting point while you read a few of these. |
Types.Internal | on | Executors injected into the game process itself. |
Types.BlockInput | on | Tools that swallow normal player input so the cheat menu can take the mouse. |
Types.External | on | Executor programs running outside the game and driving it from there. |
Types.Bypass | on | Known techniques for hiding from the checks above. |
Types.Spoofed | on | Executors that spoof their identity so they read as something legitimate. |
If you want the whole set on and banning, that is the default and there is nothing to change. Written out, it is this:
"AntiExecutor": {
"Enable": true,
"Action": "ban",
"Types": {
"Internal": true,
"BlockInput": true,
"External": true,
"Bypass": true,
"Spoofed": true
}
}You do not edit that file. Protection Rules is where these switches live, and the copy in your resources folder is never read.
Reading a hit
Every Anti Executor ban or kick carries the type that fired, and some also carry a method number. The reason line is the fastest way to tell a stack of these apart, so it is worth knowing which type each one belongs to before you start reviewing them.
| Reason | Type | Method |
|---|---|---|
| Internal cheat detected | Internal | 1 |
| Internal cheat detected (2) | Internal | 2 |
| Internal cheat detected (3) | Internal | 3 |
| External cheat detected | External | - |
| Block input cheat detected (1) | BlockInput | 1 |
| Block input cheat detected (2) | BlockInput | 2 |
| Block input cheat detected (3) | BlockInput | 3 |
| Block input cheat detected (4) | BlockInput | 4 |
| Executor detected (E1) | Bypass | - |
| Executor detected (E2) | Bypass | - |
| Executor detected (L2) | Spoofed | - |
See Reading a detection for where the type and method appear on the row.
Narrowing down a false positive
If Anti Executor is quiet, leave it alone. If it is not, the fix is almost never to switch the detection off, because that drops five checks to deal with one. Work from the reason line instead.
Read the Type on the rows you do not believe and turn off that one type. The other four keep running, and you have narrowed the hole from the whole detection to one check. If the rows disagree with each other, set Action to kick for a day and read what comes in before you change anything else: a kick costs a legitimate player a reconnect, and it keeps the evidence coming.
What not to do: do not turn all five types off and leave Enable on. It has the same effect as switching the detection off, and it reads in the panel as though something is still watching. Switch Enable off and be honest about it, or keep the types you trust.