Good observation! But the proposal I mentioned above is that Roblox only allows searching for elements, without allowing them to be deleted, created or modified. In other words, when someone writes FindFirstChild(“CoreGui”).Menu, the system would return only the Menu, without allowing changes to it.
Very good argument! You are one of the smartest commenters so far. Some people just said that it is useless to check exploits on the client, but they don’t think that there are tools like Remote Spy, Dark Dex, Infinity Yield, Aim Bot Menu, Hydra, among others. You really brought a smarter view.
All the exploit UIs you mentioned are extremely easy to detect, a basic example for DEX:
local Check = setmetatable({game:GetService("InsertService"), newproxy(true)}, {
__mode = "v"
})
while true do
if Check[1] and not Check[2] or not Check[1] and Check[2] then
while true do end -- crash the client as a form of punishment ( you should fire a remote to the server to ban the player before this)
elseif not Check[1] and not Check[2] then
Check = setmetatable({game:GetService("InsertService"), newproxy(true)}, {
__mode = "v"
})
end
task.wait(1)
end
1 Like
what the hell is this code? ‘-’ 
kkk
1 Like
gibberish code, don’t even make sense, Roblox don’t support weak tables.
Dex is the easiest exploit to detect because it creates a GUI called “dex”, which uses the playerGui itself.
1 Like
as previously said in this post:
giving coreGui access is utterly useless, most exploits use syn_protectgui() or gethui() which render any detection for the UI useless, let roblox do the detections
protect your game by doing checks while keeping it optimized
Although I agree that developers should be allowed to check instances in CoreGui (since it feels dumb that Roblox keeps legitimate developers out of it), there’s one problem…
If developers could view and read the properties of CoreGui instances, exploit executor developers could add their own “container service” (something that works just like CoreGui for GUI elements or where-ever Roblox stores CoreScripts for anything else).
Currently, they have a function that lets exploit scripts store data in a hidden table, getgenv() (their counterpart to getfenv() and _G), but they could add this potential secret container quickly if they needed to.
Oh, yeah… I forgot this was possible, since I don’t think any executor since Synapse X has included a function that hides instances from built-in indexing methods.
The only place they can really inject their menus is basically in CoreGui. Their defense is extremely weak, as all they do is put in a random string (like in Infinity Yield), use names identical to the tabs in CoreGui, or insert their menus into already existing tabs in CoreGui. This doesn’t hide anything at all. Additionally, most exploit menus, especially aimbot menus, aren’t updated, which makes detection even easier.
with a simple hook function you can hide your UI from being index by any script, you know that right? still making your “detection” useless
As I said in the topic, Roblox would not need to allow creating, modifying, cloning or deleting instances in CoreGui, but only allowing searching within CoreGui. There are functions that already do this basically, such as disabling CoreGui elements, creating notifications in CoreGui, among others.
I understand your point of view, but I’m saying, in general, that if they allowed access to search in CoreGui, amateur menus for aimbots, among others, would be easily detected. The old menus, which still work, would become ineffective, and the current menus, made by programmers who are not so competent, would not be able to create effective menus. This would be a short-term measure so that, at least, developers try to do something about it, instead of waiting for Roblox to release an update every six months to try to solve the problem.
I agree, Roblox should 100% give developers more control over the client to combat exploits, but as previously said again
most script-kiddies use UI libraries with already all the anti-detection available
sadly coregui isn’t enough
Just to head off this discussion, what you are asking for is not unreasonable to me. But it won’t be long before someone is going to comment that trying to block hacks via the client is just too easy to bypass. If your script is running on the client, a hacker can simply delete it. Rendering it’s detection ability moot. If you are trying to emulate some sort of client/server handshake to combat this, they simply fake the handshake and basically still bypass your detection. Not to mention, Roblox is constantly doing stuff to the CoreGui, which means if you do have access, they might change something today that sets off false detection in your own script. That means you have to constantly update your own exploit prevention script to avoid hurting legit players. It would be a never ending battle of your time and resources. If you can break your own detection in Studio, then so can any hacker with full access to the client.
1 Like
Vamos fazer um exemplo aqui. Se você for um exploiteer e eu criar um script para detectar seu menu, e esse script estiver dentro do framework das armas do jogo, e se você deletar ou desativar as armas, elas não vão dar dano. Como você burlaria isso? Claro que essa forma que mostrei é a mais fácil que consigo pensar no momento.
O hacker simplesmente alteraria o script da arma para ignorar a detecção. Se você pode derrotar sua própria detecção no Roblox Studio, eles também podem.
hummm tem como voce dar um exemplo
Então o script da arma tem a detecção. O cliente faz uma cópia do script e depois altera a linha de segurança que sinaliza se um Gui foi detectado. Seria tão simples quanto alterar uma instrução if,then. Ou o hacker pode pegar o script inteiro e modificá-lo apenas para ignorá-lo e substituí-lo quando ele se conectar ao seu jogo. Basicamente, qualquer coisa a que o cliente tenha acesso, ele pode mudar. É por isso que a detecção de exploits de clientes é tão difícil de manter para os desenvolvedores.
se tu esta falando de exemplo game.Players.KainagamerTigre.PlayerScripts.AntExploit.Source = “” ‘-’ isso aqui nao funciona acabei de testar
me mostre um codigo que faria isso ‘-’
Você me falou que “eles podem mudar seu script”. Basicamente, isso significa que:
1 Eles podem ver o que você está verificando e tentar burlar a detecção.
2 Eles podem literalmente reescrever seu código para impedir que sejam kickados.