Creating modules to hide game assets in repstorage

I’m not sure if this is the best place for this; But I am trying to make my game less exposable by hiding remotes and other client side objects such as level pieces and scripts.

The issue is that I am not sure if I’m wasting my time doing this.

I read somewhere that a way to hide local objects is to place them all into modules at runtime, and delete the folders that originally contained them; and then access these objects through the modules.

I don’t fully understand exploiting, but this seems like it would be great if it works. My game is already at a point where doing this would be tedious. Is it worth doing?

Well, I never heard about that module thing but I can explain you some things about the Exploits and Events.

The exploiters can access to any type of Client-side Script or RemoteEvents (Also bindable events, if they are Client to Client).

Trying to avoid the RemoteEvents is so hard, they are so useful but dangerous. The best things that you can do is using keys to ensure that exploiters can’t access and hiding the Server-side things.

The scripts can be seen by exploiters but not modified, but if you give them RemoteEvents will allow them to modify the Scripts. The hidden scripts can be modified with RemoteEvents but can’t be seen by exploiters.

It’s like fighting with an invisible enemy, you don’t know where it is and how it is.

To hide them, there are some parts of the game were you can hide them with no need of using any type of module, like the ServerScriptService or ServerStorage.

1 Like

Exploiters can retrieve unparented or destroyed objects whenever they want. If it’s something in their computer’s RAM, they have access to it.

You should put stuff into ServerStorage instead if LocalScripts don’t need them.

2 Likes

Cheaters can get access to whatever his own computer sees and runs. This includes all visible services for client (all except ServerScriptService and ServerStorage). They can both just copy all models and decompile LocalScripts. You can’t prevent this. I would suggest focusing on protecting the remoteevents to avoid abusing them instead.

1 Like

Keys used to communicate from the Client to the Server are also pretty much useless. Some exploits have a “Remote Spy” tool that will let you see the data being sent through all RemoteEvents from your client. The exploiter can simply check to see what the Key is and start firing RemoteEvents in your game with no problem.

As @Etheroit said, arguably the best practice is always to implement good sanity checks on the server, and to not let the client dictate things like amounts. For example if you have a RemoteEvent for purchasing an item in your game, do not let the Client tell you how much it costs. The Client should send the name of the item (or similar identification of what they bought), and the server should decide how much currency, etc. to deduct from that item.

2 Likes

Thank you all for the valuable advice!

So, if I understand correctly, using a module wouldn’t really work, since they have access to the replicated storage, and thus making the module readable anyway; Giving them access to the remotes and their names.

What about renaming my modules to something that couldn’t be understood… But as I write this, I think to myself, if the code is visible to the client, then they can just see what the remote is firing to with a little bit of reading… So that doesn’t seem to be a good idea either (And is just more work for nothing)

Since my game is heavily reliant on the client, and although I am taking all precautions I can possibly think of; Is it even necessary to hide all my scripts? I also don’t want someone to steal my work, and make their own game using my assets; Would placing them all into a module solve my worry?

You shouldn’t even bother with hiding instances from the client, exploits will be able to get anything even if it’s parented to nil. The exception is when instances get garbage collected, but it’s only useful doing that to LocalScripts

1 Like

so lets say that I place a folder in a module as a clone, and destroy the folder; Leaving me access to the module to get whatever information I need from it. This seems like it would prevent the exploiter from getting direct access to the overall scripts, just not workspace itself. So the exploiter would need to play each stage to get the info from each stage in order to get the assets.

Edit: and furthermore, I could just send that folder to be garbage collected immediately after getting its contents.

Rename, reparent, do what you want, it’s all a colossal waste of time. Developers have brought up this topic ad nauseam and the responses are in the same manner. The only person who’s foot is getting shot here is your own. If it’s on the client at all, an exploiter can access it.

I’m not sure where the heavy reliance on modules is coming from since it’s brought up frequently, but using a module doesn’t suddenly secure your code. It is simply a script fragment only ran upon being required which can also return values.

most exploits support a function called getnilinstances which returns a table of instances parented to nil and when instances get deleted they end up in nil

also it can’t be marked as garbage unless it’s not being used by anything

1 Like

elaborating on my edit above:

I could just send that folder to be garbage collected immediately after getting its contents. would this remove it from nil?

does it make saving a local copy of the game nearly pointless? since they’d have to re setup the entire project by playing the game all the way through.

sorry for spamming. Lots to respond to :slight_smile:

so cloning something and sending the original to garbage would make the clone nil? I suppose I could try it out, but I can’t see anything outside the workspace.

Doesn’t matter what you do. Bringing up hypothetical situations doesn’t help the case any better and neither does relying on hacks and weird systems that do not belong in production code. Clients can tamper with anything that is visible on their end, regardless of it’s in the DataModel or nil.

This topic has been brought up countless times so please do search other threads first.

something won’t be marked as garbage by Lua unless it has zero references and is just taking up memory, marking stuff as garbage isn’t something you can do (atleast not in Roblox’s Lua)

1 Like

I have actually looked into this for several months; but still haven’t found the answers Im looking for.

I’ve heard people say that the module system works, and others say it doesn’t.

Others have set up ways to prevent exploits, and others have argued that its pointless.

basically, I see 50/50 saying ‘yes’ and ‘no’ respectively.

at this point, I’m trying to see what can and can’t be done. what should and shouldn’t be done. get some opinions from people who have found ways to prevent this; or if there are even any realistic ways to prevent this.

How can I keep my assets safe, is the main question at this point.

and if all client side items are exposable, then whats the best way to handle a client side game?

im creating a puzzle game where each player is loaded into the server, and share the same stage base. but each client is given their own instance of each stage, allowing them to complete the stage without being interrupted by another player (If that makes any sense).

Edit: So no garbage collection function in roblox lua, eh? I come from unity and other engines; So I was hoping I could rely on this.

It’s a pitiful experience for Roblox Developers to constantly get their worked copied, decompiled and abused in general but you shouldn’t worry about such thing other wise most front page games won’t be able to stay where they are and all of them have been abused but no major damage can be done.

Like everyone else said, have smart sanity checks; check on both the Client and Server and check for impossible request like for example; the Client will never send a remote to buy something they they don’t have enough money so if there is a request you know it’s an exploiter.

1 Like

This is the third and final time I’ll be mentioning it: anything the client can see, it can take. Geometry data, sounds, animations, images, meshes, unions, does not matter. The client requires access to it, therefore it can see it and therefore also it can take it.

Roblox does what they can to secure the engine natively but ultimately the only thing that is truly secure is your serverside items. Anything else, regardless of where it is, is fair game for exploiters. That includes nil parented instances.

A lot of responses are going to come from failure to understand how a certain implementation actually works so if you’re following discussion you need to read everything and verify the credibility of responses and take multiple opinions as well as not take them at face value.

Your only other option, if not to use the server, is not to develop at all. 100% surefire way to stop your assets getting stolen and I’m not even kidding when I say it. Stop developing here and now or don’t worry about something inevitable and end up shooting yourself in the foot for nonexistent gains in combating this by implementing terrible production code you believe will stop an exploiter from obtaining your assets.

The best way to script a clientside game is just to script it and ignore the fact that it can and probably will get stolen. That happens to countless developers. Shrug it off and move on. Take up issue only with people actively profiting off of your work or getting popular with it.

1 Like

As said previously:
All client side items are exploitable and readable. Assets. Models. Scripts. Modules. Functions. Cheaters can even change their UserIds locally or block functions. That’s nothing you can prevent.

The only thing you can do is making server scripts not exploitable.

tl;dr
LocalScripts → Client (Exploitable)
ModuleScripts → Client & Server (Exploitable)
Scripts → Server (Not-exploitable)

Changing the name, reparenting to other instances and other methods won’t work.
The only solution that could work was making messy line of or operators in script which would cause the exploit code (decompiler) to crash. This was only a bug and is probably fixed already though.

Same thing happens with other games sort as CS:GO

You can download all assets, decompile scripts, make exploits, blocking things. Nothing will stop you, because that’s how a server (Roblox) trusts your PC. Roblox can’t do all the math, physics and generate graphics for you.

This is kind of “downloading” the game along with models, modulescripts and localscripts when you join the game. It stays saved somewhere on your PC and you can access it. Nothing to prevent that.

1 Like

Well I quit… Jk.

So from what I understand; Nothing can be done to prevent this. Accept it and move on. lol.
Thank you all so much for being blunt and honest with me. :slight_smile:

Edits: Besides sanity checks; I’m going to look into this now :slight_smile:

1 Like