I recall an engineer stating in some thread that they’ve made remote throttling better, and that they couldn’t be spammed by exploits as easily. I don’t remember which thread it was, it was sometime in 2018.
1 Like
PurchaseGold should be unexploitable in new servers… thank you
1 Like
I can’t find an article for that, but the limit is 50 KB/sec occurding to the roblox dev site
https://developer.roblox.com/en-us/articles/Remote-Functions-and-Events
1 Like
I heard a few people talk about this here and there, but I’m still super worried about this. If you could find that reference it would be great
As I said before, you should be having a debounce for each client on each remote. Despacito has said that he spams your remotes to get free money. I believe he mentioned that he could spam {0,0} to the purchase gold remote and it will glitch out the remote.
As for the combat one, combat should 100% ALWAYS have a serversided debounce. It should be handled 100% on the server. The client should literally only send when the player sends input.
Bottom line is, your hacker is very helpful in dispelling his methods. Remember to never trust the client and flag any sort of suspicious activity to your mod team. If you find exploiters in a server, you may want to ask about what sort of vulnerabilities they are exploiting (if they give it to you) and put in server side warning to see when remote events and functions are firing and from what client they are from.
Also people are talking about a limit on remote events - I’m not sure if it’s a real thing but the exploiter I asked said he had no trouble spamming remotes.
EDIT: So it is a real thing but the exploiter still was able to spam remotes. ¯\_(ツ)_/¯
3 Likes
4 Likes
as i mentioned in my reply, there is a limit in place internally. you can’t trigger the limit under normal conditions, the limit tl;dr will prevent bursts of event invocations at a rate faster than you can achieve normally, hence the denial of service attack.
events shouldn’t have a debounce unless necessary, it’s clunky. I outlined how to properly implement this in my reply too, however the issue you mentioned should be resolved with proper error handling instead of adding an arbitrary debounce (plus the $ shouldn’t be sent as an argument to the server anyway).
4 Likes
Make sure you “Type check” what gets sent from the clients aswell, if the server is expecting a string then make sure you check if its a string. Expecting a number? make sure its a number. @Osyris has a great module for stuff like this. "t" - A Runtime Type Checker for Roblox
2 Likes
In OP’s case, it is necessary as the exploiter was able to spam events enough to glitch them out. Now, of course the events could be glitching out for other reasons besides a lack of a debounce, but it was the first thing that came to mind as it happened to me once.
Proper error handling is a must and should be implemented always. I’m not sure if it will fix everything here, but it will definitely help OP
it isn’t necessary, in-fact I’d say it’s counter-productive. type check input and implement proper error handling instead of manually rate limiting the events, which takes time and can get pretty clunky.
compare something along the lines of if typeof(x) == y then ... else ... end to implementing limits on the logical functionality of events.
Not trying to bag your work or target you, but I’d recommend against doing that for those reasons 
.
4 Likes
I believe the current vulnerabilities Despacto used are fixed. I will get to type checking next, this was also something I was unaware about.
Thank you all so much, this has been extremely helpful.
This is not true and nothing but a baseless accusation. Please do not spread rumours.
Aside from the responses already given, well, your post is fairly vague. You haven’t explained specifically what exploits you’re encountering, only a list with “etc” attached to the end. That being said, the exploits you listed are just common cases of bad coding structure and lack of security.
Remotes are rate limited on the backend and if you drop requests that don’t pass checks, then exploiters firing remotes is a non-concern. They already do that with several games. Unless your remotes are accepting those requests and doing something expensive each call, doesn’t matter.
Look into securing your server. There are tons of resources in and around the DevForum regarding exploitation prevention and such.
FilteringEnabled is default in all games and cannot be toggled. Proper way to refer to a “FilteringEnabled game” is just a game. Games that didn’t have FE were experimental games. There’s no such division between “FilteringEnabled games” and “games” anymore.
And it’s typically these exploiters that most likely have dynamic IPs or VPNs as well for that very reason, ignoring the casual ones who don’t have any understanding of cleaning up their trails. Don’t rely on any kind of moderation; it’s fancy to have and it blocks out an account but it’s not scalable. Most exploit prevention should come down to automation done by your server.
Shooting yourself in the foot for no gain is a bad idea. This is a form of security through obscurity, which isn’t obscurity at all. Randomising remote names gives you no gain. Exploiters can read the traffic going to each remote and send their own input or track down the purpose of a remote.
False positives can be flagged. Major money gain in games does exist. In the first place, this won’t do much: an exploiter can work around this very easily. Increment small numbers or adapt to the watching that the server does for values. Simple answer is not to let the client be authoritative of any stat exchanges, it should only be sending requests.
1 Like