How to talk to server with out it being hackable?

Help and Feedback Game Design Support
, ,
#1

  1. What do you want to achieve?
    Talk from a local script to a script without it being hackable.

  2. What is the issue?
    From what I heard. A remote event can easily be hackable. I want to find a way to make it non hackable.

  3. What solutions have you tried so far? I’ve look online and haven’t found anything.

(This is my first topic, so please tell me if I did something wrong)

1 Like
#2

I don’t think this as possible as pretty much EVERYTHING that is on the client can be seen and messed with.

#3

script.Parent = nil hides the local script from hackers.

#4

before that is run it will be in the client though. Then they can just delete that line.

#5

it does make it harder to find.

#6

Why do you need a RemoteEvent? What does it do? What can exploiters even do with that RemoteEvent?

#7

Usually I use Remote Events, but I want to find a less hackable way to communicate from client to server. Exploiters can see what is put in Remote Events and when there ran and run Remote Events. So when you use a Remote Event it has a risk. I want to figure out if there is another option or a way to make Remote Events less hackable.

1 Like
#8

As far as I am aware, there is no way to prevent a malicious user from modifying the information sent via the RemoteEvent(LocalScript) to the server(Script). For that reason it is recommended you do server-side validation for any type of RemoteEvent.

Here is an article which may help too:

1 Like
#9

You don’t. End of story. Exploiters are smart, and they have access to everything on their system, and you don’t. Instead, focus on designing your systems to not be exploitable in the first place.

2 Likes
#10

Pass a checksum as one of the parameters each time a remote is invoked.

#11

What’s stopping the exploiter from just running the altered data through your checksum function and using that instead?

#12

How would I (as the exploiter) be able to pick out which function should be the checksum? Switching up the names of the methods.

If I could find the specific method you used to direct the calls (it might be directly accessible via ModuleScript), no RemoteEvent trickery can fix it. That is unless you intentionally use inconsistent parameter types across similar methods.

#13

I would imagine you can make it more difficult by requiring a key. The key changes every time the remote event is fired. The servers a new key to the client which cannot be seen to my knowledge. This should make it very difficult to hack. You can also implement basic sanity checks to see if they player is has the money/item or whatever to use the remote. This can be done with,

if somthing==something then (execute stuff here) end

this will make it impossible to hack, if not really difficult, and should scare script kids. This should solve 90% of problems, but it is impossible to make some things 100% secure, but we can get close to it at least.

#14

getnilinstances() is a thing with exploits, so no it will not hide

#15

It’s probably important to clarify that the only purpose of a remote is to transmit data across environments: primitives are copied if supported and instances are passed by reference, to explain it in summary terms. When it comes to security what you’re dealing with is receiving potentially tampered contents on the server, not anything else. It’s not the RemoteEvent you exploit.

Generally the rule of thumb is that you should never assume that anything received by the server from a client has positive integrity and that’s why you run checks or changes on anything received, respectively called validation and sanitisation. For example: you may want to do nothing if a client fires a remote without meeting certain conditions or you may want to cap a string off at 200 characters if an exploiter happens to send one with 500 and the server attempts to work with that string. Each case will vary.

There’s never a time where you will not be performing client-server communication with complete integrity; anything sent or received can be changed. It’s your primary job to mitigate as many vectors for cheating as possible based on the needs of your systems and experience as a whole; and also to ensure that if a vector can only be patched in a limited way or not at all lest you compromise a core aspect of your experience, that the damage that can be caused by that vector is minimal to none.

2 Likes