ignore 100 million characters okay
25 Likes
Awesome, can’t wait for this to be patched in a day!
16 Likes
There’s not a permanent patch for this, its an old method and has been out in public for a while.
4 Likes
And for proof it being out in the open, here is proof. How do you detect dark dex? - #487 by Mystery_Devx
6 Likes
Very cool! but you shouldnt open source these stuff because soon dex will notice it and patch ir
3 Likes
Read my replies above. Theres a script almost exactly like this that has been out for 5 months.
1 Like
yeah but u putting it in resources will make the chance more likely for dex to notice
it basically detects almost every single gui so yea, good prevention of coreGui exploits
2 Likes
If a script like that has been out for a while out like that, some people wouldve told 3ds and he wouldve noticed. There might not be a permanent patch to this as there are still other things you can look for when executing dex.
1 Like
Why do you release it again if it’s already released?
1 Like
The original reply takes a bit of time to find, I just added a few changes to the script and posted it in Community Resources
Thats not entirely true, this method relies on finding a file called “DexStorage.rbxm” but exploiters can just not set the gui in the coregui, they could set it directly to the players gui.
There are also drawing libraries that don’t use GUIs, but instead actually draw things to the client, making them quite literally undetectable. I’ve seen GUIs that rely on this library before and to my knowledge you can’t patch them.
2 Likes
This is already a public method btw, this is nothing new. Also it wont get immediatly “patched”, but exploits can have custom scripts that bypass this.
1 Like
include this to make sure there are no false detections.
GetService=game.GetService
local GuiService = GetService(game, 'GuiService')
GuiService:SetInspectMenuEnabled(false)
while wait(2) do
GuiService:SetInspectMenuEnabled(false)
end
this script may also flag false detections with backpack items (tool icons)
1 Like
Ah, that’s why literally nobody uses this script: It’s completely pointless and can be defeated instantly.
Local scripts can have :Destroy() run on them and bam, they no longer work. Doesn’t matter if you parent them to nil or not, as any self respecting exploit has a multitude of ways to get nil instances (the most popular one literally having getnilinstances() which returns a whole table of them.)
for i,v in pairs(getnilinstances()) do
if v:IsA("LocalScript") then
v:Destroy()
end
end
So much for “somewhat secure” considering you shouldn’t be putting stuff in nil anyway.
3 Likes
I inserted it into ReplicatedFirst and there seems to be an infinite loop of detections.
1 Like
This method of detection isn’t very secure anyways and bypass methods have already been available for months now afaik.
1 Like
I worded my first reply poorly because I wasn’t educated on this as much as I thought I was. I’ll take this L and admit I got that part wrong.
However, to get around this (as well as loop parenting it to nil) the user can at the very least just do two task.spawn()s, one which loop parents it to somewhere else and the other which loop attempts to destroy it.
If it does it fast enough, which it likely will at some point, the script will be gone. Sometimes just straight up brute force is an effective method.
Regardless of the pcall, if the client sided kick is disabled you straight up can’t kick client sided. To get around that you need to fire a remote or activate something which can again be disabled/blocked from firing.
Scriptware has a hidden gui function that places it in a protected area that cannot be touched by these types of detections. Synapse currently has a function similar to that, but it doesn’t do the same thing. However, Synapse is gaining this same functionality soon.
1 Like
its patched exploiter can just hook PreloadAsync
Edit:
There’s have way to prevent exploiter hookfunction
3 Likes