Bypassing WRD Key System

"Faking" a web server in order to trick WRD

Outline

What is a key system?

A key system (a form of a paywall) is used by Roblox exploit developers to generate revenue without having to charge users a sum to access the exploit (seen in paid exploits).

Key systems are typically implemented in two ways:

1. By implementing a key system into a frontend of an exploit. For example, MainDab is a frontend for multiple Roblox exploit APIs.

2. By implementing a key system directly into the exploit API itself. WeAreDevs, for instance, does this.

Prior to 2023, both implementations were often done for free Roblox exploits.

For the technically minded, bypassing WeAreDevs key system is fairly trivial:

1. Identify what server WeAreDevs is contacting. WeAreDevs uses a service called mboost.me which is luckily documented.

2. Create a "fake" local server to handle supposed requests to mboost.me.

3. Redirect traffic from mboost.me to the fake server hosted on localhost.

This is highly likely to be the case with other Roblox exploits.

Why not just a browser extension?

A browser extension could be use as an alternative, but in the case of WeAreDevs, a browser will still open every time whenever a user attempts to use WeAreDevs. We do not want that.

Why bypass key systems

The effect on WRD's developers is negligible

The key system in WRD expects users to subscribe to a YouTube channel and to join a Discord server. As such revenue is not directly generated from the key system.

Combined with MainDab's almost non-existent userbase since April 2023, the effects are expected to be negligible.

MainDab was originally created with the goal of providing an ad-free experience. Prior to 2023, MainDab tried avoiding APIs that had key systems in them.

In order to fulfill the original objective in 2025, a key system must be implemented.

Identifying what WRD expects

This is perhaps the most trivial step as attempting to inject WRD already shows which key system is used.

WeAreDevs uses a service called mboost.me.

mboost.me is documented which saves the need of doing network monitoring in order to determine how a key system is being called and what response is expected.

What WRD expects is best explained from mboost.me:

Creating and running a fake local server

Before initilising WRD, we need to create a "fake" server on localhost to process supposed requests to mboost.me.

On Windows, we may use the hosts.txt, located in C:\Windows\System32\drivers\etc , to direct requests elsewhere, namely to localhost (127.0.0.1):

127.0.0.1 mboost.me
127.0.0.1 api.mboost.me

Elevated permissions is required to edit hosts.txt (as its located in System32), which is why MainDab requires admin permission to run.

We will also need a way to process https requests (not http!) to mboost.me. In Node.js we can easily do this:

const https = require('https');
const fs = require('fs');

const options = {
    key: fs.readFileSync('mboost.me.key'),
    cert: fs.readFileSync('mboost.me.crt')
};

const server = https.createServer(options, (req, res) => {
    console.log(`request received: ${req.method} ${req.url}`);

    res.writeHead(200, { 'Content-Type': 'application/json' });
    res.end(JSON.stringify(
        {
            success: true
        }
  ));   
});

server.listen(443, '127.0.0.1', () => {
    console.log('Server running on https://127.0.0.1:443 (remember admin!!!)');
});

There are two things to note:

• The server is being hosted on port 443, meaning to run this script elevated permissions is required. This is why MainDab needs to be run as admin.

• SSL certificates are used. WRD refuses to connect over HTTP.

To generate the certificate used, OpenSSL can be used. We can save the below configuration as cert.conf:

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = State
L = City
O = LocalHost
OU = Development
CN = mboost.me
[v3_req]
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
extendedKeyUsage = serverAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = mboost.me
DNS.2 = api.mboost.me
IP.1 = 127.0.0.1

Then using OpenSSL:

openssl genrsa -out mboost.me.key 2048
openssl req -x509 -new -nodes -key mboost.me.key -sha256 -days 365 -out mboost.me.crt -config cert.conf

mboost.me.crt then must be installed to the Trusted Root Certification Authorities:

and we may now run the Node.js server.

Conclusion

Bypassing WeAreDevs API key system should be considered simple compared to other exploits due to how there was no need to further investigate what request WRD expects.