Load wrapper loophole [CC1.8 and some earlier versions]

local fenv = getfenv(load)
fenv._G = fenv
fenv.error = function() end
setfenv(load, fenv)
load(string.dump(function() print("HI") end), "X", "b", _G)()

See "more correct" revision of code below. It does not affect _G, unlike this version
This shouldnt work…

b flag in load function is for binary chunks, which should be blocked by the bios

What version of CC is this, have you replicated the issue on latest?

Lupus590, on 24 March 2018 - 12:58 PM said:

b flag in load function is for binary chunks, which should be blocked by the bios

Eh. It doesn't actually validate that elsewhere, so you can still load binary flags by passing nil. Given that CC runs LuaJ instead of PUC Lua, it's really not a big issue - you can't actually exploit bytecode at all.

Lupus590, on 24 March 2018 - 12:58 PM said:

should be blocked by the bios

Here is the best proof I can give:
Though I cannot show you that I have not modified the environment, you can try it for yourself.

BTW,

SquidDev, on 24 March 2018 - 03:03 PM said:

you can't actually exploit bytecode at all.

Lyqyd, on 19 August 2015 - 01:10 AM said:

Obfuscated downloads are not allowed.

Bytecode exploit: write a script that deletes all files, compile it to bytecode, base64 it, write what appears to be an installer, de-base64 it at runtime, and pass the result into the hacked load.

More "correct" version of the code that will not override the global env. The previous code still shows the point, but was not 100% correct.

local fenv = {}
for k, v in pairs(getfenv(load)) do fenv[k] = v end
fenv._G = fenv
fenv.error = function() end
setfenv(load, fenv)
load(string.dump(function() print("HI") end), "X", "b", _G)()

Previously _G.error would be overrided, this still shows the point without doing that.

EveryOS, on 24 March 2018 - 09:53 PM said:

SquidDev, on 24 March 2018 - 03:03 PM said:

you can't actually exploit bytecode at all.

Lyqyd, on 19 August 2015 - 01:10 AM said:

Obfuscated downloads are not allowed.

Bytecode exploit: write a script that deletes all files, compile it to bytecode, base64 it, write what appears to be an installer, de-base64 it at runtime, and pass the result into the hacked load.

That's not really an exploit, and regardless, you can do that with source code to the same effect.

But still, I would think there would be a point to the (rather badly coded) load wrapper
Also, bytecode is still further from readable then source code. Plus, if you convert the hard-to-read source code to bytecode, it's even harder to read.

EveryOS, on 24 March 2018 - 09:53 PM said:

Bytecode exploit: write a script that deletes all files, compile it to bytecode, base64 it, write what appears to be an installer, de-base64 it at runtime, and pass the result into the hacked load.

Or, instead of doing that, you could just delete all files in the installer script. Maybe add 200 whitespaces in the first line and after that the malicious code in the same line so noone will know.
That's way sneakier than de-base64-ing some string and loading it.