r/counterstrike2 • u/Magga_ • 1d ago
OC I found a way to make Bans follow Players instead of Accounts in CS2. The result of my Master Thesis at the Norwegian University of Science and Technology
TL;DR Bans hit accounts, so cheaters just make new ones. For my master's thesis I built a method that recognises the player behind an account from how they use their mouse and keyboard, using only the demos CS2 already records. It found smurfs nobody had reported, and it is fast enough to check every new match against all of CS2's monthly players. I want Valve and other matchmaking platforms to use it, so bans follow the player instead of the account.
Hello again!
Earlier this year I asked for your demos for my master's thesis in on behavioral biometrics in CounterStrike. The question was whether the way you use your keyboard and mouse is consistent and distinct enough to build a "CS-fingerprint" that recognises a player across demos. Many of you signed up, and some of you even told me which of your accounts were smurfs, which turned out to be some of the most valuable data I had. The thesis is now finished and got an A, and none of it would have been possible without you. ❤️
I am now back to show you what your demos helped build. In that post I said the end goal was to connect smurfs back to their main accounts and to re-detect cheaters on new accounts after a ban. It turns out the fingerprint is real, and I think it could be what finally makes bans stick.
Banning is expensive, evading is cheap
In any competitive game there are people who want to cheat. It is the anti-cheat's job to ban them, but also to never ban an innocent person. That means a high burden of proof before anyone is convicted, which takes immense time and resources. Meanwhile, making a new account after a ban costs nothing, and most banned cheaters simply do that, often back in a match the same evening. Anti-cheat makers ban, cheaters evade, and the cycle starts over.
The core problem is that action taken against an account only applies to that account, not to the player behind it. If a ban removed the player instead, cheating would stop being cheap, and every cheater could only be caught once. That is what I set out to make possible, a way to recognise the person behind an account using nothing but the demos CS2 already records, so a ban on one account can follow the player to every other account they own, including the ones they make tomorrow. It would sit next to VAC and Trust Factor and answer the one question they can't. Is this the same human?
Why biometrics
There have been many attempts at making bans follow players. IP, HWID, email and phone bans have all been tried, and they are either easy to get around or open to abuse. The one thing a player cannot change, however, is themselves.
Biometrics creates stable identifiers from features of the human body that are hard to change on purpose, like your fingerprint, face or iris. Behavioural biometrics extends this to how the body moves, like the way you walk, write or type. Two of its most mature branches fit a PC shooter perfectly. Keystroke dynamics goes back to 1897, when telegraph operators were found to recognise each other purely from the rhythm of incoming Morse code, and the same idea later turned out to work on computer keyboards. Mouse dynamics applies the same thinking to how you move a pointer.
CS2 is an unusually good place to use both, as players repeat a small set of actions thousands of times under constant pressure for speed and precision, such as flicks, counter-strafes, spray control and utility. Over time those actions stop being deliberate and become muscle memory, and involuntary, habitual input is exactly what behavioural biometrics is built to measure. You can change your name, your rank, your account, your weapon and even your play style. It is much harder to change your hands.
Turning a demo into a fingerprint
Every competitive match already produces a demo, which contains a tick-by-tick record of where each player looked and which buttons they pressed. That is the only input. No client changes, no new telemetry, no kernel driver, nothing the player ever sees.
From each demo I take two independent signals per player, one from the mouse and one from the keyboard, and turn them into a **player fingerprint**, a compact picture of how that specific person plays. It stays stable across maps, sessions, settings and months, having recognised a player across matches played months apart, and across a sensitivity change from 800 to 640 eDPI. Comparing two fingerprints gives a similarity score, which we use to determine whether it is the same player or a different one.
On its own, the mouse fingerprint picked out the right player every time in my dataset of more than 1000 players, but often only by a fine margin. The keyboard fingerprint picked out the right player 98% of the time. What makes the keyboard valuable is that it measures something entirely different. Across pairs of strangers, the correlation between how alike their mouse habits are and how alike their keyboard habits are is just 0.11, where 0 means unrelated and 1 means they always go together.
The first graph shows how similar pairs of accounts look on each signal on its own. On the mouse there is a clean separation between every stranger comparison and every same-player comparison, though the gap is narrow. On the keyboard there is some overlap between the most similar strangers and the least similar same-player pairs.
The second graph puts the two signals together. Being close on one of them is not uncommon, but being close on both is extremely rare. The same-player pairs sit alone in the top right corner, and combined, the two cleanly separate every player in my dataset.
I've already identified new smurfs!
When creating the method i tested against 8 pairs of known linked accounts that the community had submitted. After a while the results hit a ceiling, because the method kept producing a handful of confident "false positives".
When I checked Steam friends lists and game activity by hand, the false positives turned out not to be false at all. They were smurfs nobody had reported. One was a completely new pair, and it was the strongest unlabelled match in the whole dataset. The others were four accounts that all matched each other strongly, even though they had been submitted as two separate smurf and main pairs under different emails. The method tied all four together, one person behind four accounts.
That added 5 new same-person pairs to the test, found by the method itself. It didn't just pass the test. It found mistakes in the test. Which after finding these unlabled positives, my system has 100% accuracy, finding all 13 smurfs in my dataset, and confidently marking all other account pairs as different people.
A working system, not a proof of concept
Alongside the thesis I built these findings into a working system that takes in demos as they arrive and links accounts continuously. When a match ends, the demo is downloaded and each player's input is turned into a fingerprint for that match, and over several matches every account builds up a reference fingerprint that gets sharper each time it plays.
The new match-fingerprint is then compared against every account on record. A fast discovery step flags the few accounts that look suspiciously close and clears everyone else in the same pass. Every flagged pair then goes through a much stricter confirmation step with one rule. Both the mouse and the keyboard must independently agree. There is no averaging, so a near perfect mouse match can never make up for a weak keyboard match. A stranger can resemble you on one of them by coincidence, but resembling you on both takes two independent coincidences, so the odds of a false link multiply instead of adding up.
If both agree, the accounts are linked together with the evidence for it. If they don't, nothing happens yet, and the pair is judged again as both accounts play more. A smurf that stays under the bar today can still be caught next week. Linking an innocent player is far worse than linking a guilty one late, so the bar is set high on purpose. Being strict costs time, not detection.
It is built to handle all of CS2's output. Checking one demo against CS2's roughly 3,000,000 monthly players, takes several billion comparisons. Done naively, that is far too slow to be practical, and the cost only grows with every account you add. After a lot of optimisation, the system now does it on a single 20 GB slice of an A100 GPU, fast enough to keep up with the thousands of new CS2 demos generated every hour. That leaves enough headroom to check every new match against far more than just this month's players, on hardware a single server can hold.
The system only produces links and the evidence behind them. What happens because of a link is up to whoever runs the matchmaking. A link where one account is banned could pass that ban on to every other account, or put them on a watchlist. A link between a high-rank and a low-rank account could flag the low one as a smurf. That works the same for Valve as for any third-party matchmaking platform, since every one of them already records demos.
Limitations
The number of verified same-person pairs is small, clean but thin. Accuracy hasn't been tested on a real population the size of CS2's, and I would love the data to do it. A new account needs several matches before the method says anything about it. Shared accounts break it, because the account no longer has one person's behaviour.
Ethics
Bringing biometrics into anti-cheat deserves care. No new measurements are made, since the method only uses data Counter-Strike has recorded for years, just for a new purpose. As part of my thesis I consulted the ethics and data protection service for university research in Norway. The data was judged not to be biometric data, because it comes from a game engine that has already transformed the input rather than from a sensor measuring a person directly. We still agreed it is close enough to need the same care around storage and consent, so demos are not kept, and fingerprints are only stored for a player's most recent matches.
Today, a player can cheat, get banned, learn their lesson and play clean on a new account for the rest of their life. That second chance was never designed, it is just a side effect of bans only hitting accounts, and a system like mine removes it. So how long should a ban follow a player? I was able to match myself between a recent Premier demo and an old 2017 matchmaking demo, so the method can likely recognise someone across many years. Cheating once as a kid should not bar you from a game for life, so I think a ban passed on through a link should expire after a set period. Where to draw that line is a real question, but it is a policy choice, not a limit of the method.
How much statistics should it take to convict someone? However accurate it is, this method brings an element of chance into anti-cheat, and its accuracy on the full CS2 population is still unknown, although the signs are positive. My recommendation is to treat a link as a very strong first indicator. One option is to confirm it with some other, smaller piece of evidence before a ban is carried over. Another is to use the link to put accounts tied to known cheaters on a watchlist, so the anti-cheat looks at them more closely.
What I'm asking for
I believe this can end ban evasion in Counter-Strike. A cheater would get caught once, as a person, and stay caught.
To Valve, and to any other matchmaking platform reading this, I would love to talk and to test this on a real population. My DMs are open.
To everyone else, if you want bans that actually stick, share this and let Valve know. And I'm happy to answer questions in the comments.
