Anticheating mechanisms

Added by Radegast over 6 years ago

I recently read an interesting article about a proof-of-concept GPL Quake anticheat. It may not be the most sophisticated way of doing it, but it has several advantages over TZAC: relatively easy to implement, multiplatform and mod independent.

Here it is: http://quake2world.net/blogs/jdolan/gpl-quake-anticheat

It could certainly be a start and we could improve upon it over time.


Replies (21)

RE: Anticheating mechanisms - Added by Radegast over 6 years ago

Anti-Wallhack

btw, I wrote a simple wallhack to test our anti-wallhack feature created by Laszlo Menczel for the Q3 engine. It works, but, as others found out, there are some glitches, so it is not suitable for use on competition servers.

wh_blue.jpg (108 KB)

wh_red.jpg (91.9 KB)

Wh_blue Wh_red

RE: Anticheating mechanisms - Added by Spyhawk over 6 years ago

Thanks Radegast, very interesting indeed.
The comments in the link that you can find in the above article are also worth reading.

PGP signing is certainly the way to go, although this is not perfect. The 'closed’ source part bugs me, and in fact I’m afraid there is a big issue with people compiling the game themselves, right? I’m mostly thinking about Gentoo here.

While searching about some anti-cheat counter measure, I came across this article that proposes a somewhat interesting way (although a bit controversial) to prevent mass cheating:

Effective banning

If you want to give the player the power to get rid of cheaters, they need to be able to get really rid of them. A simple IP ban can be evaded by doing a new dial in. Using some more obscure methods to generate an unique player ID, by using the MAC-Address for example, can also be evaded by changing the relevant information. Face the truth that without some worse TPM based DRM, you don’t have the chance to identify a certain hardware or player. As such, evading a ban has to be coupled to effort or - even better - money. Commercial games which have a game key, which is currently a pretty good thing for this. When implemented the right way, the player has to authenticate against a game master server and the game server they want to join. Using this, you can have a unique identifier which doesn’t change and if you make it possible to ban by this identifier, you basically ban the game key from your server and the cheater has to buy a new game key to evade this ban. As such, ban evading is bound to financial effort which can be a huge obstacle.

But how can open source games implement this, since nothing is being sold? Short answer: Authentication. For example, you could implement game accounts and let the players or game server admin decide if they want to play only with authenticated players or not. If so, you can ban the player account and the evading cheater has to go trough the registration process again (fill the captcha, create a new e-mail address, activate the account by e-mail etc...). If you don’t want to use a central server, which has to be always available, you can create certificates for each player, which are then validated by the server using your public signing key. I’ll probably make a dedicated post about such a system and infrastructure at some time, but I guess you’ve got the point.

However, while creating a new account isn’t such a high obstacle compared to financial effort, it is better than none at all. That said, even as a non-commercial open source game developer, you could still add a financial obstacle as well. For example, you could sell game keys, accounts or certificates for only 1$ or 2$ and make all the money go to charity. Players and server admins could still decide if they want to allow only paying players and if they do so, the money was used for something good. And due to the low price and the charity model, the player acceptance will be probably somewhat high. Bonus: If a cheater spends a lot of money for some keys, he supports at least the charity!


RE: Anticheating mechanisms - Added by Spyhawk over 6 years ago

Zero wrote:

Is PB GUID still transferred & saved in plain text? If yes, it’s useless. Using it has obvious good things such as many mods supporting it already, but as long as it’s so unsecure I don’t see a point in using it.

Encrypting the cl_guid doesn’t make sense, does it? It is already an encrypted form of the initial etkey. Any information sent to clients and that goes back can be manipulated. The only real solution would be to ensure the client is unaltered (see above).

RE: Anticheating mechanisms - Added by ailmanki over 6 years ago

The guid has to be sent in a secure channel - encrypted - to the server. So that a spy cannot get the guid.
At best we use PGP mechanism to solve this.
Identification is very important.

The Antiwallhack from Laszlo Menczel has been created in first place for Quake 3 Noghost.
For reference this is the topic where he started this stuff as far as I know (he username is "speaker":
http://www.quake3world.com/forum/viewtopic.php?f=7&t=47496
http://www.quake3world.com/forum/viewtopic.php?f=7&t=47832

Here is a demo I made with a earlier version (same code though as far as I know)
http://www.youtube.com/watch?v=vobJyRhR3ZE

Improving this anti wallhack should be a high priority, as it effectively blocks wallhacking.
Then maybe its also possible to alter info’s about the players themselves. Health, Class.. those information a cheat displays.

Client-side anti-cheating is a Sisyphus project imho. Its like DRM and antivirus.. with enough "criminal energy" they can be circumvented. So before doing that, maybe explore all the other options - which might be very difficult, but once done - they will be forever useful. Like anti-wallhack, pattern detection to find cheaters, authentication, server side demo.

RE: Anticheating mechanisms - Added by nate over 6 years ago

Hey all!

Been lurking around every now and then, but since I’ve seen this discussion I’ve decided to give my input.

@antiwh
I’ve added it to mine project sometime ago. I assume you’re already familiar with bugs but just for the sake of it; It was not hard to fix leaning bug (just a simple lean check) and spectator bug - where player spectating (eg. shoutcaster) loses sight of players once out of radius, which renders it useless for shoutcasting so a simple ignore of spectators in wh check solved it. I didn’t thoroughly tested it so there may be other problems but one that’s confirmed is a ping issue, with patches I applied it creates problems for players with high pings - players poping up around a corner, so that’s something I have to solve yet (once I have more time).

@Effective banning
I’ve addressed this issue in following manner. I took dpmaster’s source code, rewrite it and instead of acting as master server it’s auth server that’s tied to (*sql) database. I’ve hooked key creation under forum account, so any user registering can easily create a new key→download it & place it in root folder. I wont really go into specifics due obvious reasons but, you can easily solve the worries about plain text transmission by pairing on auth server’s part. To simplify it- client fires a clean serial key check directly to auth server and another packet containing guid to a server (s)he’s connecting, server grabs guid and if streaming is enabled, relays guid to auth server. Auth server solves this easily - in memory it pairs keys with challenges, and once guid challenge is received, it simply queries the memory to see if there’s a challenge with corresponding key residing there..if it is, it lets client in, if not it.. That way guid is useless as spoofing of it wont let someone in without having an actual key.

It’s far from fool save method but by combining it with additional layers can strengthen the process. Some of additional layers I’ve applied are in shape of website interaction - like various methods of tracking (again not fool prove) to prevent double accounts, and ability to filter guid age per server- meaning server owners can simply set min age of guid to enter at least 1 day etc..so that way a cheater caught that bypasses forum checks, is still in queue before they can enter that specific server.

Like I mention few times it’s far from fool save, but it does help as it complicates things for general f*ktards and brings some aid to server admins as well as some piece to players. Anyway, hope it helps you in any way.

RE: Anticheating mechanisms - Added by Dragonji over 6 years ago

nate wrote:

@Effective banning
I’ve addressed this issue in following manner. I took dpmaster’s source code, rewrite it and instead of acting as master server it’s auth server that’s tied to (*sql) database. I’ve hooked key creation under forum account, so any user registering can easily create a new key→download it & place it in root folder. I wont really go into specifics due obvious reasons but, you can easily solve the worries about plain text transmission by pairing on auth server’s part. To simplify it- client fires a clean serial key check directly to auth server and another packet containing guid to a server (s)he’s connecting, server grabs guid and if streaming is enabled, relays guid to auth server. Auth server solves this easily - in memory it pairs keys with challenges, and once guid challenge is received, it simply queries the memory to see if there’s a challenge with corresponding key residing there..if it is, it lets client in, if not it.. That way guid is useless as spoofing of it wont let someone in without having an actual key.

Offline auth server = no possibility to play

Not a good solution in my humble opinion. It works good for games supported by huge companies because they usually have really solid servers with almost 100% uptime. I am afraid you can’t guarantee 100% uptime in a small project.

RE: Anticheating mechanisms - Added by nate over 6 years ago

I solved this with "strict cvar" method, where owner can decide if they want to let someone in when auth is down - after 8 seconds (3 queries) or refuse entry (strict on). Albeit there’s no 100% uptime nowhere but it’s not hard to get a decent small and stable vps with 98-99% uptime and a ddos protection for almost a pocket change. Footprint in may case is 8mb and it doesn’t need much if anything to run it. I’m aware from first hand that money is scarce but whatever you’ll decide to do, will almost always have to fall back to some sort of backend server where all the same risks will be posed.

In either case, just wanted to share my thoughts and approaches.

RE: Anticheating mechanisms - Added by IR4T4 over 6 years ago

Hey nate!

Your code has been merged a while ago but ET: L does only exclude free flying spectators. I think it should be same in rtcw.
As an extension for the strict way a local player whitelist may assist the admin. Similar to the shrubbot system - allowed to connect with level=regular only.
We need database connectivity ASAP ...

RE: Anticheating mechanisms - Added by nate over 6 years ago

Heya,

I personally don’t see a free floating spectators as a problem. Cheating on public server by running 2 instances still requires a lot of attention or there’s a communicational lag between 2 players thus in fast paced games like et/rtcw doesn’t really bring much of a benefit on a more competitive level. Albeit competition aspect is easily solved by locking spectators and allow a trusted shoutcaster only to spectate, so with that in mind I decided to keep it on. Another possible solution would be where only logged in spectators with certain level would be ignored but this kinda of solutions usually resolve in bunch of hacks and a mess so for now I just let it be like it is.

A possible solution to your problem would be to port *sql support from Dushan’s openWolf. Deploy a white/black list scheme where white list would be used when public repo is down and would basically be a shrubbot approach in essence and blacklist would be used in combination with official repo. Simple php parser could be written and released so any owner could hook it under cron/task job and would simply grab txt file from official repo and parse (banned guids) to their local server. Alternatively same thing could be deployed for txt based handling for ones that don’t have DB support/or a DB hosting for a small fee could be offered which would aid admins as well as helping project to cope with expenses etc. Although blacklist approach would be somewhat useless since guid can be created per desire..in that case you could deploy min guid age scheme so blacklist approach at least makes any sense. Just tossing out ideas.

RE: Anticheating mechanisms - Added by IR4T4 over 6 years ago

SQL support of openWolf is limited to mysql. The current ideas is to use this lib http://soci.sourceforge.net/

RE: Anticheating mechanisms - Added by lrq3000 over 2 years ago

Hey guys,

It’s great you implemented the antiwallhack system of Laszlo, it’s really the best way to prevent wallhacks.

About aimbots, I worked on an opensource anticheat architecture, completely server-sided (so that cheaters can’t avoid it), based on behavior analysis automated by machine learning.

There are several research papers about automated behavior analysis to detect cheaters, it works well. My architecture goes beyond simply doing behavior analysis by providing a full architecture to produce the necessary behavior data from servers automatically, then ease the analysis (using any algorithm you want), the sharing of behavior analysis parameters (so that server administrators can share the parameters or even the behaviors databases in order to construct big datasets to get better parameters) and finally allows for ban/kick/demo recording/any rcon command as a final measure.

The whole project is here, made for OpenArena, but easily translatable to any ioq3 based game:

That being said, I stopped the project because of a lack of time, but it fully works. The only downfall is that the algorithms I used are not efficient enough. I plan to add support for scikit-learn, leveraging the big library of machine learning algorithms scikit-learn offers. Also, better behavior features could provide better results, such as a better reaction time estimator and a crosshair estimator (is the crosshair aiming at a player’s head? for how long? etc.).

This approach was implemented by the mod ExcessivePlus (along with an enhanced antiwallhack but stemming from the same Laszlo patch). If anybody is interested into reviving this project, I can supervise the effort and provide the update to support scikit-learn.

RE: Anticheating mechanisms - Added by lrq3000 over 2 years ago

To clarify what is the goal of such a system: with behavior analysis, you analyze what are "normal" players behavior (non-cheaters), and from that you can detect "anomalous" behaviors (cheaters). This has the big advantage that you just need to get data from normal players, which is readily available. It will also be robust enough to detect new cheats (because we don’t model the cheats anyway but the non-cheat).

In the end, cheats can still work, but only if they do not display "anomalous" behavior, such as a too high precision or unnatural human movements or reaction time. So in the end, such cheats are not a threat anymore, since they do not give a "surnatural" power, because they simply are not allowed to trespass the "natural ability" threshold.

Of course that’s in theory, and in practice there will be several false positives. But the goal of the system is NOT to auto-ban or auto-kick (even if it is possible), but rather to autodetect suspicious behavior, and launch an autorecord of them, for later review by the server administrator. This would also be the most efficient, as delaying the punition will reduce the clues cheaters can have (indeed if they get kicked instantly, they can iteratively refine their cheats, whereas if the punition is delayed, they can’t know what version of their cheat did that).

RE: Anticheating mechanisms - Added by lrq3000 over 2 years ago

Finally, here are english slides about the whole project and how it works: https://github.com/lrq3000/oacs/blob/master/doc/PIAD34-OACS-1-en.pdf

You can ask me here if you want more details on one point. I’m convinced this is the best approach for an opensource anticheating system, as it will leverage the collaborative nature of opensource, because:

1. you can share datasets and parameters, everything is anonymized, the ids are not necessary for the behavior analysis).
2. having the database/parameters does not provide the program (since it is learnt by a machine), and even if learnt, it cannot be bypassed (since everything is analyzed server-side). This is why this approach is also being investigated by AAA studios currently such as Battlefields.

RE: Anticheating mechanisms - Added by Spyhawk over 2 years ago

Wow! Now that is interesting!

It’s also been a while I have been convinced the best approach to counter or reduce cheating is based on statistical learning, and creating such a system has been on my mind for quite some time. I am also quite familiar with ML techniques and scikit-learn/tensorflow, so your work is definitely very relevant to this project, thanks! I’ll have a closer look asap, expect to heard from us very soon!

RE: Anticheating mechanisms - Added by lrq3000 over 2 years ago

Great, I’m very eager to continue this project, but alone it’s been very difficult to complete it

You might also be interested in looking into a similar project, whose author contacted me a few months ago to merge with my project: https://github.com/The-Skas/Anti-Cheat

His approach was oriented towards CounterStrike-GO, but it is very similar, except that it uses a new machine learning algorithm based on hidden markov model.

RE: Anticheating mechanisms - Added by Spyhawk over 2 years ago

Tracked in #1021.

I’ve had a look at the provided documentation and had a quick overview of the interface code, and I can say that I like what I see.
In particular, I love the flexibility provided, and that the ML part is done entirely in python and can be easily visualized with Jupiter notebook. I honestly don’t have many questions as I’m quite familiar with ML concepts already.
Using a multivariate Gaussian/clustered augmented Gaussian algorithm is a good approach, but I guess there are quite many possibilities that could be tested, including "deep learning" techniques.

Your slides seem to show good results detection, so maybe you could expand on what is actually not working well. Or to reformulate it: "Why don’t I see bad results in your slides?"

Also, reading https://github.com/ioquake/ioq3/pull/265 I guess this could also be used to analyze server demo. If I’m not wrong, our implementation is based on your own code or at least very similar.
I am also not sure if the work done by The-Skas could be reused somehow, as CS pattern recoil system is quite specific (each weapon has always the same recoil pattern), but I haven’t had a closer look at the provided code.
Adding or improving support for scikit-learn would be definitely useful here.

RE: Anticheating mechanisms - Added by lrq3000 over 2 years ago

Hey Spyhawk,

Sorry about the late reply, I intended to answer much earlier but I had a very big project to finish for my IRL job

Thank you very much for your interest! I’m also excited to work again on this project

So I can start working on the project again beginning from middle of June onwards (until probably the end of the year, which should be way more than enough if I have collaborators to work with).

What I need help with:
  • porting the data recorder from ioquake3+OA to et-legacy (should not be too hard, the data recorder is implemented similarly but even more standalone than my server-side demo patch).
  • add new behavioral features. I’m talking here about machine learning features, I guess you see what I mean In particular, I think the anti-wallhack routines could be reused to generate new features, such as knowing if player A is aiming at player B, ever better would be the exact localization such as middle body part, head part, etc. Which was not possible in ioquake3.
    Another idea of a feature that I think would be powerful and unavoidable: get target player ID (when aiming or shooting) so that we can join target player’s infos, such as: target player speed, target player distance, etc.
  • setup a server to test data collection and anti-cheat detection (I have a set of custom ioquake3 aimbots to test but I’m not sure they will work on ET, but anyway we need data from real players too!).
Then on my side, but help is welcome too!
  • Variables combiner: to create new variables as linear combinations of several other variables, eg: to allow to combine target player moving x speed, I expect anticorrelated with time aiming at body with big outliers for aimbots.
  • frames aggregator: currently, each sample for the ML algo = one timeframe, we could aggregate and average over several timeframes to get more smoothed and robust predictors (this is the most common approach used in scientific studies on anti-cheating systems based on behavior).
  • bridge to scikit-learn, should be easy using sklearn-pandas (https://github.com/paulgb/sklearn-pandas), which was not available at the time I created this project.
  • automated cross-validation. There is already a ROC curve and a confusion matrix generator, and cross-val is partially implemented in the notebook, I would just like to automate it (and make it compatible with scikit-learn).
  • discrete variable expander: a module to expand discrete variables into as many variables as there are values, this should greatly enhance the performance for classifiers and non-linear models.
  • unit testing (not 100% but at least some to ensure coherency across versions).
  • (self-reminder: merge author-detector core into OACS to include structural coherency constraints ala colored petri networks).

That’s all I planned for now. With only these few features added, I expect the accuracy to increase substantially, which is the only weak point of the system for now, so that we get a robust working core that can quickly be used by server administrators

Feel free to propose stuff if you have any other idea of things we should add to the core (or later as additional modules)!

RE: Anticheating mechanisms - Added by lrq3000 over 2 years ago

Just additional notes here to answer your side questions

Using a multivariate Gaussian/clustered augmented Gaussian algorithm is a good approach, but I guess there are quite many possibilities that could be tested, including "deep learning" techniques.

Yes, the multivariate gaussian was a first generic approach, but there are much more clever algorithms nowadays, it should be easy to try them with scikit-learn. Also I might have a look if it’s possible to use deep-learning frameworks such as Theano.

Your slides seem to show good results detection, so maybe you could expand on what is actually not working well. Or to reformulate it: "Why don’t I see bad results in your slides?"

Because it was for a university project, I tried to show mostly the good sides to get a good mark ;-p But you can see the detection is not great by looking at the scatter plots, the data is not linearly separable. I did not hide it, just minimized it for presentation purpose But everything that is present in the slides is also present in the software, everything works!

Also, reading https://github.com/ioquake/ioq3/pull/265 I guess this could also be used to analyze server demo. If I’m not wrong, our implementation is based on your own code or at least very similar.

Yes it’s my implementation of server-side demos that is used in et-legacy, but I don’t think we could analyze demos for anti-cheats, because demos do not reproduce all players commands. In my server-side demos patch, there is a commented part that allow to record all these infos, but it makes demos so big this is hardly useful in practice... But it should be possible.

I am also not sure if the work done by The-Skas could be reused somehow, as CS pattern recoil system is quite specific (each weapon has always the same recoil pattern), but I haven’t had a closer look at the provided code.

About The-Skas, in fact he already contacted me by email a few months ago, he offered to merge his project into mine, since my framework is more general purpose, while his is an implementation of a specific algorithm (which seems to work well!). For the moment it’s a bit stalled, but we might do that in the future

RE: Anticheating mechanisms - Added by lrq3000 over 2 years ago

Ps, i forgot to say, if the results are good enough, i will write and publish a scientific paper in a peer reviewed journal, and all contributors will be co-authors I really intend this project to be collaborative, from the core to the end!

RE: Anticheating mechanisms - Added by Spyhawk over 2 years ago

Glad to hear back from you!

I’m myself quite busy at the moment, but just drop a post at mid-June so we can plan and coordinate our effort.

Because it was for a university project, I tried to show mostly the good sides to get a good mark

I kinda knew it haha

if the results are good enough, i will write and publish a scientific paper in a peer reviewed journal, and all contributors will be co-authors

Quite interesting!

RE: Anticheating mechanisms - Added by lrq3000 over 2 years ago

Ok perfect, I’ll post in mid June BTW i did thes project at the beginning of my studies in AI and machine learning, it’s no wonder i did not get great results, that’s why I’m pretty sure we can do a lot better, particularly if we are working together and now that i finished my studies and worked on several other projects!

(1-21/21)