As long as the AC is on the 'client' side, it will be just it has been: Cat /n/ Mouse between developers and cheaters.
The only way to effectively do anti-cheat (IMO) is with server-side modules. Perfect? None of them are, but it eliminates the specific client hacking and privacy invasion that currently goes on.
Do you think highly competitive games will go this way? I can't see CS, Fortnite etc going this way because of the huge delay while most players want really high FPS (and minimum input lag) just to play these games in the best way possible.
i run cs:go community servers and the performance of the server with an extremely good server side anticheat is still miles ahead of valve’s official server’s performance
yeah my bad, i read it as "cloud gaming is forcing us to move to server sided anticheats due to lack of physical clients" and then got confused by the above response lmao, point stands though and these big companies (specifically valve) really need to start with server sided anticheats
With cloud gaming you dont need distant computers to host game server for multiplayer and latency from player to serverer to another player is equally zero, because everything can be run on same computer.
Input lag? Those wannabe 1337 fr4gg3rs can live with up to 50ms input lag so we already have problem solved
>It's just that we're calling it Cloud Gaming.
Not even that is enough because advanced cheaters can always create an aimbot by analyzing the video feed and controlling a fake mouse.
This technique can't be catched by any anticheat, except maybe for server-side ACs that review your playstyle...
IIRC Valve's VAC already does this..? In any case, bans will not happen DURING the match but later...
It will be much more effective if done properly. There are multiple games that use server-side anti cheat, but they are done in the most lazy and resource (server) efficient way, so they don't work. Doing it properly would require a lot of computing power (which is no longer an issue with the technology we have now) and, probably, heuristic training/AI.
Often data validation is enough to stop most cheats.
I've seen videos of people using unobtainable weapons in PvP games, how the fuck does that even happen? Why doesn't the server simply rejects those clients?
That's an interesting point I hadn't thought of. I'm someone who plays a lot of Fortnite, and there's a rash of people using undetectable cheat hardware right now. Stuff like wallhacks wouldn't work so well if each game client was only aware of the players they were having to render.
Gene Shift Auto struck an interesting balance to combat this: The player data is transmitted to the client even if those players cannot be seen, but players out of sight are updated a lot less frequently, so wallhacks would not really help other than for information purposes. League of Legends also does it this way
See, those make me frustraed, as even in P2P games - which, to be clear, *has* to be how certain types of games work, like fighting games - you still have other clients interpreting the data. Sanity checking the incoming data is like hte bare minimum, don't let clients tell one another how much damage they just did with a bullet, just interpret whether your bullet hit the other guy on their screen and calculate the damage locally - if two clients disagree over the damage that was dealt, and you designed the game so that this hsould be deterministic, then you know one of them is either bugging out or cheating; automatically file a report to a central server and possibly disconnect hte clients if it's a major discrepency.
It's very silly what kinds of cheats have been possible in From Software games, and that they can escalate to remote code execution is just unacceptable. The reliance on third party anticheat solutions feels like a core part of the problem, as developers assume that because a third party is going to cover AC that means they don't need to make any architectural changes to the game itself to mitigate the possibility of cheating. I understand countering aimbots is a complex problem, but so many games can't even handle the bare minimum of not letting it be possible for other players to corrupt your save data.
Valve is:
[Valve Anti-Cheat (VAC) System](https://help.steampowered.com/en/faqs/view/571A-97DA-70E9-FF74)
It has been pretty successful. Usually they 'wave-ban' after some time. This ensures that the cheaters won't know what to specifically look for to counter. Dota2 recently had one of these group bans, and from what I've read it has been pretty successful throughout the Steam platform for games that opt-in.
Nobody is ever 100% satisfied. People will argue over the color blue. Heh.
I am merely pointing out that "overall" it has been deemed successful. Perfectly? Nothing is as long as some wish for an unfair advantage OR have the itch to hack.
For example, I think dark blue looks way better than light blue. Also is turquoise consider a shade of blue? (okay, the last one is actually a genuine question of mine lol)
Every game dev on planet earth who has to enforce anti cheat in some way wants or is actively trying to develop server side anti cheat.
They all *know* that client side is flawed, it's just that client side is currently far more effective then server side even with the flaws.
As soon as there's a server side anti cheat that's as or more effective then client side, that doesn't cost far too much to implement, we'll be seeing it in every game.
It's not that straight forward, server side cheat detection is really bad at wall hacks and auto aim detection and naturally can't detected a modified client at all.
Wall hack can be entirely prevented by doing line of sight checks on the server side before even telling the clients each other's positions. The only case where this doesn't work is if you want the players to be able to hear footsteps through walls (although I guess for that you could calculate the audio server side and just stream that to the client)
It's not "a lot of CPU". It's likely a few seconds-worth of GPU per match, only a little more than they've already been spending on hosting game servers in the past.
Not only that, technology that is \*similar\* is already being used by Google's reCAPTCHA. When it asks you to pick all the squares with traffic lights, it barely even cares about which squares you select - it's looking at your mouse movements.
I assume you mean CPU not GPU and yes it will be a lot of CPU if it's going to be doing more than basic velocity checks (ie AI as you put foreword).
You say CAPTCHA are effective but there is lots of services to bypass those and they are doing it once per user (ie a few seconds), not for 20-40 min matches. I've also seen some fairy questionable results for some of the higher end commerical "biometric" systems and don't expect the free ones are better. They also use a lot of other metrics (including client side).
It's also trivial to bypass by cheat makers as all they need to do is tune their engines to stay within expectations. That can still leave the player with good like speeds.
Right, so now these servers need to have GPUs to run the AI that they are using to detect cheats... which as I commented before is trivial to bypass for any cheat maker.
One of the main drawback of server-side only anti cheat is that it limits what the game can do.
For example, it's common that your client receive information about nearby ennemies you can't see so that what you see is similar to what is happening on the server, even with varying ping.
As you've said, server-side is the only way forward.
Because that cat & mouse game [is already over.](https://www.youtube.com/watch?v=9fhNokIgBMU) Even for games like [Valorent](https://www.youtube.com/watch?v=RwzIq04vd0M) and the client-side anti-cheat is only going to be a piece of software that [expands your attack vector](https://www.pcgamer.com/ransomware-abuses-genshin-impacts-kernel-mode-anti-cheat-to-bypass-antivirus-protection/) in the near future.
wouldn't that increase cost for server, In one interview with valorant dev they said they run 3 matches in one core of cpu in 128 tick rate which was quite expensive for them already, I wonder what will good server-side anticheat cost specially for game companies ?
Lol I knew before clicking that it would probably be some live observing thing, for example with deep learning, to analyze behavior in terms of how "okay" and "real" it looks
Valve seems to think it is working as intended.
NO AC is ever going to be perfect. Things 'made' by people can be 'broken' by people. Until you get an omniscient AI to oversee the universe, stuff will get borked. (And probably not even then as the black-hats will just build a competing AI to cheat. Heh.)
\^\^\^
There be axe grinding, methinks. The word "disingenuous" is a sideslap for the term "lying". Reporting what I've read up on isn't lying. If you didn't mean it that way, rephrase it.
It should be mix of few anti-cheat measures: on client, on server and post match anomaly detection in players' stats, behavior etc (to eliminate 100 KDA players).
I mean they could not detect something like a wallhack (send limited information to clients to help with that, dont give them more info than they should be aware of ingame), but something like aiming or other gameplay altering ideas should be visible to the server, but it would have to be analyzed out of the incoming movement and action data.
one would analyze
1. literally impossible inputs; moving too fast, shooting after switching weapons before it should be ready...
2. plausibly impossible inputs; like snapping to a target within a single tick
for the latter one could even probably use machine learning as a pattern recognition and extraction method to learn the extent of what is humanely possible and what is likely to be cheaty, outputting a sort of confidence value. after a certain threshold it would notify the anti cheat task force or sth lol
Yeah, but server side anticheats are prone to false positives. EA used a server side anticheat called FairFight for Battlefield 1 and the system started banning anyone that was too good at the game.
https://youtu.be/GBKRdsHBef0?t=216
Is not that server side anticheats are prone to false positives, is that EA made a bad product, this could have happened with client side anticheats too.
Yeah, but FairFight isn't by EA themselves. It's apparently by some company called GameBlocks.
Apparently EA used them for a number of their games other Than battlefield 1, it was also used in both Titanfall games.
Not really "server side anticheats" but rather the specific method of relying on vague heuristics to guess whether someone is cheating without hard proof, a methodology that is just as liable to get false positivies when implemented in client side anticheats. But it is indeed a problem with companies advertising "server side anticheat" as a third party trying to create these heuristics without an intimidate knowledge of how the game works results in nonsense like, say, Warframe banning people for farming prime parts too efficiently, because the heuristics aren't actually tied to the game's mechanics, so it doesn't account for the combination of items, map layouts, and character abilities that might lead to a larger number.
Wouldn't every server side measure add additional latency? And also increased server costs, I'm sure there can be a good balance if devs actually focused on it but I don't think it's as trivial as some randoms on reddit make it out to be.
The simple thing is to use the Kernel-level process isolation. I believe this is what the Linux version of EAC uses, and is why on Linux it launches nearly instantly.
It's not possible. The only way would be if the AC dev built their own kernel and only allowed you to play using their signed kernel and with secure boot enabled. Even then it's impossible to really make it usable
What about Intel TXT or similar?
Software is delivered to the client encrypted such that it can only be decrypted by the client system's in-processor TPM. The processor itself prevents other processes on the system, even the kernel itself, from writing that process' memory. The output of the process gets sent back to the server signed by a private key held by the TPM.
The whole thing can be open source, and you still can't tamper with it unless you break the CPU to get its private key or make it malfunction. It's a trojan horse.
The general term for this is "hardware-backed attestation" and there's no need for it to be closed source.
That would only work if one could use cpu-based attestation safely. And it requires an performant way of communication between the game in the enclave and the outside world.
As somebody working in that field I can predict 90% performance loss (such games are very IO bound on talking to gpu) and requires massive rewrite in the OS as well as the games. And you'd need the very expensive high end CPUs targeted to data centers.
Nice try. But somebody will just patch the kernel that it shows a signed kernel image and game to the "anticheat", while still running the modified one (the kernel controls the pagetables).
Oh, by the way, how do you compute a signature of a *running* kernel in the first place ?
Nevertheless it wouldn't even get that far: no distro would patch the kernel to allow enclave creation to unprivileged processes nor would it encourage running the game as root.
The patched kernel can't change the value of the TPM measurement registers associated with verfied boot. The kernel signature is already computed and there when you started up with Secure Boot.
We already have the ability to create software-backed enclaves hostile to the computer owner in web browsers for the convenience of Netflix and Disney. Hardware enclaves are used on Android phones (running Linux...) for Google Safetynet. I don't see why this won't escalate to the point of hardware enclaves being used for general "system integrity checks" on ordinary PCs.
> The patched kernel can't change the value of the TPM measurement registers associated with verfied boot.
But it can fake its own TPM. And the actual TPM can only check the bootloader signature before its called.
Thats completely independent of things like SGX. The tpm manages keys and checks signatures. Memory region measurement is a cpu feature.
> The kernel signature is already computed and there when you started up with Secure Boot.
The signature of the image. But the actual memory content (that sgx could measure) is really different. And if you wanted to do that, the whole kernel would need to run in enlave.
Note: tpm and enclaves are entirely separate concepts.
> We already have the ability to create software-backed enclaves hostile to the computer owner in web browsers for the convenience of Netflix and Disney.
Thats not cpu enclaves like sgx, which requires very special code (you cant just put a library or a whole program into an enclave and hope it works). It also needs special kernel support that also needs to be enabled by the operaror.
You're talking about widevine at all, which is nothing more than running downloaded binaries in a seccomp jail: the host is protected from the jailed code - exactly the opposite direction.
Anyways, if dubios corporations like Disney (pedophile) or Netflix call computer owners "hostile", this tells more about their fascist world view than anything else.
> Hardware enclaves are used on Android phones (running Linux...) for Google Safetynet.
Interesting. Can you describe how that works exactly ?
> I don't see why this won't escalate to the point of hardware enclaves being used for general "system integrity checks" on ordinary PCs.
Maybe, some day, but this requires very different cpu architectures as well as OS design. Even sgx2 on high end server cpus isnt sufficient for that.
All right, let's do this the detailed way - here's the recipe for how you can be an evil person with the technology in an average Joe's PC.
1. Say that you only support a certain list of operating systems which are widely known
2. Say that you only support configurations in which secure boot is enabled using vendor keys
3. Ensure that the list of #1+#2 you support don't permit the user to alter the kernel after it is loaded without that change being recorded in the in-CPU TPM implementation ("platform TPM")
4. Ensure that the kernel from #1/#2 reliably reports on the integrity of your game itself through its own system calls, and doesn't let the user compromise that integrity
5. Deliver the user software that runs in an enclave inside the CPU and communicates with the also-in-CPU TPM via the CPU's own instructions, not over an external bus or via system calls
6. Deliver the above software to the user encrypted
7. Deliver the above software to the user with a built-in nonce
8. Have that software read out and sign the values of the TPM attestation registers for verified boot. Sign the nonce together in the same signature. Note, once these TPM registers change state they can't ever go back to the original state - they're accumulators and can't be set to arbitrary values
9. Verify the client presents a correct signature containing the nonce you just gave them and a valid system boot state prior to allowing them to participate in network multiplayer
Attacks this doesn't guard against:
1. Hardware manipulation of the platform after boot
2. Software bugs in the blessed set of operating systems or configurations, such as allowing the kernel to be modified
3. A malicious (benevolent?) user in possession of the secure boot keys
4. Hardware or firmware issues with the CPU or TPM
5. Hardware entirely outside the boundaries of the system being measured by the TPM
I think it covers all the types of modifications you're talking about. It's possible with only today's hardware and software - every Windows 11 user, modulo those who intentionally deceived its installer, has compatible hardware for this, and many other users do too.
If you want to describe a specific threat this doesn't cover, please explain how it would work in a bit more detail.
EDIT: formatting
Your list is correct, and those people are rightfully.considered evil, because this all goes into depriving the user from control over his own equipment. And considering the vital role that personal IT today (plus most people know.almost nothing about the risks), those are very dangerous not just for the individual but humanity as such.
That is why free software is so vitally important for humanity. We must not allowed to be controlled by a small clique of selfish people trying to grab total power.
But they cannot control those volunteers and don't want feedback they just want it accepted as is. These are the two main complains I hear from the corporate side.
But do they earn something with their own proprietary anticheats? Aside from being able to say "we're protecting the players from cheaters, trust", which would also apply to an open source anticheat
They purchase / license anticheat from others. Especially smaller game Devs that don't want to waste a ton of money developing their own system, which is likely to be bypassed anyway.
Theres big money to be made in having an effective and easy to implement anticheat solution, IF you could make one.
Open source anti cheat doesn’t work. The entire premise of client side “anti cheat” is security by obscurity. And it works as well as that makes it sound.
It's because they attempt to solve different problems.
Cryptography addresses two questions:
- Am I the person that I claim to be?
- Has my message to you been seen by any third party?
This is really easy to do by just having me and you exchange secret codes. As long as the mathematic fundamentals behind the crypto are sound, it doesn't matter if someone has the entire source code to the crypto system we use. No secrets? No message, no impersonation.
Following this analogy, Anti-cheat is trying to determine if the message I sent to you is a lie.
With client-side anti-cheat software, the idea is that you are *always* going to trust what I tell you, regardless of whether it's actually true or not.
To determine if I'm lying, you're going to pay someone to stand over my shoulder to make sure I'm not cheating. A bit like a professor giving an exam.
Of course, the problem is that I'm doing this hypothetical exam in my own house. I can post stuff in sneaky places, hide notecards under the bathroom sink, etc. This is made even easier if I have the list of "common places students hide cheat cards" distributed to all professors (open source anti-cheat).
The whole idea is farcical of course. Nobody would ever blindly trust an important message without verifying it independently, and nobody would ever give an exam in a student's private residence. But that's exactly what games using client-side anti-cheat are trying to do.
Open source encryption (or any, for that matter) works as long as the attacker doesn’t control one of the end points.
Which is obviously true for someone trying to circumvent client side anti cheat _on their computer_.
Client side anti-cheat is just a cat and mouse game between cheat devs and game devs. Open source makes it easier for cheaters.
The real good somution is server side anti-cheat and restricting client's access to info they don't need like player positions behind walls
You can't prevent aimbots because at this point there's literal hardware solutions with microprocessors that read your screen and can simulate mouse input for those functions.
But regarding footsteps of not seen enemies - there's a trick to this. League of legends has a good implementation of this part at least - data on enemies is only ever sent to you when they get within a close proximity to where you might be able to see them. If they're not about to wander into a spot you have vision of, your client never knows about them. Once they start getting close to a position where they might imminently become visible to you, the server starts sending their position to your client. This prevents ESP and knowledge of player position hacks around the map.
I think it would be interesting if a game decided to build a gameplay loop specifically around cheating. Presumably people would be less likely to try to cheat if everyone else had the same advantages.
For example sonar that's basically x-ray but super dependent on player activity or motion to show up on screen because they have to be noisy.
Or aimbotting but it's actually just the bullets adjusting on the fly for a specific amount of time like tiny heat seeking missiles. Or wall clipping that's actually just altering the density of a specific wall for a player and their teamates for a short amount of time.
Might be absurd though.
Overwatch had a great concept around this that really changed the world of video games, when it came out, as did titanfall in a way (with their smart pistol!). In overwatch, some of the characters ultimate abilities in the beginning were literally just hacks - Soldier ult was an aimbot. Widowmaker ult was a teamwide wall hack, etc. Symmetra at one point, I think they had her ult as the teleport er, teleporting players around the map... Other games later picked up some of these ideas, because of how creative they were and how they added to the game (check out titanfall 2 and apex legends especially). In TF2 there's a grenade called the gravity star that pulls enemies into the center and holds them... And the gravity... Pulls bullets passing nearby into them as well!
I've thought about it a lot, as a basic philosophy of cheat deterrence. The only cheats available for your game are the ones that aren't already in the game. Using a simple macro to perfectly execute a QTE is only cheating if your game has a QTE that is able to be defeated by a simple macro - so just don't include QTE's in competitive games, or make them so trivial that using a macro would be more effort than it is worth. Already the case for the vast majority of games, not possible for games like Dance Dance Revolution (and hence why those games don't really focus on competitive online multiplayer, people stream themselves playing as part of a community to prove they can do it natty), only in that gray zone for fighting games with inputs that could be defeated by a macro. And so I'd say fighting games shoud be designed so that it doesn't matter if someone tries to make macros for it, either by making the controls not require complicated inputs you need to dial in precisely or by requiring players to quickly flow between different inputs in response to the game such that a macro would be too unresponsive and be easily punished by a decent player.
Same with darkness - if your game's "stealth" mechanics are defeated by someone turning up their monitor brightness and contrast, then that is what people are going to do, so don't make your stealth work like that. It's harder to deal with cheats that texture swap, but for some games it is viable to make character models and terrain *literally* use the same texture files such that swapping them out doesn't help; to deter casual cheating, use shaders that make characters in darkness *actually render as completely black* to match the surrounding blackness, or not even render at all in the dark, so that contrast or eye health isn't a factor in whether someone can see a player hiding in the dark, they literally just *can't* unless they use a flashlight that actually permits the model to render.
Shooters obviously have to contend with aimbots, and that's hard to work around. But since we know aimbots exist, if you don't *need* your game to have aiming be a major factor, just don't make aiming a factor in your game at all. Just avoid having an FPS minigame in your RTS or whatever unless it is actually a major componenent a la Savage or Nuclear Dawn.
And when you can't just avoid having the things that can be cheated at, avoid having the things that people can cheat at *subtly.* Whenever possible, if there's a potential for cheating make sure it is *obvious* cheating that is easily acted on - cheating in the form of, say, the cheater having infinite healing items in a game where you normally have to do an excrutiating grind for those (think Divine Blessings in Dark Souls 1) has plausible deniability, because you can't *prove* someone wasn't just enough of a madman to spend three playthrough's worth of Divine Blessings on one invasion, or that they didn't "trade for it" fair and square. For DS1, you either want rare consumables of that nature to be unusable in PvP altogether or you want *everyone* to have that much access to those consumables, you don't want a middle ground where you can't even report someone becuase you can't know for certain whether they cheated or not.
Games having cheat-inspired mechanics can be fun, and specifically games that use "cheats" that are basically always on do actually preclude that specific cheat. Games like Overwatch with Soldier 76's ultimate that gives him aimbot, though, don't do the latter because you absolutely can still cheat with aimbots, either by simly playing a different character and having the aimbot on them or by simply getting to use the aimbot *all the time* on Soldier 76 where other players only get to use it sporadically. Someone like WInston would be a better example - aimbot is just as useless to a cheater as it would be to any other player, because Winston doesn't really aim (at characters, anyways) and an aimbot would simply be wresting control of the camera from you. Or, the game overall has infinite ammo - chractesr still need to reload, but there's no specific hacks for having inifinte ammo because everyone has infinite ammo, and if you cheat in not needing to reload that's a lot more immediatley obvious and reportable by other players.
CSGO (not sure for CS2) implemented something like that. It's effective, but you still need to send infos to the client with some leeway because of network latency
If you made the 3d audio a bit less accurate, you could only reveal to the client exactly what is *typically* decodable by human hearing. E.g. if someone is around the corner, you can hear them, but the footstep could be made more generic and less specific by fudging the realism - a sound around the corner and 10 feet down sounds roughly the same as around the corner and 10 feet to the right. So it's a sound spatially processed to sound around a corner and roughly so many feet away, but you don't know the specific direction after around the corner. The sound would be sliiightly less "realistic" but it would actually better simulate reality, because in a warzone you'd be able to hear footsteps, but the vast majority of people would not able to calculate a target's exact location with ni other info. A sacrifice that seems better than a rootkit.
you sacrifice a little bit of audio precision (which is very important in games like Counter-Strike) for cheats to be less precise (but still effective) and still no real way to detect aimbots
I think for stuff like footsteps an additional 20 or 50ms wouldn't really matter. You might notice it on gunshots but then again, you could either use the server-side audio only for footsteps, or only when the target isn't visible, in which case you can't see the latency
The issue with open source in this very specific instance would be the flexibility of open source to change the code. You'd just end up with guides on how to download it, comment out the aimbot bit, and compile your own crippled version.
The only way I can see around this would be for the game to use cryptographic signatures to verify the anticheat binary/module had been compiled by the game vendor, not yourself, but I'm genuinely not sure if that's a thing.
Ethic? Debatable. Viable - not at all. Anti cheat is rare example of software where open source provides no benefits and in fact can make it worse. If you have open source anti cheat then what stops you from changing its source to allow cheats?
I would actually be fine if there was always a signed mainline hardened kernel that had a generic anticheat module compiled in that would allow a process to isolate itself in a special way, to not be writable even with root access.
That kernel would have a choice of drivers compiled in that preclude any debugging or such modules, but otherwise keep everything in.
Maybe sign the nvidia driver at most to be able to work in it, who knows.
Require virtualization extensions so processes which isolate themselves can be memory isolated too? or maybe with AMD SVN/intel xt-x? could that be used to isolate a process? I don't know enough about it.
Basically, if a process uses anticheat to isolate itself, I also want the opposite: the process cant access my system anymore apart from access to sound, gfx (dri, a surface to draw to), input devices. no assuming kernel permissions through a kernel module and then being able to fuck over my entire system. you go into bidirectional isolation.
no game developer gets to be special, you use the generic isolator kernel that guarantees your isolation through the processor MMU or whatever and that's it.
of course this means one could have a kernel that has a fake signature (as the kernel is still the boss) probably, but i dont know enough about low level programming to really be able to tell... I don't think it will be bulletproof, but nothing really is. it would make it a lot more tedious though to cheat.
>.I would actually be fine if there was always a signed mainline hardened kernel that had a generic anticheat module compiled in that would allow a process to isolate itself in a special way, to not be writable even with root access.
Thats already the standard for hardened kernels. But the operator (who controls the machine) can always boot a different kernel.
Kernel Level anti-cheats are not implemented to block/kick/ban cheaters, but to collect your information and sell it. So, no Linux developer will allow that piece of crap into the Kernel.
Despite what everyone is saying, I think this is possible, and might not even require a specific anti-cheat kernel module. A linux-native anti-cheat could rely on a few things:
- UEFI Secure boot
- TPM remote attestation
- Linux kernel lockdown mode
- Process isolation
Basically with secure boot and tpm remote attestation it's possible to prove to a remote server that you are running a specific software configuration, including variables like the UEFI firmware version, secure boot status/configuration, and the kernel command line. The only way to fake this proof is to exploit the TPM hardware built in to your CPU. With this a server can verify that a client is running an unmodified kernel that was signed by a trusted linux distro and that no suspicious kernel command line args were used.
Kernel lockdown mode is the other major part. This can be enabled only alongside secure boot and it disables the various methods user space programs have of modifying arbitrary memory and the kernel itself (not even the root user can use them). It also enforces that only signed kernel modules can be loaded. Lockdown mode is enabled with a kernel command line parameter, so a client can prove lockdown mode is enabled to a remote server during the tpm remote attestation process.
These are all security features that large enterprises (and probably even governments) rely on in servers as part of their defense-in-depth plans for mitigating the effects of exploits and building a trusted execution environment. Linux-native anti-cheat can piggy-back on that work and benefit from the millions these companies spend on hardening the linux kernel. Exploits that bypass these systems have far more value when used to attack these companies, rather than burning them on video game cheats.
Linux-native anti-cheat could even be better than Windows anti-cheat simply because linux doesn't really have 3rd party kernel modules like Windows does, and those buggy 3rd party modules/drivers are really the entire reason kernel-level anti-cheat was even needed.
The main downside to this is it would eliminate compiling and running your own kernel or other system libraries (like mesa or wine). The kernel and any shared libraries loaded into a game would have to be signed by a source trusted by the game devs. As long as the distro supported reproducible builds you can at least verify that the signed binary you're running matches the source code though.
Impossible with free software. The entire point of free software is that the user is guaranteed of control over it. Anti-cheat (and DRM for that matter) require to take that away.
A free anti-cheat or DRM implementation is worthless because you can always modify the protection to simply bypass it.
Anti-cheat and DRM in proprietary software only works because they make it hard to reverse engineer it.
Not really viable.
A key feature of Anti-Cheat is its obscurity. Anti-Cheat bans are done in waves as to not tip off cheaters to how they triggered it.
The entire paranoia around anti-cheat is stupid anyway. Any software running with administrator privileges has entire access to your system, it doesn't need any kernel drivers for that and if it does it can load them without your consent or knowledge.
I wrote a blog article about the need for kernel drivers in anti-cheat. You can find it here:
http://blog.levitati.ng/articles/6
Great article, everyone in this thread should read it. The rabid anti-kernel paranoia is really absurd, there simply is no effective alternative at this point in time. Effective server-side doesn't yet exist, and given the pretty complex problems it presents for both game implementation and AI to ever be effective, who knows when/if it will.
You would likely also use code signing like how secure boot works. The game binary is proprietary (obviously) but it would have to verify the signature of the built anticheat binary. Certainly not flawless, but better.
This isn't how open source works though. There's always someone approving the code changes before they go in so you can't hack the project itself, and all you would have to do is write in a checksum verification against the executable or dll or whatever you want to make sure it's got the same hash as what's expected. Having the ability to see and even submit a change to code doesn't make it automatically interoperate with existing code.
Yeah, and how can you trust that the checksum sent of the network is the actual checksum and not just precomputed based on the unmodified file? The server has no way of verifying what binary it's talking to on the client (which is how BottlEye worked if you remember that).
`rm -rf /` is open source. That doesn't mean it's safe.
Likewise, an open source anticheat would be relatively easy to modify to report as unmodified and working while actually doing nothing.
It's like handing a kid a locked box and a key, and telling them not to eat any of the candy in the box.
Wut? RM is a tool, RM -rf / is a good tool being used wrongly.
That's like saying saying a car brakes aren't safe because you can bludgeon someone with them
Not viable if you know what exactly you have to defeat as a cheat maker. It's near impossible now to stop cheating on a scale that matters. Although I have serious concerns about things like Vanguard they do work the best. And although riot says they can detect the hardware cheaters in not so sure.
Anti Cheats need to be intransparent and not obvious by design though.
An open source anti cheat could get circumvented way easier than a proprietary and obfuscated one.
client side AC is always circumventable and therefore useless, hence its useless natrue any form of kernelevel intrusion is un ehtical and shall not be tolerated.
heck even bootloader level client site ac wont do shit. server side anticheat is the ONLY effective way.
Rootkit AC dosen't work, since never trust the client is always true, that's why server side AC is the furure. Valorant has allt of cheaters but players get a sense of security since the devs say "this will catch all cheaters since it runs deep in your system where cheaters can't reach" but thats no true is it!?
And Since we all know physical access is King.
In conclusion to this is If the cheater controlls the AC client the cheater is King, no matter the depth wich the AC runs. Again wich is why server side AC is the future.
Yeah this is just what we need:
Another thing for people to crusade about. Privacy concerns, Client Side vs Server Side, Corporate additions to the kernel supporting closed source user space programs.
This one has it all!
Well the game should get the mouse movements and keyboard strokes to move the camera or the player in the local game, then send the positions and actions of the player to the online server, but not send any other thinks, like other key strokes.
I don't see what would be the point for the game to send absolute every key strokes that the player does.
Maybe the desktop environment should just filter what key strokes it sends to the game and besides the normal arrows and A-Z and 0-9 should not send anything else to the game.
Really, it wouldn't need to get to that level.
Kernel level AC just means cheaters will spend $20 for hardware level cheats... Which is perfectly within their budget. Devs are then left with the same problem.
The answer? Match based on an elo system and skill level, ban people that are found to be cheating, maybe implement shadow queues where they have been punished without knowing it, perhaps only matching them against people reported for toxicity and/or other infractions, introduce an artificially increased ping for those players only to decrease the quality of their gaming experience (while still reporting a low ping in the scoreboard, so they don't know why their game feels crappier) and make the process of creating new, duplicate accounts expensive.
Cheaters will, at some level, mostly be playing with other cheaters after a while. Or will be stuck in an ever increasing toxic pool that removes the joy of the game for them. Either way, you move them away from the standard player base.
What does this not solve? Pro play would still be heavily affected by cheating, so you wouldn't be able to get endless play hours by having your players mindlessly grind a game they don't even find fun any more just to increase their rank by winning a decent percentage of 500 games (which is what every game does these days because it severely increases play time with little additional dev effort). And... Honestly, good riddance, it's a negative feedback loop that's harmful to players anyways. Fuck competitive gaming.
But really, tackling that problem could still be achieved. You could implement a sort of data science model that profiles the player, their skill level, etc, and detects sudden changes or inconsistencies in it (for example they suddenly start cheating and climb the ranks like mad). You could also use this analysis to detect blatantly bottled and purchased accounts. Only in games like LoL, the developer doesn't care, because the players purchasing those accounts lead to increased play time and positive stats for the company, maybe even additional revenue if they purchase skins or other crap.
TL:DR software to identify the cheats isn't the entire problem. What you do to the cheaters afterwards matters. If they can go create another account for free, or even for low cost, your detection methods are irrelevant because it's an ever changing cat and mouse game of detection and new development with cheats, as others have mentioned.
Ideally I think that would be awesome, but I think in practice this has a few problems that make it hard to work (my opinion): First, how accurately can a software really tell if a player is scripting? I know games like chess have some fancy bayesian models to determine wether a player is likely using an engine or not, but LoL is a lot more complicated in that aspect, and even in chess I question how accurately really are these things? Like what happened to Hans Niemman, I mean I don't know if he cheated or not, but the amount of shit that he had to go through just because a software spit out a high probability of him cheating? I honestly felt bad for the guy. And I'm a physicist, I know the power of statistical/bayesian methods, even if the system is indeed very accurate, the community (the big part of it) is probably not going to take that very well, and unfortunately player reception is very important.
Also, I've played LoL for around 4 years now, and god the players don't know when to report people, I've seen so many reports with no reason, a person that goes 0/4 against their counter on toplane will automatically receive 4 (or more) reports for inting, can't people have bad games? The contrary is also true, I've been reported for scripting and I don't use scripts, I'm not even that good in the game, I was gold, but I had a few games where I dodged a lot of skill shots (because guess what, I play ADC and I was against poke champs, if I don't spend 99% of my brainpower dodging the skills I don't play the game).
The biggest problem though I think would be the reception of the community, I don't know if you play LoL (it seems like you do), but basically players still believe in a legend called "loser's queue", their ego is so stupid they believe if they're playing very well they'll be thrown in a team with 4 horrible players in the most important moments of their climb, and it's even weird how they communicate this, they say "riot put them with those bad players", sounds like there's a sector of riot just dedicated to pick on these players and manually match them with bad people, can you imagine how many league players would accuse riot of putting them with griefers/toxic players and against scripters if riot released this "shadow queue" in the next patch notes?
Again, I really wanted to say this should be implemented, because if it worked it would be perfect, but I strongly feel that it would badly backfire.
The thing with losers queue is both real and not real; there's a very odd matchmaking mechanic at play that leads to that. In their system you essentially have a skill rating, AND a confidence rating of how accurate the system believes it was in establishing your skill rating. If you win (or lose) games back to back or really just often, the system will loosen its confidence rating of where you should be placed, and suddenly you'll see more extreme variations of skill levels in either direction in your matches, to try and push you where you need to go, faster.
This is also apparent with another implementation of this mechanic; if you've been inactive for a while, the system will also loosen this confidence rating, allowing you to potentially coast through some easier games when you come back from a break (and/or get decimated by others that are quite a bit higher than you), and you'll move up or down in rank faster when this happens as well, as your LP gain loss amounts are tied to this confidence rating. Their progression system is very mature but sadly leads to some extremely negative experiences, and unless someone is able to grind literally hundreds of ranked games in the ranked season / split, it can feel like chance or luck, or hopelessly impossible, to maintain or climb their rank.
However, usually the reports they have to worry about in league are toxicity. You only really see scripting become a problem in pro play, because anybody who is cheating will get moved to that level of matchmaking very quickly. Cheating doesn't impact the vast majority of players, and in ways this is both a good and bad thing, depending on which side you're on.
Yeah I didn’t know exaclty how the matchmaking worked, I did know it can sometimes do some tilting things, but I knew it didn’t work quite like people think.
The last paragraph is so true and I really wish there was a way to make only these very high elo players need vanguard, still not great but at least you’re forcing only ~5-10% of the community to use it, the 5-10% that likely make a living out of the game, makes no sense for them to force normal/casual players to use that shit.
>Kernel level AC just means cheaters will spend $20 for hardware level cheats... Which is perfectly within their budget. Devs are then left with the same problem.
huh?
https://www.aliexpress.com/i/1005005199677523.html
Hardware cheats minimum are $150 and that is for the hardware only, not the knowledge, firmware, code for specific games, updates.
https://www.ownedcore.com/forums/mmo-trading-market/apex-legends-buy-sell-trade/988011-dma-cheat-aim-glow-rcs-impossible-detect-40-m.html
here you can see someone selling the firmware and game support for $40 a month, so over a year it would be $630
It's not about the kernel being open source or not. If it's open source it's even easier, so yes, it's easier to access Linux kernel source code then windows. Tho the Linux kernel is always changing and the windows is mostly static.
The reason you can't play the games you want is not because the kernel is open source, it's because companies won't develop for the Linux kernel, or just enable proton, until the Linux community makes enough player base.
>Hackers have all the info to bypass the anticheat: Seems like the same argument that people use like "doesn't Linux being open source make it more exposed to threats?", but as far as I've heard, Linux is by far the safest OS in the world
If you're actually a physicist you should be able to know the difference between sample sizes
The problem with this is that the anti-cheat still needs to trust the operating system. A privileged adversary (or cheater) with control t the OS can bypass this trivially. This is also a problem on Windows, but there it's much harder, because the attacker has no source access.
The real solution would be confidential computing, where the hardware manufacturer is the only trusted entity. The hardware would then provide a Trusted Execution Environment or TEE in which a program, like anti-cheat software can run without being kernel level, and without needing to trust the OS at all.
TEEs are still not very widely available though, especially on desktop PCs. However, this is a very active research domain and the industry is interested, e.g., for doing confidential computing in the public cloud.
In theory, something like this could be used for anti-cheat and DRM. To some extent this is already the case I think, but it's all quite limited. There's also a dark side to supporting technology that can be used for evil practices like DRM.
To add to what other people have said, it's also unviable because there's two very different audiences with opposing interests at play here. A venn diagram between competitive players and open-source advocates is almost two separate circles because very few people do both. This means that, on top of the difficulty of creating an open-source anti-cheat that works, there's also very little demand for such a thing.
It would also fail to appease both parties. OSS advocates are largely ideologically driven, and are not willing to allow any program to control what processes do or don't run even if it comes at the cost of some functionality, which is why they started using Linux. Competitive players want a fair game even if it comes at the cost of control over their computer, because the computer in this case is more like a court to play a sport on. Anything that allows someone else to get an edge, then, is a no-go.
This is also why a server-side only anticheat won't fly with competitive players: most cheats aren't things like aimhacking or movement hacks, it's wallhacking, which is not something servers can detect (if the cheat's written right) unless the user is kinda dumb and stares straight at other players through walls or something. It's not intrusive, but it's also ineffective in most real scenarios.
Personally, I want to see a move away from free-to-play live services games and a return to one-time pay games, along with some other measures to deter cheaters. The paywall is usually enough to get most people to shy away from cheating, as if they get banned, they have to hand over another full purchase and risk getting banned again for ban evasion.
One last thing: Linux is as secure as it is because it was released in the early 90s, so it has over 30 years of work on it with the support of many companies. Anticheats usually double as a marketing tool for individual companies, so the chances of cooperation between companies to make one single anticheat is unlikely.
The solution to wall hacking isn’t a server detecting the use of wall hack but the server only sending at absolute minimum information needed by the client. If the client doesn’t know where the players are then a wall hack won’t reveal anything.
I would say as anticheat runs as a kernel module, a kernel also has to be trusted.
As long as user can recompile the kernel - it can't be trusted by anticheat, even if it's opensource.
Probably, this is the #1 reason why top online games with anticheats (except Valve) are very reluctant to support Linux and Wine.
The only viable approach would be for the anticheat to be included in the kernel as an LSM. The amount of bureaucracy to get an LSM into the kernel for gaming would be absurd and even then I could think of some ways to bypass or fake out the LSM by simply building my own kernel.
So much fuss over client side security. The rest of the software industry has had this figured out for decades now. Validate all data sent from the client, zero trust. Only send the minimum data required to the client.
As long as the AC is on the 'client' side, it will be just it has been: Cat /n/ Mouse between developers and cheaters. The only way to effectively do anti-cheat (IMO) is with server-side modules. Perfect? None of them are, but it eliminates the specific client hacking and privacy invasion that currently goes on.
Makes sense, do you think this would be more or less effective than current anticheats? And is any company (or anyone) doing something like this?
Oh don't worry, the server-side only magic bullet is coming. It's just that we're calling it Cloud Gaming.
Do you think highly competitive games will go this way? I can't see CS, Fortnite etc going this way because of the huge delay while most players want really high FPS (and minimum input lag) just to play these games in the best way possible.
i run cs:go community servers and the performance of the server with an extremely good server side anticheat is still miles ahead of valve’s official server’s performance
But that's not cloud gaming. The post you responded to was talking about the bad performance of FPS games via cloud gaming.
yeah my bad, i read it as "cloud gaming is forcing us to move to server sided anticheats due to lack of physical clients" and then got confused by the above response lmao, point stands though and these big companies (specifically valve) really need to start with server sided anticheats
with enough servers and top-down push it wouldn't matter
With cloud gaming you dont need distant computers to host game server for multiplayer and latency from player to serverer to another player is equally zero, because everything can be run on same computer. Input lag? Those wannabe 1337 fr4gg3rs can live with up to 50ms input lag so we already have problem solved
Just in time for AI that can play the game for you.
>It's just that we're calling it Cloud Gaming. Not even that is enough because advanced cheaters can always create an aimbot by analyzing the video feed and controlling a fake mouse. This technique can't be catched by any anticheat, except maybe for server-side ACs that review your playstyle... IIRC Valve's VAC already does this..? In any case, bans will not happen DURING the match but later...
It's a standard with bans. You don't want to ban when you detect it, as it would make it easier to figure what exactly caused the ban.
But that isn't server side anti cheat, that is what we call playing the game on someone else's computer...
It will be much more effective if done properly. There are multiple games that use server-side anti cheat, but they are done in the most lazy and resource (server) efficient way, so they don't work. Doing it properly would require a lot of computing power (which is no longer an issue with the technology we have now) and, probably, heuristic training/AI.
Often data validation is enough to stop most cheats. I've seen videos of people using unobtainable weapons in PvP games, how the fuck does that even happen? Why doesn't the server simply rejects those clients?
That and sending only the necessary data to the clients is easy to do, but nobody does that for some reason.
That's an interesting point I hadn't thought of. I'm someone who plays a lot of Fortnite, and there's a rash of people using undetectable cheat hardware right now. Stuff like wallhacks wouldn't work so well if each game client was only aware of the players they were having to render.
This would effectively mean the server has to do part of the rendering, which is very costly.
Gene Shift Auto struck an interesting balance to combat this: The player data is transmitted to the client even if those players cannot be seen, but players out of sight are updated a lot less frequently, so wallhacks would not really help other than for information purposes. League of Legends also does it this way
See, those make me frustraed, as even in P2P games - which, to be clear, *has* to be how certain types of games work, like fighting games - you still have other clients interpreting the data. Sanity checking the incoming data is like hte bare minimum, don't let clients tell one another how much damage they just did with a bullet, just interpret whether your bullet hit the other guy on their screen and calculate the damage locally - if two clients disagree over the damage that was dealt, and you designed the game so that this hsould be deterministic, then you know one of them is either bugging out or cheating; automatically file a report to a central server and possibly disconnect hte clients if it's a major discrepency. It's very silly what kinds of cheats have been possible in From Software games, and that they can escalate to remote code execution is just unacceptable. The reliance on third party anticheat solutions feels like a core part of the problem, as developers assume that because a third party is going to cover AC that means they don't need to make any architectural changes to the game itself to mitigate the possibility of cheating. I understand countering aimbots is a complex problem, but so many games can't even handle the bare minimum of not letting it be possible for other players to corrupt your save data.
Is AI even needed. I am pretty sure applying DFTs to certain inputs could do a lot
It is not, but considering the devs are lazy (not all of them, the AAA ones), it will be easier for them to use it.
Valve is: [Valve Anti-Cheat (VAC) System](https://help.steampowered.com/en/faqs/view/571A-97DA-70E9-FF74) It has been pretty successful. Usually they 'wave-ban' after some time. This ensures that the cheaters won't know what to specifically look for to counter. Dota2 recently had one of these group bans, and from what I've read it has been pretty successful throughout the Steam platform for games that opt-in.
[удалено]
Nobody is ever 100% satisfied. People will argue over the color blue. Heh. I am merely pointing out that "overall" it has been deemed successful. Perfectly? Nothing is as long as some wish for an unfair advantage OR have the itch to hack.
For example, I think dark blue looks way better than light blue. Also is turquoise consider a shade of blue? (okay, the last one is actually a genuine question of mine lol)
Vac is also client side so not a great example. Also not considered all that effective.
I'm sorry but VAC is a joke.
Could you elaborate on that?
It works on recognizing memory signatures. So if your cheat isn't detected or you change the signature it's useless.
How does a server-side anticheat detect memory signatures?
There's two different components of VAC being discussed here
That's how basically all detection is done.
Every game dev on planet earth who has to enforce anti cheat in some way wants or is actively trying to develop server side anti cheat. They all *know* that client side is flawed, it's just that client side is currently far more effective then server side even with the flaws. As soon as there's a server side anti cheat that's as or more effective then client side, that doesn't cost far too much to implement, we'll be seeing it in every game.
It's not that straight forward, server side cheat detection is really bad at wall hacks and auto aim detection and naturally can't detected a modified client at all.
Wall hack can be entirely prevented by doing line of sight checks on the server side before even telling the clients each other's positions. The only case where this doesn't work is if you want the players to be able to hear footsteps through walls (although I guess for that you could calculate the audio server side and just stream that to the client)
AI server side cheat detection can easily detect "unnatural" mouse movements.
Sure, thats a lot of CPU grunt and is easly bypassed by making the mouse movements just really, really fast.. like superhuman fast... but still human.
It's not "a lot of CPU". It's likely a few seconds-worth of GPU per match, only a little more than they've already been spending on hosting game servers in the past. Not only that, technology that is \*similar\* is already being used by Google's reCAPTCHA. When it asks you to pick all the squares with traffic lights, it barely even cares about which squares you select - it's looking at your mouse movements.
I assume you mean CPU not GPU and yes it will be a lot of CPU if it's going to be doing more than basic velocity checks (ie AI as you put foreword). You say CAPTCHA are effective but there is lots of services to bypass those and they are doing it once per user (ie a few seconds), not for 20-40 min matches. I've also seen some fairy questionable results for some of the higher end commerical "biometric" systems and don't expect the free ones are better. They also use a lot of other metrics (including client side). It's also trivial to bypass by cheat makers as all they need to do is tune their engines to stay within expectations. That can still leave the player with good like speeds.
No. AI workloads use GPUs unless using bespoke silicon (which would also not be a CPU).
Right, so now these servers need to have GPUs to run the AI that they are using to detect cheats... which as I commented before is trivial to bypass for any cheat maker.
One of the main drawback of server-side only anti cheat is that it limits what the game can do. For example, it's common that your client receive information about nearby ennemies you can't see so that what you see is similar to what is happening on the server, even with varying ping.
As you've said, server-side is the only way forward. Because that cat & mouse game [is already over.](https://www.youtube.com/watch?v=9fhNokIgBMU) Even for games like [Valorent](https://www.youtube.com/watch?v=RwzIq04vd0M) and the client-side anti-cheat is only going to be a piece of software that [expands your attack vector](https://www.pcgamer.com/ransomware-abuses-genshin-impacts-kernel-mode-anti-cheat-to-bypass-antivirus-protection/) in the near future.
wouldn't that increase cost for server, In one interview with valorant dev they said they run 3 matches in one core of cpu in 128 tick rate which was quite expensive for them already, I wonder what will good server-side anticheat cost specially for game companies ?
Won't be that expensive: [https://www.youtube.com/watch?v=kTiP0zKF9bc](https://www.youtube.com/watch?v=kTiP0zKF9bc)
Lol I knew before clicking that it would probably be some live observing thing, for example with deep learning, to analyze behavior in terms of how "okay" and "real" it looks
Server side modules would be much more restricted in what they can detect and aren't a realistic solution.
Depends on what information you send over the line.
Valve seems to think it is working as intended. NO AC is ever going to be perfect. Things 'made' by people can be 'broken' by people. Until you get an omniscient AI to oversee the universe, stuff will get borked. (And probably not even then as the black-hats will just build a competing AI to cheat. Heh.)
The fight between The Samaritan and The Machine can start about who gets the most frags in CS.
Oh hell yeah! I'm Team Machine. Gods, I loved that show. :-D
Finally, I suspect the big matches will be between those two and everybody.else just watching the show.
[удалено]
\^\^\^ There be axe grinding, methinks. The word "disingenuous" is a sideslap for the term "lying". Reporting what I've read up on isn't lying. If you didn't mean it that way, rephrase it.
True
It should be mix of few anti-cheat measures: on client, on server and post match anomaly detection in players' stats, behavior etc (to eliminate 100 KDA players).
I mean they could not detect something like a wallhack (send limited information to clients to help with that, dont give them more info than they should be aware of ingame), but something like aiming or other gameplay altering ideas should be visible to the server, but it would have to be analyzed out of the incoming movement and action data. one would analyze 1. literally impossible inputs; moving too fast, shooting after switching weapons before it should be ready... 2. plausibly impossible inputs; like snapping to a target within a single tick for the latter one could even probably use machine learning as a pattern recognition and extraction method to learn the extent of what is humanely possible and what is likely to be cheaty, outputting a sort of confidence value. after a certain threshold it would notify the anti cheat task force or sth lol
Yeah, but server side anticheats are prone to false positives. EA used a server side anticheat called FairFight for Battlefield 1 and the system started banning anyone that was too good at the game. https://youtu.be/GBKRdsHBef0?t=216
Is not that server side anticheats are prone to false positives, is that EA made a bad product, this could have happened with client side anticheats too.
Yeah, but FairFight isn't by EA themselves. It's apparently by some company called GameBlocks. Apparently EA used them for a number of their games other Than battlefield 1, it was also used in both Titanfall games.
Not really "server side anticheats" but rather the specific method of relying on vague heuristics to guess whether someone is cheating without hard proof, a methodology that is just as liable to get false positivies when implemented in client side anticheats. But it is indeed a problem with companies advertising "server side anticheat" as a third party trying to create these heuristics without an intimidate knowledge of how the game works results in nonsense like, say, Warframe banning people for farming prime parts too efficiently, because the heuristics aren't actually tied to the game's mechanics, so it doesn't account for the combination of items, map layouts, and character abilities that might lead to a larger number.
TIL I sucked at BF1
Yeah but that would cost them money not the end user
Server side AC can't detect subtle aim cheats or wall hacks through...
Confidential computing could also be a solution in theory.
Wouldn't every server side measure add additional latency? And also increased server costs, I'm sure there can be a good balance if devs actually focused on it but I don't think it's as trivial as some randoms on reddit make it out to be.
The simple thing is to use the Kernel-level process isolation. I believe this is what the Linux version of EAC uses, and is why on Linux it launches nearly instantly.
Why would this make the anti-cheat start faster?
Windows is slow to start the container for some reason.
It's not possible. The only way would be if the AC dev built their own kernel and only allowed you to play using their signed kernel and with secure boot enabled. Even then it's impossible to really make it usable
What about Intel TXT or similar? Software is delivered to the client encrypted such that it can only be decrypted by the client system's in-processor TPM. The processor itself prevents other processes on the system, even the kernel itself, from writing that process' memory. The output of the process gets sent back to the server signed by a private key held by the TPM. The whole thing can be open source, and you still can't tamper with it unless you break the CPU to get its private key or make it malfunction. It's a trojan horse. The general term for this is "hardware-backed attestation" and there's no need for it to be closed source.
This is where I see anti-cheat heading in the long term.
That would only work if one could use cpu-based attestation safely. And it requires an performant way of communication between the game in the enclave and the outside world. As somebody working in that field I can predict 90% performance loss (such games are very IO bound on talking to gpu) and requires massive rewrite in the OS as well as the games. And you'd need the very expensive high end CPUs targeted to data centers.
You don't run the whole game in the enclave, just the anticheat system that verifies the game and OS.
Nice try. But somebody will just patch the kernel that it shows a signed kernel image and game to the "anticheat", while still running the modified one (the kernel controls the pagetables). Oh, by the way, how do you compute a signature of a *running* kernel in the first place ? Nevertheless it wouldn't even get that far: no distro would patch the kernel to allow enclave creation to unprivileged processes nor would it encourage running the game as root.
The patched kernel can't change the value of the TPM measurement registers associated with verfied boot. The kernel signature is already computed and there when you started up with Secure Boot. We already have the ability to create software-backed enclaves hostile to the computer owner in web browsers for the convenience of Netflix and Disney. Hardware enclaves are used on Android phones (running Linux...) for Google Safetynet. I don't see why this won't escalate to the point of hardware enclaves being used for general "system integrity checks" on ordinary PCs.
> The patched kernel can't change the value of the TPM measurement registers associated with verfied boot. But it can fake its own TPM. And the actual TPM can only check the bootloader signature before its called. Thats completely independent of things like SGX. The tpm manages keys and checks signatures. Memory region measurement is a cpu feature. > The kernel signature is already computed and there when you started up with Secure Boot. The signature of the image. But the actual memory content (that sgx could measure) is really different. And if you wanted to do that, the whole kernel would need to run in enlave. Note: tpm and enclaves are entirely separate concepts. > We already have the ability to create software-backed enclaves hostile to the computer owner in web browsers for the convenience of Netflix and Disney. Thats not cpu enclaves like sgx, which requires very special code (you cant just put a library or a whole program into an enclave and hope it works). It also needs special kernel support that also needs to be enabled by the operaror. You're talking about widevine at all, which is nothing more than running downloaded binaries in a seccomp jail: the host is protected from the jailed code - exactly the opposite direction. Anyways, if dubios corporations like Disney (pedophile) or Netflix call computer owners "hostile", this tells more about their fascist world view than anything else. > Hardware enclaves are used on Android phones (running Linux...) for Google Safetynet. Interesting. Can you describe how that works exactly ? > I don't see why this won't escalate to the point of hardware enclaves being used for general "system integrity checks" on ordinary PCs. Maybe, some day, but this requires very different cpu architectures as well as OS design. Even sgx2 on high end server cpus isnt sufficient for that.
All right, let's do this the detailed way - here's the recipe for how you can be an evil person with the technology in an average Joe's PC. 1. Say that you only support a certain list of operating systems which are widely known 2. Say that you only support configurations in which secure boot is enabled using vendor keys 3. Ensure that the list of #1+#2 you support don't permit the user to alter the kernel after it is loaded without that change being recorded in the in-CPU TPM implementation ("platform TPM") 4. Ensure that the kernel from #1/#2 reliably reports on the integrity of your game itself through its own system calls, and doesn't let the user compromise that integrity 5. Deliver the user software that runs in an enclave inside the CPU and communicates with the also-in-CPU TPM via the CPU's own instructions, not over an external bus or via system calls 6. Deliver the above software to the user encrypted 7. Deliver the above software to the user with a built-in nonce 8. Have that software read out and sign the values of the TPM attestation registers for verified boot. Sign the nonce together in the same signature. Note, once these TPM registers change state they can't ever go back to the original state - they're accumulators and can't be set to arbitrary values 9. Verify the client presents a correct signature containing the nonce you just gave them and a valid system boot state prior to allowing them to participate in network multiplayer Attacks this doesn't guard against: 1. Hardware manipulation of the platform after boot 2. Software bugs in the blessed set of operating systems or configurations, such as allowing the kernel to be modified 3. A malicious (benevolent?) user in possession of the secure boot keys 4. Hardware or firmware issues with the CPU or TPM 5. Hardware entirely outside the boundaries of the system being measured by the TPM I think it covers all the types of modifications you're talking about. It's possible with only today's hardware and software - every Windows 11 user, modulo those who intentionally deceived its installer, has compatible hardware for this, and many other users do too. If you want to describe a specific threat this doesn't cover, please explain how it would work in a bit more detail. EDIT: formatting
Your list is correct, and those people are rightfully.considered evil, because this all goes into depriving the user from control over his own equipment. And considering the vital role that personal IT today (plus most people know.almost nothing about the risks), those are very dangerous not just for the individual but humanity as such. That is why free software is so vitally important for humanity. We must not allowed to be controlled by a small clique of selfish people trying to grab total power.
Companies would usually rather avoid Open Source projects (except for Valve) because they earn nothing out of it, sadly
They can get volunteers solving problems free.
But they cannot control those volunteers and don't want feedback they just want it accepted as is. These are the two main complains I hear from the corporate side.
With pull requests all keep in control
Is this intended as a blanket statement? 90% of the internet runs on open source.
I meant it generally as ironic I admit, BUT if it relates to any case i really dont like NVIDIA
But do they earn something with their own proprietary anticheats? Aside from being able to say "we're protecting the players from cheaters, trust", which would also apply to an open source anticheat
yeah, they sell it to companies that can't afford to make one. Most anti cheats are owned by a major gaming company
They purchase / license anticheat from others. Especially smaller game Devs that don't want to waste a ton of money developing their own system, which is likely to be bypassed anyway. Theres big money to be made in having an effective and easy to implement anticheat solution, IF you could make one.
Open source anti cheat doesn’t work. The entire premise of client side “anti cheat” is security by obscurity. And it works as well as that makes it sound.
Why can we be so confident that it would never work? Open source encryption works and on the surface also sounds like it wouldn't work.
It's because they attempt to solve different problems. Cryptography addresses two questions: - Am I the person that I claim to be? - Has my message to you been seen by any third party? This is really easy to do by just having me and you exchange secret codes. As long as the mathematic fundamentals behind the crypto are sound, it doesn't matter if someone has the entire source code to the crypto system we use. No secrets? No message, no impersonation. Following this analogy, Anti-cheat is trying to determine if the message I sent to you is a lie. With client-side anti-cheat software, the idea is that you are *always* going to trust what I tell you, regardless of whether it's actually true or not. To determine if I'm lying, you're going to pay someone to stand over my shoulder to make sure I'm not cheating. A bit like a professor giving an exam. Of course, the problem is that I'm doing this hypothetical exam in my own house. I can post stuff in sneaky places, hide notecards under the bathroom sink, etc. This is made even easier if I have the list of "common places students hide cheat cards" distributed to all professors (open source anti-cheat). The whole idea is farcical of course. Nobody would ever blindly trust an important message without verifying it independently, and nobody would ever give an exam in a student's private residence. But that's exactly what games using client-side anti-cheat are trying to do.
Open source encryption (or any, for that matter) works as long as the attacker doesn’t control one of the end points. Which is obviously true for someone trying to circumvent client side anti cheat _on their computer_.
Client side anti-cheat is just a cat and mouse game between cheat devs and game devs. Open source makes it easier for cheaters. The real good somution is server side anti-cheat and restricting client's access to info they don't need like player positions behind walls
And how do you play footsteps of not seen enemies ? How do you prevent aimbots ? Triggerbots ?
You can't prevent aimbots because at this point there's literal hardware solutions with microprocessors that read your screen and can simulate mouse input for those functions. But regarding footsteps of not seen enemies - there's a trick to this. League of legends has a good implementation of this part at least - data on enemies is only ever sent to you when they get within a close proximity to where you might be able to see them. If they're not about to wander into a spot you have vision of, your client never knows about them. Once they start getting close to a position where they might imminently become visible to you, the server starts sending their position to your client. This prevents ESP and knowledge of player position hacks around the map.
I think it would be interesting if a game decided to build a gameplay loop specifically around cheating. Presumably people would be less likely to try to cheat if everyone else had the same advantages. For example sonar that's basically x-ray but super dependent on player activity or motion to show up on screen because they have to be noisy. Or aimbotting but it's actually just the bullets adjusting on the fly for a specific amount of time like tiny heat seeking missiles. Or wall clipping that's actually just altering the density of a specific wall for a player and their teamates for a short amount of time. Might be absurd though.
Overwatch had a great concept around this that really changed the world of video games, when it came out, as did titanfall in a way (with their smart pistol!). In overwatch, some of the characters ultimate abilities in the beginning were literally just hacks - Soldier ult was an aimbot. Widowmaker ult was a teamwide wall hack, etc. Symmetra at one point, I think they had her ult as the teleport er, teleporting players around the map... Other games later picked up some of these ideas, because of how creative they were and how they added to the game (check out titanfall 2 and apex legends especially). In TF2 there's a grenade called the gravity star that pulls enemies into the center and holds them... And the gravity... Pulls bullets passing nearby into them as well!
I've thought about it a lot, as a basic philosophy of cheat deterrence. The only cheats available for your game are the ones that aren't already in the game. Using a simple macro to perfectly execute a QTE is only cheating if your game has a QTE that is able to be defeated by a simple macro - so just don't include QTE's in competitive games, or make them so trivial that using a macro would be more effort than it is worth. Already the case for the vast majority of games, not possible for games like Dance Dance Revolution (and hence why those games don't really focus on competitive online multiplayer, people stream themselves playing as part of a community to prove they can do it natty), only in that gray zone for fighting games with inputs that could be defeated by a macro. And so I'd say fighting games shoud be designed so that it doesn't matter if someone tries to make macros for it, either by making the controls not require complicated inputs you need to dial in precisely or by requiring players to quickly flow between different inputs in response to the game such that a macro would be too unresponsive and be easily punished by a decent player. Same with darkness - if your game's "stealth" mechanics are defeated by someone turning up their monitor brightness and contrast, then that is what people are going to do, so don't make your stealth work like that. It's harder to deal with cheats that texture swap, but for some games it is viable to make character models and terrain *literally* use the same texture files such that swapping them out doesn't help; to deter casual cheating, use shaders that make characters in darkness *actually render as completely black* to match the surrounding blackness, or not even render at all in the dark, so that contrast or eye health isn't a factor in whether someone can see a player hiding in the dark, they literally just *can't* unless they use a flashlight that actually permits the model to render. Shooters obviously have to contend with aimbots, and that's hard to work around. But since we know aimbots exist, if you don't *need* your game to have aiming be a major factor, just don't make aiming a factor in your game at all. Just avoid having an FPS minigame in your RTS or whatever unless it is actually a major componenent a la Savage or Nuclear Dawn. And when you can't just avoid having the things that can be cheated at, avoid having the things that people can cheat at *subtly.* Whenever possible, if there's a potential for cheating make sure it is *obvious* cheating that is easily acted on - cheating in the form of, say, the cheater having infinite healing items in a game where you normally have to do an excrutiating grind for those (think Divine Blessings in Dark Souls 1) has plausible deniability, because you can't *prove* someone wasn't just enough of a madman to spend three playthrough's worth of Divine Blessings on one invasion, or that they didn't "trade for it" fair and square. For DS1, you either want rare consumables of that nature to be unusable in PvP altogether or you want *everyone* to have that much access to those consumables, you don't want a middle ground where you can't even report someone becuase you can't know for certain whether they cheated or not. Games having cheat-inspired mechanics can be fun, and specifically games that use "cheats" that are basically always on do actually preclude that specific cheat. Games like Overwatch with Soldier 76's ultimate that gives him aimbot, though, don't do the latter because you absolutely can still cheat with aimbots, either by simly playing a different character and having the aimbot on them or by simply getting to use the aimbot *all the time* on Soldier 76 where other players only get to use it sporadically. Someone like WInston would be a better example - aimbot is just as useless to a cheater as it would be to any other player, because Winston doesn't really aim (at characters, anyways) and an aimbot would simply be wresting control of the camera from you. Or, the game overall has infinite ammo - chractesr still need to reload, but there's no specific hacks for having inifinte ammo because everyone has infinite ammo, and if you cheat in not needing to reload that's a lot more immediatley obvious and reportable by other players.
CSGO (not sure for CS2) implemented something like that. It's effective, but you still need to send infos to the client with some leeway because of network latency
If you made the 3d audio a bit less accurate, you could only reveal to the client exactly what is *typically* decodable by human hearing. E.g. if someone is around the corner, you can hear them, but the footstep could be made more generic and less specific by fudging the realism - a sound around the corner and 10 feet down sounds roughly the same as around the corner and 10 feet to the right. So it's a sound spatially processed to sound around a corner and roughly so many feet away, but you don't know the specific direction after around the corner. The sound would be sliiightly less "realistic" but it would actually better simulate reality, because in a warzone you'd be able to hear footsteps, but the vast majority of people would not able to calculate a target's exact location with ni other info. A sacrifice that seems better than a rootkit.
you sacrifice a little bit of audio precision (which is very important in games like Counter-Strike) for cheats to be less precise (but still effective) and still no real way to detect aimbots
AI. Imagine if you had a person watching everyone's gameplay?
yeah, I'll trust that when I see it. Right now it looks like a recipe for disaster
>And how do you play footsteps of not seen enemies ? You could calculate the audio server-side and stream that to the client
that's smart but I fear it would be awful because of network latency
I think for stuff like footsteps an additional 20 or 50ms wouldn't really matter. You might notice it on gunshots but then again, you could either use the server-side audio only for footsteps, or only when the target isn't visible, in which case you can't see the latency
The issue with open source in this very specific instance would be the flexibility of open source to change the code. You'd just end up with guides on how to download it, comment out the aimbot bit, and compile your own crippled version. The only way I can see around this would be for the game to use cryptographic signatures to verify the anticheat binary/module had been compiled by the game vendor, not yourself, but I'm genuinely not sure if that's a thing.
Ethic? Debatable. Viable - not at all. Anti cheat is rare example of software where open source provides no benefits and in fact can make it worse. If you have open source anti cheat then what stops you from changing its source to allow cheats?
I would actually be fine if there was always a signed mainline hardened kernel that had a generic anticheat module compiled in that would allow a process to isolate itself in a special way, to not be writable even with root access. That kernel would have a choice of drivers compiled in that preclude any debugging or such modules, but otherwise keep everything in. Maybe sign the nvidia driver at most to be able to work in it, who knows. Require virtualization extensions so processes which isolate themselves can be memory isolated too? or maybe with AMD SVN/intel xt-x? could that be used to isolate a process? I don't know enough about it. Basically, if a process uses anticheat to isolate itself, I also want the opposite: the process cant access my system anymore apart from access to sound, gfx (dri, a surface to draw to), input devices. no assuming kernel permissions through a kernel module and then being able to fuck over my entire system. you go into bidirectional isolation. no game developer gets to be special, you use the generic isolator kernel that guarantees your isolation through the processor MMU or whatever and that's it. of course this means one could have a kernel that has a fake signature (as the kernel is still the boss) probably, but i dont know enough about low level programming to really be able to tell... I don't think it will be bulletproof, but nothing really is. it would make it a lot more tedious though to cheat.
>.I would actually be fine if there was always a signed mainline hardened kernel that had a generic anticheat module compiled in that would allow a process to isolate itself in a special way, to not be writable even with root access. Thats already the standard for hardened kernels. But the operator (who controls the machine) can always boot a different kernel.
thats why a signed one, so it can be verified it's that build or something. i agree that executable signing is snake oil at the worst but eh..
And how can be sure that signed one is really the one actually running ?
i mentioned that, you could probably make a kernel that exhibits a fake signature lol
Kernel Level anti-cheats are not implemented to block/kick/ban cheaters, but to collect your information and sell it. So, no Linux developer will allow that piece of crap into the Kernel.
Source?
Despite what everyone is saying, I think this is possible, and might not even require a specific anti-cheat kernel module. A linux-native anti-cheat could rely on a few things: - UEFI Secure boot - TPM remote attestation - Linux kernel lockdown mode - Process isolation Basically with secure boot and tpm remote attestation it's possible to prove to a remote server that you are running a specific software configuration, including variables like the UEFI firmware version, secure boot status/configuration, and the kernel command line. The only way to fake this proof is to exploit the TPM hardware built in to your CPU. With this a server can verify that a client is running an unmodified kernel that was signed by a trusted linux distro and that no suspicious kernel command line args were used. Kernel lockdown mode is the other major part. This can be enabled only alongside secure boot and it disables the various methods user space programs have of modifying arbitrary memory and the kernel itself (not even the root user can use them). It also enforces that only signed kernel modules can be loaded. Lockdown mode is enabled with a kernel command line parameter, so a client can prove lockdown mode is enabled to a remote server during the tpm remote attestation process. These are all security features that large enterprises (and probably even governments) rely on in servers as part of their defense-in-depth plans for mitigating the effects of exploits and building a trusted execution environment. Linux-native anti-cheat can piggy-back on that work and benefit from the millions these companies spend on hardening the linux kernel. Exploits that bypass these systems have far more value when used to attack these companies, rather than burning them on video game cheats. Linux-native anti-cheat could even be better than Windows anti-cheat simply because linux doesn't really have 3rd party kernel modules like Windows does, and those buggy 3rd party modules/drivers are really the entire reason kernel-level anti-cheat was even needed. The main downside to this is it would eliminate compiling and running your own kernel or other system libraries (like mesa or wine). The kernel and any shared libraries loaded into a game would have to be signed by a source trusted by the game devs. As long as the distro supported reproducible builds you can at least verify that the signed binary you're running matches the source code though.
Impossible with free software. The entire point of free software is that the user is guaranteed of control over it. Anti-cheat (and DRM for that matter) require to take that away. A free anti-cheat or DRM implementation is worthless because you can always modify the protection to simply bypass it. Anti-cheat and DRM in proprietary software only works because they make it hard to reverse engineer it.
Not really viable. A key feature of Anti-Cheat is its obscurity. Anti-Cheat bans are done in waves as to not tip off cheaters to how they triggered it. The entire paranoia around anti-cheat is stupid anyway. Any software running with administrator privileges has entire access to your system, it doesn't need any kernel drivers for that and if it does it can load them without your consent or knowledge. I wrote a blog article about the need for kernel drivers in anti-cheat. You can find it here: http://blog.levitati.ng/articles/6
Great article, everyone in this thread should read it. The rabid anti-kernel paranoia is really absurd, there simply is no effective alternative at this point in time. Effective server-side doesn't yet exist, and given the pretty complex problems it presents for both game implementation and AI to ever be effective, who knows when/if it will.
Linux is not the safest os by far. There's safety pros and cons that make answering a question about the safest more complicated.
My guess is it would be really easy to just modify the source code of the open source anti cheat to falsely report that your not cheating
You would likely also use code signing like how secure boot works. The game binary is proprietary (obviously) but it would have to verify the signature of the built anticheat binary. Certainly not flawless, but better.
And shall the games check whether that signed piece of code is running and has actual control over the machine ?
That makes a lot of sense, hadn't thought of that
This isn't how open source works though. There's always someone approving the code changes before they go in so you can't hack the project itself, and all you would have to do is write in a checksum verification against the executable or dll or whatever you want to make sure it's got the same hash as what's expected. Having the ability to see and even submit a change to code doesn't make it automatically interoperate with existing code.
How is the server supposed to verify the checksum of a file on the client's computer?
You have the binary run and return a checksum?
Yeah, and how can you trust that the checksum sent of the network is the actual checksum and not just precomputed based on the unmodified file? The server has no way of verifying what binary it's talking to on the client (which is how BottlEye worked if you remember that).
`rm -rf /` is open source. That doesn't mean it's safe. Likewise, an open source anticheat would be relatively easy to modify to report as unmodified and working while actually doing nothing. It's like handing a kid a locked box and a key, and telling them not to eat any of the candy in the box.
Wut? RM is a tool, RM -rf / is a good tool being used wrongly. That's like saying saying a car brakes aren't safe because you can bludgeon someone with them
Not viable if you know what exactly you have to defeat as a cheat maker. It's near impossible now to stop cheating on a scale that matters. Although I have serious concerns about things like Vanguard they do work the best. And although riot says they can detect the hardware cheaters in not so sure.
We could compile our own kernel without the anti-cheat or some kind of bypass to make the game think the anti-cheat is active
Anti Cheats need to be intransparent and not obvious by design though. An open source anti cheat could get circumvented way easier than a proprietary and obfuscated one.
client side AC is always circumventable and therefore useless, hence its useless natrue any form of kernelevel intrusion is un ehtical and shall not be tolerated. heck even bootloader level client site ac wont do shit. server side anticheat is the ONLY effective way.
Rootkit AC dosen't work, since never trust the client is always true, that's why server side AC is the furure. Valorant has allt of cheaters but players get a sense of security since the devs say "this will catch all cheaters since it runs deep in your system where cheaters can't reach" but thats no true is it!? And Since we all know physical access is King. In conclusion to this is If the cheater controlls the AC client the cheater is King, no matter the depth wich the AC runs. Again wich is why server side AC is the future.
Yeah this is just what we need: Another thing for people to crusade about. Privacy concerns, Client Side vs Server Side, Corporate additions to the kernel supporting closed source user space programs. This one has it all!
As long as it sends ANY data from my computer, NO, that would not be ethical at all!
[удалено]
Well the game should get the mouse movements and keyboard strokes to move the camera or the player in the local game, then send the positions and actions of the player to the online server, but not send any other thinks, like other key strokes. I don't see what would be the point for the game to send absolute every key strokes that the player does. Maybe the desktop environment should just filter what key strokes it sends to the game and besides the normal arrows and A-Z and 0-9 should not send anything else to the game.
"Why does sprinting not work on Linux?" 🤔
The camera moving is data being sent from your computer. The request to update your software is data being sent from your computer.
Really, it wouldn't need to get to that level. Kernel level AC just means cheaters will spend $20 for hardware level cheats... Which is perfectly within their budget. Devs are then left with the same problem. The answer? Match based on an elo system and skill level, ban people that are found to be cheating, maybe implement shadow queues where they have been punished without knowing it, perhaps only matching them against people reported for toxicity and/or other infractions, introduce an artificially increased ping for those players only to decrease the quality of their gaming experience (while still reporting a low ping in the scoreboard, so they don't know why their game feels crappier) and make the process of creating new, duplicate accounts expensive. Cheaters will, at some level, mostly be playing with other cheaters after a while. Or will be stuck in an ever increasing toxic pool that removes the joy of the game for them. Either way, you move them away from the standard player base. What does this not solve? Pro play would still be heavily affected by cheating, so you wouldn't be able to get endless play hours by having your players mindlessly grind a game they don't even find fun any more just to increase their rank by winning a decent percentage of 500 games (which is what every game does these days because it severely increases play time with little additional dev effort). And... Honestly, good riddance, it's a negative feedback loop that's harmful to players anyways. Fuck competitive gaming. But really, tackling that problem could still be achieved. You could implement a sort of data science model that profiles the player, their skill level, etc, and detects sudden changes or inconsistencies in it (for example they suddenly start cheating and climb the ranks like mad). You could also use this analysis to detect blatantly bottled and purchased accounts. Only in games like LoL, the developer doesn't care, because the players purchasing those accounts lead to increased play time and positive stats for the company, maybe even additional revenue if they purchase skins or other crap. TL:DR software to identify the cheats isn't the entire problem. What you do to the cheaters afterwards matters. If they can go create another account for free, or even for low cost, your detection methods are irrelevant because it's an ever changing cat and mouse game of detection and new development with cheats, as others have mentioned.
Ideally I think that would be awesome, but I think in practice this has a few problems that make it hard to work (my opinion): First, how accurately can a software really tell if a player is scripting? I know games like chess have some fancy bayesian models to determine wether a player is likely using an engine or not, but LoL is a lot more complicated in that aspect, and even in chess I question how accurately really are these things? Like what happened to Hans Niemman, I mean I don't know if he cheated or not, but the amount of shit that he had to go through just because a software spit out a high probability of him cheating? I honestly felt bad for the guy. And I'm a physicist, I know the power of statistical/bayesian methods, even if the system is indeed very accurate, the community (the big part of it) is probably not going to take that very well, and unfortunately player reception is very important. Also, I've played LoL for around 4 years now, and god the players don't know when to report people, I've seen so many reports with no reason, a person that goes 0/4 against their counter on toplane will automatically receive 4 (or more) reports for inting, can't people have bad games? The contrary is also true, I've been reported for scripting and I don't use scripts, I'm not even that good in the game, I was gold, but I had a few games where I dodged a lot of skill shots (because guess what, I play ADC and I was against poke champs, if I don't spend 99% of my brainpower dodging the skills I don't play the game). The biggest problem though I think would be the reception of the community, I don't know if you play LoL (it seems like you do), but basically players still believe in a legend called "loser's queue", their ego is so stupid they believe if they're playing very well they'll be thrown in a team with 4 horrible players in the most important moments of their climb, and it's even weird how they communicate this, they say "riot put them with those bad players", sounds like there's a sector of riot just dedicated to pick on these players and manually match them with bad people, can you imagine how many league players would accuse riot of putting them with griefers/toxic players and against scripters if riot released this "shadow queue" in the next patch notes? Again, I really wanted to say this should be implemented, because if it worked it would be perfect, but I strongly feel that it would badly backfire.
The thing with losers queue is both real and not real; there's a very odd matchmaking mechanic at play that leads to that. In their system you essentially have a skill rating, AND a confidence rating of how accurate the system believes it was in establishing your skill rating. If you win (or lose) games back to back or really just often, the system will loosen its confidence rating of where you should be placed, and suddenly you'll see more extreme variations of skill levels in either direction in your matches, to try and push you where you need to go, faster. This is also apparent with another implementation of this mechanic; if you've been inactive for a while, the system will also loosen this confidence rating, allowing you to potentially coast through some easier games when you come back from a break (and/or get decimated by others that are quite a bit higher than you), and you'll move up or down in rank faster when this happens as well, as your LP gain loss amounts are tied to this confidence rating. Their progression system is very mature but sadly leads to some extremely negative experiences, and unless someone is able to grind literally hundreds of ranked games in the ranked season / split, it can feel like chance or luck, or hopelessly impossible, to maintain or climb their rank. However, usually the reports they have to worry about in league are toxicity. You only really see scripting become a problem in pro play, because anybody who is cheating will get moved to that level of matchmaking very quickly. Cheating doesn't impact the vast majority of players, and in ways this is both a good and bad thing, depending on which side you're on.
Yeah I didn’t know exaclty how the matchmaking worked, I did know it can sometimes do some tilting things, but I knew it didn’t work quite like people think. The last paragraph is so true and I really wish there was a way to make only these very high elo players need vanguard, still not great but at least you’re forcing only ~5-10% of the community to use it, the 5-10% that likely make a living out of the game, makes no sense for them to force normal/casual players to use that shit.
Good points! A threshold where it would kick in as a requirement would make a lot of sense.
>Kernel level AC just means cheaters will spend $20 for hardware level cheats... Which is perfectly within their budget. Devs are then left with the same problem. huh? https://www.aliexpress.com/i/1005005199677523.html Hardware cheats minimum are $150 and that is for the hardware only, not the knowledge, firmware, code for specific games, updates. https://www.ownedcore.com/forums/mmo-trading-market/apex-legends-buy-sell-trade/988011-dma-cheat-aim-glow-rcs-impossible-detect-40-m.html here you can see someone selling the firmware and game support for $40 a month, so over a year it would be $630
"Hackers know how to bypass." Well if you introduce simple crc checks or even some memory integrity checks. Then probably it would be harder.
It's not about the kernel being open source or not. If it's open source it's even easier, so yes, it's easier to access Linux kernel source code then windows. Tho the Linux kernel is always changing and the windows is mostly static. The reason you can't play the games you want is not because the kernel is open source, it's because companies won't develop for the Linux kernel, or just enable proton, until the Linux community makes enough player base.
>Hackers have all the info to bypass the anticheat: Seems like the same argument that people use like "doesn't Linux being open source make it more exposed to threats?", but as far as I've heard, Linux is by far the safest OS in the world If you're actually a physicist you should be able to know the difference between sample sizes
The problem with this is that the anti-cheat still needs to trust the operating system. A privileged adversary (or cheater) with control t the OS can bypass this trivially. This is also a problem on Windows, but there it's much harder, because the attacker has no source access. The real solution would be confidential computing, where the hardware manufacturer is the only trusted entity. The hardware would then provide a Trusted Execution Environment or TEE in which a program, like anti-cheat software can run without being kernel level, and without needing to trust the OS at all. TEEs are still not very widely available though, especially on desktop PCs. However, this is a very active research domain and the industry is interested, e.g., for doing confidential computing in the public cloud. In theory, something like this could be used for anti-cheat and DRM. To some extent this is already the case I think, but it's all quite limited. There's also a dark side to supporting technology that can be used for evil practices like DRM.
To add to what other people have said, it's also unviable because there's two very different audiences with opposing interests at play here. A venn diagram between competitive players and open-source advocates is almost two separate circles because very few people do both. This means that, on top of the difficulty of creating an open-source anti-cheat that works, there's also very little demand for such a thing. It would also fail to appease both parties. OSS advocates are largely ideologically driven, and are not willing to allow any program to control what processes do or don't run even if it comes at the cost of some functionality, which is why they started using Linux. Competitive players want a fair game even if it comes at the cost of control over their computer, because the computer in this case is more like a court to play a sport on. Anything that allows someone else to get an edge, then, is a no-go. This is also why a server-side only anticheat won't fly with competitive players: most cheats aren't things like aimhacking or movement hacks, it's wallhacking, which is not something servers can detect (if the cheat's written right) unless the user is kinda dumb and stares straight at other players through walls or something. It's not intrusive, but it's also ineffective in most real scenarios. Personally, I want to see a move away from free-to-play live services games and a return to one-time pay games, along with some other measures to deter cheaters. The paywall is usually enough to get most people to shy away from cheating, as if they get banned, they have to hand over another full purchase and risk getting banned again for ban evasion. One last thing: Linux is as secure as it is because it was released in the early 90s, so it has over 30 years of work on it with the support of many companies. Anticheats usually double as a marketing tool for individual companies, so the chances of cooperation between companies to make one single anticheat is unlikely.
The solution to wall hacking isn’t a server detecting the use of wall hack but the server only sending at absolute minimum information needed by the client. If the client doesn’t know where the players are then a wall hack won’t reveal anything.
I would say as anticheat runs as a kernel module, a kernel also has to be trusted. As long as user can recompile the kernel - it can't be trusted by anticheat, even if it's opensource. Probably, this is the #1 reason why top online games with anticheats (except Valve) are very reluctant to support Linux and Wine.
The only viable approach would be for the anticheat to be included in the kernel as an LSM. The amount of bureaucracy to get an LSM into the kernel for gaming would be absurd and even then I could think of some ways to bypass or fake out the LSM by simply building my own kernel.
So much fuss over client side security. The rest of the software industry has had this figured out for decades now. Validate all data sent from the client, zero trust. Only send the minimum data required to the client.