So why does he talk about looking for objects that arent in coregui right now? He said that theres folders that u see dex put in the game like Dex Output and such.
Dex creates “Dex Output” in game and another folder called “Dex Storage” in nil, etc. Those could be used as detectables.
1 Like
Hm, well when you go into game and try to print its location, you’ll get the nil instance folder location issue. His way sounded great but…isn’t the right way.
A summary: dark dex cannot be detected and even if it could it would be patched easily resulting in a waste of the developer’s time.
1 Like
Hm? Um, no this game has 3.5k people playing right now and they detect dex perfectly without any failure: [READ ME] Football Fusion - Roblox
1 Like
Are you sure it isn’t using unreliable systems such as memory. Also, it can be easily bypassed.
It is impossible, trust me. I’ve tried every method I could think of for an anti cheat system, Roblox locks CoreUI’s, so you cannot use :IsA(), type(), etc. You could check the descendants name, but that doesn’t work for newer versions as exploits make their names random.
Anything locked cannot be called as the Client Identity Level is 6, Roblox is constantly patching methods of accessing CoreGUI, the reason for them doing this is because malicious game devs were able to disable the Leave buttons and make their game impossible to leave short of shutting down your computer.
1 Like
That game uses Memory, which is patchy at best and stupid at worst. Never use client memory for an anti exploit check as it is easily bypassed and pointless, at worst it may even ban innocent players.
1 Like
Huh… you just click X on top right instead of leave button.
1 Like
saddly roblox patched findfirstchild from reading core gui like 2 weeks ago.
They are using memory checks. I bypassed it in like 10 seconds. And it does false positive sadly but yes it works on less experienced exploiters, but I still recommend looking for dex’s other properties with in the game that are not in core gui.
The real reason why Core GUI read-access was disabled is because devs could punish players for reporting the game. Give regular scripts permissions to read Core GUI - #8 by ConvexHero
1 Like
Yes they can also scam players and make them buy things with out their knowing like this:
1 Like
This was patched so this is no longer the case.
1 Like
Yes I know it was patched I’m just giving an example.
4 Likes
Also this wasn’t accessing the core gui but rather it was overloading the Roblox gui system.
My methods of patching Dark Dex are pretty much the worst you could imagine: Searching for memory spikes from a LocalScript. However, it does 100% kick the player every time Dark Dex is opened, with an average memory spike of 23MB using the Stats:GetMemoryUsageMbForTag() method.
Alternatively, I’ve done my research a month or so ago and scoured through YouTube videos of people using Dark Dex and found a require script to be able to use It with the DevConsole: require(3010581956):Fireplace("yourusernamehere")
With this, you can now paste it in the DevConsole and a non fully-functioning Dark Dex will appear. (Now I’m not sure if this Dark Dex is up to date or on a different version, but we’ll work with this.)
When I first required it, I wandered around the explorer and saw a gui named “Dex” in my PlayerGui. Strangely, it wasn’t in CoreGui, probably because that only happens when injected with an executor. Then I found a RemoteEvent named LoadData in ReplicatedStorage. And if you switch to the server there’s a script named ResponseSystem in ServerScriptService. I then looked inside its code and found that it replicates functions from the client to the server (group/delete, etc on server):
Patches I made: (Please let me know what you would do instead)
- Having a server-sided anti exploit to run
:ChildAdded()into ReplicatedStorage and ServerScriptService to delete LoadData and ResponseSystem. - Doing a
:ChildAddedon the PlayerGui for anything named “Dex” - Did a memory check (catches Dark Dex but does return false positives, I suggest to not do this)
If someone here has already mentioned a better solution or would like to give me tips, please let me know as I didn’t read the entire post’s replies.
6 Likes
Bro, exploits only run on the client so you can’t have a “server-sided” anti cheat for this kind of stuff.
Dex 80% of time uses game.CoreGui or game:GetService("CoreGui") not game.LocalPlayer.PlayerGui
I did this and it works but also kicks you for no reason, so if your game has this no one will play it lol.
Here’s how I detected dex:
- Looking for dexs objects that aren’t in core GUI (recommend)
- Find first child (eh not that good but still ok)
- Memory checks ( work well but is NOT recommended for big or medium sized games)
- Looking for dev console errors ( not recommended)
- Mouse detection ( works well but I wouldn’t use it because of false positives )
And it still works to this day.
3 Likes
You can’t. Things like synapse do a very good job at protecting against that.
This is the simplest solution that i could come up with. as soon as something is added to the players UI the local script deletes it. Also this needs to be a local script in starterPlayerScripts
wait(1)
script.Parent.Parent.PlayerGui.ChildAdded:Connect(function(new)
new:Destroy()
end)one of the downsides to this though is that you cant have any ScreenGui’s added to the players UI
1 Like