To clarify: FindFirstChild works, it just doesn’t detect the exploited objects
Many people (including myself) have it in dozens of live games right now.
If it was disabled or even deprecated it would be shown here. So for clarification, it still works on its own.
It is really difficult to make an Anti-Exploit. That involves either multiple exploits or just one exploit.
Keep in mind that Roblox announced that they are making an Anti-Exploit. However I don’t know if it is gonna be 100% Foolproof. As even Anti-Exploits like the one used in Valorant. It’s really advanced but yet not 100% Foolproof.
Not every Anti-Exploit is perfect…
Adding in a blacklist or an whitelist won’t really work well. - Blacklisting - Exploits can name themselves random strings this solution isn’t really great worthwhile - An whitelist will just be an small bandaid fix opposed to what’s actually going on.
CoreGUI Detections using Hacky Methods to detect the restricted service I won’t recommend. As executors can patch it. It is probably better to stop the execution not through their UI. However If you wanna go through that path. I’m not gonna stop you as you decide.
I’m not sure what you mean by “explorer” however there is a way to detect if something has been injected into the game. For security reasons, I will not be sharing what it is.
Dex outputs something like “COPY” in console, you can take some advantages against that.
Though i only think DEX V3 does this. Not sure about other versions.
If you can detect that dex screengui has been added, can’t you just use getchildren on it? since it seems like the frame names arent randomized.
Or you can just use game:FindFirstChildOfClass("ScreenGui", true) then check the contents of said screengui and if it catches a frame with a name like Caution kick the player.
Its quite difficult to patch this kind of thing, as the gui itself changes often. One solution won’t work forever honestly, and the solutions that work the best are not the most performant.
I wouldn’t bother listening to a lot of these comments. There’s no point to a client-side anti-exploit as the client can never be trusted. Client-side anti-exploit scripts can easily be disabled or spoofed. Even if that weren’t possible, some exploits have special functions and classes designed around being completely undetectable to in-game scripts. This includes protected gui that will be impossible to detect.
I’ve seen so many of these threads and the end result is always the same. Do not make a client-side anti-exploit. Server-side anti-exploits are your only option. There is no anti-dex, anti-esp, anti-aimbot, etc. Sanity checks and verification are the only things you can do, and you must do it from the server’s end.
Do you have any proof of that? The video doesn’t link to any games or scripts. It looks more like the game is just kicking after a certain length of time.
No exploit developer is this stupid to put it at game, instead they put it at coreGui and thats what scripts cant access, you will have to do some hacky methods to detect it but even then its not worth it as it will get patched.