some exploits/guis uses external interfaces, one example is RcM (a global ESP/aimbot)
if they are programmed in C++, they are probably using ImGui (an opensource C++ gui library)
A script will keep checking the local script so there wonât be need for remotes
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
2 Likes
Imma test and try to find another way if this doesnât work. Get back to ya in several half hours.
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.
1 Like
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. 
A lot more (and probably more accurate) information can be found on this devforum post. A Current Explanation of Normal Identities and Security Tags
2 Likes
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.
The truth is that you are right, since they use libraries that give them âadministrator permissionsâ to say it in a way
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.