Dex exploit detection script?

there was recently a post from someone which showed a way to detect that dex exploit everyone’s using these days. However I can’t find it anywhere on the forums anymore. So if someone still has a link to it, that would be great!

6 Likes

Any detection script can be easily overridden (some exploits nowadays even run scripts on their own when injecting so the user doesn’t have to think about it). Why do you need to stop Dex?

4 Likes

Dex gets placed into CoreGui through the exploit.

I saw a post of someone also asking the same question, and one of the comments mentioned game.DescendantAdded. I made a script a bit ago and it has been catching people using DEX for quite a while. There are unique children named stuff you probably wouldn’t put in your game such as “SaveInstance”. I made a script that detects if 3 of these oddly named children are added to CoreGui or PlayerGui, it will print that it found dex and you may proceed to do whatever action you desire. Although exploiters can delete this local script, you can have 2 scripts to watch each other’s back to make sure they don’t get deleted. The exploit will delete one script before another if they delete them both and you can have it report to the server that one other script was deleted. This is some basic advice to help you with some possible workarounds exploiters may have for this I hope this reply helped you, and the code to find dex is below. I would prefer if you would not share this method with many people as it has an easy workaround for the creators of exploits, and they could possibly patch it.

local BlacklistedGuis = {
	Dex = {
		'SaveInstance';
		'CallRemote';
		'ScriptEditor';
	};
}

local BlacklistedFound = {} --Blacklisted items found

wait() --Wait for game to load. Exploits cannot inject this fast so there's no worries.

game.DescendantAdded:connect(function(a)
	--//We will use a pcall to get its name, you can only string an object for its name if it's in CoreGui.
	local suc, err = pcall(function()
		local n = a.Name
		if n then end
	end)
	
	if err then --Must be in CoreGui because it errored out due to the security level
		if tostring(a) then --If we can find the name of the inserted object.
			local Name = tostring(a)
			
			for ExploitName, Values in pairs (BlacklistedGuis) do --Go through blacklisted guis to see if this matches one of their children.
				if not BlacklistedFound[ExploitName] then
					BlacklistedFound[ExploitName]  = 0
				end
				
				for Index, GuiName in pairs (Values) do 
					if GuiName == Name then
						BlacklistedFound[ExploitName] = BlacklistedFound[ExploitName] + 1 --We found a possible child of the exploit, we will search for some more though.
					end
				end
				
				if BlacklistedFound[ExploitName] >= #(Values) then --If we found all of these inside of CoreGui, they must have dex.
					BlacklistedFound[ExploitName] = 0
					
					print("Thanks for using "..ExploitName.."!") --We have found our blacklisted GUI! In this case, DEX!
				end
			end

		end
	elseif a.Parent == game.Players.LocalPlayer.PlayerGui then --Some people like it inside of PlayerGui.
		if tostring(a) then
			local Name = tostring(a) --This is its name, just being consistent.
			
			for ExploitName, Values in pairs (BlacklistedGuis) do
				if not BlacklistedFound[ExploitName] then
					BlacklistedFound[ExploitName]  = 0
				end
				
				for Index, GuiName in pairs (Values) do
					if GuiName == Name then
						BlacklistedFound[ExploitName] = BlacklistedFound[ExploitName] + 1 --We found a possible child once again. 
					end
				end
				
				if BlacklistedFound[ExploitName] >= #(Values) then --Oh hey look we found dex.
					BlacklistedFound[ExploitName] = 0
					
					print("Thanks for using "..ExploitName.." inside of PlayerGui!")
				end
			end

		end
	end
end)
15 Likes

Unless they intercept this whole structure by targeting the remote they invoke instead.

1 Like

That is true, there is no perfect fix for everything. This is just a start but I’m sure you could do something like change their walkspeed and when the server sees that it will ban them if you set it to a very specific walkspeed.

Don’t think that would really work since the newer dex versions have randomized names, you should consider detecting ANY new guis in coregui and check if the name is of a gui that’s supposed to be there and kick the user if the name isn’t of a gui that is supposed to be there.

Any new version of Dex Explorer (v4+) have a randomized name, making this impossible.

On a side note I believe you can completely block injections (like Bloxburg did) by tracking client memory.

1 Like

Pretty sure Ripull posted something about this on his twitter page. I am not 100% sure though if it was Dex, and if it was it wasn’t a detection script, it was simply giving the developers all the code to the exploit to prevent exploiters from using it, but then again exploits are frequently updated.

This is something that gets the children of DEX. The dex itself may be random, but there are components inside of it that are named what is in the table. If it finds the 3 suspicious names that developers most likely don’t have in their game, there is most likely a dex or an exploiter inserting instances named this.

2 Likes

I like that suggestion, but that would take a lot of tracking because I would have to find all possible CoreGuis and all their descendants, I will think about doing this in the future if this becomes unusable. As to the random names, it only randomizes the GUI name, not all the frames inside of it.

ah, gotcha, I mean, isn’t it possible to only detect the parents? aka the actual ScreenGui objects?

Using DescendantAdded gets all descendants added to the game. This is every single object added including all the buttons and SelectionBox. Unfortunately, you must tostring it to see the name and cannot see anything else about it. I believe you’re thinking of ChildAdded which would be on CoreGui, and we cannot do that.

ahhh, okay, thanks for the clarification.

What exactly do you mean by “tracking client memory”? Also, not all DLL injections are bad–products like Discord and Fraps inject DLLs.

It’s possible to detect any exploit in injection but some methods are super unstable

By tracking client memory he means by watching for spikes in memory usage since exploits use memory when they inject. Since roblox has spikes in memory a lot or some games in general use a lot, this can be unstable and lead to false detections.

3 Likes

Don’t look for “Dex”. Don’t waste your time trying to look for and destroy this. Dex is just a simulation of Roblox Studio on the client and it’s the same as an exploiter running code in your game. Make sure your server is secure so that exploiters can have as little impact on other players as possible. Your problem thus becomes solved.

3 Likes

90% of the time there will always be pesky vulnerabilities, and those are found with the assistance of dex almost 100% of the time.

The response does not change. Exploiters can run code and see your hierarchy all the same. Dex is merely a visualisation of the game’s hierarchy as far as the client is able to read. It is your job as the developer to secure your server and minimalise the amount of opportunities that exploiters can leverage to affect the game.

6 Likes

Interesting to hear that the new DEX has randomized names. I created this a while back ago when challenged to detect items being added into CoreGUI which might be useful for anyone looking into actually getting it working into perfect shape. The current issues are found when going into the menu which I attempted to write a couple quick checks but was not able to find anyway to detect the second set of menu items which are prompted after clicking the selected option (Reset > are you sure you want to reset etc…) This should be able to detect the client adding things to the CoreGui by using the errors which will pop up and lags anyone who adds DEX into the game since it is looping through all 1800+ items which are added. Might be useful to someone so I figured Id post my two cents. This will not be a failsafe but definitely will help in preventing some of the less advanced players from exploiting.

game.DescendantAdded:connect(function(decendant)
	print(decendant.Name)
	print(decendant.Parent)
end)
local Players = game:GetService("Players")
local player = game.Players.LocalPlayer
local UserInputService = game:GetService("UserInputService")
local GuiService = game:GetService('GuiService')
local EscPressed = UserInputService:IsKeyDown(Enum.KeyCode.Escape)

local function onCharacterAdded(character)
end
 
local function onPlayerAdded(player)
	player.CharacterAdded:Connect(onCharacterAdded)
end

local playerjoined = Players.PlayerAdded:Connect(onPlayerAdded)

wait()
while wait() do
if GuiService.MenuIsOpen == true or EscPressed or playerjoined then
    wait(1)
else if GuiService.MenuIsOpen == false then
    game:GetService("ScriptContext").Error:connect(function(message, trace, script)
    if message == ("The current identity (2) cannot Class security check (lacking permission 1)") and script.Name == "" then --checks which script has given the error
        print(script:GetFullName().." CoreGui Detection")
        print("Reason: "..message)
    game.ReplicatedStorage.KickEvent:FireServer()
end
    end)
 end
end
end
5 Likes