Keeping your Game Secure: Part 1, Protecting Remotes

Resources Community Tutorials
#23

all the scripts in it will have nil parents just put the modules somewhere else or embed them or define them before niling the actor

#24

It will not be the same. As I have said in previous replies this will get more and more in-depth as I go. It’s not gonna be just basic things. Eventually it will get into a full on anti-exploit that anyone can make and understand how it works. Most of the time people just explain basic concepts, versus what I am going to be doing. I will also be turning this guide into a long-form youtube video. Please understand that there are new developers looking for things like this, and most guides are either outdated or don’t explain these concepts enough. If this isn’t for you, then don’t follow it and don’t comment on it.

#25

That is why I am doing this. I used to exploit, I know how it works from the inside, that is why I am working on a more in-depth guide and video form of it.

#26

Thank you for somewhat defending this guide, I do appreciate it.

1 Like
#27

Why not handle gui actions totally on Server scripts? Easy to handle in my opinion


#28

You want to largely avoid doing any form of user input on the server. Less work for the server itself and also if we can’t already handle user input on the server why would we be able to handle client-sided UI.

2 Likes
#29

Sure we can’t do anything with the UserInputAervice from server. But I’ve had bad experience with plethora of events, conditions, which is why I try putting plausible client inputs in server for concise code.
But you may be right, since my games’ guis seem to be visible slower than other games😅

#30

Are you sure? I think they may since you’re putting the Actor in ReplicatedFirst in the first place (Actor.Parent ~= nil) and just afterwards you’re setting it to nil
 so there’s a window of opportunity.

Ehm
 I’m not sure. All instances whose Parent property is set to nil are still stored in memory, and since many exploits directly inject code into the VM they have access to all memory stuff, besides they may check all threads currently running (let their Script instances being parented to nil or not).

Synapse is a script injector
 yes, uses a DLL injector which ‘injects’ the thread directly into the VM, but just for running scripts, so, yes, I agree with you in this one, there’s no real practical chance with Synapse.
Now, ‘unbypassable’, absolutely not: there’re exploits that inject the player’s Client before joining any experience, so, absolutely everything that happens to the client, is registered by this kind of exploits (in other words, they’re injected into the VM before ReplicatedFirst runs: so they have access to ReplicatedFirst in its initial, uncompiled state, still when the parent of Actor isn’t nil).

Take a look at this topic, it has interesting information about it:

#31

The content of your post is good, I like it.
One issue that IMO may be causing many of the negativism is that your title is “[
] Protecting Remotes”, and you’re only exposing one way to actually protect Remotes, ignoring other methods by doing so. So, I think many users are criticizing this in a non-constructive way because it doesn’t cover a more complete spectrum of this complex topic, “minimizing it to a simple, straightforward series of simple steps”.

I understand this is a tutorial directed towards a more beginner audience, but I believe, in a constructive way, that you need to convey so more explicitly.

Hope this helps!

1 Like
#32
  1. no executors currently have auto execute faster than replicatedfirst
  2. getnilinstances didnt show it (as soon as it was parented it wasnt findable) syn tried to stop people using actors with the actor library but getactors would either crash or not show the actor if nil
  3. synapse executed before replicatedfirst and roblox stores bytecode on the server + even if you do use auto execute to run before the script a client + client + server handshake will instantly ban them which would take way too long to bypass with getting banned and rejoining every single time

actor method ftw (unbypassable if u dont skid)

#33

Ah, alright, that’s an interesting perspective. I’ll surely look more into it!

Thanks for the input!

#34

I also try to check the leaderstats on the client and the server, so if the user changes their leaderstats on the client, and if it doesnt correlate on the server, the player gets kicked for hacking.

Scare the script kiddies

#35

What would be the benefit of changing the leaderstats on client? :thinking:

#36

If the user doesn’t really know stuff (like FE), so I scare them!

#37

FE is default on all games now, and leaderstats don’t replicate last I checked.

#38

I know that, it’s just I wan’t to scare dumb hackers who don’t know about that stuff

#39

I don’t know how that would “scare” them, it just wouldn’t do anything?

#40

The hacker would get kicked, and if the hacker isn’t knowledge they might think they got banned from the game, just a little troll