Can we access "nil"?

[mightybaseplate (Opponent)]

Check “Solution” of this thread! This would not be a permanent fix, and could lead to more problems than good

Another Edit: Pretty much everything I said below is just completely a garbled mess that doesnt hold up, but ill leave it up for forum

Roblox has lead most developers to believe that “nil” doesn’t exist and can’t be accessed but more popular exploits like: Elysian, ProtoSmaster, and Synapse have a custom function called ‘getnilinstances()’ which returns a table of every instance inside of nil, these objects can be cloned, parented, named etc just like anything else.
If you’re unaware all exploits either parent their scripts to CoreGui (which can currently be detected(descendantadded on the datamodel + tostring)), or to nil (no way of being detected), by Roblox allowing developers to view this “nil” we can potentially detect if a new script is created.

Example:

Elysian names their scripts ‘tpircsnaisyle’

As we can see they’re parented to “nil”.

There are currently no other scripts inside of nil unless a developer places them there themselves.

We could easily detect when a script named ‘tpircsnaisyle’ is added to nil and assume that is an exploit.

Roblox allowing developers to access nil instances could eliminate exploits pretty much entirely,
nil is the only place developers don’t have access to which is also where exploit creators parent their scripts.

Doing this would leave exploits no other place to parent scripts therefore eliminating the only way they can execute scripts.
I don’t see any security vulnerabilities in giving developers access to nil but plenty of benefits this being the main one.

If I’m getting something terribly wrong feel free to correct me. If you have any other potential solutions for me those will help as well. Thanks.

[Autterfly]

This does nothing at all to help us because code doesn’t actually need a host script to run under. Simply feeding code into the VM would do the same, it just wouldn’t have access to a script variable. Not to mention anything can be used in replacement to “scripts”, and the way of getting things in nil could be compromised and disabled by an exploit.

This feature wouldn’t be useful for the suggested use case.

[mightybaseplate (Opponent)]

I’m not an expert but I don’t think there’s any exploits that work without having an actual script instance added to the game, they(exploiters) would probably have to come up with something else

[Kampfkarren (boyned)]

Let’s assume the exploit in question uses a Script object at all (with regards to feeding the instructions directly to the VM, something something protos).

What is stopping the exploit maker from just hiding the Scripts it makes when Roblox polls it?

[mightybaseplate (Opponent)]

If this is possible why would these exploiters not hide it like this in the first place, maybe it’s just an extra step and they have to do extra work? I agree that there is def more they can do to hide it so you are right

[Autterfly]

The LocalScript/Script instance has no actual say on the execution of the code besides some predetermined Roblox logic and a global variable from which to access the instance tree from.

It’s not about hiding the scripts, it’s the fact that the Lua VM doesn’t need a script attached to a thread to run any sort of code.

Exploits inject code and then set the script variable for convenience. Often times, this script instance was literally created via Instance.new('LocalScript') and is just a compatibility thing. No actual functionality.

[mightybaseplate (Opponent)]

This might be unrelated, but what one of my boys sent me is this:

elysian only executes the code when it detects that the script added is from elysian itself. Maybe this could just be redone if roblox lets developers access nil. I guess at this point this conversation isn’t about accessing ‘nil’ but just having more options to combat exploiters. They can always go deeper and hide so it might be a futile fight with trying to fix stuff like this

[mightybaseplate (Opponent)]

But yes, this clears things up a tad. Thanks

[Autterfly]

Adding more ways to combat on the client side is a losing fight; this may expose more security issues than it fixes, not to mention exploits wouldn’t need to implement this function on their own anymore.

[Semaphorism (standalone_ecu)]

One of my friends who is into exploits and helps me patch some exploits

Let me give my input on this, there is many reasons beyond that function why giving nil access to the normal game scripts is a bad idea. Since I own that same exploit let me dive into the function he uses. PIC BELOW. It accesses the LUA_REGISTRYINDEX via getreg() and gets where the GC table is stored. It’s more then what you see in that screenshot he posted. as you can see it get’s stuff that is in nil, but in reality that table contains everything controlled by GC. so essentially roblox would have to control what gets put in the “Nil access” table that is returned to you to ensure there is no security issues with normal game scripts. It will be more work then gain. Because exploits are well above the level of lua scripts and they can easily mitigate the issue before any lua script can do anything