A way to block hyperion bypass

Alright so Hyperion got released to UWP client’s by upgrading them to 64-bit however there is a way in which you can gain access to the 32-bit Microsoft store version. So I thought I would explain how you can stop that

Here is how:

Make a local script in StarterPlayer → StarterPlayerScripts


So right now we need to actually check if they are 32-bit.

For this, I found a very well made post about how to do it here: https://devforum.roblox.com/t/byfron-required-place/2544853/31

But if your not interested in that, then the code would be:

function determineBitArchitecture(): number
	local tableAddress = tonumber(string.sub(tostring{}, 8))
	if #tostring(tableAddress) <= 10 then
		return 32
		return 64

So now that we have check if they are using a 32-bit client then we have to make sure we kick/ban the right person

Kicking the right person

What we don’t want to do is accidentally kick some mobile player who can only run 32-bit software.

Meaning we would have to check if they are using mobile. To do this let’s just use UserInputService

local UIS = game:GetService('UserInputService')

local IsPhone = UIS.TouchEnabled and UIS.KeyboardEnabled

And after some intense coding and thinking there is the check.

Now let’s kick them

Actually Kicking the person

Now here you can do what you want. e.g add them to a flag based anti-cheat, kick them or just ban them outright.

Kicking is pretty simple it’s just :Kick() but if you don’t know how to do that then here’s the code I would use:

local UIS = game:GetService('UserInputService')

local IsPhone = UIS.TouchEnabled and UIS.KeyboardEnabled

function determineBitArchitecture(): number
	local tableAddress = tonumber(string.sub(tostring{}, 8))
	if #tostring(tableAddress) <= 10 then
		return 32
		return 64

if IsPhone == false then
	local Client = determineBitArchitecture()
	if Client == 32 then
		game.Players.LocalPlayer:Kick("Strange how you managed to download a 32-bit client when the new version is 64 isn't it?")

(Before hyperion roll out)

Let’s test it out:



So now to recap, the code checks if they are using a 32-bit client and on phone then if they are using a 32-bit client and not on phone it kicks them

You may want to add a way where this can’t be bypassed by using actors or something like that but anyways.

Thanks for reading and I hope this helps :smile:


Please don’t do this. Blocking all 32-bit players that don’t spoof this will block more normal players than exploiters. Some players can only play on the 32-bit client (known as the UWP client) due to limitations like Windows 10 S.

Edit: Hyperion on UWP is rolling out now. This check will be irrelevant quite soon. Again, please don’t do this, because now it may be a waste of time.


arsenal did it. And if your making a competitive game then this would be a quick way.
I never said you had to do this. I’m just saying this could be an alternative while roblox haven’t implemented there ban system and alt detection yet.

edit: (It’s a trade off between blocking a chunk of cheaters and players or allowing cheaters - which push away players). This could be a solution if your game was quite big.


This sounds like a risk developers have to weigh for themselves. Is potentially stopping a chunk (not all) of cheaters worth losing legitimate players over? Depends on how damaging cheaters are to your game. Really Roblox should just hurry up and do something about UWP instead.


Not only does it ban all 32 bit players but exploiters can easily bypass it anyway.


It may not stop all but it stops most and also it is a very low count on how many people actually use a 32-bit and are not on 64.

1 Like

Instead of kicking them, use it as a signal for your moderators. Really depends on your scale, but you can have a notification/flag when a PC player uses 32-bit (or perhaps quicker anti-cheat punishments).

And besides, a custom version of Hyperion for UWP has been confirmed and is coming soon to Roblox (expected in a few weeks after RDC23). Android will have its protection around Q4.


Well then. There you go, this is a quick solution until that comes out also yes you could implement it with other moderation so if they have had been flagged 5 times for suspicious activity by an anti cheat and they are 32 bit then it bans them

  1. don’t put it in StarterPlayerScripts put it in ReplicatedFirst
  2. this can be bypassed and multiple bypasses have already been made including whatever arsenal does
  3. Create an Actor instance in ReplicatedFirst and parent your script to the Actor then at the first line use this code:

this will parent the script and actor to nil, remove all refrences to the script and actor and disconnect all connections connected to them (UWP Exploits have yet to create the function run_on_actor which means we can use actors to bypass hooks etc because the script will be running on a different lua state and no your script won’t stop working.


A version of Hyperion for the UWP Roblox client is soon to be implemented, best bet is to just hold off for the time being.
I bet that Microsoft were giving them trouble with the addition of Hyperion tech into a MS Store game…

1 Like

There is no point, seriously. It’s like adding an age lock to your game just because you assume every newly made account is an exploiter which will in turn block new, genuine players. You are just hurting your game’s population by doing this. Additionally, many older mobile phones still run on the 32-bit architecture (for iPhones, models older than 2016) so you are doing even worse damage.

Exploiters can just spoof or delete your check upon launch, please don’t do this!!!


This stops literally nothing, only kills part of your playerbase.

You can only do these calculations and such through localscripts, meaning the exploiter can and very easily will stop any and all client sided kicks, as well as blocking any remotes that tell the server to kick the client.

Great job!


You can also do the trick where, you place it on Localization service, or somewhere else like chat service, using a script with run context to client, so It runs in most services, this will bypass

 if instance:IsA("Script") then
 instance.Enabled = false
-- This is just an example.

Even if they call directly the service, calling destroy or enable/disable won’t do anything.
Combine that with an actor to prevents hooks

1 Like

In Arsenal I evaluated the impact before and after the implementation of UWP blocking (using a different method than provided here).

The results were insane, being an 85% drop in automatic bans and no noticeable drop in player count. We had a few people reach out saying they were unable to play now due to 32-bit hardware, but that’ll become an issue for them regardless due to Hyperion rolling out to UWP as well.

It was worthwhile for us, but that doesn’t mean it’ll work for everyone. Please evaluate your own implementation to determine whether it’s right for your game.


You have a point, though Windows 10 S can easily be removed. When I had to setup a Windows 10 S laptop, I just went kn the MS store and there was a button somewhere to switch to normal Windows 10 for free. I don’t think Windows 10 S should be a dealbreaker. What’s more to worry about is those that are on a tight budget and may have older computers. Unfortunately that’s common

1 Like

I forgot to reply to this before, but removing S mode is most likely not an option for a student in an education environment. Regardless, Hyperion for UWP is rolling out now, so… maybe don’t do this because it will be useless very soon, I guess?

With the method described in the post, this is impossible.

Genuine question, unless they can take their device home, why would they install Roblox on an educational device? I find that a bit hilarious.

Also, at least for us, we don’t have S Mode in school. We have everything that could be dangerous (such as downloading .exes) locked by an admin, but not by S Mode. I feel like it’s a really bad decision for schools to use S Mode rather then locking features with an admin account.

recommand not do do it. However, we can use the system to keep an eye on 32bit version

They can temper with the script using DescendantAdded and disabling every script in replicated first, or making one of the functions return wait(9e9), both can easily get fixed, the first one is using scripts with run context to client and place it on localization service and make the script immediately destroy itself, the other one can get fixed by using actors, since no exploit had parallel support, or by using handshakes.