According to the repository's readme, an exploit doesn't actually need to support the entirety of the UNC API for it to display its participation in the consortium. Even though this kind of defeats the purpose of a unified consortium, I suppose some exploits cannot implement everything the UNC prescribes so this makes it fairer for them.

The problem this creates however is some developers will assume a UNC-branded exploit supports all UNC functions. This problem may get worse if the developer doesn't test on more than one UNC platform and ends up releasing his supposedly "UNC compatible" script, only for users to complain that it doesn't work on their exploit due to unimplemented functionality. To fix this I suggest that a function be added to return a dictionary of supported features, similarly to how the cpuid instruction tells a program the features of the CPU it's running on.

The table it returns could look like this:

{
    websockets = true,
    filesystem = true,
    profiles = false,
    -- ...
}

Then retrieved and used like this:

local supported_features = features()
if (not supported_features.websockets) then
    error("Your exploit does not support the WebSocket API.")
end

Calling a function to retrieve supported features is more intuitive than checking the environment. Anyway, the UNC was literally designed to avoid checking the environment for stuff, so this fits the bill. We could also add a third return value to identifyexecutor but then the alias becomes a bit of a misnomer since it starts checking more than just the exploit's identity.

• Feature Name: standardise_environment_checker
• Start Date: 2022-9-10

Summary

Standardise UNCCheckEnv.lua to either be written in 100% Luau or in 100% PUC Lua 5.1, in order to improve legibility without needless sacrifice of compatibility, and vice versa.

Motivation

The current version of UNCCheckEnv.lua contains Luau features such as compound assignment (+=, *=, ..=, etc), but also unfriendly PUC Lua 5.1 idioms such as a and b or c. This sacrifices the utility of the script on 2 fronts:

1. Compatibility issues with non Luau executors (if any such UNC compliant executors exist)
2. Sacrifice to code legibility due to PUC Lua 5.1 idioms and lack of type information

This can be corrected by switching to complete conformance with either Luau or PUC Lua 5.1

Reference-level explanation

The implementation of this feature only affects the conformance checking script, and not the standard itself. As was discused, complete conformance to either Luau or PUC Lua 5.1 is the goal, which would be achieved by converting PUC Lua 5.1 idioms into Luau idioms/features, or vice versa. For example:

This PUC Lua 5.1 idiom:

local x = switch and a or b

Can become:

local x = if switch then a else b

With much better legibility.

The same is true with:

for key, value in ipairs(table)

As it becomes:

for key, value in table

(There initially used to be a performance drawback to the 2nd, but this is no longer the case)

And finally, this is especially important with function prototypes/signatures:

local function concat(...)

Can become:

local function concat(...: table)

Drawbacks

This may compromise legibility for the sake of compatibility, or vice versa; there is no perfect outcome in this situation, but the maintainers have the final say on what to sacrifice for what.

Rationale and alternatives

The only alternative is to do nothing, but taking a decision now is imperative. The UNC is an important standard, and it only makes sense for the conformance checker script to conform to a standard as well, leaving it in limbo is hypocritical and can cause problems for people down the road.

Prior art

0866 made a contribution that greatly improved the performance and legibility of the script from its initial iteration, but the changes were inadequate and the current iteration remains in limbo.

Unresolved questions

The main unresolved question here is if there are any UNC executors without Luau support that would get affected by a change to Luau, or are currently affected by the presence of Luau-only features in the current version of the script.

basically what the title says

will throw "attempt to call a nil value" on getscriptclosure test, even if all the functions there actually exist, could you look into this?

I believe if there is an official alternative to getting a table's readonly status with table.isfrozen, usage of a custom function for this should be discouraged.

please read the title
instead of this:

function setthreadidentity(identity: number): ()

it would be like this:

function setthreadidentity(identity: number): number

Since :Remove() exists, I believe we do not need another alias for it, since it has always been :Remove() from the beginning.
Another thing is: getnilinstances test needs to be worked on more carefully, as the getnilinstances test will not work on such games like a basic baseplate.

There isn't a function that I know of that allows you to know if the executor being used is scriptunc supported. I believe it would be a nice addition to have a function for simple usage, indicating if the current exploit is scriptunc supported.

UNC = uncsupported or false

I know that pretty much all exploits have a HWID header already, but they're all named after the exploit. All script developers that want to use this have to manually check whether the header is called "Fluxus-Fingerprint", "Oxygen-Fingerprint", etc. which is honestly just a hassle for the developers, but also makes a lot of scripts not supported on smaller exploits. A Unified HWID Header or the gethwid() function would honestly solve this problem.

Gafyggh
Gsjdbg @jdpatdiscord

yeah no idea whats wrong but its not working anymore

who the hell uses getrenderproperty, setrenderproperty and isrenderobj? they are already in my environment but I see no script devs using it?

where are the other functions such as firetouchinterest, fireproximityprompt, firesignal???? you cant just add fireclickdetector and go on with it, that'd be stupid

setscriptable's "unique instance persisting" issue is with nearly every cheat, its honestly useless and that check should be removed
getcallbackvalue is a good function but i dont think it should be included in a universal environment check test script..

saveinstance() is entirely undocumented in UNC.
Although all modern executors seem to follow (almost) identical arguments and whatnot, I believe it needs to be standardised.

A current point of contention for scripters - especially ones with special needs for whitelisting - definitely suffer from lack of standardization on this front.

UNC declares it as crypt.decrypt(data: string, key: string, IV: string?): string,
Synapse as: syn.crypt.decrypt(data: string, key: string): string, and
Script-Ware as: crypt.decrypt(data: string, key: string, iv: string, mode: string) despite existing documentation saying otherwise.

Synapse makes the standard algorithm AES-GCM, Script-Ware claims to be AES-CTR - I was unable to find documentation for Krnl, Fluxus, and Oxygen U to confirm theirs.

Some AES implementations hold the random IV in the text returned in order to reduce it to one payload instead of requiring two sets of data in order to function, but other forms do not.

The standard of naming functions should be improved to have no more confusion.
Like for example:

- No underscore characters
- Only lowercase characters

(you get the point)

and maybe some sort of like grouping of functions like:

- instance.cloneref
- instance.invalidatecache
- instance.iscached
- instance.getcallbackvalue

- closure.hook (hookfunction)
- closure.isexploitcaller (checkcaller)
- closure.iscclosure

(maybe u get the point)

but it should be designed well with user experience so it wouldn't be a hassle typing those function names. There might be a problem with grouping the functions with this names like "isexploitfunction" which needs a rename to it, but idk.

So let me get this, the functions 'is_fluxus_closure' is registered in our custom exploit?

crypt.encrypt that everyone uses accepts 2 args, a data and a key (both accepted as strings)
crypt.encrypt( data, key)

however, the UNC env check test did it in a horrifying way
local encrypted, iv = crypt.encrypt("test", key, nil, "CBC")
which is unacceptable, it also has mixed up args.
crypt.custom.encrypt( cipher, data, key, iv)

please do fix this, as it causes things to be really messy.

kill isreadonly also OG

debug.getproto test supposedly gets the first proto of "test" function, but there isn't any. Is that on purpose?
EDIT: might've been my mistake, I apologize for that.