Revamped Remotes

Revamped Remotes should not be used for actual projects (unless you really want to) at this time. Bugs, glitches, and possible bypasses can (doesn’t mean it will) occur at this time. Be warned! This is currently a proof of concept and this forum is to find bugs and bypasses and suggestions so I can fix them before I do a total “Use it for actual projects” advertisement.

This is also meant for newer developers, and as a quicktool so you don’t have to do it yourself.

Hey developers! Here I have created a ModuleScript called Revamped Remotes.

What does it do?

Revamped Remotes basically allows you to create Secured Remote Events and functions (soon).

When you create a Remote it will store its data within’ the module. When a player wants to fire this “remote” they must request a Temp Key for their user only. This Key can only be given by the server. Every time the Key is used, it is dumped and becomes expired and will also expire by the time you set. (Default, 5 seconds)

When the Key is in order. It will fire a Bindable event for proper use.

Cool. How do I install and use it?

You can install it here. Put it on your game and require it with a Serverscript.

Remember to check back here once in a while to check if there is an update. You can match the CURRENT VERSION in the Modules setting area with this below.

0.1-InDevBuild

You can learn to use it below in the Documentation.

Documentation

Something to note before we begin is functions are currently under development. Please do not try to use them.

The module has to be called on clients that need to Fire these remotes as their secured. The module will basically be the main connection.

(Don’t worry. The module has a Server, and client mode to avoid clients running or seeing server stuff)

Server > CreateEvent(name,eventtype)

Create event will allow you create secured RemoteEvents, or RemoteFunctions. You can supply a name, and a type. The type can be either “event” or “function”.

Here is a basic remote example.

local RR = require(game.ReplicatedStorage.RevampedRemotes)
local OurFirstRemote = RR:CreateEvent("NewRemote","event")
CreateEvent() > KeyRequest()

KeyRequest will return a BindableFunction that will fired when someone requests a key. You must then return true or false if they should or shouldn’t receive a key. This key will be ONE TIME USE and will expire after the set time in the Module (Default, 5 seconds). If a key expires it must be Rerequested.

local RR = require(game.ReplicatedStorage.RevampedRemotes)
local OurFirstRemote = RR:CreateEvent("NewRemote","event")

OurFirstRemote:KeyRequest().OnInvoke = function(player)
	if player.Name == "Lakodex" then
		return true --This will tell the Serverscript "Yes" to give them the key.
	else
		return false --The player was denied the key. The Remote main remote at EventFired() will not fire at all.
	end
end
CreateEvent() > EventFired()

EventFired will be Fired once someone enters a Correct Key.

local RR = require(game.ReplicatedStorage.RevampedRemotes)
local OurFirstRemote = RR:CreateEvent("NewRemote","event")

OurFirstRemote:KeyRequest().OnInvoke = function(player)
	if player.Name == "Lakodex" then
		return true --This will tell the Serverscript "Yes" to give them the key.
	else
		return false --The player was denied the key. The Remote main remote at EventFired() will not fire at all.
	end
end

OurFirstRemote:EventFired():Connect(function(player,arg1,arg2,arg3,arg4,arg5) --Fired only when someone fired the remote with the correct key.
    print("Someone had a key and gave us a message! "..arg1)
end)
Client > GetRemote(name)

This will request Public Data on an Event. This data can be used to Request a key, or to fire the event.

Here is some example code to fire the event made in the Documentation “CreateEvent()”

local RM = require(game.Workspace.RevampedRemotes)

local remote1 = RM:GetRemote("fard") --This remote does not exist and will yield for 5 seconds until it eventually quits trying to find it. This is basically WaitForChild but for events.
local remote2 = RM:GetRemote("NewRemote") --This remote exists however. So it wont yield.

if remote1 then
    warn("Remote1 exists")
end
if remote2 then
    warn("Remote2 exists")
end
GetRemote() > Fire(key,arg1,arg2,arg3,arg4,arg5)

This will fire the access Remote. If the key is correct it will fire the BindableEvent that will perform the wanted task.

local remote = RM:GetRemote("NewRemote")

if remote then
    remote:Fire("lolfardbucket","LOL i hackered your game") --The Key is incorrect. The Remote wont fire.
end
GetRemote() > RequestKey()

This will request a Temporary one use key to fire an Event.

The decision to give you a key or not is deciphered by the Developer.

local remote = RM:GetRemote("NewRemote")

if remote then
    local key = remote:RequestKey()
    remote:Fire("lolfardbucket","LOL i hackered your game") --The Key is incorrect. The Remote wont fire. Learn how to get the key in the Next part of Documentation.
    wait(2)
    remote:Fire(key,"lol I have a key >:). I only have this key because.. IM LAKODEX!") 
end
3 Likes

I don’t get how this is useful because all clients can easily access this code? Knit already has a quite functional system to stop script kiddies and this wouldn’t stop any experience exploit developers. Looks like a cool system though so if this is your first module not bad.

Hey @RoloTheDevBunny

Thanks for you concern and opinion. I am always finding ways to make it more secure as this is a proof of concept.

Knit has the same security as a normal Remote event. Knit doesn’t have any features that stop the use of exploits. Simply put they just have their own remotes. If someone figures out the game using Knit all they have to do is fire the Signal using the module. Knit is more of a Script package (That just makes developing easier for newer developers) than a security application.

However. Revamped Remotes is still in development (an early release) and I’m always finding ways to make it secure and add more security features. You mentioned

I don’t get how this is useful because all clients can easily access this code

Not if the developer takes measures. The key system requires the opinion of the server before they receive it and if it’s accepted generates a random UUID for that specific player only and can expire. At this time however it’s underdeveloped and could definitely be more secure. That will change in the future.

This module does nothing to protect remotes against exploiters, the key system can be easily exploited by any experienced exploiter. Another issue caused would be an increase in latency since you have to request the remote from the server every time you want to call a remote.

2 Likes

Hey @TheBrainy06

If you could give me an example on how exploiters would be able to bypass the Key system without modifying the server in a Discord Screenshare I would fix the issue. However, you did not explain how it was bypassable to fix the issue (Or you just read the Module and didn’t try. You should always try before posting such claims)

The latency does exist however. But is too small to cause lag based issues. The only latency would probably be the developer putting wait or yielding code in the key request system.

And if you read the top of the post you may see this is a Proof of concept and In Development. In the future I am hoping to get this more secure for actual use in a game environment. As stated again Bugs, glitches, and possible bypasses can occur at this time as well as This is currently a proof of concept and this forum is to find bugs and bypasses and suggestions so I can fix them.

Thanks for your opinion. However, you did not state how and why the Key system is exploitable

My Discord: Laqota#7812

There is nothing stopping an exploiter from requesting a key and making a request. They could also just modify the data in an already existing request. Key systems are fundamentally flawed, and you shouldn’t really be focusing on them.

2 Likes

Hey @Pokemoncraft5290

If you have used the module yet the server fully decides if the Key is sent or not. This includes Control from the developer. While a key may be REQUESTED by an exploiter does not mean it will be given. Developers coding decisions, and server decision decides. A user is only limited to one key, and each key default expires after 5 seconds.

As the last reply I have not been given any details on how, when, and how again I could fix the issue. Which I’m implying you possibly just following up an opinion from the past.

I am always also finding ways to improve. Message me on Discord if you would like.

Laqota#7812

The key needs to exist somewhere in memory for the client to use it, which means that the exploiter can see it and use it as well. Again, security which relies on the client is fundamentally insecure, so the key system will always be insecure.

1 Like

I see. Thanks for your reply!

May the key be seen with a Remote Spy Program? Yes. Will they be able to use it to their advantage? No.

The key may be stored in memory somewhere by one request for it. However when the key is used it expires. After 5 seconds without use, it expires. This is only a One Use, 5 second expiration key that is created by the Server and sent. The key must be requested from the server using GetRemote() > RequestKey() and caught by CreateEvent() > KeyRequest() (Which is a BindableFunction). This request can be declined, or accepted by returning true or false.

The client cannot get information from the server without requesting it using a RemoteEvent.

Also. Thanks for your follow up! I’ll try making ways to make the entire system more secure in the future.

Again, there is nothing stopping an exploiter from just using it before a legitimate script does. Also, what is stopping an exploiter for just requesting another key afterwards other than the developer? There isn’t anyway to differentiate a legitimate request for a key from an exploiter’s request.

1 Like

Sorry for bothering you so much but this stands no chance against exploiters. Then can send, stop, view, and edit all remote events/functions incoming and outgoing. They can write a simple script to detect when this is defined/updated and update their variable using hooks. Imo this is a bad way to try to stop hackers. The number 1 priority is that your systems are secure. Some systems are harder than others but it is a better use of your time and processing power to do checks/generate the data on the server than try to validate requests from clients.

3 Likes

I believe you aren’t fully reading my posts. This is in development and I’m finding better ways to improve.

In the future I’m hoping to find other ways to secure. Instead of smoking on the module not being secure if you could tell me how It could become more secure I would definitely take your idea in to consideration. At this time however you have not supplied any information on how I could fix this, how I could make it more secure, and how I could stop exploiters from changing the information.

If you aren’t going to be any help to suggest, fix, or make better security for the module (as requested in the post) then please ignore the post.

Thank you for supplying this information. This helps tremendously in stopping the bypass of the Module.

However I’m confused on the part when you said

They can write a simple script to detect when this is defined/updated and update their variable using hooks

I believe that all information sent out through a RemoteEvent/Function cannot be changed and can only be changed before the send. If I could take notes on how I could avoid this type of behavior I would greatly appreciate it!

This is true, after all when you send a request you are just ‘talking’ to the person, it’s their choice if they want to hear it or not.

The problem isn’t that it can be modified before send, just that it can be received when it is sent and used. Before I give more input I’d like to know how this module intends to help with security, is it meant to ‘prevent’ exploiters by only allowing one key for the client, or what is it trying to solve and how does it solve it?

1 Like

Hello @STORMGAMESYT7IP Thanks for being interested.

I am planning to change the authentication method away from keys and to something more advanced. At this time however the system is using a one time use UUID key generation system per user only.

The client can request to create a key. The developer can then decide whether the key is sent or not with code. If yes, the key is then returned and can be used within’ the time set by the developer (which is default 5 seconds). It will expire after 5 seconds or when the key is used.

I get that this is under development, but what is the point honestly. Securing remote events is like obfuscating your code. Time consuming and useless

Anything that is local to the user’s machine can be accessed or edited. It doesn’t matter how many roadblocks you add, the car will just knock them down in the end.

2 Likes

Hey @2jammers

Thanks for an actual opinion and not just saying a fault and putting it in a way I can understand. I may discontinue the project if clients can still read Server Tables and access them easily. (However That should be something Roblox should fix. That could be a very good security risk in general)

1 Like

Use remote spy. You bypassed the module already. Win.

They cant read anything from the server. Unless the server replicated it to the client.

This is your first module, and im not surprised you thought this was a good method for preventing exploiters, you should read anti cheat topics before attempting to make anything like this

1 Like

Just like other developers mentioned, there is a problem with this module. If I am not wrong, the module is trying to prevent exploiters from firing remotes using a temporal key given by the server. There are problems in this system, which are the following:

  1. There is no way to distinguish a real script from an exploiter script: The exploiter can always just request a new key and use it to fire a remote, it doesn’t matter if the key is unique or has a limit, they can always wait and ask for a new one.

  2. Exploiters can always see their computer: Every single bit of data you send to a client can be seen by the client, this means the exploiter can easily hook when a key is sent and use it for 5 seconds to send any request.

Important things to note:

  1. Something I liked from this attempt to create an anti-exploit is that you can’t just ‘fire’ the remote using an exploiter tool, since from my understanding, the server events are hooked behind the sanity check which checks for a valid key, so in this aspect, the module is correct.

  2. You are searching in the wrong place, you shouldn’t try to prevent exploiters from firing or communicating to the server, where you need to focus is when the server receives the information and make the server ignore invalid calls and only accept valid ones (the so-called sanity check).

  3. In the future, try to avoid creating systems where the security relies on the client. Every single byte you send to a client can be viewed by the exploiter, after all, the exploiter owns the computer and can do whatever they want with it. Focus on the information you send to the client and rely only on information you know is true. There are many examples of true information:

    • The ID/Name of the player, essentially any information sent by Roblox: Exploiters can’t modify information sent by roblox since there is just no way they can. As long as the information comes from Roblox (such as the name of the player, the ID, etc…) exploiters will not be able to modify it. Please bear in mind that I mention information that comes from Roblox since some times this can be confused with methods that take in information from the client (like TeleportService, or the new URL feature which take input from the client and send it in services), this information can often be mistaken as sent by Roblox, when in reality, Roblox is just being the middle man.

    • Your information: You know that only you know your info, you know if you told someone else, and you know if you didn’t. That is why passwords or secret keys work for exploit prevention since you are the only one who knows such information. That’s why you can also use these as a method to prevent other people to access certain features.

I digress, the idea sounded perfect, and, in a world where exploiters can’t hook or know info in their own computer, it could’ve worked. However, we now know that exploiters can just check the info in their computer and hook functions to certain events, thus, making the anti-exploit useless. Sadly, this anti-exploit did not work, nevertheless, from experiences like this is where great knowledge comes from, so just make sure you keep on learning!

2 Likes

Thanks @STORMGAMESYT7IP

We really do need more people like you on DevForum’s. Not only you explained in detail why it’s a terrible idea but you also put examples on how the idea could be fixed and what to avoid. The other people are just saying “yeah they can hack it” and just leave without giving any details on how, and what I could do to fix it.

(It’s obvious their trying to get more comments)

I’ll try to find ways to avoid using keys, and doing as much sanity checks (as mentioned) as possible. Thanks!

2 Likes