Cheat Engine Executor Prevention

Resources Community Resources
#88

It’s been so long since I’ve used exploits but the stack overflow can pretty much be mitigated with a if not checkcaller() then. As for parenting the player to nil, I can just hookup a __newindex hook and use string.sub to remove those null-terminated strings and just use error or use an empty dummy function as opposed to using old.

key = string.sub(key, 1, (select(2, string.find(key, '\0')) or 0)) -- will pretty much remove everything after \0

Also we can also remove the :lower() call for getnamecallmethod() to prevent that pcall check. (Since, unlike RemoteEvents/RemoteFunctions, you can return nil IIRC)

2 Likes
#89

Ok bro what the flip are you waffling about

1 Like
#90

Sorry for the bump but my god a ton of you don’t know how cheats work.

Firstly, level 8+ executors do not exist. Script context levels range from 1-7, not any lower or higher. Your average run-of-the-mill executor will have a script context level of 6, with only some high-degree exploits providing the mythical level 7 execution level. The executors that do have level 7 execution level most of the time limit a large range of features provided because the big difference between level 6 and level 7 is mainly just account control, such as sending friend requests, unfriending players, following/unfollowing, etc.

Secondly, anti-cheats are made to out-maneuver the cheater and provide road blocks; they are made to be deterrents. Trying to make an anti-cheat to block an executor entirely is just shooting yourself in the foot.

Thirdly, cheat engine executors are so far fetched that there’s literally no point in making anti-cheats for them. They can break if you breathe on it the wrong way, and they have never been very stable.
Cheat engine is written with Lua, but that doesn’t mean it goes hand-in-hand with Roblox.

Lastly, for those cheaters who don’t skid half their scripts, hookfunction and replaceclosure are good methods for bypassing anti-cheats for when you know where to look, but they are not the go-to. Simple traceback and methods such as PluginManager(), game:GetService("CoreGui").Name, error(), debug.traceback(), debug.getinfo(function() end) are all ways to counteract this. You need to use functions to set the thread identity to a lower level to pass all of these checks and half the time doing this will result in a crash. Setting your execution identity does not hide it from traceback.
Krampus has functions such as setthreadcaps and setclosurecaps, however these are notoriously very unstable.

Hooking on the game metamethod is also spottable as well. The time it takes for a simple __index and __newindex can be monitored and be easily caught when it suddenly consistently spikes up in execution time.
Lua C values, memory size, memory allocation in/out + bandwidth, are all fields affected after injection. These happen regardless of outside variables because the executor has to inject somehow, and hooking on these fields and meticulously filtering out bad actors is not practical and very slow.

4 Likes