Anti-cheat is a misnomer; it's much more about detecting cheats more than it is preventing them. For people who are familiar with how modern anti-cheat systems work, actually cheating is really the easy part; trying to remain undetected is the challenge.
Because of that, usermode anti-cheat is definitely far from useless in Wine; it can still function insofar as it tries to monitor the process space of the game itself. It can't really do a ton to ensure the integrity of Wine directly, but usermode anti-cheat running on Windows can't do much to ensure the integrity of Windows directly either, without going the route of requiring attestation. In fact, for the latest anti-cheat software I've ever attempted to mess with, which to be fair was circa 2016, it is still possible to work around anti-cheat mechanisms by detouring the Windows API calls themselves, to the extent that you can. (If you be somewhat clever it can be pretty useful, and has the bonus of being much harder to detect obviously.)
The limitation is obviously that inside Wine you can't see most Linux resources directly using the same APIs, so you can't go and try to find cheat software directly. But let's be honest, that approach isn't really terribly relevant anymore since it is a horribly fragile and limited way to detect cheats.
For more invasive anti-cheat software, well. We'll see. But just because Windows is closed source hasn't stopped people from patching Windows itself or writing their own kernel drivers. If that really was a significant barrier, Secure Boot and TPM-based attestation wouldn't be on the radar for anti-cheat vendors. Valve however doesn't seem keen to support this approach at all on its hardware, and if that forces anti-cheat vendors to go another way it is probably all the better. I think the secure boot approach has a limited shelf life anyways.
I remember reading that Microsoft is trying to crack down on kernel level anti-cheats. Just like anti-virus, they mess with the operating system on a deep level, redirecting/intercepting API calls, sometimes on undocumented and unstable internal APIs.
Not only does this present a huge security risk, it can break existing software and the OS itself. These anti-cheats tend not to be written by people intimately familiar with Windows kernel development, and they cause regressions in existing software which the users then blame on Windows.
That's why Microsoft did Windows Defender and tried to kill off 3rd party anti-virus.
Apple has gone a similar way with effectively killing kernel extensions for the same reasons. In theory all the kernel extensions use cases have been replaced with "System Extensions" but of course not the same.
The basic explanation is that it prevents binaries that are not signed by default from being loaded during the boot process. It only restricts the booting process in the uefi stage. If an executable has been modified, then it will not load due to secure boot. Technically there is nothing stopping you from modifying say winload.efi and signing it with your own key then adding that key to your bios keystore so that it will pass secure boot checks and still use secure boot.
I think the biggest thing is that the anticheat devs are using Microsoft's CA to check if your efi executable was signed by Microsoft. If that was the case then its all good and you are allowed to play the game you paid money for.
I haven't tested a self-signed secure boot for battlefield 6, I know some games literally do not care if you signed your own stuff, only if secure boot is actually enabled
edit: Someone else confirmed they require TPM to be enabled too meaning yeah, they are using remote attestation to verify the validity of the signed binary
Disclaimer: This is only an educated guess based upon public info. Also, it's impossible to make something truly unspoofable, but it isn't that hard to raise the bar for spoofing pretty high.
There are two additional concepts built upon the TPM and Secure Boot that matter here, known as Trusted Boot [1,2] and Remote Attestation [2].
Importantly, every TPM has an Endorsement Key (EK) built into it, which is really an asymmetric keypair, and the private key cannot be extracted through any normal means. The EK is accompanied by a certificate, which is signed by the hardware manufacturer and identifies the TPM model. The major manufacturers publish their certificate authorities [3].
So you can get the TPM to digitally sign a difficult-to-forge, time-stamped statement using its EK. Providing this statement along with the TPM's EK certificate on demand attests to a remote party that the system currently has a valid TPM and that the boot process wasn't tampered with.
Common spoofing techniques get defeated in various ways:
- Stale attestations will fail a simple timestamp check
- Forged attestations will have invalid signatures
- A fake TPM will not have a valid EK certificate, or its EK certificate will be self-signed, or its EK certificate will not have a widely recognized issuer
- Trusted Boot will generally expose the presence of obvious defeat mechanisms like virtualization and unsigned drivers
- DMA attacks can be thwarted by an IOMMU, the existence/lack of which can be exposed through Trusted Boot data as well
- If someone manages to extract an EK but shares it online, it will be obvious when it gets reused by multiple users
- If someone finds a vulnerability in a TPM model and shares it online, the model can be blacklisted
Even so, I can still think of an avenue of attack, which is to proxy RA requests to a different, uncompromised system's TPM. The tricky parts are figuring out how to intercept these requests on the compromised system, how to obtain them from the uncompromised system without running any suspicious software, and knowing what other details to spoof that might be obtained through other means but which would contradict the TPM's statement.
Perhaps, I have yet to experience anything like what the older games had though.
It might just be the game too - I do think the auto aim is a bit high because I feel like I make aimbot like shots from time to time. And depending on the mode BF6 _wall hacks for you_ if there are players in an area outside of where they are supposed to be defending. I was pretty surprised to see a little red floating person overlay behind a wall.
Anticheat devs could REALLY benefit by having some data scientists involved.
Any player responding to ingame events (enemy appeared) with sub 80ms reaction times consistently should be an automatic ban.
Is it ever? No.
Given good enough data a good team of data scientists would be able to make a great set of rules using statistical analysis that effectively ban anyone playing at a level beyond human.
In the chess of fps that is cs, even a pro will make the wrong read based on their teams limited info of the game state. A random wallhacker making perfect reads with limited info over several matches IS flaggable...if you can capture and process the data and compare it to (mostly) legitimate player data.
> Any player responding to ingame events (enemy appeared) with sub 80ms reaction times consistently should be an automatic ban.
It's really much more nuanced than that. Counter-Strike 2 has already implemented this type of feature, and it immediately got some clear false positives. There are many situations where high level players play in a predictive, rather than reactive, manner. Pre-firing is a common strategy that will always look indistinguishable from an inhuman reaction time. So is tap-firing at an angle that you anticipate a an opponent may peek you from.
You mustve missed the part where i spoke of consistency?
Ive played at the pro level. Nobody prefires with perfect robotic consistency.
I dont care if it takes 50 matches of data for the statistical model to call it inhuman.
Valve has enough data that they could easily make the threshold for a ban something like '10x more consistent at pre-firing than any pro has ever been' with a high confidence borne over many engagements in many matches.
Then youve immediately made the cheater worse than the best players to blend in with them. Mission accomplished, cheater nerfed significantly. You wont even know theyre doing it.
Good! Thats a much better situation than the one we are in. Thrre is a limit to how much damage a good legit player can do to the average player experience. Just the psychological damage a blatant or rage hacker does is immense. Kills your motive to play, makes you question others, etc.
There's well analyzed video of a pro player streaming who got temporarily banned for something like this. It might not even have been pre-fire, but post-fire at a different enemy retreating at the same position
Valve need to tweak the model so that it requires a higher confidence level before a ban, and to reduce false positives in their data capture methods. This is a mistake but doesnt kill the idea.
We used to track various timings in some of our games to detect cheating. Cheaters find out and change their cheat engines to perform within plausible human reactions. Which is a benefit - now the cheating isn't obvious to everyone, but it still happens. I don't know if you could sprinkle data scientist dust on the problem and come up with a viable cross-game solution though.
Good! Thats actually one of the goals. Reduce the advantage cheaters can gain to within human bounds. They can cheat to feel like a good player, but not a god.
Or perhaps the 0ms-80ms distribution of mouse movement matches the >80ms mouse movement distribution within some bounds. I'm thinking KL divergence between the two.
The Kolmogorov-Smirnov Test for two-dimensional data?
There's a lot of interesting possible approaches that can be tuned for arbitrary sensitivity and specificity.
Throwing in ML jargon and going straight to modelling before understanding the problem reduces your credibility as a data scientist in front of engineers and stakeholders.
As always, one of the most difficult parts is getting good features and data. In this case one difficulty is measuring and defining the reaction time to begin with.
In Counter Strike you rely on footsteps to guess if someone is around the corner and start shooting when they come close. For far away targets, lots of people camp at specifc spots and often shoot without directly sighting someone if they anticipate someone crossing - the hit rate may be low but it's a low cost thing to do. Then you have people not hiding too well and showing a toe. Or someone pinpointing the position of an enemy based on information from another player. So the question is, what is the starting point for you to measure the reaction?
Now let's say you successfully measured the reaction time and applied a threshold of 80ms. Bot runners will adapt and sandbag their reaction time, or introduce motions to make it harder to measure mouse movements, and the value of your model now is less than the electricity needed to run it.
So with your proposal to solve the reaction time problem with KL divergence. Congratulations, you just solved a trivial statistics problem to create very little business value.
Appreciate the feedback, you're right - armchair speculation is different than actual data science. Without actual data to examine, we're left with the latter and that can still be a fun exercise even if it doesn't solve any business problem. We're here to chitchat and converse after all.
Yeah, apologies if it was too harsh. I was more irked by someone else who kept trying to asset it's an easy problem, and confused it with your display of raw curiosity, which is something I don't wish to discourage.
Cheaters don't have to play like normal people to avoid detection. They just have to make it expensive to police them. For example, the game developer may be afraid of a even a 10% false positive ban rate, and as a result won't ban anyone except perhaps a small number of clean-cut cases.
Yes, the current status is that cheaters can play distingushable from humans. But my point was more that, if we create a system that allows cheating that still is equivalent to a good player, then it just feels like playing against good players. Which, to me, feels like it'd be mission accomplished.
This is one of the cases where ML methods seem appropriate.
Most cheaters are playing well outside of human limits and doing huge amounts of damage to the legitimate player experience. A 10% safety margin beyond human play sounds reasonable. A world where cheaters can only play 10% better than humans is a far better world than the one we are in at the moment.
Strong disagree. I play a lot of casual CS, and the number of extremely poor / new / young players using rudimentary cheats and performing far below average is huge. Most players don't watchfully spectate the bottom fraggers in the lobby, but if you do, the number of them brazenly using wallhacks is quite high.
These players aren't using aimbot / triggerbot (or if they are, they don't understand the gunplay and try to shoot while running), and may not even understand wall penetration, so their reaction times wouldn't look abnormal at all. From the data, they would likely have below average reaction times still.
Even though they are not performing well, their presence still massively alters the gameplay for legitimate players. For one, lurking becomes a pointless endeavor. You're better off rushing wildly than attempting any sort of stealth.
Why not? As long as there are players, some of them also want to be admins. You maybe mean commercial administration is not scalable for games with a fixed price? Sure, but give the option to the community to manage (rent) servers on their own and they will solve it themself.
Its not even an option in most titles and the industry as a whole has moved away from such hosting models, partly to ensure players receive a consistent and fair experience. Community servers were rife with admin abuse.
Its okay if you havent played an online game in 20 years mate
Like another commentor mentioned, I think that only works for a specific cheat(engine) - as long as they don't adjust (and randomize more for example). If it could be solved with some statistics, I think it would have been done already. I ain't a statistician though, but if you feel confident, I think there is quite some money in it, if you find a real world solution.
>Can you define what "reacting" means exactly in a shooter
A human can't really, which is why you need to bring in ML. Feed it enough game states of legit players vs known cheaters, and it will be able to find patterns.
Yeah, that's why you need a data scientist or two to figure that stuff out. Its a solvable problem, but you're not going to get solutions instantly for free in the reply section of HN.
But in the reply section you can read about that it has been tried in reality, with not so much success as in theory. But if you see a working solution, then you don't need to tell me, but can market it yourself.
Because of that, usermode anti-cheat is definitely far from useless in Wine; it can still function insofar as it tries to monitor the process space of the game itself. It can't really do a ton to ensure the integrity of Wine directly, but usermode anti-cheat running on Windows can't do much to ensure the integrity of Windows directly either, without going the route of requiring attestation. In fact, for the latest anti-cheat software I've ever attempted to mess with, which to be fair was circa 2016, it is still possible to work around anti-cheat mechanisms by detouring the Windows API calls themselves, to the extent that you can. (If you be somewhat clever it can be pretty useful, and has the bonus of being much harder to detect obviously.)
The limitation is obviously that inside Wine you can't see most Linux resources directly using the same APIs, so you can't go and try to find cheat software directly. But let's be honest, that approach isn't really terribly relevant anymore since it is a horribly fragile and limited way to detect cheats.
For more invasive anti-cheat software, well. We'll see. But just because Windows is closed source hasn't stopped people from patching Windows itself or writing their own kernel drivers. If that really was a significant barrier, Secure Boot and TPM-based attestation wouldn't be on the radar for anti-cheat vendors. Valve however doesn't seem keen to support this approach at all on its hardware, and if that forces anti-cheat vendors to go another way it is probably all the better. I think the secure boot approach has a limited shelf life anyways.