A "Logical" Exploit Question

Help and Feedback Scripting Support
#1

A small Exploit Question,

If I use something like

PLAYER.PlayerGui.ChildAdded:Connect(function(ins)
   ins:Destroy()
end

Would that sortof prevent exploits as of Dexplorer or Troll guis if I make sure to not add GUIs In my game? Seems logical in my opinion.

#2

No, exploiters don’t put their exploits in PlayerGui. Some put them in CoreGui (which you can’t access) but they don’t have to use Roblox UIs at all.

1 Like
#3

Yes, but if they do in fact put them in PlayerGui, would this be effective?

#4

They can just disable the LocalScript that deletes it, but I guess it would work if they don’t disable the script and put their UI in a different place from every single other exploit.

1 Like
#5

If it’s possible to check if childs were added in coregui, you could just kick the player.

#6

This is a post that is on the devforums.

2 Likes
#7

Roblox uses CoreGui for their UI. You would end up kicking people for opening the escape menu.

1 Like
#9

In short, no this isn’t 100% exploit proof.

Lesser experienced “expoiters” might get stuck with this, but any more advanced exploiter could easily just disable the localscript or place their gui in a different place.

Focus on making your remote events secure first, as then they won’t be able to achieve anything even with the exploited gui!

4 Likes
#10

Yeah, I know most exploiters are just the kinds that @Jrelvas1 has explained, which is who I’m targeting as There would be a few “Professional” exploiters which wouldn’t hurt much.

#11

Script kiddies who don’t know how to script use scripts written by people who do know. They don’t write their own exploits.

1 Like
#12

Yes, but you can always deploy a patch until they find a workaround which is very unfortunate.

1 Like
#13

You shouldn’t make an inherently flawed system just because you think you might be able to fix it later.

3 Likes
#14

This is a post that is on the devforums.

1 Like
#15

To stop players from messing with localscripts, some crucial localscript could also be the “exploit checker”, that way, the game becomes unplayable. I know that a exploiter could check for the script source, but i don’t think it’s well know that that’s possible.

#16

You can try make your game anti-protosmahser proof.

try:

if PROTOSMASHER_LOADED then
print("Hacker alert")
end
3 Likes
#17

The simple answer is no

One thing you have to always remember is malicious users will always have more control over the local environment than you do, period. Your security model should prioritize what you can prevent on the server, as literally anything you do on the client can be bypassed.

This is not to say you should never do client-sided detection, there are scenarios in which client-sided detection works. For example, logging malicious use for X period of time then banning all users who were logged - this can catch developers who fail to check remotes and it can be surprisingly effective.

Your solution to removing GUI’s can be bypassed in a few ways, here’s two.

  • 1:
    Parenting their GUI’s to CoreGui a service which you cannot access. It is already common practice in the exploiting space to use CoreGui over PlayerGui for things such as ESP and HUDs

  • 2:
    Using a custom functions present in most exploits called getconnections() and disconnectall() which can be fed a signal and disconnect all attempts to listen to it. For example in your case an exploiter could simply do:

for _,signal in next, getconnections(game.Players.LocalPlayer.PlayerGui.ChildAdded) do
     signal:Disable()
end

Finally your theory on targeting unskilled exploiters is flawed - the thing is the majority of people whom exploit are getting scripts from experienced users, so targeting your methods of prevention at the small amount of individuals who are both incompetent at reverse engineering and making scripts is really pointless. Cause the overwhelming majority of people exploiting on your game will be using a script likely developed by people who are proficient and have included a bypass in their public script.

#18

If it does get deleted or disabled, can’t we use a server script to keep adding or enabling the local script back in when it’s deleted?

#19

That would require a remote, so the exploiter could simply delete the remote

#20

this was possible a while ago, until roblox removed the abillity to use tostring() on RobloxLocked instances, now we dont have a single way to detect instances being inserted into CoreGui etc.

#21

that would not work, due to us developers not being able to access exploit’s own custom functions, like that one.

1 Like