The main use of this was for a local CoreGui detection for any malicious GUI’s trying to be added by exploiters. It worked before, but it randomly broke yesterday for no apparent reason. Now it returns the same error as trying to get .Name of it.
My question here is, is there any other alternative for doing such thing? I don’t care how hacky it is, I just want a method that works. And if not, should I even bother with this? I mainly did it to prevent ESP’s and Dex from my game, which seem to be the most prevalent.
The replies in the thread I linked to address this. Basically, you’re better off not doing this at all. It’s more beneficial in the long run to just assume the entire client is malicious from the start.
You’re right, but that still doesn’t change the fact that detecting malicious CoreGuis can be effective against script kiddies who don’t know how to bypass such checks. And from my knowledge, even some front page games such as Dungeon Quest were doing it (until the recent update).
And even if we put CoreGuis away, there are many other things which require the use of tostring() on robloxlocked instances.
My friend for example was checking for the presence of NameHealthContainer using tostring() in order to delay his TopbarEnabled SetCore until it was added, to workaround some topbar issue he has been experiencing.
I know I’ve seen many threads that say “Never trust the client, just focus on securing the server-side scripts and remotes.” But after we do this, then what? Over 95% of exploits are all client side anyways, so we’re not achieving much to begin with. That’s where client-sided exploit detection comes into play. Over 95% of exploits are based around GUIs added to CoreGui, and it’s not too hard to detect them. If exploiters have the power to even be able to read basic properties of CoreGui descendants, then I think developers should as well. Of course, no game can be 100% exploit-proof, but it’s better off making the game more secure from the script kiddies that grab free exploits from websites. Removing the tostring() reliability for detecting malicious GUI’s just made exploiting like this even easier.
You do nothing after it. If it doesn’t affect your game, there’s no point in pursuing it. It just serves as simple gratification that you’re able to stop casual exploiters who don’t bother to breach your game’s security further. Client-side exploitation detection can be circumvented, it’s their own device, irregardless of what after-factors are involved.
Unsubstantiated.
That’s where potential security issues come into play. There’s also no real reason for us to interact with the CoreGui aside from the API that’s exposed to us. We don’t really need to access any internals either (for example, there’s RobloxReplicatedStorage).
The difference between why exploiters can access it and why we can’t is because they’re exploiters. Their code runs at a higher permission level than developer scripts (Scripts/LocalScripts/ModuleScripts). It’s not that they’re given access, they give it to themselves.