I usually store all RemoteEvents in ReplicatedStorage, but, as far as I know, exploiters can see them since they’re replicated to the client. Unfortunately, some events are difficult to reliably validate, so I was wondering if it was possible to somehow obfuscate them as an easier way of preventing exploiting?
1 Like
No, no matter how hidden it is they will always find it, but I found out a way how to prevent most exploits so I’m releasing the model of it later
2 Likes
It’s impossible to stop an exploiter from sending false positives to a server on roblox. The position of your RemoteEvents doesn’t matter either, as I believe there are programs out there to listen to and record remotes. If you want to keep your game secure, use sanity checks and don’t rely on the client for info, unless its an input or something only the client can provide.
This just seems improbable, and so forgive me if I’m wrong, but are you saying you’ve found 1 method to prevent most exploits? There’s multiple types and ways people exploit, so unless it’s some sort of physics tester it probably won’t cover a large majority of hacks that are out there.
3 Likes
I’m kinda interested what is it?
This can be provable. Just make the serscript send the pass to local then local sends pass to serscript and serscript will randomize password and send it again.
And if exploiter sent the wrong password the ser script will kick the exploiter.
Just make the serscript send the pass to local then local sends pass to serscript and serscript will randomize password and send it again.
And if exploiter sent the wrong password the ser script will kick the exploiter.
This obviously won’t prevent all exploits but it prevents most exploits
The only exploits this would prevent would possibly be free model assets that have already existing hacks, however it’d only take someone upwards of 5 minutes to realise that you’d use some sort of password protection on the event. As such, newly created hacks made through vulnerabilities, physics, etc wouldn’t be affected by this.
2 Likes
it randomizes the password Everytime event is fired.
1 Like
Banking industry uses methods like this, and its definitely secure. I’m using a similar method to prevent item duping using GUIDs. I’m curious how you will prevent the hacker from intercepting the client signal and using it for their signal.
2 Likes
I believe the secret is to never let the remote event do anything important.
Example of a bad remote:
“I attack”
Example of a better remote:
“I want to attack”
Let the server do the heavy lifting.
2 Likes
Just add sanity checks.
3 Likes
You can’t “hide” the RemoteEvent from a client. If the Client can’t access the Remote, the Remote is useless.
As others have said what you do is do all logic and sanity checks on the server. The Client should ask “Can I buy this sword” not say “I can buy this sword”
If you really really want you can name your RemoteEvents obfuscated texts so that exploiters don’t know what they do. But if you write your sanity checks properly that isn’t necessary, plus it could really confuse the developer.
3 Likes
This is not a secure method. Exploiters can actively see what arguments you pass to the client by hooking into Remote listeners. Any exploiter who even remotely knows what they’re doing can immediately counteract this.
Your best weapon against exploits is sanity checking.
1 Like
I’m confused , what are sanity checks?
1 Like
There is a link a few posts up explaining it. Short version: check on the server to make sure the remote event makes sense.
1 Like
I mean you could in theory “hide” it by destroying it on the client. But, not only isn’t that entirely secure but it defeats the entire purpose of having a RemoteEvent in the first place.
I am interested. What type of information are you trying to validate here? I am sure this question is more helpful
2 Likes
I also though at making this but I was too lazy to make it
I got a good one:
So, in a wargame, like, RISK!, but with Fog Of War, so you only see tiles, next to one of your units I delete each tile (country) on the map, locally, at the start.
game.Players.LocalPlayer:WaitForChild(“ClearCache”).OnClientEvent:connect(function(Tab)
local obj = nil
for i = 1, #Tab do
table.insert(CamList,Tab[i].Name)
table.insert(CFrameList, Tab[i].CFrame)
table.insert(RotList,Tab[i].RotVelocity)
obj = Tab[i]
obj.Parent = nil
end
end)
Whenever a Player moves a unit, I send a list of the new tiles he can see, and replace the old tiles he can’t see, with a B/W picture, like StarCraft…
game.Players.LocalPlayer:WaitForChild(“ClearTile”).OnClientEvent:connect(function(Obj, NegObj) – object is a list
for i = 1, #Obj do
local cloud = container[Obj[i].Name]
cloud.Decal.Transparency = 1
cloud.Transparency = 1
cloud.OldInfo:ClearAllChildren()
if cloud:FindFirstChild("Mesh") then cloud.Transparency = 1
cloud.Mesh:Destroy() end
Obj[i].Parent = workspace.globe
end
wait(.5)
for i = 1, #NegObj do
NegObj[i]:clone().Parent = container[NegObj[i].Name].OldInfo
greyOut(container[NegObj[i].Name].OldInfo[NegObj[i].Name])
NegObj[i].Parent = nil
end
end)
An exploiter could just get rid of the Deletes, but I REALLY want to do it this way, 'cause it works…
Oh, also he has a list of all of the tile’s .Names…
What would be a goo sanity check on this: Checking if he can see stuff he isn’t suppose to see?
(I’m not gonna kick 'em. Just lower his odds of winning every battle, so that he spreads it around and I make even more people think that they are just bad at the game…)
1 Like
To sum up everything that’s been said:
1.) You cannot hide remote events from the client, nor should you try to. It will be ineffective at catching exploiters and will make it 10x more difficult to actually use them in your game.
2.) Utilize sanity checks on the server. The client should be a “reflection” of the server, so to speak. Example:
--Serverside Code
SomeEvent.OnServerEvent:Connect(function(player)
if player.Name == "bingusbongis" then
-- Allow the below code to be executed because their name is "bingusbongis", reflecting the client-sided code. This cannot be bypassed in any way because it's running on the server
end
end)
-- Client-Side Code
if player.Name == "bingusbongis" then
SomeTextButton.Visible = true -- Only make the text button visible to the client if their name is "bingusbongis"
end
SomeTextButton.MouseButton1Click:Connect(function()
SomeEvent:FireServer()
end
3.) While sometimes effective for exploiters who have no clue what they’re doing, anyone who is remotely experienced in scripting (and is exploiting) will be able to bypass any client-sided “admin” checks or anything like that and modify your client-sided code in any way they desire. Make use of sanity checks like I explained above.
Can you think of a foolproof sanity check for my FOW ex.?
1 Like