How do you detect dark dex?

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):
Screenshot 2021-07-11 at 8.14.55 pm

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 :ChildAdded on 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:

  1. Looking for dexs objects that aren’t in core GUI (recommend)
  2. Find first child (eh not that good but still ok)
  3. Memory checks ( work well but is NOT recommended for big or medium sized games)
  4. Looking for dev console errors ( not recommended)
  5. 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

This is entirely useless, as exploiters put it in CoreGUI which is inaccessible and locked.

1 Like

Actually a lot of the regular ones that don’t do too much is put in the clients GUI
While yes a few of the elite ones are stored elsewhere, with that simple code you can stop a good portion of them.

Rather than check if the gui is ran or not, u should check what data it reads. I’m pretty sure dark dex is detected with metatable tampering, and not with gui parenting in most cases.

Either way, detecting metatable tampering is a lot more efficient, cause gui parenting can be bypassable.

CoreGui won’t allow you to check for dark dex. If there are ways to detect it, then you should research on that. I don’t think a lot of people know how to do this, so you’re out of luck.

This is an server-side version of Dex designed to be used on SS executors/script builders, it normally parents to PlayerGui, the LoadData remote is for server-client communication, you cannot use require(assetId) on the client as no executors bypass that.

(I know all of this because I used the exact same thing and modified it aswell)

1 Like

I’ve actually got someone to test dex with synapse in my game (does not use memory checks)

You have many posibilities to do stuff as a developer. Detecting exploits, UIs or even scripts is very possible (you can even get the constants from their script and remake it if you’re smart enough)

12 Likes