We must first begin by how _G and shared are actually stored; on initialisation, the scripts’ environment gets set to a sandboxed version of the main thread. Then, Roblox sets the _G and shared global on the thread. This means that the variable is present only on the current thread, but not on the table that we are proxying. However, executors now a days are somewhat careless and have grown used to pushing these two globals into the global environment of the main mainthread without care.
while task.wait(1) do
_G = nil -- Remove _G from the current thread environment
shared = nil -- Remove shared from the current thread environment
if _G or shared then -- If the global is somehow present, then it means that we obtained it thanks to it being proxied via the roblox global environment (which should not contain it!)
print("Executor detected") -- Detected gg.
end
end
You can think of this as the way we do OOP, because this is essentially it: if the field is not on the table we index, it will search the table it proxies (the global environment), and because it is present, it will return that. Because of this, you can detect some executors this way, such as AWP.gg, before it was patched.
Exploits such as Zenith, Swift and Potassium suffer from this issue; however, it is only observable after getrenv() has been called at least once, since then they push the globals to the environment. I still don’t understand why they only do it after calling this function, lol.
Clientside anti-exploit scripts are not reliable. The best anti-exploit methods are written on the server and are done by following the golden rule of “never trust the client.”
Nothing stops exploiters from just removing that code from their client upon injection.
Reliable exploit detection is almost impossible to implement. Just as a game can be exploited, those exploits can also be detected.
However, having some kind of exploit detection is always better than having none at all.
Server-side detection isn’t always reliable either, especially when it’s based on player movements or similar patterns. This becomes even more of a problem since most exploits happen on the client side, making them harder to track and prevent.
What you say is true, but you have to understand client side security is still important, server sided detection cannot detect cheats that aim to imitate skill, such as aimbot, the server just can’t, rely in having the client send his angle every frame, it would also be incosistent because latency exists and it would lead to a lot of false positives.
Also client sided anti cheat works best on paid games, since an exploiter can’t just come back on an alt, they have to buy the game again, so you are proffiting off every failed attempt they make at cracking your anti cheat.
I good use I found for client sided anti cheat is for my private test place, since testers can’t always be trusted, if they attempt to use cheats to leak or steal parts of the game, they instantly get banned and demoted.
“Yay i love trying to prevent new developers from getting their game hacked”
please let new devs get their game hacked, it’s funny to me (i am and never was a developer, i am an exploiter myself stop ruining our fun)
Exploiters can easily spoof that. They have the ability to modify anything on their client. They can simply just remove the “clientside anti-cheat” while keeping the heartbeat alive and telling the server that they are a legit client.
The only reliable anticheat is by verifying everything on the server.
That’s where manual review comes into play. Even games off-platform with excellent anticheats (even clientside anticheat, mind you!) still struggle heavily with aimbotting. There is no “one size fits all” solution. There will always be a necessary combination of serverside anticheat with manual moderation review for Roblox games. Clientside anticheat is too easy to bypass and leads to a false sense of security.
Yes. Anything that is replicated to the client (the ingame world, localscripts that the client is executing, etc.) can be fully viewed, ripped, or modified. That’s why it was so common to see full rips of games before FilteringEnabled was forced.
