Yeah, I use the local Get xpcall(function() return game[nil] end, function() Get = debug.info(2, "f") end) trick to localize the __index metamethod and such as to avoid the metatable indirection for userdata. It’s been really helpful in cutting frame times in half for expensive stuff like custom foliage updating.
The only possible vulnerability I could think of would be if Roblox’s userdata hooks didn’t check the metamethod arguments properly, but I have yet to find a case where calling e.g. the __mul for CFrame with a RaycastParams didn’t stop and throw an error.
Now there’s probably some Rube-Goldberg machine you could make that tracks the call stack to detect exploits with, but that’s beside the point. There’s no direct vulnerability possible with debug.info.
(I would love to hear what engineers think about this, though. My use case is very niche, and I would totally understand if they reserved the right to break it. I think a more future-proof solution would be to expose methods like Instance:Get and CFrame.mul that could be localized better.)
It did actually get rolled out to the client, and is in full effect.
It warned about property accesses with null bytes and that it’ll throw an error in the future. A few updates later it did actually throw with a special error, now however it seems to just throw a generic ‘not a valid member’ error.
I don’t think it was aimed at patching a detection vector, but rather just a fix to some jankiness that caught it in the crossfire.
I do also believe the patches weren’t rolled out immediately was because there wasn’t an immediate threat (like a malicious actor actively using it in a crosswoods game or something) – it’s more akin to a blanket patch that fixes any hidden gremlins and prevents future issues.
They also wanted to allow developers time to change their code such that a breaking change wouldn’t come unnanounced.
To be honest, I don’t think the CoreGui detections did much, __mode detection could very much have broken unintentionally in the future if the garbage collection system got an update, and most executor developers did eventually patch it.
For strings with hidden bytes, if your game had a dedicated attacker that justified the use of it in the first place, it wouldn’t be particularly hard to bypass.
I think this was a change that was a bit overdue. It’s not that serious, though it could potentially break a few client anticheats, so they’ll probably do a rollout over the course of a few months.
Once again, CoreGui has always been referencable by unprivileged states to my knowledge, and the detections that came from ContentProvider:PreloadAsync have been around as long as that function has existed.
Wanna know what hasn’t existed?
“vulnerabilities” for them.
You can’t modify CoreGui at all, You can’t access CoreGui at all, can’t modify properties, can’t modify instances, I refuse to believe there is genuinely a vulnerability of sorts that led them to patching this detection.
You shouldn’t be able to access or reference protected services in the first place, while it might not have any known vulnerabilities, it also wasn’t that useful – executor devs patch methods, and a dedicated attacker would certainly not find it hard to bypass.
I do agree it’s sad to see a detection vector go, but you do have to admit they weren’t that effective.
You also have to remember that this is definitely undocumented behavior, and engine or language changes would’ve probably unintentionally broken them eventually (maybe even unannounced).
You have no idea how many times I’ve heard the “bUT THEY CAN PATCH IT!!!” excuse on DevForum, you’re wrong for several reasons.
It was massively effective, because for mobile exploits, it detected the key redeem GUIs they all had, and they couldn’t execute code until they got past that GUI, and by that point they were already banned.
Also, anyone who chose to try hooking PreloadAsync could’ve been detected by numerous different methods
callstack inflation
__tostring
simply loading a detected asset and checking if it exists
For this reason, no exploit directly tried detouring it, and it remaind one of the biggest and most reliable detection methods.
The problem is that you ‘fix’ these behaviors (which are widely used for exploit detection) and provide no alternatives. Hyperion is slow and practically useless, letting offenders off with warnings and short-term bans that do not extend to alt accounts. Server Authroity was announced to be delayed on the same day you rolled out these patches. In 2023’s Roblox roadmap, it was stated we would get more ways to ‘identify and block cheaters using Byfron’s technology’.
Said technology never came, and since then Roblox has only patched more lua-based detection methods. These changes wouldn’t be as big of an issue if you actually took game integrity seriously. Where are the Hyperion tools that were promised?
I’ve written my fair share of anticheats myself, and tested them with executors. They only worked on the less popular and sketchier executors.
The sUNC spec has methods to modify the callstack, though I’m not actually sure if they get around inflation, but once the method gets overused, bypasses are sure to follow.
Again, these detections would only work against an exploit developer with little actual experience, but they’ll fall apart the moment a dedicated attacker sees them.
another week another time roblox reinstalls itself for an update, like can the update system be revamped? i really want to be able to pin studio somewhere for more than a week at a time.
How many of them aren’t from other methods like LogService.MessageOut?
Delta is laughably bad, they used to store their guis in PlayerGui.
My point of executor developers being able to quite easily bypass CoreGui detections still stands, I expect more security will be coming to mobile clients soon, as per the recent announcement on emulators.
It works on the insecure executors, that’s correct, but again would be very easy to bypass and doesn’t work on every executor.
Strongly depends, I guess the average exploit developer isn’t very smart I’ll give you that, but again if someone is dedicated enough they can bypass it, and they are very fragile detection methods that would’ve broken sooner or later – null-bytes were patched because there was actually a bug stemming from it, and __mode detection would break if garbage collection was changed in the future.
I’ll end it here since I don’t think there’s much else to discuss about (respectfully), let’s just see how it’ll pan out.
Truthfully I don’t believe these patches were intended to break detection vectors, it may be a necessary evil to fix poor practices or prevent any issues.
I’m not saying they might remove it, I’m saying that the behavior might change, for instance what if hard references get separated by execution states? It would still be totally compatible with Lua 5.1, because you can’t do anything outside of the normal execution state/level.
Totally agree with this, they like to patch things like this for seemingly 0 reason and yet refuse to patch the several ACTUAL ACE vulnerabilities in both the studio console and output
