Anyway to access CoreGui or any method to prevent Exploit injectors

Help and Feedback Scripting Support
#1

Hello, me and my friend have been doing research for hours on how to access CoreGui to prevent Exploiters menus from being inserted.

Is there any possible method of detecting if a Injector has been inserted with or without CoreGui being used?

Thank You, Zonix.

4 Likes
#2

Exploits tend to be unpredictable to an extent, try researching one exploit and see if it’ll cause any issues with other exploits.

1 Like
#3

Me and my friend are working to prevent Dark Dex and how it seems to work is that it gets put into CoreGui.
It doesn’t seem possible to prevent to our knowledge.
Any help with preventing Dark Dex would be appreciated.

#4

After a quick read (like 20 seconds, bash me if you want) of CoreGui, a theoretical solution is to listen into its events. However, it requires a localscript, and we all know what happens with those and exploiters.

I haven’t ventured far enough into popularity to be handling exploiters on a regular basis, but I have read this and found it useful for other reasons.
Exploiting Explained - Resources / Community Resources

2 Likes
#5

You simply can’t since anything in Core gui is RobloxLocked meaning you can’t read any properties to check if it’s an exploit also some exploits use nil rather than CoreGui.

1 Like
#6

So there is almost no real way to detect them and prevent them then?
If so that’s really annoying.

#7

Executors like Synapse use NoByteCode and they place scripts in nil so there would be no way for you to detect it, though there was one way this month (The owner patched it quickly) Basically you detected “NotificationFrame”

1 Like
#8

You can make it if a child is added to CoreGui or PlayerGui to see if they are using a exploit or some.

#9

Roblox just patched a huge number of exploits. And patched them good. But te developers are already working on unpatching them.

(Sorry for bad spelling im typing this on my phone)

3 Likes
#10

I’ve tried this but as devs we can’t check if children are added to CoreGui for “Security Reasons”

#11

Actually you can patch dex, the issue is there are 4 different types.

version 1 and 2 are easy to detect and lucky for us dex v2 is the most popular. However dev v3 and v4 are virtually impossible to detect but this might help…

-- Anti Dex & other exploit guis for unprotected guis that are not parented to core gui...
if game:IsLoaded() then
wait(6) -- so we dont get kicked right off spawn
local plr = game.Players.LocalPlayer
local gui = plr.PlayerGui

game.gui.ChildAdded:Connect(function(child)
if child:IsA("ScreenGui") or child:IsA("Folder") then --checking for guis and folders
wait(1.5) -- so nothing goes wrong
plr:kick()
wait(10)
print("Player is still in game, possible bypass detected")
gui:Destroy()
                end
          end
    end)
end

This one will work for dex 1 & 2 The other 2 versions are virtually undetectable but this may work…

while true do  -- keeps it in a loop even though the findfirstchild is recursive just to be safe
	wait(5) -- DONT MAKE THIS ANY LOWER IT CAN LAG THE GAME!
	local dex = pcall(function() game:FindFirstChild("Dex Output" , true)
		if dex  then 
			wait(1)
			game.Players.LocalPlayer:kick()
			wait(10) 
			print("Player still in game, oh so your still in the game huh?")
			game.Players.LocalPlayer.PlayerGui:Destroy() -- anti bypass, kills their guis ;)
		end
	end) — after testing this script no longer works sorry

I know the 1st script works, i’m not 100% sure if this one does but it should. Hope This Helps.

2 Likes
#12

the Exploiter can place dex in coregui

#13

The second script can read core GUI, but I think it may not work anymore.

#14

If the script is located in the client the exploiter could simply just delete it

#15

Yes that’s the thing with client side scripts they are un secure

#16

They could just recreate PlayerGui

#17

Can’t DarkDex Uses A Random Title System

Lets Say I Do It In Adopt Me, The Title Can Be “9U3NHGF201210J1D”
And I Rejoin The Same Game The Title Can Be “2J90F93G39JKF93I”

Sadly There Is No Way To Prevent This

#18

Not necessarily, put a check for the Anti-Cheat in one of the Player Control Modules.
If it gets removed kick the player.
I put my Anti-cheat scripts in StarterPlayerScripts so it’s easiest for the Player Controls to detect it.

Edit: To my knowledge it’s impossible to reload the player control modules without re-joining causing this Anit-cheat detection system to be impossible to bypass.

#19

This check must be done on the client due to filtering enabled. :confused:

Yet exploiters can fake to the Core Scripts that it still exists.

#20

Yes, the client DOES do this check in fact! :smiley:
That’s exactly how it works.