One thing you have to always remember is malicious users will always have more control over the local environment than you do, period. Your security model should prioritize what you can prevent on the server, as literally anything you do on the client can be bypassed.
This is not to say you should never do client-sided detection, there are scenarios in which client-sided detection works. For example, logging malicious use for X period of time then banning all users who were logged - this can catch developers who fail to check remotes and it can be surprisingly effective.
Your solution to removing GUI’s can be bypassed in a few ways, here’s two.
1:
Parenting their GUI’s to CoreGui a service which you cannot access. It is already common practice in the exploiting space to use CoreGui over PlayerGui for things such as ESP and HUDs
2:
Using a custom functions present in most exploits called getconnections() and disconnectall() which can be fed a signal and disconnect all attempts to listen to it. For example in your case an exploiter could simply do:
for _,signal in next, getconnections(game.Players.LocalPlayer.PlayerGui.ChildAdded) do
signal:Disable()
end
Finally your theory on targeting unskilled exploiters is flawed - the thing is the majority of people whom exploit are getting scripts from experienced users, so targeting your methods of prevention at the small amount of individuals who are both incompetent at reverse engineering and making scripts is really pointless. Cause the overwhelming majority of people exploiting on your game will be using a script likely developed by people who are proficient and have included a bypass in their public script.
this was possible a while ago, until roblox removed the abillity to use tostring() on RobloxLocked instances, now we dont have a single way to detect instances being inserted into CoreGui etc.
That logic is flawed, the server doesn’t have any access to the common places of localscripts (PlayerScripts and PlayerGui) and even if it did, the deletion of the script would not replicate to the server
Slight correction - the server does have access to these areas. The second point of your post is correct however, the deletion would not be replicated to the server at all. Only server-changes replicate across the boundary. Outside of the physics, etc.
It’s not necessarily that it’s easier to use, it’s that developers can’t access CoreGui. By an exploiter putting their Guis in CoreGui, the developer is unable to remove them. In the off chance that a developer creates a client-sided anti-exploit that an exploiter is unable to stop, they can at least stop the removal of their Gui by putting it into a container which is access-locked for developers.
If I cannot access the CoreGui, why in the WORLD is the client able to access it? Hiding things that we developers cannot see but the client of all people can? Is there a reasoning to this, is this just stubbornness, or am I missing something?
Old thread but it has been bumped recently so I might as well contribute to an unasked question on the post.
Your ability to access certain things is based on the environments Context / Identity level. For example, the command bar can index game.CoreGui, however, a localscript can not. The exploits just have elevated contexts that allow them to index what a normal LocalScript can not.
You can view the identity level of the current environment by calling the printidentity function.
Using this you can see console has an identity level of 4, whilst a LocalScript has a identity level of 2.
The CoreGui contains stuff like the topbar and the escape menu.
The main reasoning for not giving developers access to it is that bad actors could spoof/remove some important things, such as the report tab in the escape menu or the leave game button.
they should atleast allow us to index the descendants of coregui, while not editing them.
that’d basically eliminate any ui based exploits, that put their ui’s in the coregui.
this used to be possible, before they patched that. (cough tostringing robloxlocked instances)
That way was more of a hack, and it doesn’t really help either. For example when the new devconsole was added, games with CoreGui checks detected it as a foreign gui.
Also, some exploits are able to create a virtual CoreGui and parent guis there, while other can use ImGui to draw custom windows on top of roblox without interacting with the game’s “universe”, so there is no point for roblox to bother adding any way to list CoreGui children. Especially since those methods could be hooked and spoofed as well (just like tostring() was by exploits changing __tostring).
Really if you can access the core gui with this command
this is what hackers do to install in the core gui, what if you use this command to install an anti exploit in the core gui you could
That’s not accessing the CoreGui though, that’s just setting the parent of something to it. That’ll throw because developer code doesn’t have a sufficient enough security level to access it. Exploiters can do it because they have their code set to execute at the highest permission level.
You can’t accomplish this. Even if you could, not worth it. CoreGui is client-side and exploiters can modify anything client-side.
I don’t think that’s necessarily the case, to be pedantic about it. It’s not big or mysterious or anything. They simply have the capability to pass code to the compiler and have it run the same way other local code runs. Just the executed code has a different security context level.
