Well that snippet had false positives. It kicked Web Roblox (the one with byfron).
To fix that, I added math.huge which now forces it to use 64-bit address during the check when on Web Roblox, and UWP can’t use 64-bit address so it has shrunken down version of math.huge to fit a 32-bit address.
Adding more data inside of a table doesn’t change the resulting memory address, memory addresses show where it has been allocated in memory and is different every time you run the code.
While that’s true, 64-bit is split into 32-bit so UWP Roblox can use. I recommend you try running code multiple times with and without math.huge.
It doesn’t work like that; it’s not a simple click or renaming that changes this, it’s literally the language behind everything. If they really wanted to do this, they would have to alter the underlying code of the application to support 64 bits, and in that case, I think it would be easier to bypass Byfron itself than converting the app to 64 bits. For a single person, it’s too big.
In other words: This solution is effective, but it has to be used carefully to avoid false positives, such as mobile or console gamers who use a keyboard/mouse.
The app does not become 64-bit. Most injectors will modify the version number of the client to match 64-bit Byfron-enabled clients. It doesn’t mean they actually rewrite it into a 64-bit app.
Yes, they may in fact alter the version number of the client, as it is a simple number, but they will never be able to alter memory addresses, which is ehat this method uses, without converting the app’s source to 64bits.
See this:
And this:
I understand what you’re saying but that wasn’t what the original commenter was talking about. The commenter said you can check if the client is 64-bit by calling the version number using a deprecated client-side function. It does not actually check if the client’s source is 32 or 64-bit. Anyone can change that number and the version would be printed differently.
2 Likes
A simple hookfunction can bypass the bit check by hooking the tostring() function to always return a string that has a 64-bit length for tables.
then detect if tostring() is behaving weirdly, if so, then fill up the exploiter’s memory.
Every detection can be bypassable as exploiters have full control over their clients.
And what would you do if this generated false reports? Innocent players getting their memories filled up because the game thought they were doing something about tostring()? And how are you going to detect if tostring() is behaving weirdly?
3 Likes
have two tables, one with random stuff, and other with expected output when used tostring().
Then loop thru the table and use tostring() on items and check if they are the same as in other table. Along side the checks, monitor the speed of tostring(). If it’s much slower then flag it and cause fill up their memory. If you don’t want to go this far, then just let them be, Roblox will take care of them eventually.
An exploiter can easily see the expected output table and hook the tostring() function accordingly.
Not even going to mention that your method of filling up a player’s memory just because the method slowed down is going to cause a lot of problems and cannot be used in any public game whatsoever.
Oh, Roblox did already, I’m just saying that your method is easily bypassable, and not only that, might cause problems for innocent players with a slow internet/device.
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.