# Bypassing WRD Key System

## Outline

{% hint style="info" %}
**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).&#x20;
{% endhint %}

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.&#x20;
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.&#x20;

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](https://mboost.me/) which is [luckily documented](https://docs.mboost.me/).
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.&#x20;

{% hint style="info" %}
**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.
{% endhint %}

## Why bypass key systems

{% hint style="warning" %}
**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.
{% endhint %}

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.&#x20;

WeAreDevs uses a service called [mboost.me](https://mboost.me/).&#x20;

mboost.me is [documented](https://docs.mboost.me/) 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:

<figure><img src="https://1912506009-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fjwg0hgIzNexQDPOl9a5A%2Fuploads%2FGkyXzHfsZ1tuEEseXCkg%2Fimage.png?alt=media&#x26;token=eb46af43-bded-4b5f-8c14-57e51a470a9f" alt=""><figcaption></figcaption></figure>

## 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):&#x20;

```
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:

```javascript
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`:

```tsconfig
[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:

```shell
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
```

<figure><img src="https://1912506009-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fjwg0hgIzNexQDPOl9a5A%2Fuploads%2FXVNUBHOYnAgzLJy3DqAy%2Fimage.png?alt=media&#x26;token=e5c578d9-669c-4720-a504-d3c5e8095910" alt=""><figcaption></figcaption></figure>

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

<figure><img src="https://1912506009-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fjwg0hgIzNexQDPOl9a5A%2Fuploads%2FlxvvxLqn7IkotJxCELZg%2Frundll32_Q1cFZKfvJc.png?alt=media&#x26;token=77074b0e-370e-4280-9f9e-805ca8623ce0" alt=""><figcaption></figcaption></figure>

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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://maindab.gitbook.io/maindabdocs/maindab-faq/bypassing-wrd-key-system.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
