Exploiting Explained

Autterfly · August 25, 2018, 3:39am

Exploiting Explained: Second Revision

This post is a general information source on common exploiting terminology, tools, and methods. The formatting is in sections for each specific topic, and is in no specific order.

If you’re not aware of exploiting by this point, you’ve probably been living under a rock that the pioneers used to ride for miles. While Roblox is seen as open grounds for free reign of exploits, this isn’t the case, and I attempt to tackle this wrong assumption in this post.

The following sections cover common issues often brought up.

Asset Stealing

This section is dedicated to explaining asset stealing; place and source code stealing are covered here.

Place Stealing

If you’re wondering about place stealing in general, here’s what that usually entails. Someone has some kind of script executor, and a script which serializes your place into XML or a Roblox compatible format that Studio can open. Some exploits already come with this feature, others just use a script, but the gist is that they use data that’s already available to your client, which means it’s not something you can stop, or try to stop.

Some uncommon forms of place stealing might be tricking someone into giving Team Create access, where it’s possible to steal everything by saving locally. Additionally, very rarely Roblox could have a major security vulnerability, but then anything can happen.

Script Stealing

Script stealing is another issue similar to place stealing but quite different in practice. Script stealing is done by a process known as “decompiling”. Decompiling consists of using software to generate readable source code from already compiled Lua code, which is in a form called “bytecode”, and doesn’t contain enough information to usually convert back into its exact source counterpart. This process also can’t be stopped, but recent changes such as Luau using a new instruction set can slow down the development of the tools used.

Note that decompiling is not a perfect science. With Luau stripping debug information that Lua usually passed along, things such as local variable names and upvalue names are no longer retrievable by decompilers. On the same note, white-space, comments, and style choices are not stored in the bytecode either.

Lastly, decompiling is only possible on LocalScripts, and ModuleScripts used by LocalScripts. That is to say, Server scripts can not be decompiled, in any way shape or form. If someone obtains your server code, that’s a huge red flag of a different underlying issue. Roblox does not send bytecode from server scripts to the client, ever.

Additional Resources

Echo Reaper actually has a pretty good post on this, which details more than just the basics I mentioned.

Filtering Enabled & Exploits

A good way to get started is to echo what you always hear: under no circumstances should you trust the client with authority over your server game logic. When implementing your RemoteEvent and RemoteFunction code remember to think as the attacker. Your code should be built around thinking, “if I had absolute control of my client, what could I send over this bridge to break everything?” Design should be based around asking the server “can I”, and not telling it “I can”.

Think Offensive

A simple example is a store; ask the server, “can I buy this sword?”, and don’t tell it, “I can buy this sword.” The server should be the one checking everything from currency to experience points to levels, since it has the final say in what’s really happening. You should always be ready for someone on the other side of the bridge to outsmart you, and make absolutely certain the code you wrote is well tested for cases like someone throwing a NaN at you or expecting an object and getting a table that looks like an object.

A really common pitfall is the attempt to “secure” your remotes, or “validate” your data, and anything that is done client side. As a pro-tip: anything coming from your client will not be secure. It doesn’t matter how clever your system looks, or how much time it took you, you’re not the one in control of your client. If it makes you sleep better at night, the extra headache is okay, but you should not be relying on it to ever really work.

Think Defensive

Some exploits don’t actually rely on remote exploitation, but instead in simple things like Roblox’s rules of replicating properties. You might encounter these exploits in the form of flying, super jumps, or speed hacking. The issue stems from the fact that players have physics ownership over their characters for smoothness and fast feedback, but in turn this gives them the ability to move them anywhere. You can mitigate these on the server, or add basic checks on the client, but be sure to remember you can never actually rely on the client.

Stop Thinking

Lastly are maybe some of the peskier exploit types which are just plain local enhancements. These are usually undetectable via conventional means, if at all. You might see these in the form of aim-bots, auto-hotkey style scripts, and general automation of game-play.

Local Software

It’s about time to address software such as Elysian, Synapse, and others which enable users to execute local code or do other mischievous things. The software in question tends to fall into a few categories, some more common than others. The same tips as with the Filtering Enabled & Exploits section apply to mitigating these kinds of issues.

Script Executors

Possibly the most common, or at least most problematic type of exploit as of this revision are script executors. These exploits are centered around allowing users load Lua code into the Roblox client to execute as a regular script or disembodied code. Script executors tend not to be just limited to Lua you run in game or Studio, but also come with special features.

You might observe exploits of this kind bypass context level restrictions when calling functions, or have special API designed by their creators such as getrawmetatable or saveinstance. The special API also usually is made to bypass restrictions or read and write to thinks you shouldn’t be. The names “Level 4”, “Level 7”, and “Level” alongside any number ever were made to refer to these kinds of exploits and the fact they could access functions from higher context levels. The number itself doesn’t mean anything, and the terms are usually misquoted as meaning different things. A “Level” anything is just a fancy way of saying “script executor”.

Script executors have lots of ways of executing their code, and without going into many details I will list a few which were used once upon a time:

Proto Conversion - A normal Lua compiler would create a Lua function, and then some other code would convert the normal Lua function into one that’s Roblox compliant. This technique still sees widespread use.
Bytecode Conversion - A normal Lua compiler would create and dump a Lua function, and then some other code would convert the resulting bytecode into Roblox compliant bytecode. This bytecode would then be somehow loaded by Roblox.
Precompiling a VM - A really stupid method that works. People take a Lua in Lua VM such as FiOne or LBI and pre-compile it to be Roblox compliant, and then feed it with real Lua bytecode to run through the compatibility layer.

Lua C Executors

This is a very niche exploit type which surged from people’s laziness. Lua has a C API which is officially made for C code to interact with its internals easily. What “Lua C Executors” refer to is exploits that parse simple commands and call the associated API function. These are very stick and stone exploits, and usually don’t have much of a threat.

Command Exploits

The laziest of all, command exploits would present users with an interface with buttons. Each button would usually be bound to some string of pre-compiled calls to the previously mentioned C API, or some other code. When the user clicks the button, the code is ran. These are usually intended towards simple local exploits such as flight or teleportation.

Luau and the Future

This short section addresses Luau and the future of exploiting on the platform. Luau is Roblox’s implementation of Lua, which changes so much of Lua internally that it has its own effect on exploiting. Taking an opinionated side for a second, I don’t believe exploiting will ever cease to be a problem on the platform, but what’s going on behind the scenes to mitigate it certainly isn’t minor either. As it happens there will just always be people that want to mess with other people and games, and that’s an issue every game and platform out there faces.

What does Luau tell us? It’s an interesting change of scenery to the exploiting community. Previously it was possible to at least have a base to stand on when designing an exploit, which was Lua and its open source aspect. With Roblox now using a proprietary implementation of Lua that deviates so much from standard, only time will tell how this affects the exploiting community. It’s likely those who have always been here will stay, but the barrier for entry is certainly higher now, and developers as a whole should feel at least a little bit better.

What has Roblox done?

Roblox has done a lot, and mostly behind the scenes. They don’t talk about every new check or encryption they implement, or what heuristic they got working this time, and even mention that they’re actually working on this issue. The truth is people vastly over-hype exploiting as if anyone with mild knowledge can walk in and develop the next big hack. Instead of shouting at engineers, take a minute to thank them for what they do, and remember as a developer it’s also on you to practice good game design.

From the client riddled with land mines to FilteringEnabled being enforced, Roblox is always working on keeping its client safe. Likewise, people on the other side are constantly working to tear it apart. It’s a cat and mouse game.

Final Thoughts

Whether exploiting is still a thing or not, it’s best for everyone to try to just focus on making their game enjoyable and playable to users. Local exploits probably won’t go anywhere, and sketchy people will always be around. Designing your game to minimize impact and thinking about who is really playing it will save a lot of thinking and over-thinking.

Remember to listen to feedback from your players.

This post is subject to change should any of the information become outdated.

CheetahSp33d · August 25, 2018, 4:07am

Very informative. Good work.

grilme99 · August 25, 2018, 8:10am

You should explain how some games get leaked with server scripts and children from server-sided containers, because some people are going to be wondering it.

Just a heads up: the main reason is because developers give someone team create access and that person leaks the game.

TechnicalLad · August 25, 2018, 8:16am

Brilliant post and very informative, loved reading it. Keep up the good work!

konlon15 · August 26, 2018, 7:00pm

Thanks SO MUCH for writing this out! People have been saying that FilteringEnabled being forced doesn’t make a security difference since the client can “still run code”, which is just wrong. I’ll be copy-pasting this to prove them wrong.

Nuinik · August 26, 2018, 7:13pm

Cleared up my confusion.

Alkan · August 26, 2018, 7:25pm

What is stopping a talented exploiter from figuring out how to fully steal a game? Roblox has patched it many times and they always seem to figure it out again, even if it takes longer the next time.

SteadyOn · August 26, 2018, 7:46pm

Really useful! People jump to blame Roblox too quickly without looking into it themselves.

SteadyOn · August 26, 2018, 7:49pm

If you mean objects and scripts, they pretty much can any time; if it’s server side scripts and objects I think this happens when Roblox accidentally either allows non authenticated players to access certain place files or when an exploiter manages to access the internal game servers. I guess when running a game on massive scale it’s hard to keep track of 100% of the copies that are running at one time, or make sure users can access their places without exploiters being able to.

Autterfly · August 26, 2018, 7:52pm

Adding onto this; places being fully stolen through unauthorized means that aren’t directly Roblox related (aka not Team Create and such) are more serious security flaws which aren’t really related to client exploiting at all, but more involved with network protocol vulnerabilities and such. These are often rare; much rarer than something like a script executor.

DoomedPerson · August 26, 2018, 10:30pm

Thanks for the very useful info.

Nuinik · August 27, 2018, 12:20am

Wait can’t you just email ROBLOX to get your game not to be stolen anymore. I worded that terrible but I don’t know how to fix the wording Most of the games are named say, “Jailbreak Uncopylocked” Shouldn’t the uncopylock section be fixed. Also Uncopylock seems it serves no use except for stolen games. Team create can handle any deal that uncopylock does. It seemed like a super flawed feature.

Frxshy · August 27, 2018, 12:41am

I’m honestly hoping that ROBLOX releases a code or a model directly installed in your inventory or on ROBLOX studio, named ‘Exploit protection enabled/disabled’ or something along those lines. It would honestly remove unwanted stress and emails to ROBLOX.

Autterfly · August 27, 2018, 1:08am

It’s mostly about open source; I don’t see a problem with uncopylocked, as people can just save the place file and spread it even faster even without it.

LouieK22 · August 27, 2018, 1:59am

The (un)copylock feature serves quite a big purpose. Namely sharing code and demos with other the community. I learned FABRIK from the uncopylocked demo of it that’s linked on the wiki. They can also serve to preserve Roblox history by allowing creators to let others maintain a game long after the original creator has left the site.

EncodedLua · September 2, 2018, 9:30pm

Thank you for clearing this up for everyone. Maybe if you ever have time try to add why anti exploits that check a player’s character is more accurately handled by the client but is safer handled by the server. Maybe just provide a link to network ownership or something.

X_Z · September 2, 2018, 11:54pm

Here’s a basic(but not completely accurate since there is still a bit more) idea of thinking of what an exploiter can do: Whatever a LocalScript can do, an exploiter can do.

Dynastorious · September 3, 2018, 8:53pm

And more, sadly. They can access areas and change certain values we don’t have the permission to.

ClanDominus · September 8, 2018, 7:37pm

Great post, more people should know this stuff instead of simply yelling at Roblox.

DutchDeveloper · September 8, 2018, 8:02pm

My way to go against exploiting is to have safety measures. I 1 localscript and only modules. here’s how it works:

this script below stores the modules in a table for each module we send the list with the modules and module information and use Init a function in my module that will store the info and after it has send to all the modules it will delete them. so whenever the client tries to hack they cant get the modules. only this peace of localscript.

local Modules = {
	MenuModule = require(script.Modules.MenuModule),
	ResultsModule = require(script.Modules.ResultsModule),
	RotationInspecterModule = require(script.Modules.RotationInspecterModule),
	TimerModule = require(script.Modules.TimerModule),
	SettingsModule = require(script.Modules.SettingsModule),
	CodesModule = require(script.Modules.CodesModule),
	ChestsModule = require(script.Modules.ChestModule),
	BadgesModule = require(script.Modules.BadgesModule),
	Notifications = require(script.Modules.Notifications),
	SoundModule = require(script.Modules.SoundModule),
	RatherModule = require(script.Modules.RatherModule),
	StarterPackModule = require(script.Modules.StarterPackModule),
}

local ModuleInforMation = {
	Modules = Modules,
	ScreenGui = script.Parent,
	Player = game.Players.LocalPlayer,
	T = game:GetService("TweenService"),
	BadgeService = game:GetService("BadgeService"),
	MarketplaceService = game:GetService("MarketplaceService"),
	MainScript = script,
	Assets = script.Assets,
}

for i,v in pairs(Modules) do
	spawn(function()
		v.Init(ModuleInforMation)
	end)
end

for i,v in pairs(script.Modules:GetChildren()) do
	v:Destroy()
end

Why an i doing this?
My guis handle allot from effects to transitions. people that would steal it could use this for their own.
And i dont want my hard work to get stolen or used without permission.