AsyncMatrix's Blog

Replacing a Gym App With Roblox Out of Principle

Mon, 08 Dec 2025 00:00:00 GMT

So, I just signed up for a new gym and immediately fell into a technical rabbit hole. All I wanted was their app.

Attempt #1: Aurora Store. The download failed instantly. Curse.
Attempt #2: APKPure. Same story. Installation failed.
Attempt #3: Some other random APK mirror. Still no luck.

Alright, final stand. I grabbed my old phone, downloaded the app from the Play Store, and used a sketchy APK Extractor to get the raw file. I juggled some ADB commands, pushed the APK to my new phone, and went to install it.

The result? The exact same soul-crushing error that started this whole mess: “Your device isn’t compatible with this version.”

An hour of my time, completely wasted. This isn't just an error anymore; it's a challenge. And I plan on winning. 😡

The brainstorming

Alright, the app is dead to me. So what now? The gym could sell me a keyfob, but there is no way I'm paying them extra because their own tech fails. That’s just a terrible business model. So, my only free option was the PIN code.

My first encounter with the gym door was a disaster. There are two gates, and the first one is just a keypad. I stood there like an idiot, poking at it. What does "ON" do? Why is there an "OFF" button? After about five minutes of looking like I'd never seen technology before, someone on their way out buzzed me in, probably out of pity.

Yeah, that was a low point. But we push through.

I finally got the hang of it at the second gate, but it still felt ancient. Punching in a code while people glide past with a flick of their wrist? No. My inner monologue was screaming, "I will not tolerate this."

So the next day, the big ideas started flowing.

"Why don't I just build my own gym app?" A fantastic thought, except I don't know the first thing about creating Android apps and, let's be honest, I don't want to spend the next month finding out.

"Okay, what about a simple website?" Again, too much work. Hosting, security... what if my credentials get leaked? The anxiety is not worth it.

Then, the lightbulb moment, powered by pure spite and my very specific skill set. I'm a Roblox developer. What if I made a Roblox game... for my gym pass?

Is that against the rules? A little bit. Am I going to do it anyway? You bet. It's a private game, for my eyes only.

So there you have it. My master plan is to use a blocky avatar game as a high-tech key to the gym. What could possibly go wrong? Wahoo!

Ah, but wait, how does my gym app work?

<small>To save us both a bit of time, i've structured the following section like a war diary, a battle between myself, stupidity and my gym app!</small>

I first had to figure out how the original worked. Time to go reverse engineering, a field in which I am a complete amateur.

Objective: See the app's network requests.
Weapon of Choice: PCAPdroid, an open-source traffic sniffer. I installed it on my old phone.
First Contact: Success! I captured traffic. But it was encrypted with TLS. Obviously.
Counter-Attack: PCAPdroid's MITM feature to decrypt TLS traffic. This requires installing a new user certificate.
Enemy Defence: The app immediately threw a fit. Errors flooded the screen. It was using certificate pinning, a security measure specifically designed to stop people like me. I was cooked.
Escalation: The only way to win is to cheat. I rooted the phone using Magisk. The goal was to install a module that forces the OS to trust my malicious certificate.
Stalemate: Even with root, it failed. TLS errors galore. The project felt dead in the water. I walked away for a few days, completely stumped.
A New Battlefield: A fresh idea hit me: maybe my old phone was the problem. Instead of more hardware, I turned to software: the Android Virtual Device (AVD) emulator. I spun up a virtual phone on my PC in minutes. It felt powerful.
The Final Assault: The fresh start on the emulator hit the same certificate wall. But an emulator is just files on a computer. I found a script called rootAVD, ran it, and in less time than it takes to make a coffee, I had a fully rooted virtual Android device. The ease of this was a massive motivation boost.
Breaking Through: With the rooted emulator, I could install the "Always Trust User Certs" Magisk module and place the PCAPdroid certificate directly into the system's trusted certs list. There was no way this app could get around this.
Victory: I fired everything up one last time. It worked. The traffic flowed, completely decrypted. I could read every single request the app made to its server.

After an hour of watching, I had their secrets. The API was simple: log in, get a token, use the token to generate QR codes. The entire plan was laid bare.

Great, so now the easy(?) part

Right, with the API cracked, it was time to build. The easy part, right?

Wrong. I needed to turn a string of text into a QR code inside Roblox. This presented two problems:

Generation: There's no Roblox package to create QR codes. I cheated and used a random third-party API online. Sketchy? Yes. But the codes expire in a minute, so I went for it.
Rendering: The API gave me a PNG file, but how do I display that in-game? Thankfully, a hero named sircfenner made a png-luau package that decodes PNG data for Roblox's EditableImage feature. It saved the entire project.

I wired everything together, and it was done. A gym app. In Roblox. What a wild ride through territories I'd never explored, all because of a single installation error.

The real test came that evening. I walked up to the gate, loaded up my creation, and scanned my phone. The gate unlocked.

It actually worked.

This is insane. I must be the only human on Earth who logs into their gym through Roblox. It's a monument to my habit of overcomplicating everything, and honestly? I love it.

Well, good news, bad news..

Well, there's some bad news.

First, the good news: My Roblox app worked flawlessly for weeks! I even added new features: a real-time gym population counter, workout timers, and a multi-user login so anyone could theoretically use it. It was awesome.

Now the bad news: As I was writing this very blog, I decided to try installing the official app one last time to find the exact error message. But it downloaded and installed perfectly.

I felt like a complete clown, but a happy one. This project may have been technically pointless in the end, but the experience was everything. It was a blast, and I learned a ton.

So, for your viewing pleasure, I present the source code for the most wonderfully unnecessary project I've ever built. I'm proud to show you the gym-app, in Roblox.

https://github.com/4x8Matrix/gym-app

Roblox Security - Practical examples

Tue, 17 Dec 2024 00:00:00 GMT

:::note Once again, this is all just my opinion, and I'm not a security expert - so please take this guide with a grain of salt. :::

Practical Examples

:::tip There's no foolproof way to eliminate hackers entirely, but there are strategies to make their lives more difficult. Our goal is to foster a fair and secure game experience for everyone. :::

Cookie Clicker

Clicker games are notoriously easy to exploit, making them a perfect case study. Here's a step-by-step guide to securing such a game.

Approach to Game Security

Client-Side Guesswork: Let the client invoke a click request to the server. Assume on the client side that the click has been accepted to maintain a seamless user experience.
Server as the Source of Truth: While the client handles the immediate visual feedback, the server maintains the authoritative count of clicks.
Periodic Updates: Send the updated click count from the server to the client every few seconds. This ensures the game feels responsive without compromising security.

Why this approach?
By balancing real-time feedback with server authority, we enhance the user experience while paving the way for effective security checks.

Implementing server-side security checks

Once the server receives a request to validate a click, we can implement a variety checks to identify and mitigate exploits, examples:

Interval Consistency: Monitor the time between clicks. If it's consistently identical, the player might be using an automated tool.
Human Click Speed: Research suggests humans rarely click faster than 24 milliseconds. Use this as a benchmark to flag suspicious activity. (comparison between the last click and the current click)
Pattern Recognition: Look for repeated click patterns (e.g., four identical clicks followed by one variation), which could indicate attempts to bypass initial detection.
Session Durations: Humans usually take breaks during extended gameplay. Continuous clicking for over an hour may indicate automation.
Click Positioning: Check the click location of the click. (sent through the remote) If it's static or repeats exactly, it's likely a bot.
- Distance Tracking: Analyze the distance between successive clicks; genuine clicks tend to vary slightly in position.
  - We could check if they're clicking at the same position, or if they're clicking at totally random positions, it's atypical behaviour for you to click at random positions on the screen..
AFK Detection: Periodically (e.g., every 20 minutes), require the player to interact with a UI element to confirm they're not idle or using automation.

Obbies

Obbies present a unique challenge in Roblox security due to their heavy reliance on player movement and object interactions, often without robust server-side oversight. This lack of server authority creates vulnerabilities that hackers can exploit, enabling them to bypass obstacles or fly directly to the end of the Obby.

Server-side security checks

There are a few things we could do to improve the security:

Distance-Based Respawn: Respawn players if they stray too far from the area between their current spawn point and the next. This prevents skipping large sections of the Obby.
Sequential Spawn Point Progression: Only allow players to claim a new spawn point if they've already activated the one before it. This ensures progression is linear and prevents hackers from flying directly to the end.
No-Fly Zones: Designate specific regions in the game as "no-fly zones." If a player enters these zones while flying or using unintended methods, respawn them to maintain fair play.
Speed-Based Section Tracking: Monitor how quickly players complete each section of the Obby. If completion times are suspiciously fast, respawn the player.

Generic Security Tactics for Obbies

In addition to these Obby-specific strategies, we can apply general security checks to further safeguard the game:

Position Monitoring: Track player movement. If they exceed a reasonable speed threshold, respawn them to prevent exploits like speed hacking.
Void Detection: If a player is detected over the void (suggesting fly hacking) and a downward raycast fails repeatedly (e.g., five times in a row), respawn them.
Clipping Detection: Monitor for instances where players clip through floors or walls. This can be identified through raycasts and corrected by respawning the player.
Jump Exploit Detection: Use humanoid states to detect infinite jumping or other gravity-defying behavior. If this is identified, respawn the player.

Tycoons

Tycoons are a popular Roblox genre but are particularly vulnerable to exploits, such as automated purchasing, resource manipulation, and invalid interactions. To ensure fairness and security, implementing robust server-side checks is essential.

Server-side security checks

Distance Validation: Verify the player's HumanoidRootPart is within an acceptable distance of the object they are interacting with. Hackers often simulate inputs to trigger interactions remotely, so the server should validate proximity before processing the request.
Time-Based Validation: Monitor the time intervals between item purchases. Legitimate players must move physically across the game map to access items, which introduces a natural delay. Abnormally fast purchase sequences can indicate automation or cheating.
Purchase Cost Validation: Always validate the cost of purchases on the server. The server should be the sole authority for deducting resources and confirming transactions. Never trust the client to supply or verify purchase details.

:::note You can add onto this further by implementing specific cheat detections for your experience - for example, if you know the player is put into a cutscene after X purchase - don't let them do anything until you know that cutscene is over. :::

General Security Tactics

While game-specific security measures are essential, having a set of generic security practices can help safeguard various aspects of your game. Here are some examples of strategies that can be applied across different game environments.

Detection and Prevention Tactics

Bait Remotes: Bait remotes are a commonly used tactic to detect and deter cheaters. These remotes are intentionally placed to lure hackers into calling them, allowing the game to accurately identify exploiters and respond appropriately.
Networking Key-Exchange System: Implementing a key-exchange system enhances security by ensuring only valid communication between the client and server. The server assigns a random, mutable key (e.g., using Random.new():NextNumber), which the client must use for requests. If a hacker bypasses the networking implementation, the key becomes invalid, causing subsequent requests to fail.
Obscuring Remote Parents: To prevent hackers from easily locating and exploiting remotes:
- Temporarily parent remotes to ReplicatedStorage and move them to nil after a request.
- Rename remotes to obscure names like "Parent" or unconventional characters such as "\1," making it harder for exploiters to target them. (You should store the remote as a variable so that you can still access said remote!)

Obfuscation Techniques

Obscuring the Game Environment: Rename all game services to non-standard names, as your scripts should use :GetService. Hackers often rely on game.ServiceName, and this technique disrupts poorly written exploit scripts.
Obscuring Script Names and Parents: Change the names of scripts to make it harder for hackers to analyze your game logic. You can also temporarily parent scripts to nil to prevent easy discovery.
- Note: Be cautious with this approach if your scripts call require post-obfuscation.
Fake Goals and Objectives: Place decoy objects or objectives in your game, visible only through exploit tools. These traps can trick hackers into revealing themselves by interacting with hidden elements they shouldn't be able to access.

Player Behavior and Physics Monitoring

Player Collision: Disable player-to-player collisions to prevent exploiters from using collision-based attacks, such as flinging others into the void.
Noclip Detection: Use raycasting to identify when a player passes through solid objects. If detected, respawn the player.
Speed and Teleport Detection: Implement a loop to track player movement speed and position. If a player moves unnaturally fast or teleports without a valid reason, return them to their last known location.
- Note: This method can also help detect and address fly hacking.

:::note If you're still interested and want to learn more about this subject, check out the documentation Roblox provides:

https://create.roblox.com/docs/scripting/security/security-tactics :::

Why am I blogging?

Mon, 09 Dec 2024 00:00:00 GMT

Ever wondered why a 21-year-old would feel the urge to share their thoughts with the world? Well, here’s my take. Blogging, for me, isn’t just about writing—it’s about learning, growing, and connecting. Let me break it down.

What drives me to blog?

I want to share what I know

I’ve been programming since my early teens. Over the years, I’ve developed my own way of approaching problems and solving them. Why keep that to myself when it might help someone else?

Whether it’s a small tip or a detailed guide, I want to make what I’ve learned accessible - You never know who might need it.

I want to show that it's okay to make mistakes

Let’s be real—I mess up. A lot. But you know what? That’s part of the process. Mistakes are how I learn and grow. Too often, we’re our own worst critics. A bad day or a big failure doesn’t define us—it’s just part of being human.

:::warning Don’t try risky experiments in production environments! Always stick to safe spaces for learning. :::

This helps me to learn

There’s a saying: “If you can explain something to a child, you truly understand it." I believe that teaching is one of the best ways to learn.

Writing about a topic forces me to break it down, understand it deeply, and make it accessible. Plus, feedback from others helps me see things from new perspectives.

It's good to get my thoughts out

Sometimes, you just need to get your thoughts out. Writing is my way of making sense of the chaos in my head. By blogging, I create a mental model of ideas, concepts, or situations—and I can always revisit them.

It’s also a space to clear my mind, reflect, and yap about things I’m passionate about.

Roblox, it's Networking and Security

Thu, 05 Dec 2024 00:00:00 GMT

:::note Pre-warning, i'm not a reverse engineer, or a security expert, so this is just my perspective - if you find that something is wrong, please reach out to me on Discord, or though my GitHub! :::

Hey, so this topic’s been rattling around in my brain for a while—so, here I am, writing about it. My headspace, my thoughts, and hopefully, a perspective that’ll help other developers understand the nitty-gritty of Roblox security a bit better.

Either that, or I’ll be yapping incoherently, making zero sense, and rambling about why writing paranoid code is strangely fun.

Roblox, and it's history with hackers!

Let’s dive into this little gem of a history lesson, shall we? First things first: Roblox didn’t always have Remote Events or Remote Functions. Nope, back in the day, any client could modify the environment for everyone else.

And oh boy, what a disaster it was. If a cheater didn’t like someone in their server, they could just… kick them out. That’s right. Roblox actually let them do it. Welcome to the dark ages, folks.

In Roblox, we call this Replication, where both the client and server shared the same level of authority over the environment.

(If you’re into nostalgia or just want to geek out more, check this out: Replication Filtering)

:::note There was a feature called FilteringEnabled (introduced in 2012!) you could toggle on, but it was defaulted to off. So yeah, most Roblox experiences back then lacked the secure client <-> server communication we take for granted in 2024! :::

The history of Filtering Enabled

Let’s rewind to 2012, when Roblox introduced a nifty little feature called Filtering Enabled. Its job? To split the authority between the client and the server. When turned on, any replication changes made by the client would be filtered by the server.

Fast forward to 2018, and Roblox took a bold step: Filtering Enabled became mandatory. This meant that all new experiences on the platform automatically had client-side replications filtered out.

While this was a giant leap forward for Roblox security, it was a big step back in the learning curve for developers. Suddenly, creators had to figure out how to write code that worked both on the server and the client, all while learning how to make them talk to each other using Remote Events and Remote Functions.

So, where do hackers play a part in all of this?

Before Filtering Enabled, the client wasn’t just modifying itself—it could actually modify the server. Don’t just take my word for it; here’s a peek at what that chaos looked like:

To break it down quickly: in the video above, the hacker uses a common tool called an injector (we’ll dig into this more later) to inject a DLL into the Roblox process.

What’s the DLL doing? Essentially, it’s manipulating the Roblox process, giving the client the power to make changes to the game. In this case, the hacker had access to a whole menu of commands—think of it like a cheat panel.

Using these commands, the hacker could directly modify the properties of objects within the game’s data model. Annnd because Filtering Enabled wasn’t turned on, those changes were replicated straight to the server.. total anarchy!

Well, it gets worse..

I can’t quite recall what the very first cheats were, but one that sticks in my mind is RC7. Back when I joined Roblox in 2014, RC7 was gaining serious popularity—and boy, was it more than just a collection of commands. Let me explain.

RC7 wasn’t just a cheat menu; it was a tool that let hackers run code inside Roblox. Yes, you read that right: code. A hacker could write a script in Lua—maybe even whip it up in Studio—and then use RC7 to execute that script on the client, in any game they wanted. And that, my friends, is where things got really dangerous.

But hey, don’t just take my word for it—check out this video of RC7 in action:

For me, at least, this marked the start of a new era of hacking. The word "hacker" was replaced with "exploiter", as the lines blurred. The people writing these scripts weren’t hacking in the traditional sense; they were leveraging software like RC7 that hacked Roblox for them. From there, it was all about using it to cheat.

And well, to round up the history books.

Exploits kept popping up, the community kept growing, and the library of scripts just kept piling up. With this arsenal, anyone armed with an exploit that could run Lua suddenly had the power to cheat—and do pretty much anything they wanted in the engine.

Fast forward to today, and we’re still seeing this same pattern. Modern hacking software often supports Luau (a flavour of Lua), making it easy for exploiters to manipulate experiences. These tools are then released to a growing community, where people use them in creative ways to mess with games.

And it’s not hard to get started. A simple search for "Roblox <game> scripts" will probably give you exactly what you’re looking for. Exploiting on Roblox is absurdly easy—all you need is an executor and a script someone else on the internet whipped up. Feeling bold? You can even write your own script! (please do not!) These executors come with a special runtime that let exploiters run code at a higher identity level than a developer’s code. Yes, you read that right.

This brings me to a mantra you’ll hear a lot: Never trust the client. You never know if it’s your code—or theirs.

Going to run through a range of different points..

So, funny story—I actually made a list before I started writing all this. Naturally, I ignored it until now. But hey, better late than never, right? Below, I’ll walk you through that list. Hopefully, it’ll give you a clearer picture of this topic and help tie everything together.

Roblox is one application, for millions of experiences.

This is a big one, and honestly, it doesn’t get talked about enough. Hackers only need to exploit one client—the Roblox client—and they instantly gain access to millions of experiences and, by extension, millions of players.

Think about it: if someone successfully hacks the Roblox client (and let’s be real, humans are ridiculously resourceful when they put their minds to something), then no individual game is safe.

This is why there’s so much value in exploiting Roblox. It’s like hacking Steam and suddenly being able to cheat in every game on the platform. That’s why developers can’t just sit back and hope Roblox will magically fix everything. They’re up against an overwhelming tide of exploiters—and while Roblox does a commendable job, it’s not a battle they can win alone.

The takeaway? Never rely entirely on Roblox to solve your security woes.

The bar for hacking isn’t Cheat Engine or speed hacks—It’s Luau

As developers, we write our code in Luau. Everything we create for Roblox is either wrapped in Luau or is straight-up Luau. But my point is.. hackers use Luau too. They write their scripts in the same language we use, and those scripts run in a similar environment as ours. (Okay, technically not the exact same runtime, but I’m not a cheat developer, so let’s not dive too deep into that rabbit hole.)

The scary part? Any code you write as a developer can be taken, dropped into these executors, and run inside their custom runtime. That’s why exploiting Roblox games can feel so effortless—hackers can literally write or copy code in Studio and then execute it in their exploit tool.

I don’t know of any other platform where cheats let you run your own scripts directly within the engine. But on Roblox? That’s exactly what hackers are doing.

The server is your saving grace

The server is the only part of your Roblox experience that’s safe from exploiters. Why? Because as of 2018, the server is in charge of deciding what gets replicated and what doesn’t. This means security ultimately falls into the hands of the developer.

Specifically, anything stored in ServerScriptService or ServerStorage is completely safe from the client. Roblox doesn’t replicate these instances to the client—it’s strictly a server-side thing.

What does this mean for you? It’s up to you, the developer, to handle client input properly. And remember, the client firing your remote calls may not even be your code! You need to validate every piece of data coming from the client and set up constraints on the server that prevent malicious actions.

In short: trust the server, not the client—and make sure your server is doing the heavy lifting when it comes to security.

:::tip instances are not safe from the client! Once I came across a framework which used instances to replicate state... ClaimCoinEvent:Fire(CoinModel), this was not good.. let me dive into why..

the server code was specifically doing this:

ClaimCoinEvenet.OnClientEvent:Connect(function(player: Player, CoinModel: Model)
	local reward = CoinModel.Reward.Value

	player.leaderstats.Coins.Value += reward
end)

and so, how could someone exploit this? Well - don't send an instance:

ClaimCoinEvent:FireServer({ Reward = { Value = 99999... } })

And with that, the client can get infinite money... ehh.. not ideal, which is why we should always validate the data we receive from the client! :::

Well, all is not lost.. meet networking frameworks

I like to call these networking frameworks because they provide a structure for handling networking. In reality, though, they’re more like IDL (Interface Definition Language) compilers that translate some constructs of a language into Luau.

At the time of writing, I’m aware of two standout examples: Blink, and Zap. Both are phenomenal tools, and I’d highly recommend checking them out. But let’s dive into how they add a layer of security.

These frameworks work by optimizing the data sent over the network. They do this by implementing their own serialization and deserialization of Roblox data types and constructs. The result? A serialized format that isn’t human-readable—which is actually a great thing!

Here’s why: imagine a hacker intercepting the data you’re sending to the server. If your data is serialized in a way they can’t easily decode—unless they’re running as the server or reverse-engineering the library—it creates a massive headache for them. And honestly? Hackers don’t love headaches.

Of course, you can’t completely stop hackers from getting into your game or figuring things out. But you can make it significantly harder for them, which helps weed out the 70% of hackers who aren’t programmers at all. Sometimes, making life difficult for exploiters is half the battle.

Lets go even more abstract: The client is not to be trusted

Here’s a wild thought experiment: imagine the client connected to your Roblox server isn’t actually a Roblox Player. Instead, some mad genius has created their own custom client that successfully connects to the Roblox server. Sounds far-fetched? Maybe. But is it impossible? Absolutely not.

This is the mindset you need to adopt: the client is not a player. Think of it as a command line, someone trying to manipulate your game - do not give them the keys to the castle.

Verify everything the client sends, because you don’t actually know what—or who—is on the other end. Is it a real player? A bot? A rogue terminal perfectly interfacing with Roblox servers? You have no way of knowing.

Sure, this scenario might sound like an impssible edge case, but it’s a useful perspective to have. The takeaway? Never trust the client. Always validate, always double-check, and always design with the assumption that the client might not be what it seems.

Let me introduce you to.. the dark side of Roblox

Alright, so with a thriving community of hackers lurking behind the scenes of Roblox, where’s their HQ? Surely there’s a forum or central hub, right?

The honest answer? I’m not entirely sure. I imagine there are a bunch of Discord servers that get deleted and then re-created every other week. But one place I was keenly aware of a few years ago was V3rmillion.

To my understanding, V3rmillion was the hacker forums for Roblox. If you wanted to exploit a game, you could make a request there, and someone would probably do it for you. Want to understand Roblox’s anticheat or dip your toes into reverse engineering? That was the place to go.

Now, while hackers are obviously a problem, I have to say—it’s hard not to acknowledge the sheer talent in that community. I’ve seen some mind-blowing stuff and honestly wondered, why are these people spending their time hacking Roblox when they’re this smart? (sorry, i'm a dev but I have to appreciate the talent when I see it)

Around ~2023, V3rmillion shut down. I’ve got no clue why, but it happened around the same time that Synapse X joined forces with Roblox. Recently, I checked back out of curiosity and noticed it’s up and running again. My guess? Someone else picked up the torch and is now running the forum.

Place copying

Ah, place copying—a problem that has plagued the Roblox platform for years. While there are ways to mitigate it, it’s pretty much impossible to stop entirely. Let me break it down for you:

Imagine you’re a small creator, maybe a builder showcasing your assets to the world. A few weeks later, you spot those very same assets in the Roblox marketplace, used in other games, and you’re left scratching your head. How did this happen?

Well, much like "asset ripping" in games outside Roblox, hackers on the platform can do something called place copying. They iterate through every object in your game, serialize it into XML, and then convert that into an .rbxlx file. This file can be opened in Roblox Studio, giving them access to a studio-compatible version of your game’s assets.

And here’s the problem: your code isn’t safe either. Exploits can be used to dump the Luau bytecode (the format Roblox sends to the client). This bytecode can then be decompiled into a human-readable format, allowing hackers to understand your code.

The result? Hackers can potentially create a fully functional client-side version of your game. (Well, "fully functional" might be a stretch since they don’t have your server-side code—but still, it’s a problem!)

Well, your game is safe as long as you protect the server, right?

I wish I could say yes, but there’s another attack vector that’s been around for a while: server-side exploits. And let me tell you, these are the nastiest of them all.

So, how does this happen? Is there some secret Roblox backdoor? Nope, thankfully not. But hackers have found a sneaky workaround—they flood the Roblox Marketplace with semi-functional assets that come bundled with hidden scripts.

Here’s how it works: you download a free model or asset, maybe thinking it’ll save you some time, or look good in your experience. You open the script to check - the script looks fine at first glance, but buried deep inside could be something like a suspicious require(number) statement...

What happens next? These scripts often ping a Discord webhook, alerting the hacker that their malicious code is running in your game. Once they know their script has infiltrated your server, they can access it using a whitelist system, effectively giving them a console to execute server-side commands. Yikes.

The lesson here is simple but critical: BE CAREFUL WHEN USING FREE MODELS FROM THE MARKETPLACE! Roblox warns you with the "This model has scripts 🤓" notification for a reason. Always inspect what you’re importing—blind trust is not worth the risk.

And if one of these server-side exploits ends up in your game, a hacker could use it to create something obscene or inappropriate. They could then report your game, leading Roblox moderators to take it down—or worse, suspend your account entirely. So, yeah, this isn’t something to take lightly.

The vacuum that is Roblox Characters

Roblox characters are… interesting. They’re client-authoritative, which is great for user experience (UX)—when you move, you move instantly, making everything feel responsive and smooth. But here’s the problem.. the server doesn’t validate these movements to ensure they’re safe. And that’s where problems start creeping in.

Speed hacks

Speed hacks exist because hackers can simply set their Humanoid.WalkSpeed to something absurd—like 1000. While this property isn’t replicated to the server, the speed at which the character moves is. And fixing this isn’t as straightforward as it seems.

Why? Because there are plenty of legitimate scenarios where a character might move unusually fast:

Falling from a height.
Being pushed by another force.
Sitting on seat (which can teleport you).
Using a ragdoll system that messes with physics.

All of these could easily trigger false positives in an anti-cheat system. And since clients control their character physics, they can make themselves move faster, fly, or even spin like a Beyblade if they want.

Spinning players suck!

Let’s talk about spinning players—and why they’re the worst. If a player spins ridiculously fast and collides with another player, Roblox’s physics engine tends to freak out, launching the unfortunate victim into oblivion. Not ideal.

Worse still, this kind of interaction could false-flag the victim as a cheater, which opens up a whole new can of worms (as you’ll read below).

One way to counter this chaos is by disabling player-to-player collision, which can help mitigate the problem. That said, server-side fixes for these issues exist, but they’re far from perfect solutions.

A semi competent understanding on how these exploits work

I just wanted to dive into my understanding of what these exploits do, and how they generally work - it's likely the the majority of this is wrong, but this is how I understand them:

The layers of an exploit

An exploit typically consists of three parts: the Injector, DLL, and the Application. Let’s break these down:

Injector: The injector’s job is to locate the Roblox process and inject the DLL into it. This usually involves finding the memory address of the RobloxPlayerBeta.exe, creating a new thread in that process and somehow getting the DLL to run within said thread.
DLL: The DLL is the core of the exploit—it’s the part that does the dirty work. Once injected into the Roblox process, the injector starts to tamper with critical parts of the process, such as the script context or data model. Once initialized, the DLL sets up a communication channel that allows the third component, the application, to interact with it.
Application: This is the fancy UI that exploiters use to control the injected DLL. When a user performs an action in the application—like pressing a button to execute a script—the application sends a message to the DLL, instructing it to perform the requested task.

The Inner workings of the DLL

So, I had to double-check my understanding of this. To do that I used a list of open source exploits, as well as reverse engineering some of the exploit libraries made by the community.

Instantiates the IPC, the first step in the DLL's lifecycle is to instantiate some sort of IPC so that the DLL can communicate back and fourth with the application. This is typically done through a named pipe
Listens to said IPC, the DLL then listens to the IPC for messages from the application. These messages can be a range of things, but to list two - it can be used to send commands to the DLL to execute a script, or to receive data from the Roblox Process.

Example of a script execution

Once the DLL receives a message from the application to execute a script, it does the following:

Wrapping Luau, typically the DLL will wrap the contents/source code that the exploiter is wanting to execute into a function - then do things outside of the scope of that function..
- This is done to potentially modify the environment, as well as spawn a new thread for each script that's being executed.
Compiling Luau, the DLL will compile the luau script into bytecode format, this is most likely done using the OSS Luau compiler itself as there's no valid reason to implement one by hand.
Modifies the behaviour of the Luau VM, the DLL will then modify the behaviour of the Luau VM to allow for the execution of code outside of the engine.
Uses the now vulnerable VM to load the bytecode, the DLL will then use the modified VM load the bytecode into the applications memory (this is then pushed onto the Luau stack)
Calls task.defer, the DLL will then call task.defer to execute the script.
Resets the Luau stack, to avoid corrupting the stack, the DLL will reset the stack to its original state.

Now, don’t take my word for it—I’m not a professional reverse engineer, just a hobbyist. But this is how I understand it - it could be wrong!

Punishments should depend on how bad the exploit is..

If you’re speed hacking, as we mentioned above, it’s not necessarily a big deal. The player shouldn’t be banned outright because there are many legitimate reasons why they could have been flagged—like falling, being pushed, or interacting with certain game mechanics.

But if it’s something like firing a honeypot remote—a trap designed to detect malicious intent—that’s a different story. A honeypot remote is impossible for a legitimate user to fire accidentally, so if it’s triggered, that’s a 100% indicator of foul play.

You could pair this detection with a weighted system. For example:

If a player triggers one suspicious event (like speed hacking), you could just log it.
If they trigger the same exploit multiple times consecutively—say, 10 times—you can escalate the response. Maybe start by respawning them, slowing their character, or applying another form of non-intrusive punishment.

By gradually increasing the severity of the response based on repeated behavior, you ensure that you’re confident in the detection before taking harsher actions. This method avoids punishing innocent players while making it harder for exploiters to continue their antics undetected.

Well.. this is why I think banning hackers isn't the answer..

Let me start by saying I’m not against banning hackers—it’s definitely a good thing. But in my opinion, it’s not the solution. For games I’ve poured time and effort into, I usually implement systems that let me detect when someone is cheating. But instead of banning them outright, I just slap a flag on their account.

And here’s where things get fun: with that flag, you can get really creative.

In an FPS game, you could make it ridiculously hard for them to aim. Maybe the gun has an insane spray pattern or fires blanks half the time.
In an obby, why not fling them randomly or disable their ability to jump?
In a leaderboard-based game, let them see themselves at the top of the leaderboard… but make sure no one else does! 😂

See where I’m going with this? The idea is to waste the hacker’s time. They’ll have no clue they’ve been caught; instead, they’ll just notice weird, frustrating problems cropping up. And the best part? They’ll probably blame their exploit! 😂

The point is, I find this kind of punishment far more effective than a simple ban. Why? Because bans are easy to bypass with alt accounts. Instead, make their lives hell. Confuse them. Cause them headaches. The ultimate goal is to deter them—and while it’s true there’s no perfect solution to hacking, this approach can at least make it less appealing.

But don't let this deter you from creating an awesome experience..

I’m not saying you can’t create amazing experiences on Roblox—it’s absolutely possible! It’s just a little trickier to make them secure. Let me explain with an example: cookie clickers, one of the easiest types of games to exploit. In fact, you don’t even need fancy hacking software or executors to mess with one.

To make a feature secure, it needs to be server-authoritative. But how do you achieve that in a cookie clicker without making the game feel laggy due to network delays?

You fake it!

Here’s how it works:

When a player clicks, send a request to the server to increase the cookie count.
The client then updates it's UI to show the new local cookie count
The server validates the request—if it detects something fishy, like an impossible click speed, it simply drops the request.
The server then sends back the true cookie count to the client, ensuring everything stays accurate and secure.
The client then updates its UI to show the new server cookie count.

From the client’s perspective, you can show the cookie count increasing immediately with each click to maintain a responsive feel. Once the server confirms the actual count, the client updates to reflect the correct value. This approach makes the game feel snappy while still being secure. (Click -> cookie count goes up -> server validates -> client updates to match.)

The key takeaway? It’s entirely possible to make your game feel great while keeping it secure—you just might need to think outside the box.

Please, read this if you're a Roblox developer

Think of an exploiter as a Local Script. This Local Script has the power to make any API call—yes, even the ones you’re not allowed to run. Your job? Make sure this script can’t wreak total havoc in your game.

Now, imagine this Local Script comes with special globals, giving it ways to access your scripts. It can modify your variables, call your functions, and even mess with your code—even if your logic is tucked away inside regular scripts instead of modules.

Here’s the truth: there’s no surefire solution to hackers. But there are always ways to mitigate the damage they can cause. Stay vigilant, validate everything, and design with security in mind.

Arch Linux, Linux & Me

Mon, 02 Dec 2024 00:00:00 GMT

:::note This post is a bit of a mess, but it runs through my history with Linux, and how I got to where I am now - but in short if I could go back and change anything, I wouldn't. I love OSS, Arch and all of the wonderful technologies that make it possible. :::

I’ve been meaning to write about my experience with Arch Linux for a while—finally getting to it now!

Well, where did this journey begin?

I’ve been a Windows user since Windows 7, mainly because that’s all I knew. But as a curious, slightly misguided teenager, I strayed into the world of third-party exploits and "hacking tools," thinking it made me cool. Spoiler: it didn’t. I stumbled across Kali Linux during that phase, drawn in by its "hacker" reputation, and attempted to learn tools like Metasploit.

One day, someone in a voice call challenged me: "Bet you can’t handle Arch Linux." That was all it took for me to dive headfirst into something I wasn’t remotely ready for.

Well, how did that go for me?

It was a disaster. I overwrote my Lenovo recovery partition, wiped my Windows install, and realized I had no clue what I was doing. 😅 But in the chaos, I learned a lot—about Linux, about software I still use today, and, most importantly, about not being so gullible.

Looking back, those early mistakes taught me valuable lessons the hard way, and for that, I’m grateful.

So, what happened next?

For the next few years, I stuck with Windows. I did manage to get Arch running on my laptop eventually—after three attempts and a lot of frustration with NVIDIA drivers 💢—but I only dabbled in Linux here and there. It never really stuck.

And a few months later.. I decided to take Linux more seriously as a potential Windows alternative. I tried switching multiple times, but it always felt too inconvenient, and I wasn’t motivated enough to fully commit. So, Linux remained a side project—a "someday" idea I’d tinker with but never fully embrace.

This does have a good ending right?

When I joined Dubit, I had the chance to save up for a Linux-based computer I’d been dreaming of. It felt like a big step into unfamiliar territory, but I was ready to dive in.

By the following year, I had built the PC and was eager to embrace Linux fully. Then I hit a roadblock: Roblox.

Roblox had been my go-to platform for years—a constant in my life from Greenwood Town to Build Your Own Mech. But it didn’t support Linux, which left me torn between two worlds. After months of indecision, I finally chose to cut ties with Roblox. If I had to let go of one, it would be Roblox, because I knew Linux could teach me so much more than Windows ever could.

(Though I’ve been able to use Roblox Studio on Linux for a while, just that running or playing games natively has never been an option.)

:::tip As of writing this, you can run Roblox on Linux, by using Sober, a Runtime dedicated to Roblox, it's an awesome project and I am grateful to the developers for their hard work.* :::

And so, my Linux arc began.

I started with Arch, I've previously used other distros, but nothing hits home like Arch, and specifically it's package manager - Pacman. I just know how to configure it, how to use it and how to fix it in any unexpected situations, these are skills I don't have with other distros - and if I were to switch to Linux, I want it to be as painless as possible - I need to have a functional computer for Work!

And so, I started my journey with Arch Linux, I've ran into a few issues (on my first install, I annoying rm -rf'd my icons directory! Which in turn borked my system..) I had no choice but to accept I was an idiot and to retry the install again.

But this just bolstered me, installing arch isn't the issue, it's committing to it which is!

And.. so that brings me onto my next point, Gnome.

I’ve stuck with Gnome as my desktop environment, and it’s been fantastic. While some prefer KDE or others, I’ve found Gnome simple and effective. Customizing QT and GTK for consistent system themes is easy, and the workspaces feature has been a game-changer. Switching windows with the super key + scrolling feels so intuitive—it’s leagues ahead of Windows’ implementation, which never clicked for me.

The Gnome extensions repository is another highlight. It’s like a marketplace for powerful add-ons—whether it’s fun tweaks like "Burn My Windows" animations or practical tools like embedding Spotify controls in the top bar, it just works.

Gnome has turned what once felt inconvenient into something enjoyable, something worth personalizing. I’ve put in the effort to make it my own, and while I haven’t shared my setup ("rice") online, I’m happy to call it mine—it reflects me.

In light of the preasent situation on Windows

I’ve seen too many horror stories with Windows, and even the ones I brushed off couldn’t hide the fact that it’s slower, more resource-intensive, and just not scalable. (Seriously! I used to have a tradition for re-installing Windows every few months!)

And don’t get me started on Copilot. The idea of my PC being controlled by a massive corporation like Microsoft is a nightmare. Sure, Linux isn’t perfect—Canonical has its issues (or so i've heard!) —but at least I’m not being forced to use something like Microsoft Edge (which I absolutely despise).

What was once inconvenient has now become my base of operations. I still keep Windows as an alternative-dual boot, but I log into it maybe once a month, usually to test something I can’t do on Linux.

In short, I don’t see myself going back to Windows anytime soon. Linux fits into my daily life now—and yes, I even play games on it. CRAZY, right?

Finally, my second blog post

Mon, 02 Dec 2024 00:00:00 GMT

Why has my website changed so much? What’s going on? Well, in my fantasy land where people actually read the stuff I write, I’ve decided to take the plunge and start documenting my journey... again.

What began as a simple blog—a fun way to dive deeper into the world of web development—slowly turned into a chore. It became this "someday" project where I’d magically find the time to learn and adopt new technologies. Spoiler: I never did. If only I had a time machine... But instead of moving forward, it started weighing on me.

Enter Fuwari & Astro! 👋

This change is something I’ve been wanting to do for a while, and I took inspiration from the Discord-Luau Documentation for how to structure this site. Let me break it down further:

As a self-proclaimed web development noob, trying to fully grasp these frameworks was a stretch goal—especially because, let’s face it, I don’t care that much. I’m a game dev at heart. I like making games, not building websites! But the framework I was using didn’t help me learn effectively or make the process enjoyable.

So, why did I choose Astro?

I chose Astro because it’s straightforward and easy to understand—at least for me. The ability to use MDX files is a game-changer. I mean, JS in my markdown? That’s awesome! But what really sold me was how seamlessly I can embed React components—not just in markdown files, but also in other Astro components.

Maybe this is basic stuff for those who dominate the web dev world, but for a newbie like me, this is a big deal. It simplifies my life and actually makes me want to write more. No longer am I shackled by the endless cycle of "read the manual, figure it out, get frustrated." Now, I can dive right into development, mess things up, and fix them later.

(Just to be clear, I don’t take this approach with high-value projects—LMAO. I promise, I do have some sanity. But for personal projects, like my website? Oh, this is my playground! 🥰)

But what about Fuwari?

Honestly, I was surprised by how many template blogs are available for Astro. I’m not a huge fan of the template-based approach—but I’m also not about to reinvent the wheel. So, I started exploring Astro templates to see what I could work with.

After some browsing, I narrowed it down to a few options. (At one point, I had about 10 tabs open, each with a theme I was debating!) What ultimately sold me on Fuwari was the attention to detail in its UX, how well everything is styled, and how easy it is to configure. The design is clean, thoughtful, and just feels right.

Since then, I’ve been making changes to all sorts of components. If you look to the left, you’ll notice a cool new Projects section I added. This is exactly what I’ve been looking for—a framework that lets me experiment and add fun elements like widgets and other custom features without much hassle. It’s flexible, fun, and feels like the perfect playground for my ideas!

Ok, but you said second blog post? What's that about?

Right... I almost forgot about that (well, until I started writing this). I guess I’m rambling now—so let’s get back to the point.

I wrote my first blog post on my original site and promised I’d keep it updated. Spoiler alert: I didn’t. That blog post has since been lost to the sands of time, never to be seen again.

So, this marks my second attempt at a blog post—the first one is now forever hidden away, never to see the light of day. Let’s hope this one sticks!