They don’t really escape the sandbox to say.
They usually grab the functions such as Lua_GetField Lua_Pushfield and other C functions some may grab Lua_LoadFile in which they can just execute variables then they grab the VM pointer and use the said functions to run code in the virtual machine that they aren’t suppose to! Then there are of course security checks in which they just bypass via assembly manipulation.
1 Like
For The Former, They Worked Around Those Checks And Are Now Distributing Copies Of Their Exploits That Do That, And Making Money Off Of It. Which Was Kind Of The Point Of The Thread.
1 Like
RobloxLocked is all or nothing. If it’s locked, can’t do anything. If it’s unlocked, expect someone to be reading your Robux value, age label, and move the purchase UI buttons to somewhere you won’t think twice to click them.
The reason that exploiters can bypass checks is due to the nature of exploits. All of the functions you’ve listed are custom made by the exploit developer, they don’t exist in Roblox. They are made to interact with Roblox’s code, and achieve the effects they are made to do.
Here’s a good way to think about exploits. Think about an exploit like it directly modifies the code of Roblox, or directly modifies your script. If Roblox, or you add code to “check for an exploit” whatever that check may be, the exploiter basically has the ability to remove, change, etc that code. Roblox has lots of code on the client that do all kinds of things, and an exploiter is basically able to do anything with that code. Use it, modify it, disable it, etc.
Context security levels are something that is in Roblox’s code. They have to be. Roblox uses them to determine if a script is allowed to use certain features. Well, since Roblox has context security levels, it must be possible to also set a context security level, otherwise how would Roblox use them in the first place? Maybe the code to do so isn’t present and instead the context levels come from somewhere to begin with, but even then that doesn’t mean an exploit developer can’t write their own code to set it based on where they’ve seen context security levels being used. So an exploiter can use the existing code, or even write their own code to do different things, and then make the context security level anything they want.
As to how an exploiter actually does this “code modification” it gets a little more complicated and it comes down to how Windows (and computers work). I like to think about computers like a machine that can read and write in different notebooks, and based on what it reads, it does something different, but the machine doesn’t do anything on its own. This draws a lot of parallels to actual terminology too, such as reads, writes, memory pages, etc, which is useful.
First, when you run a program, like Roblox, that program is just a file on your disk, which is again, like a notebook. Windows has its own code to look at that file, and interpret what that file is “saying” (reading the file). Windows will load the file into memory first. Memory is like another notebook, similar to your disk. Memory is much much faster than disk and has a lot of special properties, which is why your disk isn’t generally used. It’s like Windows is writing down a copy of the data from the program. Next, Windows will look at what Roblox tells it to do, for example, it might say “write something in your memory notebook here” or “compare these two things in memory.”
Well, an exploiter basically is just doing the same thing. They are adding their code to this memory “notebook” and making changes to Roblox’s page in the “notebook.” They can effectively change anything in the notebook, and thus change how Roblox acts. Obviously it’s a lot of work for an exploiter to figure out what Roblox is writing/reading in the notebook
and what it means, what it does, etc, but, they can still do this using different tools and knowledge that already exist.
So, tl;dr, it’s not truly possible to completely stop a client-side exploit ever, no matter what. No client check could ever prevent itself from being bypassed, this is just impossible due to the nature of how computers work. The only thing you can do is to make it harder for the exploiter to exploit, but if they are determined, they will eventually get past the obstacles you put in place by using other pieces of existing code, modifying or deleting those obstacles, etc.
7 Likes
Exploiters can do things developers can’t even do, with exploits. Exploiters use softwares such as Synapse which allow them to do things like kick players. But these are only client-sided, I believe.
https://developer.roblox.com/en-us/api-reference/class/Instance
RobloxLocked is a “deprecated property” and I am pretty sure it DOESN’T do much anymore.
And exploiters can just use custom exploit API like “sethiddenproperty” to disable it… but on the client only…
and PLUS RobloxLocked was specifically used to protect CoreGui objects…
After reading some post and replies. Roblox allowed us to open CoreScript in Roblox file, not sure if I am right but exploiter can add a file into core script folder and run the code. It’s impossible to fully prevent hack, best option is minimize task done by client.