I once tried to set up a GPU passthrough setup to a Windows VM to play WoW but there were a ton of report that Blizzard just banned players for using QEMU VMs because they were marked as cheaters.
I once tried to set up a GPU passthrough setup to a Windows VM to play WoW but there were a ton of report that Blizzard just banned players for using QEMU VMs because they were marked as cheaters.
Primagean recently said that in a video commenting PewDiePie's "I switched to Linux" video. While he's apparently a good programmer (he worked at Netflix), he uses Vim, so I don't trust him. Edit: part about vim is an edgy joke.
I work in AAA gamedev and have deployed kernel level anti-cheats before, and I’m aware how unpopular they are; so, sorry for that… you would also accuse us of “bad programming” if there was an overabundance of cheaters that went undetected and/or uncorrected.
The answer is unfortunately complicated, the kernel level anti-cheats themselves aren’t necessarily poorly written, but what they are trying to do is poorly defined, so theres a temptation to put most of the logic into userland code and then share information with the kernel component- but then it’s dangerous for the same reason that crowdstrike was.
Not doing endpoint detection is also a problem because some amount of client trust is necessary for a good experience with low input latency. You get about 8ms in most cases to make a decision about what you will display to the user, that’s not enough time to round-trip to a server about if what is happening is ok or not. Movement in particular will feel extremely sluggish.
So, its a combination of kernel level code being harder in general (malloc, file access etc; are things the kernel gives you in user land after all), the problem space being relatively undefined (find errant software packages and memory manipulation), not being able to break out of the kernel level environment for an easier programming and iteration experience and trying to not affect performance.
Lots of people think they can do it better, I’m happy to hire anyone who actually thinks they have a clue, it’s a really hard problem honestly and the whole gamedev industry is itching for something better: even us gamedevs don’t like kernel level anti-cheat, it makes debugging harder for ourselves too and introduces hard to reproduce bugs.
PS; sorry if I’m not being eloquent, I am on vacation and typing from my phone.
However, what if Primeagen meant that HAVING to IMPLEMENT kernel level anti cheat is a symptom of bad programming, and not the anti cheat per se? (that is, with good enough programming, it could somehow be avoided).
And kudos to you. I appreciate people in game dev, they can get a lot done in short time. I haven't played mmo fps since battlefield 3, and it wasn't that bad then. But I've heard that without kernel level they would be unplayable.
Thank you for your time!
Long term I'm kinda hopeful that this is something that will be mitigated through AI-based approaches working to detect the resulting patterns rather than trying to detect the cheat code itself. But this requires sufficiently advanced models running very fast locally, and we're still far from that.
The reason is the round trip time mainly.
Server corrections will feel like “floaty” or “banding” behaviour, we used to do that and people get upset because it “feels” wrong.
I don't understand, how could crowdstrike have avoided their issues by putting more code in the kernel? Or am I misreading your statement?
If they had not tried to parse data inside the kernel it would not have been an issue.
About 40% of games that use anti cheat currently work on linux. Getting banned for using wine is very rare because anti cheat that don't support linux would complain about not running an prevent you from even joining a game to get banned.