- It doesn’t use remotes to send to the server, unless all other methods fail
What are “all other methods”?!
What other methods exist for programmers to instruct the client to send to the server? Where can I read more about this?
I can’t reference to them anywhere… missing something?
By methods I meant my methods. If remotes were the only thing that replicates then you wouldn’t be able to walk, chat or reset.
Doesn’t chat use its own set of remotes also?
That’s only for the gui. Internally it uses a half-lua half-C signal called MessagePosted to fire the Chatted event.
(by that I mean it’s created in lua but handled in C, somehow)
I think I would put that under the same category as things like ClickDetectors which receive events from the client, but it sounds weird to lump it in with replication related things like physics and the humanoid.
Well, it isn’t weird, because I’m pretty sure it’s replicated in the same way.
Roblox actually does say it’s handled in C on this page:
Fire this to make the player directly chat under Roblox’s C++ API.
This will fire the LocalPlayer’s Chatted event.
Please only fire this on the player’s behalf. If you attempt to spoof a player’s chat to get them in trouble, you could face serious moderation action
This is actually detectable! If you have your script send periodic reports and kick for excessive latency, you can probably write a script that uses hashing and obfuscation (among other things) to make it hard to edit. Furthermore, you can hook it into important parts of your game so if they do tamper with it it’s entirely possible they break the game for themselves.
They can get past that too. You rely on the client too much by expecting them to send periodic data and an exploiter is easily capable of producing those “reports” as well. It’s a client authoritative system designed to fail. The other two are in the same boat: you just make it more difficult for an exploiter to do anything, but you equally take the leap to shoot yourself in the foot for a small gain that, given time, can be passed.
Kick if they don’t respond and protect as normal server-side.
I’m not following. Please read my post again. An exploiter can spoof remote data and send valid bypasses over. A system expectant on client responses gives the client power and they are easily capable of bypassing that by sending their own data through.
At which point the exploiter has eliminated the client detections. Great! The server still checks everything.
The server checks what, though? What is there to check? Offering vague responses isn’t helping me understand the point that’s trying to be made here, which means loss on productivity and learning. What is the thought process here?
If a client eliminates the detection, does that not make your suggestion moot? Expecting client responses to pass through a remote is unnecessary work that a bypass can be quickly made for by disabling legitimate responses and setting up a sender in the background that submits spoofed replies every expected interval.
Using client side detection will catch skids that aren’t careful. Server side protections will mitigate those that are, and they are entirely dependent on the game.
You… still aren’t explaining your thought process though, so I’m getting confused as to what you’re trying to say here. You’re jumping topics and there isn’t a clear line of thought here.
A secure server-side as well as for remotes is a given, that has been mentioned several times already. Client-based security is just if you want additional measures, even though they can be bypassed. This is rehashing things that have been said numerous amounts of times.
Your original suggestions were on client-side detection and obscurity, both of which aren’t full security measures. Yes they can stop exploiters for a given time but it’s a matter of time before a bypass is created and you need to rethink strategies or scramble again. Where you lose me is a lack of explanation and a jump to a different concept to your initial one without indication of where it comes into play; it’s extraneous.
It is best to put your time, and effort into server-sided checks (Like raycasting to see if the client is noclipping), rather than client sided checks. Don’t waste your time on something that can be bypassed.
Oh no… I accidentally… Necrobumped, I didn’t realize how old this topic was 
From what I’ve gleaned this topic has been ongoing for a long while. I’m not sure if the original starter of it even cares about it anymore, and I think at this point replies are just repeating what has already been said.
So I’m not surprised you necrobumped as this topic has gotten a bit disproportionally inflated.
I’ll be producing a module to encrypt and secure remotes. So far strings. Numbers work. But not user data values. I’m working on it and I’m planning to make it security tight. Both sides have a unique algorithm. And even if you were to decrypt it. Your going to have to figure out what other small bits are. Because if you end up with one thing wrong. You’re banned.
Sorry about the bump. I just think that the whole security aspect on roblox is lacking. Although it gives developers a drive and something to dedicate themself too it’s a struggle to comprehend for new developers
There’s nothing lacking in security, it’s just people keep repeating bad practices such as encryption and other local methods which are often easily bypassed. It’s much more effective to plan the game from the client-server model POV and thinking like the exploiter.
Encryption isn’t what you want for remote events, as third parties intercepting them is not the problem. What would be a useful module to write is a robust server-side validation layer, one that handles things like type-checking of the RemoteEvent parameters, range-checking of the parameters, per-remote flood-checking, correct-context checks, authentication checks (for remotes that require elevated privileges, like admin commands), etc.
can’t someone use iron brew/aztup brew to obfuscate scripts
or if they are a savage, obfuscate an already obfuscated script.
can’t that work or
(just realized this post was inactive a year ago dang)