Simple Remote Security

Hi developers, I came up with a way last night to make using RemoteEvents safe.

Before your pride and arrogance make you write a negative comment, let me tell you that I am aware that it may be vulnerable, and that is why I have come to post the method here, to know what vulnerabilities it may have.

The first idea that came up is to make a Remote Spy, a separate RemoteEvent that tells the client which RemoteEvents have been invoked (it’s not necessary)

Let’s start with the code example.

In my case, i just need make two Remotes, a RemoteEvent and RemoteFunction
image

_AE Use:

Its the first Step for the client.

local _AEKey = Events._AE:InvokeServer(  );

It invokes the server, to return a key, which means a Folder inside another, whose name is the key

local _AEFolder = Services.RPS._AE:WaitForChild( _AEKey, 10 );

Suppose for some reason, it takes time to create, that’s because the WaitForChild

local module
_AEFolder.ChildAdded:Connect(function(v)
	if v:IsA'ModuleScript' then module = v;end
end)
repeat wait() until module;
_AEFolder:Destroy()
module = require( module )
_ServerProxy = module:new()

And in this part, an infinite wait is made for the server to insert the module whenever.
I agree that it is completely unnecessary, but I wish the client could not read the module. It’s probably possible to see it with some deleted item log, but meh

¿What _ServerProxy doing?
is a module whose invocation of “: new” returns an object
Here’s the module

local this = {};
local Services = {
	RPS = game:GetService('ReplicatedStorage');
	PLR = game:GetService('Players')
}
local Events = Services.RPS:FindFirstChild('Events') or warn('Events no se encuentra en Replicated.')

function this:new()
	local obj = {}; setmetatable(obj, self);
	self.__index = self;
	self.ClientLogs = {};
	self.ServerLogs = {};

	Events.AE.OnClientEvent:Connect(function( evName )
		if not self.ServerLogs[ evName ] then
			self.ServerLogs[ evName ] = 1;
		end
		self.ServerLogs[ evName ] = self.ServerLogs[ evName ] + 1;
		if self.ClientLogs[ evName ] < self.ServerLogs[ evName ] then
			Services.PLR.LocalPlayer:Kick' Server closed Proxy ' return;
		end
	end)

	return obj;
end

function this:FireServer( ev, ... )
	if not self.ClientLogs[ev.Name] then
		self.ClientLogs[ev.Name] = 1;
	end
	self.ClientLogs[ev.Name] = self.ClientLogs[ev.Name] + 1;
	ev:FireServer(...)
end

return this;
8 Likes

here’s the example

1 Like

The _S module is where this seems to fail, since it’s run on the client it can be modified by exploiters, it wouldn’t be long before this would be bypassed.

Just script your remotes properly and you’ve already blocked every non-physics exploit, key systems and weird hacks like these are easily bypassable and aren’t a good idea in general

2 Likes

remote systems which rely on any sort of key are bypassable

1 Like

:flushed: How the client can modify a Lua Object ?

a lua object? I’m not sure you know how exploiting works. Exploiters can modify all code ran locally and so is the module you are making meaning your method is not going to work. and also you stated “Before your pride and arrogance make you write a negative comment”. Are people not allowed to state their opinions?

5 Likes

OP trying to make it seem like any 100% valid comment against this attempt to mitigate exploits look like hate. It’s really not, OP. Learn to take criticism. The others who have commented are right. If anything, what you wrote can be said about yourself… :flushed:

3 Likes

Thanks for contributing something not related to the development topic. I’ll take in care your advice and I’ll apply it to my private life, I’m not join to be prejudiced, how do you say I am. But I would like to make clear two things; at any moment I said in a direct or indirect way that I don’t accept negative criticism, I jus said “before”, and after I admitted that’s completely vulnerable, you can start doing all the criticism that you want to improve me. And another thing, it was all my intention to do your cristicism to my work overshadowed by my comment.

1 Like

I actually did though.

This is true. The client can access and edit anything.

Stop trying to make these workarounds to exploits. Just stop. Make sure the client is put in its place and can’t do anything it shouldn’t be doing, it’s as simple as that. No trying to secure your remotes with tricks or encryption, just code your game in a way that doesn’t give power to the client.

As for the rest of what you said, I’m not going to reply to that because honestly I don’t really understand what you said.

1 Like

You’re right, I don’t know much about exploits, but I like to try fix them. It was yesterday when I tried and it seemed to work. Another very important thing, I mean “Lua Objects” to the object returned by the “_S” module, mainly because all the invocations that the “normal” client must do (the one that is completely legal and performed by the developer) are registered there, and all the server gets, so my question is that an exploiter can modify that “Lua object”, if so, then there is no doubt that my attempt is completely superfluous.

Also another thing completely important, why it seems that you only read part of my comment

I would like to highlight this part very much

Well, it’s true, the effort may seem futile, but at least the free exploits are fixed.
I’m just testing bro, that’s why I shared it here, it’s not something I recommend doing, because I honestly don’t intend to apply it to all my projects, but hey, the silver lining is that it collapses all requests into a single object hahaha

2 Likes

Security measures on the client aren’t necessarily bad. You’ll spend at most 1 hour making one and stop every exploiter who doesn’t know what they’re doing (a considerable portion). If an exploiter ever makes a script that deletes it, you lose nothing except an hour of your time.

The only thing you have to keep in mind is that you should NEVER rely on it for anything because it can be disabled in 1 line of code.

Before people start an argument about this, I never said that this is a replacement for the typical, effective methods of securing your game. This is just a small/extra tentative measure.

Edit: sorry I didn’t mean to reply to you :stuck_out_tongue:

1 Like

I AGREE, a game is for fun, so we’ll have to give the exploiters an extra minigame hahahahaha XD

Adding to @Zephyr_42 's post, even exploiters who actually know how to script, will become really frustrated, bored, and move on to exploiting another game with no extra measures. Now I’m not an exploiter, but if I was in their hands, I would want to make an exploit on a game with no measures because I would want to see results instantly. Maybe I’m wrong, but that’s just what I think.

Is it possible to build the anti-exploit into the main client code so they can’t just delete it without the whole game breaking?

1 Like

You can do this, and it’ll make it harder for the exploiter to get rid of, but it can still be disabled.

Another option is hiding the script by parenting it to nil. However, this method is pretty common and a lot of exploiters will know to check there.