Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The problem is the cheats use kernel drivers so the anti cheat providers have to to keep up.

Edit: rather than downvoting can someone offer a reason as to why?



That is a cat-and-mouse game you cannot win, similar to DRM. There already are hardware cheating devices that use DMA to peek and poke main memory. Or cheats could run in a hypervisor or on vulnerable hardware in a SMM rootkit.

And if the response to that is ever more invasive surveillance technology then that's a security problem.


And the mistake people make is thinking it's a win or lose thing, it's not. It's about reducing the impact of cheaters and raising the bar high enough that an average Joe isn't willing to put up with the hassle needed to cheat. Just vexauwe you can't detect everyone doesn't mean you shouldn't ever try.


> It's about reducing the impact of cheaters

It's putting the collateral damage of these measures on the honest people to deter a few. These rootkits make everyone's systems less secure and less stable. Some even keep running after you close the game.

This is a hidden cost put on the consumers so that the game developers can profit without having to design a game that is safe when dealing with untrusted clients.


> it's putting the collateral damage of these measures on the honest people to deter a few.

It's putting the collateral on _everyone_ to deter a few who have a substantial impact. It's completely different to DRM where there is no knock on impact to other legit customers.

> Some even keep running after you close the game.

They all do. If they don't, then the cheat just needs to run first.

> game developers can profit without having to design a game that is safe when dealing with untrusted clients.

This isn't about profit, and thinking it is is pushing your agenda. On the most extreme side you can just pixel stream a rendered video feed, but the latency is awful for many kinds of games. You inevitably need to let the client have some sort of say (I shot at X), and it _will_ be abused.


> They all do. If they don't, then the cheat just needs to run first.

That is nonsense, otherwise the driver would have to be loaded at boot time, which in turn would mean installing a game would need a reboot which just isn't the case these days.

> It's completely different to DRM where there is no knock on impact to other legit customers.

The media industry claims that piracy cuts into their profit which would imply that it raises prices for everyone. So no, it very much is like DRM in many aspects.

> In the most extreme side you can just pixel stream a rendered video feed

Which is expensive since you now have to pay for the hardware instead of your customers paying for it, so that too is about profit. In a more extreme case you could put cloud gaming machines wherever CDNs put their edge acceleration boxes.

> You inevitably need to let the client have some sort of say (I shot at X), and it _will_ be abused.

No, not really. The client does not have to compute the canonical outcome of game mechanics, after all for any action they predict locally there might be an action taken by another player that is inconsistent with that prediction and they will only learn about that incompatibility once their lightcones intersect (which takes a few milliseconds). Something has to reconcile those, which might as well be the server rather than the client.

All a client has to do is to compute a tentative game state and the pixels that go along with it. That state will later be corrected once it learns about the canonical update, which can result in the infamous rubberbanding effect.

Most cheats that don't involve a broken game engine are of two flavors A) extracting information that the software has but the human shouldn't know (e.g. wallhacks) or B) having software perform inputs that the human should do (e.g. aimbots). A) Can be prevented by reducing the information the server sends to the client to the necessary amount to render their current view. B) cannot be prevented by any means as one could always hook up the output pixels of a GPU to an external computer and an emulated mouse via USB, this is analogous (heh) to the analog hole in DRM.

Neither of those have to do with the client determining "I shot at X" on its own.


> That is nonsense, otherwise the driver would have to be loaded at boot time, which in turn would mean installing a game would need a reboot which just isn't the case these days.

Riot Games' anti-cheat Vanguard (for LoL and Valorant) loads early during boot, requires a reboot after installing and if I recall correctly they now allow unloading it (because who wants to do banking with a rootkit loaded) but then require a reboot before playing again.


Ok, this is even more invasive than my worst experience and and also worse than some practices that already received backlash (such as persisting after the game closed, as previously mentioned). I wonder why game companies come to so different conclusions about the "need" for such things. Are their games easier to exploit and they just try to paper over it? Or is money involved, raising stakes?

If they go further we'll end up with closed, console-like systems (secure boot only with microsoft's key, only signed apps allowed). And of course DRM vendors would follow their footsteps.


> That is nonsense, otherwise the driver would have to be loaded at boot time,

This is already common - see valorant as an example.

> Which is expensive since you now have to pay for the hardware instead of your customers paying for it, so that too is about profit. I

No, it's about latency. See the absolutely vehement reaction to streaming services for twitch shooters on gaming forums.

> Something has to reconcile those, which might as well be the server rather than the client.

The problem here is that the server is some distance away from all the players. Waiting for a round trip from two players with server frame times could be up to 250ms, so for a better experience, some element of that is usually left up to the client; you can spin that either way, either the shooter gets the advantage, or the defender gets the advantage.

> Most cheats that don't involve a broken game engine are of two flavors

Most game engines are broken. The reality of the situation is that 1) this stuff is _really hard_, and 2) there are tradeoffs to be made at every single step of the process that affect how the game plays and feels. Moving processing to the server means latency, predicting and correcting server-side calculations means rubber banding. Neither of these things feel good in a twitch shooter.

> A) Can be prevented by reducing the information the server sends to the client to the necessary amount to render their current view.

Not just their current view, but everything the client needs to know about the next X ms before it expects its next server update (which might even be adjusted at a later point in time). And that state is just sitting there in memory, waiting to be (ab)used.

> B) cannot be prevented by any means as one could always hook up the output pixels of a GPU to an external computer and an emulated mouse via USB,

The number of people who are willing to do that is drastically smaller than the number of people willing to pay $130 a month for a rootkit that they willing install [0]. As I said in my previous comment, this isn't about eliminating cheating 100% - it's a cat and mouse game. It's about raising the barrier to entry from credit card to specialised hardware.

[0] https://www.skycheats.com/store/category/6-overwatch/

> Neither of those have to do with the client determining "I shot at X" on its own.

Even if you send inputs, and allow for a small amount of correction (because both clients have different representations of the game state at the same time), all it takes is one client to send "I actually did shoot at that guy 50ms ago".


> No, it's about latency. See the absolutely vehement reaction to streaming services for twitch shooters on gaming forums.

By putting trusted hardware close enough to the player you reduce the latency problem to a cost problem. This is more or less what game consoles currently happen do (of course the issue is that users still pay for it rather than the game company). Also, twitch shooters existed before rootkits. Choices made by game companies such as matchmaking with untrusted strangers probably exacerbated the problem over the years.

> Waiting for a round trip from two players with server frame times could be up to 250ms,

Only if they're living on different continents or have very high latency internet providers. Many games provide region-based servers for that reason.

And it's only a roundtrip that has to happen anyway. Clients stream their updates as they take actions, server reconciles them as they arrive and broadcasts the updates to all clients. This is the minimum amount of time it takes to get the information from player A to player B anyway unless you establish p2p connections between the clients and those happen to be lower latency than contacting the server.

> you can spin that either way, either the shooter gets the advantage, or the defender gets the advantage.

That doesn't matter, the point is that leaving reconciliation of some game actions to the client means clients can lie about something and claim that it was preempted by another action.

> Most game engines are broken. The reality of the situation is that 1) this stuff is _really hard_, and 2) there are tradeoffs to be made at every single step of the process that affect how the game plays and feels.

A problem being difficult is not a good justification for externalizing the costs, especially considering that hardware may be shared with other people and botnets that might use those weaknesses create further externalties.

> "I actually did shoot at that guy 50ms ago".

That would mean trusting the client's clock which quite obviously is something you shouldn't do. Arrival time should be the only thing that matters.

> The number of people who are willing to do that is drastically smaller than the number of people willing to pay $130 a month for a rootkit that they willing install [0]. As I said in my previous comment, this isn't about eliminating cheating 100% - it's a cat and mouse game. It's about raising the barrier to entry from credit card to specialised hardware.

That's only the tradeoff from the game dev perspective. It's totally ignoring the security or privacy implications of running these rootkits and the ever-escalating system restrictions that they demand. This is the crux of the argument. If we were only talking about game devs making tradeoffs between different game experiences, risk for themselves, profit and so on there wouldn't be a problem. But they're making a tradeoff with other assets that are not theirs.


It is about profit. They could simply not ship a root kit, and then presumably fewer people would buy the game because it would be known to have cheaters in it.


This is absurdly reductionist; they could also not ship a game, and less people wold buy it because it is known to not have shipped therefore not shipping the game is about profit, when it might be because the game itself isn't finished.


I honestly don’t understand what you are trying to say here. Not shipping a game would certainly result in less profit. These entities are profit motivated, so they make decisions to maximize profit. They decided shipping a game with a root kit is the best option available to them.


Because human moderation after an AI serverside filter is much more consistent and less desperate than solving the halting problem clientside 2 rings below your app's privilege level.


I do think you're correct, but one particularly sticky issue is what you do with all the subtle cheats. Rather than developing an exploit with wall-clip, radar, auto-headshots and so on - all obvious to a human moderator - what if you make one that just lowers recoil by a smidgen, 20% or so.

If you're watching the game as a moderator you could never tell that's what's happening. Yet -20% recoil, especially for a competitive esports player, would be such a massive advantage as to make that player the best in the world, but a way that looks quite legitimate.


Wouldnt that be trivially detectable in the data by comparing the nominal recoil configuration, reported hitscan trajectories, and mouse input profiles?

Especially since the cheats need to be available somewhere, so the developers should certainly be able to get their hands on them to test...


I assume that the argument is that pros can compensate recoil to some extent (i.e. the game doesn't just add increasingly random offsets to the trajectors but actually moves the crosshair and you can move it back if you're fast enough). If so then a cheat only has to simulate sufficiently realistic inputs based on the pixel outputs of the game, which is practically undetectable if you do it on external hardware. The only advantage the game devs would have is a larger amount of data they can use to determine what passes as realistic. And how are they going to identify false positives?


Not when the inputs are all randomized, it's nearly identical to a real human recoil control


Can you give an example of some games that take that approach that it works for?

I'd also suggest that human moderation is definitely less consistent, and definitely less able to scale.

Nobody is trying to solve the halting problem in the kernel either. If a cheat runs as a kernel level driver, and anticheat doesnt you've lost the battle already.


CSGO and Overwatch come to mind. I watch a talk on the latter, how the devs transitioned and optimised their anticheat system.

It makes sense the cheat I wrote would run as admin. It's my PC after all. I also don't have access to the server in any meaningful way and modify other people's data, either. It's a good trade-off. Devs can also write arbitrarily good statistical analyses for the game. It's their responsibility.

The question is simple - is this person performing abnormally? Well, games gather tons of telemetry nowadays, and the harder-to-detect cheats like wallhacks or fluorescent player textures are also the least useful. I am a hard silver I in CSGO. With or without aids, when I see someone run around the corner, I'll duck and magdump. Any gold nova will overpower me either way.


So, when cheats are implemented as rootkits/VM hosts, will that be required for the anticheat too?

I think at that point, it's turtles all the way down.


They already are rootkits and running in VMs. That's exactly why were talking about this. Most anticheat programs attempt to detect running in a VM host too and stop that..


It has always seemed like a flawed argument to me. The effort made into detecting running cheats requires the ability to monitor processes and give a level of access that has no place in a game.

How many computers have Valorant's anti-cheat installed on some computer it shouldn't be installed on, that suddenly gives the ability to decrypt and monitor tls traffic on the device, without detection?

It would make a lot more sense to detect cheating based on user input. Even stochastic cheats are possible to detect (where you say improve your aim in more subtle ways), yet, the most egregious auto-lock-on go on for years.

Kernel level anti-cheats are attractive, because you suddenly have a rootkit installed on millions of computers that you control. Monitoring the behaviour of them is also no good, because a targeted update can make it do whatever.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: