James TheGreatSageEqualToHeaven

bypassing blocked function protections using corescripts

author: James Napora.

roblox and exploit fundamentals

corescripts have RobloxScript permissions on Roblox.
exploit function protections do not run on any threads except exploit threads.
roblox has several permission levels: None, Plugin, LocalUser, RobloxScript and Roblox.
actors on Roblox run whenever a script under it has a client run context, e.g local scripts, scripts with RunContext.Client and corescripts.
scripts under actors share the same global state

In the previous github gist we went over multiple ways DataStoreService could be abused to rollback data. This time we will be taking a more hands-on approach where you, the reader will be trying to figure out how to rollback data in a playground specifically created with the intention to teach you how to rollback data.

This time nothing you do will be pseudo-code. Everything you abuse, fire and interact with be real. Nothing is emulated in the playground and your data is actually rolled back because the datastore threw an error, all datastore requests use SetAsync and if datastores fail UpdateAsync is used to pull your old data and include a notice for when you rejoin to notify you that you have successfully rolled back your data.

An example notice:

You will need:

~~A working exploit~~ You can use the testing

Write-up

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.

DataStoreService lets you store data that needs to persist between sessions, such as items in a player’s inventory or skill points. Data stores are consistent per experience, so any place in an experience can access and change the same data, including places on different servers.

By default, experiences tested in Studio cannot access data stores, so you must first enable API services. You will need to do this to test the vulnerabilities.

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

	-- LOP_BREAK, LOP_COVERAGE and LOP_NOP aren't possible without the C API
	-- Vector constants are supported but need to be commented in and need the ctor renamed
	-- LOADKX and JUMPX support can be commented out
	---------------------------------------------------------------------------------------
	-- PREPVARARGS
	local a = "hello world"; -- LOADK
	a,a,a,a,a,a = nil, true, false, 1, 9e9, function() --[[ RETURN ]] end; -- LOADNIL, LOADB 1, LOADB 0, LOADN 1, LOADK 9e9, DUPCLOSURE (no captures)
	FUNC_GLOBAL = newproxy; -- GETIMPORT, SETGLOBAL
	local t = { }; -- NEWTABLE 1 1
	local function stub() -- NEWCLOSURE (ref, val, ref captures)

	local function luaVersion()
	local f = function()
	return function() end
	end

	if 0xffffffffffffffffffffffffffffffffffffffffffffff == 2 ^ 64 then
	return "Luau"
	end

	if ({nil,[1] = true})[1] then

	local function getOptimizeLevel()
	local function dupclosure()
	return function() end
	end

	local O0 = dupclosure() ~= dupclosure()

	local function inlinefunction()
	return debug.info(1, "f")
	end

	-- load

	local math = math -- GETGLOBAL
	local newproxy = newproxy -- GETGLOBAL
	local ipairs = ipairs -- GETGLOBAL
	local floor = math.floor -- GETTABLE KST(C)
	local pi = math.pi -- GETTABLE KST(C)
	local _nil = nil -- LOADNIL B -> C (1)
	local _true = true -- LOADBOOL B(1)
	local _false = false -- LOADBOOL B(0)