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
I would say if the player tries to act with any tiles he cant legally see, he’s cheating.
Or, here’s a fun idea… send wrong information updating unseen tiles. This sounds like a great honey pot opportunity.
Thanks Golgi,
But just like Client can’t see Server. Server can’t see Client, as far as I know, without firing a Remote, which runs into the same problem…
Also, my question is off-topic for this post, so I will start my own.
Thanks again.
(re-formatted)
If the clouds serve the purpose to hide the enemy then you will probably want to re structure your system. If all the data is sent about where the positions of the enemy are then you need to probably rethink your entire system.
If (I am assuming you have moving parts on the server showing troops) possible you can instead send the troop movements and locations only near to the player. Then the RemoteEvents only serves a visual effect.
If RemoteEvents already only serve a visual effect then I don’t think you need to worry about securing it. But, if the RemoteEvent is pivotal to the game working or is a security flaw then you have to change the system.
No, the clouds are just decoration, for Hexs (tiles), which you haven’t been to yet at all, instead of just open sea…
He would just see the entire map and all Players units from the start…, if he stopped the initial
tile.Parent = nil
I never send any info. I just send a Remote:
tile.Parent = Workspace.Globe – to uncover a tile and all enemy units which may be in it.
That’s the beauty of it, and also the problem. He could do that at any time too…
Test124c41 is open source, I believe
I AM devious and dogged, I never say die.I will figure it out…
I guess that people COULD use this method to “hide” large areas of far off regions of an FPS map, in one shot, as defeating that would just give a Player lower performance; no real advantage…
1 Like