A warning to Roblox developers about a powerful exploit primitive. In this, I will detail the research I’ve conducted into this attack vector and walk you through how you as a developer, can protect against exploits with primitives like this.
.The idea I wanted to explore when pondering the above question was; can we exploit remotes to prevent data from saving? It is easy to blame the developer for not protecting themselves against such a simple exploit but it ends up being more complicated than that. I found plenty of examples of these vulnerabilities occurring in many popular games such as “Adopt Me!”, “Jailbreak”, “RoCitizens” and many other games.
The reason such an exploit becomes extremely powerful is because of different types of a game’s economy design. Some games may not be affected by such a vulnerability and other games might. An RPG could have a boss that you can only fight once per day per player and it could have a chance to drop a rare in-game item, the vulnerability would allow an exploiter to constantly rollback their data and attempt to get the item again. A great example is “Adopt Me!” where the game has a very stable economy due to the effort put in place to prevent exploits, the game economy could become compromised due to a wide-spread duplication exploit using a rollback.
Hi all, a while ago I released this github gist detailing various ways a malicious actor could cause a data rollback.
In an example explaining how simply a short 1 character string can cause a data store error there use to be a different patch I presented, someone posted a what I thought was a better solution using utf8.len but yesterday I found out that it isn’t a solution because it can be bypassed. I’ve updated my gist since to remedy this. The new patch, instead of utf8.len can be found here.
This is a nice little comprehensive report for newer developers who don’t quite understand the importance of checking data sent from clients. In my opinion, you do seem to be heavily dramatizing the topic of “remotes can be exploited if the developer doesn’t check the data sent from the client” throughout this writeup.
I am not heavily dramatizing. This is a rather big issue that developers ignore, all remotes should have their parameter types checked at run-time and protected against any case. The fact that these primitives are so common in popular Roblox games and the fact that this same primitive is becoming more known to exploiters is a huge issue. The vulnerability can affect game economy which I detailed in the third paragraph.
Game economies improve metrics in analytics and revenue so most games have some type of economy. Game economy becomes a very complex topic when it comes to multiplayer games, this includes trading and having a stable economy. There needs to be a clear balance between a “tap” and a “sink” which also influences player motivation (look into the pinch point). This vulnerability is quite a big issue when it comes to such aspects and why developers should put effort into properly securing their remotes.
Most of the games that fall short on fundamental remote security typically aren’t games that have enough players for the economy entering a downwards spiral to take any nonnegligible player count with it.
Why would I mean “new developers” I mean all developers in general. If you read the write up you’d see that the primitive has been present on popular games made by “experienced developers”. I talked to quite a few different developers who are very experienced to make sure the document was explaining everything properly.
I’ve been developing for a long time, and only months ago was I made aware of some of the more serious ways people will try to take advantage of your game.
You are severely underplaying the value of this thread, as it is in fact a useful thread. Dont hate on people for no reason. This isnt dramatized. You should see the things exploiters do for an economy advantage.
This point is actually explained in my small explanation about game economy in the 3rd paragraph
An RPG could have a boss that you can only fight once per day per player and it could have a chance to drop a rare in-game item, the vulnerability would allow an exploiter to constantly rollback their data and attempt to get the item again.
I do believe this is on the developers, because something like this is easily avoidable given you filter the arguments received by the client, which I believe should be standard practice?
I think it bundles down to the more widely used quote; Do not ever trust what the client sends this rule being ignored in the above exception.
And so, I’m grateful someone wrote about it, hopefully this can attract more eyes!
I actually learned about this a while ago ~ people sending instances through remotes can be exploited using tables…
A few of the points are rather obscure to even know about, such as saving invalid bytes and NaN. I could only find 2 lines in the data store documentation mentioning how these bytes cant be saved and the NaN vulnerability is caused by needing a serializer.
ChangePetName:FireServer({
PetId = 1,
PetName = "\255" --// Originally a name
})
True, they are obscure, but the point of filtration is to filter these points ~ as an example, if I wanted to allow the player to choose a name for their pet;
Event.OnServerEvent:Connect(function(player, petId, petName)
Ser.AssertType(petName, "simple-str")
-- Ser being short for Serialisation
-- AssertType validating that string with an serialisation function of the name of "simple-str"
-- if AssertType fails ~ this function will error.
doServerFunction()
end)
I do still believe this is down to the server and how you program your code, and I do believe exceptions like these will happen, and they should be documented.
But at no point can you blame anyone else except for the developers for being unable to comprehend that exploiters can leverage these methods…
I’ve also a question ~ As for my DataStores, I encode and decode my data using a custom JSON parser, so would this really have an effect?
I am honestly not sure if you would be affected by a JSON injection. The game I tested it on had a house editor and had a billboard furniture item so I had managed to do an injection after figuring out the format and injecting a 2nd furniture item. You should read the article and test if you are protected against such injection attacks.
Oooh, that raises a good point ~ Assuming the JSON injection would look something like the following?
:FireServer('Hello! ", "abc": 123')
They could potentially overwrite previous statements in the DataStore JSON - but I wouldn’t think it would get past the generic serialisations I use since it is somewhat obstructed characters like :, "
This makes me question if I should create some sort of library for advanced assertions ~ would it be helpful if I could narrow or try to eliminate as many of these as I can
I doubt any exploiter on Roblox would be smart enough to attempt a JSON injection since most of the time the exploiter does not know that you are using a JSON on the server unless that information is on the client and a reverse engineer would attempt to abuse it (and know how)
In the article I provided you can find this simple example of a JSON injection
relatively large games actually don’t check for these types of exploits because they’ve only started sprouting up in the past few months hence they aren’t really used in public release when it comes to data abuse. there isn’t really any reason to direct this to ‘newer developers’ and the appropriate target is all Roblox programmers :]
thank you @EtSapientisMagna for this useful resource, hopefully developers can take this into account when developing games that allow data manipulation via remotes.
honestly the “NaN” value on Roblox isn’t documented properly in the wiki and frankly really shouldn’t exist as it is just problematic.
