I used to write cheats for various source engine games (running vac), and later more interesting games like pubg which run battleeye. Those are two very different anticheats, and I think comparing them is interesting
An important thing to point out is that it requires a lot of reversing work and low level knowledge to make a cheat, and usually at the end of the day cheats all end up with the same core features anyways. This means that there’s a huge stigma amongst cheat developers around knowledge sharing, which makes a lot of that initial work all the more arduous. Anticheats further increase that initial work, and incur an ongoing maintenance cost since each update can break your cheat (especially of you specifically work to break the public methods that everyone is using).
Last time I looked at VAC, it was doing stuff like looking for stuff like modifications to the .text section to detect hooks implemented by writing e.g. jmps to some injected code, but never actually adapted when people started just modifying vtable entries (most source engine constructs are exposed to developers as pure virtual cpp classes). Since they stagnated, it got easier and easier to cheat over time as more and more people spread knowledge on how to hook in an undetected way. Hell, in gmod some lua anticheat developer (gmod is a sandbox game with a lua scripting interface) found a vuln in the clientside lua implementation that allowed arbitrary memory io and used that primitive to implement checks for injected dlls when people started cheating at that level in that game, which was far more effective than VAC ever was.
BE was another universe, it felt extremely prohibitive to touch the game in usermode & even in the kernel I started to feel cramped. You can still totally get past it, but it felt more like writing a very specific rootkit than actually making a cheat.
So, from the other side, anticheats raise the cost of initially developing and maintaining a cheat. If used effectively, they can also kill paysites. I think they have value, even if they aren’t achieving a 99.99999% success rate.
An important thing to point out is that it requires a lot of reversing work and low level knowledge to make a cheat, and usually at the end of the day cheats all end up with the same core features anyways. This means that there’s a huge stigma amongst cheat developers around knowledge sharing, which makes a lot of that initial work all the more arduous. Anticheats further increase that initial work, and incur an ongoing maintenance cost since each update can break your cheat (especially of you specifically work to break the public methods that everyone is using).
Last time I looked at VAC, it was doing stuff like looking for stuff like modifications to the .text section to detect hooks implemented by writing e.g. jmps to some injected code, but never actually adapted when people started just modifying vtable entries (most source engine constructs are exposed to developers as pure virtual cpp classes). Since they stagnated, it got easier and easier to cheat over time as more and more people spread knowledge on how to hook in an undetected way. Hell, in gmod some lua anticheat developer (gmod is a sandbox game with a lua scripting interface) found a vuln in the clientside lua implementation that allowed arbitrary memory io and used that primitive to implement checks for injected dlls when people started cheating at that level in that game, which was far more effective than VAC ever was.
BE was another universe, it felt extremely prohibitive to touch the game in usermode & even in the kernel I started to feel cramped. You can still totally get past it, but it felt more like writing a very specific rootkit than actually making a cheat.
So, from the other side, anticheats raise the cost of initially developing and maintaining a cheat. If used effectively, they can also kill paysites. I think they have value, even if they aren’t achieving a 99.99999% success rate.