Is renaming remote events a good way to prevent an exploiter from firing them?

In most scripts (if not all), in order to fire a remote event, you first need to define it via a variable or just doing something like game.Workspace.Remote. What if the game is designed to rename the remote names every few milliseconds? Take this coding example

let chars = ['a', 'b', 'c', 'd', 'e']
while true do
     let remoteName = _G.remoteName
     let remote = game:GetService("ReplicatedStorage"):FindFirstChild(remoteName)
     let newName = ""
     for i=0, 10 do
          newName .. chars[math.random(#chars)]
     end
     remote.Name = newName
     _G.remoteName = newName
     wait()
end

Due to the fact that the client can’t access _G, why don’t anti-exploits use this, or is there a loophole that I’m missing?

Perhaps exploiters can simply use their network observer (a.k.a RemoteSpy as I’ve heard) to mark down the essential remotes instead of referring to them with mere strings, so they can still manipulate the right ones after name changes?

I’ve seen a remote spy in action via a Youtube video, it uses stuff like game.Workspace.Money when you see the preview of what got fired, so if the name changes, won’t it throw an error?

In the end it just doesn’t work. Games like Jailbreak use systems similar to this and they’re still bypassed with relative ease because the client has complete control over their machine. Most exploits come with the ability to hook or listen to functions like the built in FireServer or even the functions you define in your own scripts that use the event.

5 Likes

So in a server script they would still be able to block it, cause won’t it work on the server just fine?

You’ll have to elaborate. The client can’t directly affect the server but it can fire remotes to it at will.

3 Likes

Yea, but if the remote events change to something completely random, how is the exploiter able to find the right remote? For example, say a Money’s remote’s default name is Money, but when the server starts, it’s name changes to stuff aioyh or hteoiwyl or whatever every few milliseconds, and since you’d need the name to reference the event, if the name isn’t valid, how can they fire it, they can’t, it’ll just throw an error

If any of your local scripts hold reference to it, then, they can use that. Think about it for yourself, how are you going to use it?

Edit; you can think of exploiting the same thing as having edit access to roblox studio but only being able to see stuff replicated to the client, they can and will find your remotes in wherever you store them.

3 Likes

Exploiters don’t need to index your remotes by game.Whatever.Thing, they can grab the references right out of your own scripts. They can also just listen to every remote and tell apart which ones they’re looking for by checking what script is calling it and what it’s sending through.

No matter how many hoops you jump through the same result is inevitable.

5 Likes

Emphasizing what @Mystifine said, as long as any of your LocalScripts have a way to access the remote, so will the exploiters. Ultimately, the point vanishes.

I just realized that after some more thinking

This hasn’t been said yet but _G and shared are both accessible by the client. It’s just that each context level gets its own variant meaning the server, client, command bar, plugins, etc. have their own variants that are inaccessible by other context levels. It’s best and easier to protect your game by following the principle of ‘never trust the client’ and sanitizing inputs.

I used print(_G.name) in a local script and it was nil yet when it was in a server script, it was “Test”, so what do you mean?

Basically the server has it’s own _G and shared tables that the client cannot access. However the client has it’s own tables that the server cannot access.

Oh, I think I know what you mean, so say if I do the following code in both type of scripts

--LS
_G.name = "LS"
print(_G.name)
--SS
_G.name = "SS"
print(_G.name)

It would print LS on the client and SS on the server?

2 Likes

Yes, it should function exactly like that.

Hackers finding your remote events/functions in a visible service is inevitable. Even parenting it to nil, it can still be found. The best way to prevent hackers from messing with your game through remote events is just performing logic events on the server once it is called. For example, if a person fires a remote event that only admins can use through hacks, simply perform a check on server if they are an admin. If they are an admin, run the code, if they aren’t. don’t. This is really the best way to do this, although it may take some extra time when scripting to implement this.

12 Likes

Just created a script exploiters would use to bypass that method. This should work, though I wasn’t able to test as Roblox Studio is down.

local children = game.ReplicatedStorage:GetChildren()

for i, v in pairs(children) do
     --Run some function to check if the RE does what they want
     v:FireServer()
end

You could use HttpService to randomize the names from a localscript checked by the server, using something like this:

while wait(3) do
local children = game.ReplicatedStorage:GetChildren()

for i, v in pairs(children) do
 v.Name = game:GetService("HttpService"):GenerateGUID()
end
end

You can make a fake remote event with a similar name. Just replace the l with a I so they can’t tell the different. Attach it with a server script in ServerScriptService and you are good to go. When the exploiter activates the fake remote, it will kick the exploiter. Hope this helps.