When people say don’t trust the client, they mean everything (including this) is vulnerable to spoofing. If your idea starts at the client and ends at the client, it probably won’t be effective.
3 Likes
It doesn’t end at the client. The server would be checking every so often using the remote, and if the client script’s response was in any way different from the correct response format of the local script, or the client script didn’t respond, the player would be kicked. So, if the script was disabled, replaced, or compromised by client-side exploits, the player would get kicked at the next check.
No, the idea ends at the client. There is absolutely no way to confirm the information going over the remote is legit and could be easily spoofed.
A purpose of not trusting the client is so you don’t have to worry about workarounds and instead concentrate on the necessary traffic.
3 Likes
Well I’m not sure how you can be sure of what I saw… unless you know EVERYTHING about Roblox or you can see me 
. Based on your reply it seems neither is correct. This magical “I.D.” you are so skeptical of is the number or asset I.D. or whatever the official term is. Just like all assets such as textures, meshes, and places have a numerical I.D. there is/was a website that uses that unique number to download the asset. The person I watched do it opened a marketplace script in Studio and found it was calling another script inside a different place… so he took the place number from that script and copied it to that website. The website popped open a dialog to download. The file downloaded was actually a regular Studio file and could be opened and edited. I watched him do this in person. Not a Youtube video and not a scam website.
To be fair, I don’t know if the place was uncopylocked. It’s true and I hope it can be fixed. This platform is just a big file server. All our hard work is on http/https web servers. I’m not sure what can be done to stop this. I stand by what I said and hope someone official here takes it seriously.
1 Like
Well, I’d say that’s quite the flaw right?
Not sure how this happened, don’t think you can just run a script inside of another game remotely and view the source of server scripts.
I’ve never heard of nor seen exploiters being able to steal server scripts. It just isn’t possible. My point still stands. There was a website that allowed you to take animations and shirts with an ID, but a game? No. Even if they had a backdoor into your game, how would they view the source of your server side scripts? Don’t think you can even print .Source of a script anymore. I believe it requires a certain level permission.
Trust me, I’ve been on Vermillion, and other exploiting sites. I’ve seen what they have to offer, and even THEY know they can’t steal server scripts. It’s common knowledge. If there was a way to just easily steal a game as you described, I’m sure Roblox would know, and it would be going crazy on Vermillion.
I am in no way claiming to know everything about Roblox, but I know enough about exploiting to know that you can only decompile local code. The game must of been uncopylocked.
If your friend has done this, has he not reported it? Apparently your friend has access to some sort of roblox servers which allows him to download any game with some magical ID he wants. What else does he have access to? Sounds like a way to get into some big trouble! 
If your friend has a report to make, they can go to https://www.hackerone.com/roblox and file a report.
Sounds like you’re describing an uncopylocked place, as the only way an external website could access these assets is if they were uncopylocked. As @WorldPosition correctly stated, it’s pretty improbable that any “server script” stealing was going on, as there is a bounty of a few thousand USD going around for that.
Since Occam’s Razor states the most simple solution is most likely the correct one, we can effectively deduce that the place you describe was uncopylocked.
2 Likes
Awesome explanation and has tons of information in it. Great work. 
It was a free model script for an elevator from the marketplace. I don’t know 30% of everything about Roblox so I’m explaining as best I can. That script had some functions, but the majority of functions came from a secondary script in this other place. The “other place” only held a baseplate and a script.
I’m not very friendly with the person now and it was at least 6 months ago. I did read the --notes-- in the first script and it sure seemed like whoever made it specifically designed it so it would not be copied. They stated something along those lines in the notes.
The reason I posted this here is because it was concerning. For me to file a bug/bounty report I’d need to find the website and maybe test it myself(?) That seemed like potential trouble all alone.
Since we don’t work for Roblox and didn’t create the stealing site, I’m not sure if any of us know if the simplest explanation is that it was uncopylocked. Roblox isn’t open source. We can’t examine all the code and thus we know half the information. There are many examples of harmful bugs in other systems over the years and the engineers knew about them, knew they were not fixable, knew all the company could do is keep quiet. Sometimes this info comes out after they finally can fix it. Sometimes we only find out after people died or money was lost. The Boeing 737 MAX comes to mind. Some Google and Apple stuff also comes to mind. I’m sure others have better examples as I’m writing this from memory.
I hope you guys are right because I really lost motivation thinking about an entire place file being stolen so easily.
About exploits that can be injected thanks to a backdoor inside a free model, they are Server Sided exploits. Make sure you have the best anti-virus plugin that detects the scripts inside a model so it knows that it’s suspicious or not.
1 Like
Last reply. We do know that you can’t steal from servers. There was a backdoor or it was uncopylocked.
Can exploits read variables? I.e:
local secret_variable2 = "omg_its_a_secret_smh"-- would they be able to read this?
local secret_variable1 = "omg_its_a_secret_smh" -- would they be able to read this?
game.ReplicatedStorage["Some weird name"].Yes:FireServer(secret,secret) -- would they be able to stop this from being fired?
I was thinking about starting up my anti-exploit as soon as the player joins the game, if they’re able to read script variables and delete them, then my exploit won’t work. Well, an anti exploit is better than none.
They can read variables, but not the variable names.
I highly advise aginast using a key system anyway. It inflates network usage. Program your remotes properly and an exploiter won’t be able to do anything bad by firing remotes.
5 Likes
What if the variable was passed on to the client with a remote event?
Exploiters can just modify the local script that receives the remote event’s message to print out what gets sent there.
Either that, or use something they call “remote spy” to do the dirty work for them.
1 Like
If the we-are-devs API is open-sourced, then would the staff have an easier time patch the exploits?
1 Like
Patching free exploits from WeAreDevs is hardly going to fix the issue. Free exploits and their limited APIs are almost impossible to utilize in more powerful scripts. So, yes. While it is theoretically easier to patch an open-source exploit, it won’t do so much to put a dent in the rest of the community or exploiting as a whole.
1 Like
So the best way is to make it so that the server is in full-control, also thanks for clarifying.
2 Likes
Exploits are practically unpatchable, because the code that “Patches” them can be easily removed because its on the client.
1 Like
Sort of. You’ll encounter times where this isn’t feasible - generally where you need quick replication, like with Phantom Forces shooting guns, it would be unplayable without compensation if all the damage processing was entirely server based.
So, a middle-ground is often found for these edge cases. One where reasonable requests can pass through, although there is non-zero chance that it can be exploited, the damage is mitigated as much as is possible / worth the time to do so.
But generally, yeah, the rules are:
- Server handles all the game logic stuff
- Client handles all the rendering and processing of raw information displayed to the clients
- Server assumes anything sent by the client or controllable by the client could have been forged, regardless of any security implemented on the clients.
5 Likes