Possible Solution to Remote Event Exploits?

Help and Feedback Scripting Support
#1

So recently I’ve heard that exploiters can break games by firing remote events through the client side. Wouldn’t a fairly good solution be implementing a passcode parameter only the remote events (and the developer) know, and kicking the player if they get that passcode wrong?
Here’s an example

--LocalScript

script.Parent.MouseButton1Up:Connect(function()
	local key = "828kjf223"
	game.ReplicatedStorage.RemoteEvent:FireServer(key)
	print("Sent!")
end)

--ServerScript
game.ReplicatedStorage.RemoteEvent.OnServerEvent:Connect(function(player, key)
	if key == "828kjf223" then
		print("Test Passed!")
	else
		print("Test Failed!")
		player:Kick("Using Exploits")
	end
end)

I haven’t heard anyone talk about a solution like this, would it not fix the issue? Is this an actual solution that I just never heard of? Or was I the first person to think of this solution (I kinda doubt it but still).

2 Likes
#2

Exploiters have access to see local scripts, even if you have a key they can just take the key. This is not a good solution because of this. You need to remember anything on the client they can see even if you obfuscate everything it doesnt matter because they can snoop on remote events and see the plaintext key being sent over anyways. There is no solution to this other than sanity checks to verify the data being sent is allowed within your parameters.

5 Likes
#3

You can’t check what script it’s coming from either because they can fire code and say, “Actually, I’m this script.”

2 Likes
#4

Ah, ok

1 Like
#5

Security through obscurity isn’t real security. What you should be doing is validating or sanitising what the client is sending, depending on what’s most applicable. How you do either of those things depends on the exact system you’re writing, so there’s no one answer to that.

Side note that I’ve moved this to Scripting Support. Technically it fits the bill of Code Review but rather than improving working code it’s asking if something is viable which leans more to support.

#6

Since clients can see everything in local scripts, this method wouldn’t be effective. What you should be doing is making sanity checks on the server. The most common sanity checks include checking the clients rank, username, permissions, or other conditions.

#7

Recently I found out that there’s code that crashes people who open/view the code

I’m pretty sure you can put this in the script that requires the key. and exploiters couldn’t view it.
it would require an exploiter to save an instance of the script and open it up in notepad just to view the script. the script would best case scenario crash the exploiter’s game, they would be confused and go to another game. I still need to test the effectiveness of this however, if this does work you might be able to obfuscate the script to make it even harder to do. and once they go through all the effort you can simply change the code next update.

Needless to say if your game isn’t large i would say its a good method (if it works that is)

#8

exploiters can see the variables in your script without a decompiler

for i,v in next, getgc() do
    if typeof(v)=="function" and islclosure(v) and not is_synapse_function(v) then
        if getinfo(v).source:find(scriptPath) then
            table.foreach(getconstants(v),print)
        end
    end
end

they can then take the constant index of the remote key from that list of variables dynamically and fire the remote

temporary solutions are not a good idea for remote security, it needs a combination of good practice, sanity checks, and a wide knowledge of both exploits and roblox lua entirely

you can add remote keys on top of it to mess with people simply to annoy them, but it will not be enough to stop exploiters alone

1 Like
#9

Hmmm. Very interesting, had no idea they could do this.

#10

They can see all of that
I am not exactly sure but I think you can make a module script that names the remote functions and remote events random strings
I’m not exactly sure but I think that would work, it would probably only confuse them though
What I do normally for my remotes is, if a certain thing should be true or false when the remote was/is fired then I check that, if it isn’t what it’s supposed to be I kick the player

For example my spawning and morph script, if it’s fired and the players character isn’t destroyed they get kicked, on top of that I have it checking if they actually own the morph the remote fired with, it seems to work fine even though I doubt someone would exploit something like that but you could try doing something similar (btw I check these on the server since removing the player is on the server)

Quick edit, you could also randomize the location of the module and also don’t make the module an obvious name like “Remotes”

#11

That has always been the method I’d use. However, I never actually knew whether it would work.

In ServerScriptService and in a ModuleScript, I have this script which generates a random 1024 digit code

local s = {"a","b","c","d","e","f","g","h","i","j","k","l","m","n","o","p","q","r","s","t","u","v","w","x","y","z","1","2","3","4","5","6","7","8","9","0"}

code = ""

for i = 1,1024 do
	local cap = math.random(1,2)
	if cap == 1 then
		code = code .. (s[math.random(1,#s)]):upper()
	else
		code = code .. s[math.random(1,#s)]
	end
end

return code

well… I don’t think exploiters will ever know what the code is. Not even you would know. I haven’t tested this method out though.

Sorry, I just realised that this post is very old. I saw people posting an hour ago and just assumed that its a new post.

#12

no dont do that plz ur players’ bandwith wont like that…

If anything, instead of stopping a player from remotely firing the remote event, just secure your server code bro

#13

i’ll be honest, i made that script when I was relatively new to scripting and feared that exploiters would break the script

yeah 1024 digits is very exaggerated. even 16 would be enough

i’m just not very sure if its a viable solution to new scripters who don’t know how to secure their server sided code

#14

No worries. when i was new to that stuff i was actually adding in little keys aswell so