Dex exploit detection script?

Help and Feedback Scripting Support
#21

Your script would most likely kick the player straight as they join the game, since it checks for the “Class security check” error, which will most likely be generated by your script’s attempt to index “descendant.Name”. Besides that, printing everything which gets added into the game would cause some serious lags for the player, and make their log file like 50MB.

There are many ways to detect Dex, but all of them can be bypassed. It doesn’t matter how it names its gui. Some exploits make tostring(gui) return “ScreenGui” for all guis under CoreGui, including Dex and the dev console.

1 Like
#22

I didn’t test this but this might be a useful idea.

You can try waiting for all of your assets in the datamodel to load then after all of them load, when a new instance is added check if its parent is unable to be indexed (its likely in CoreGui then) then call :Destory on the instance to remove it.

#23

You can’t call Destroy() on instances under CoreGui, since all of them are RobloxLocked.

#24

Well that is new to me. I guess you could still kick the player. :woman_shrugging: Thanks for informing me about that though.

#25

You’re welcome. Also, kicking the player when something is added to the CoreGui is still a bad idea. Displaying a notification with SetCore, receiving a friend request one, opening the DevConsole, even clicking its topbar. The player would get kicked for every one of those things.

1 Like
#26

You could add a whitelist for specific objects. Also i’m starting to see the more we add, the more ways an exploiter has to bypass the security.

#27

It’s been said numerous times, but exploiters often put their interfaces in the CoreGui. You can do nothing about descendants of the CoreGui. It’s a waste of time trying to detect it at all. Secure your server and make sure there’s minimal opportunities for exploiters to take advantage of. You should be more worried about your server and how clients can affect it over trying to lock down the client of foreign elements. It’s the client, it’s their device. They can do whatever they want with it.

2 Likes
#28

You won’t get anywhere by trying to battle exploiters on the client. They will always find a way around it.

5 Likes
#29

Don’t non-malicious DLL injections do the same? Ignoring of course a good exploit can just detour the method before it has a chance to check.

3 Likes
#30

As I said before, using this as detection is a very bad idea and will most likely not work in a real game as it is very unstable. As for non-malicious DLLs, I don’t think there would be any non-malicious DLL injections into the client?

1 Like
#31

Lots of things inject DLLs. As mentioned before, Discord and Fraps.

1 Like
#32

Still, this shouldn’t cause false detections. What causes this spike in usage really isnt the dll, it’s the script that exploits first execute (usually called the ‘init script’) that causes lua memory usage to spike. That’s why it’s so risky to use since regular game scripts can cause spikes in memory usage leading to false detections.

1 Like
#35