Atherum ─ advanced anti-alternate account system concept

Resources Community Resources
#1

:warning:Due to the shutdown of Session 42 Studios, this module no longer receives updates and is no longer supported. Free support is no longer available.

1440×654 107 KB

:floppy_disk:Model | :orange_book:API documentation | :test_tube:Testing place

What is Atherum?

Atherum is a brand-new ROBLOX alternate account detection system developed and maintained by Session 42 Studios. Atherum aims to detect as many alternate accounts as possible with a high-efficiency rate.

We are confident that 80-90% of ROBLOX’s ToS-breakers, such as exploiters, trollers, spammers, raiders, bots, etc. are alternate accounts. People have been trying to combat those people with different methods, but what if we fight the source of it? What if we detect those accounts before they even get to try to ruin the gameplay?

Protect yourself against;

  • botnets
  • spammers
  • exploiters
  • trollers
  • attackers
  • lag bombs
  • more

How it works

Well, we can’t magically know which accounts are real and which are alternate accounts, but we try our best. We’ve noticed that many developers use age checks only to disallow new accounts to join their game, but we believe this isn’t enough. Many “alt generator” communities provide accounts with the creation year in 2017, which would bypass the developer’s protection. It was pretty strange to find out that nobody bothers to fight alternate accounts correspondingly, so we decided to make the first step into this.

Atherum runs a set of verification checks whenever a player joins the game. It’s not only about the account age. There are several checkpoints with different importance levels that the developer can manually change, enable, or disable. After all, this is the only way developers can use for partially detecting alternate accounts at the current time.

There can be false positives or false negatives. Obviously.


How to get and install

Atherum is a free and open-sourced product. You can get it on ROBLOX’s developer marketplace here:

Once you have the model in your Inventory, drag and drop it and ensure it stays in ServerScriptService. After that, open the Atherum folder and locate the “Settings” module. Double-click to open it.

Here you can find a lot of configurable settings to make Atherum work as intended in your game. You can choose to enable or disable auto-kicking, log actions, and more. Everything is explained in a comment on the right side of the feature.

It is mandatory that you enable HTTP Requests and Studio Access to API Services in the Game Settings tab. Atherum uses Roblox’s web API for some detections. If the permissions are not granted, Atherum will not run.


API documentation

One of Atherum’s unique features is that it allows you to customize what happens when a player gets detected as an alt. You can choose to teleport them, ignore them, delete them, and much more! Here’s a list of APIs that Atherum has:

Before being able to use the APIs, you need to require the API module:

local AtherumAPI = require(game:GetService('ServerScriptService'):WaitForChild('Atherum Anti-Alt'):WaitForChild('API'))
Full API documentation

This is how to properly call the Atherum API functions:


Player detected event:

This is not part of the API module, but a BindableEvent that is placed under it.

Access it by going:

game:GetService("ServerScriptService"):WaitForChild("Atherum Anti-Alt"):WaitForChild("API"):WaitForChild("UserDetected").Event:Connect(function(player)
        -- your action here
end)



Check if a player was detected as an alt:

AtherumAPI:IsPlayerAlt(player)
  • player (mandatory) should be a player instance. It should contain the player itself, and not the player name.


        Response:

  • bool (true/false), true means the player was counted as an alternate account, false means the player was not counted as an alternate account.


The IsPlayerAlt determination is based on the "Min. detection score" that you can modify in the system Settings.


Get a player's fraud score:

AtherumAPI:GetPlayerScore(player)
  • player (mandatory) should be a player instance. It should contain the player itself, and not the player name.


        Response:

  • number (number), the higher it is, the more checks were failed.


The GetPlayerScore determination is based on the custom importance scores that you can modify in the system Settings.


Get the number of checks a player passed:

AtherumAPI:GetNumberOfPassedChecks(player)
  • player (mandatory) should be a player instance. It should contain the player itself, and not the player name.


        Response:

  • number (number), the total number of checks a player passed.


This will not return the list of the passed checks.



Get a list of the checks for a specific player:

AtherumAPI:GetPlayerCheckStatus(player)
  • player (mandatory) should be a player instance. It should contain the player itself, and not the player name.


        Response:

  • list (array), a list of all checks (names) and if they were passed/failed.


Get a list of a player's failed checks:

AtherumAPI:GetPlayerFailedChecks(player)
  • player (mandatory) should be a player instance. It should contain the player itself, and not the player name.


        Response:

  • list (array), a list of all checks (names) that the specified player failed.


Get a list of a player's passed checks:

AtherumAPI:GetPlayerPassedChecks(player)
  • player (mandatory) should be a player instance. It should contain the player itself, and not the player name.


        Response:

  • list (array), a list of all checks (names) that the specified player passed.



Get the saved data of a specific server:

AtherumAPI:GetServerSavedData(serverID)
  • serverID (mandatory) should be a string. It should contain the server ID (game.JobId) of the server you wish to find. Should NOT be a number.


        Response:

  • list (array), a list of all players who were checked in that server and their passed/failed checks, score, and more.


This will only work if DataStore is enabled in the system Settings.




You may use this in your own scripts to create your custom logic.


Note: the module can only be used in server-side scripts.

Remember that attempting to get API data immediately upon player joining might result in an error or nil response. Atherum requires a few seconds before updating the saved data.

Showcase

Video:

Testing/showcase portal:

Contribution

I guess there are two ways anyone could contribute:

  1. Suggestions/feedback/bug reports/etc.
    Help us understand how we’re doing, or what to do next. Let us know if there are bugs or things we can improve.
  2. Improve Atherum yourself.
    Since it’s open-source, you can make changes yourself. If you believe you improved Atherum, make your version of the source code public (while still giving attribution).

License and usage

You are free to use Atherum at no charge. You are free to edit Atherum’s root files.
Atherum is licensed under the Apache 2.0 open-source software license. Read it here: here (S42 website) or here (opensource.org).


Final notes

As mentioned before, false positives and false negatives are to be expected. We cannot magically know if the account joining is an alternate account or not. You can customize the system’s sensitivity yourself by changing the importance of the checks. We’re always looking forward to improving Atherum and making it more reliable. If you wish to support the cause, join our communications server or direct message me on the DevForum with ideas or pieces of code you may have for us.

Credits
  • InfiniteBlackPIX - main developer
  • Shongton - community manager and project intern

Update log

v1.1 - 20/09/2023 
[/] Updated the "verified account detection". Atherum now uses the IsVerified() function instead of checking by Spacial Voice.

Useful links

Compatible wth Blueberry
Compatible wth Blueberry520×520 104 KB
Compatible wth Blueberry
Compatible wth Blueberry520×520 16.6 KB

34 Likes
#2

What checks do they do? You have not really explained at all how this works.

13 Likes
#3

Well, all checks are visible in the configuration. Here is a list of checks we have implemented in the current version;

  • age
  • friends
  • groups
  • badges
  • premium membership
  • email verified
  • voice enabled / ID verified

We’re looking forward to adding more in upcoming updates.

5 Likes
#4

What if it false kicks/bans someone who isn’t really your alt?

7 Likes
#5

As mentioned, this can happen. You can adjust how strict the system is by changing the importance of every check in the configuration or modifying the maximum fraud score.

However, Atherum allows you to not kick the player if you don’t want to. You can use the API to mute the player or think about other punishments.

6 Likes
#6

I could kinda see this detecting people falsely open cuz the checks are kinda basic and I could see this causing issues.

4 Likes
#7

I really do not suggest using a system that works like this.

It is really bad UX for there to ever be a situation where a user is falsely identified and as an alt account. There is nothing here that is solid proof to detect that a user is an alt account, merely guessing they are an alt. This provides a false sense of security for users of this because… I can also just make an alt account in 2022… or verify ID… or join groups… These methods are hard-coded - which is the problem because what do these communities do when they see tools like this? Improvise! This is just not a good way of detecting alts and will need to be constantly updated to stay relevant.

This solution is a much better way of doing it for anyone curious.

The reality is, there is no perfect way to ban alts, the above way is very effective compared to your method but is still not perfect, but safer and will not ban normal people.

21 Likes
#8

Obviously, it is not a stable way to 100% catch alts. As you said, it’s not possible. However, it’s not that bad either.

2 Likes
#9

I would suggest reading the first section. :slightly_smiling_face:

This method is not suitable at all, it provides poor UX to users who are falsely banned and will deter people from playing. In addition, these websites will improvise and if you don’t update your module consistently, you will continue to have problems. You should think of another way of going about detecting alts, again, I would refer to the GitHub above.

5 Likes
#10

That is also bypassable, every way is bypassable.

#11

Correct, see the final comment.

If you read the details on the repository, it clearly explains who it’s for and what it is not. This does not do that in the same way.

3 Likes
#12

Oh sorry, I mis-read the post then haha.

3 Likes
#13

And remember guys, this is just the start. There is so much to be done! Imagine how far we could get with your support, give it a chance.

2 Likes
#14

Adding on to @FxllenCode:

I think the very concept of “anti alt” systems is fundamentally flawed—you should never bar any account from playing a game just because they might be a bad actor.

Alts are not the source of rule-breakers, it’s the vulnerabilities of games that are. If you accidentally kick new players (which will happen more than you think), you risk negative game perception and an inaccurately low LTD ratio.

This system isn’t bad—It’s ultimately up to the developer to decide whether to implement an anti-alt system. If you do, accurate or inaccurate, you’d be ignoring the source of your issues. You’d be cutting the legs off the dragon instead of its head, so to speak.

9 Likes
#15

Hmm, I think this is actually kind of interesting (tagging @FxllenCode because I’m interested in your thoughts on this, although this reply is directed towards the Atherum developers)

I don’t think this should be the primary means of detecting malicious users (note: there’s a difference between malicious users and alternate accounts), I think you should always wait for someone to prove their intentions via their actions.

However, this immediately rings (to me) as a way to potentially identify malicious users. What I’m about to suggest is a tad more complex (and not something directly related to Athereum application, so pardon) but is a way of using some of Atherum’s checks (which could be decent indicators - not identifiers) to potentially sniff out alternate accounts and then interfacing this with an anti-exploit’s sensitivity calibrations. From here, this might be an interesting way to adjust your anti-exploit’s sensitivity calibration’s based on an initial ‘suspicion’ or ‘hunch’ purely based off of ‘typical’ red flags.

For anyone not following, I’m basically saying that if someone is ‘more likely’ to be a suspicious user (context being that many exploiters use alternate accounts), you give them less of the benefit of the doubt when it comes to evaluating recorded or detected suspicious behavior. Obviously, doing something like this would require a lot of stress testing and smart set-ups (after all, one of the goals of an experience should be to be soo cool that people literally join the platform just to play your experience) to use these check methods as a way of catching actual bad users vice people using new/generally used accounts.

(Apologies, this reply is a little bit tangential, although I think it’s related. This is an interesting resource imo - would definitely recommend people to take a look at the method criteria. Not sure why you are requiring an external module/why this is in settings [i.e., are you expecting people to realistically substitute this module with another handler?], and I think that it would be good to allow users to handle punish functions themselves vice giving them an enumerated list of options and then handling it on your own module)

7 Likes
#16

I’ll preface this by saying that I agree with all of the problems raised by others in this post and tend to be skeptical of automatic detection systems.

That said, I have run some tests with the system with several of my accounts, and I found some poor results. You mentioned these are to be expected, but the results I got are concerning for the system as a whole. I’ll list some information about the account and the score it was given.

None of these accounts are ID verified; I don’t know how much that effects results.
Account #1: Main Account
This account is my main account and thus fulfills almost all of the criteria for a negative score. It is old, has a few dozen friends, many badges, etc. This account got a score of -2 and was correctly identified as not an alt.

Account #2: Main Alternate Account
This account is my primary alternate account. This account has the suffix _alt applied to my main account’s username and is friends with my main account, so to a human reviewer it is clearly an alt. He has only a few groups and friends, and has no premium. He is however a few years old, has many badges, and is email verified. This account got a score of 0 and was incorrectly identified as not an alt.

Account #3: Unrelated Alternate Account
This account is the final account I tested. This account is technically an alt, but it is not obvious to a human reviewer. The account has only one friend (who is also an alt of someone else), has no Robux or premium, is not email verified, and is part of no groups. The account has several badges, and is several years old. This account was immediately kicked for being an alt, and while yes he is an alt, this concerns me. This account has no visible connection with my main account and is several years old. While he could be the type of alt a hacker would create, it is far more likely that an older account with no Robux is just a legitimate user without Robux.

While it can catch some alts, the system seems to just flag users who meet the steryotypical definition of an alt; on the other hand, users that would obviously be alts to a human viewer are not detected. I can hardly describe this as advanced, seeing especially how other alternate-account detectors already do many of the same checks. It seems to me it will just fall into the same trap as others - vastly overflagging one of Roblox’s largest demographics, users without Robux, even if they have signs of legitimate use like a reasonable badge collection and several years of age.

6 Likes
#18

this is very easily bypassable, and has also false positives.

methods to bypass this:

no alt makers are this stupid to friend the same friends, or join the same groups, age, etc etc.
simply, dont do any of these and you are safe.

the false positives:

the person might be in the same group, same friends, same age, but not an alt.

Needs some serious improvement. But i like the idea.

2 Likes
#20

If you combine these two you may be able to partially fix the problem…

#21

It’s obvious that it matches the exact same details of a real account. The idea we had is that trollers and exploiters don’t waste time earning badges, joining groups, making friends, and obviously not email verify.

Also, remember that in the testing center, I have enabled auto-pass email and ID verified accounts.

Thank you for the detailed reply though.

#22

I’m confused about why we need to detect alt accounts. What is wrong with them, if they are exploiters just have an anti-exploit.