how do you stop exploiters from executing dark dex
a local script cannot access CoreGui, where dark dex is located
I have tried multiple methods such as:
game.CoreGui.ChildAdded:connect(function(p1)
if p1:FindFirstChild("PropertiesFrame") or p1:FindFirstChild("ExplorerPanel") or p1:FindFirstChild("SaveInstance") then -- Dark Dex frames/children
Kick("Dark Dex")
end
end)
You don’t. Exploiters could just name the stuff random names, which I think they do already. If not, they could take it a step further and use external drawing api, which a certain exploit program has built into it already. So it wouldn’t be in coregui at all, therefore undetectable.
Don’t patch the GUI, patch the exploit. If dex is helping them ruin your game, find what they are ruining so you can fix that.
Dark Dex is usually run on Synapse X, and they change their program name about every 3 hours.
Example: ghaThcey8548fhu to usehifduih874%#hfd
As @incapaz said, exploiters have the ability to check places such as workspace, lighting, replicatedstorage and so on. You should make sure everything they can see there cannot be abused in any way (usually refers to remotes).
Sadly you can’t access CoreGui.
Another thing is, even if you could access CoreGui they can just detect if you have an event connected to CoreGui and disconnect it, or view the function it does.
Anything on the client, the hackers have access to.
You can use a script to detect specific properties or items from a dex gui
i have thought of a method.
using game.DescendantAdded and check where it isn’t at. What I mean is this:
game.DescendantAdded:Connect(function(descendant)
if descendant:IsA("ScreenGui") and descendant.Parent ~= game.Players.LocalPlayer.PlayerGui and descendant.Parent ~= game.StarterGui then
game.Players.LocalPlayer:Kick("ngl that screengui in coregui is sus")
end
end)if this works, this can also possibly stop Infinite Yield, which also places a screen gui in coregui, and works regardless of if a spoiled skid renames the explorer too.
As others have said, there’s really no point in attempting to detect anything in CoreGui as it can be disconnected or avoided altogether by using another location or method that a LocalScript can’t reach. Client-side anti-exploits are nearly pointless. While it may catch a lot of common exploiters at first, the scripts can easily be rewritten to completely bypass such checks. A temporary measure isn’t worth the effort. If you’re going for a client-side anti-exploit, it should only be in addition to an already existing server-side anti-exploit.
Tl;dr:
It’s pointless. Never trust the client.
@incapaz is right with this one, if you are targeting one form of DEX being a Gui they will simply do it another way.
You would be better off addressing the ability to change workspace rather than the means. At the end of the day if your scripts are secure it wont matter if they can see what’s in the workspace.
All of which should be done on the server side of things.
Detect where a module is running from, if a module is running on the client then ban them on the spot.
Use pcalls on remote events, this way if they cause certain errors or fire it with nothing you know they are exploiting.
Put player inputs into values that are read by the server to take the client out of the equation with most scripts.
sadly as much as we all hate to admit, that’s just the basics. Hackers constantly try to find ways to bypass our checks. While we, just say “this anticheat is fine”. I get it you guys want to save us time. However take the roblox staff team for example. We call them very incompetent people, but in reality they constantly race with exploiters. Patching executor injection while exploiters find ways to bypass the injection checks.
This is also a reason why exploiters constantly outclass us.
2 problems:
bruh. You don’t even try to see that there is a solution to both problems
for the first problem, you use a server script to detect if the local script gets deleted (with DescendantRemoving), and kick the player who deleted the local script using [insert parameter here].Parent.Parent:Kick()
for the second problem, i don’t know how, but a group of people found how to access the coregui using very hacky ways to access it. I myself have thought of a way to access the coregui (i haven’t test it but I’m confident it can work)
You should have included that in your method.
What is the way (if you don’t mind telling us?)
What is the way (if you don’t mind telling us?)
well a way I thought of is to instead of finding if it is parented to coregui, I find where it isn’t parented to (in this case not the playergui nor the startergui) so I came up with this local script
game.DescendantAdded:Connect(function(descendant)
if descendant:IsA("ScreenGui") and descendant.Parent ~= game.Players.LocalPlayer.PlayerGui and descendant.Parent ~= game.StarterGui then
game.Players.LocalPlayer:Kick("sussy coregui thingy there")
end
end)Have you tested it in Studio? It seems like a promising solution but… it’s unlikely to be that simple
i haven’t the time to test it though, but i would once i have the time to
If an Instance is protected by Roblox, you cannot do anything with it, not even call any methods associated with it (example, :IsA). You may try it in Studio if you wish.
i will say this though, quite a few people found a very hacky method to detect if a thing is in coregui, which helped them detect dex. Not just dark dex, all but one version of dex
prob just me but i find it sickening that if most people can’t do it they assume it’s impossible