Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Anticheat Update Tracking

not-matthias.github.io

Post reply on HN
Print view View original

21–30 of 69 posts

Re: Anticheat Update Tracking

#21

Post by AnthonyMouse »

nulld3v wrote: post #4

Very nice walk-through on the reverse engineering process. Also, they linked this post that made my jaw drop: https://www.unknowncheats.me/forum/anti-cheat-bypass/667333-... Apparantly BattleEye anti-cheat had an exploit where hackers could permanently ban any player they wanted. BattleEye allowed anybody to log in as a "game server" so hackers simply booted up a fake server, told BattleEye that "player X has logged…

It's crazy that people allow this stuff to effectively run as root. One of these companies is going to have a vulnerability that lets other players run code on your machine in kernel mode.

Re: Anticheat Update Tracking

#22

Post by CJefferson »

varun_ch wrote: post #13

Forgive my ignorance, but why don’t game developers put more effort into limiting the amount of data accessible to the client (restricting it only to what’s reasonably necessary)? For example, couldn’t more movement physics be validated or handled server side? Cheats might still be able to read some data from the game process, but ideally, they’d be limited to issuing inputs like any other player, based only on the s…

Making sure that movement is validated on the server really is a reasonable requirement.

There are two main issues:

1) You typically want to let player's machines have a little knowledge the player doesn't, because if they peak around a wall, they should see an enemy, without having to wait for a round-trip before getting the information of the enemy they can see. Games often give out too much of this kind of information, but that's because it is computationally hard to figure out if a player can "almost" see an enemy.

2) Aimbots are basically impossible to check for on the server -- you can play a cat+mouse game (and games do) of seeing if players are consistently too accurate (or more likely, consistently too mechanical), but it's very hard, and player-side anti-cheat is part of trying to control this.

Re: Anticheat Update Tracking

#23

Post by brainzap »

varun_ch wrote: post #13

Forgive my ignorance, but why don’t game developers put more effort into limiting the amount of data accessible to the client (restricting it only to what’s reasonably necessary)? For example, couldn’t more movement physics be validated or handled server side? Cheats might still be able to read some data from the game process, but ideally, they’d be limited to issuing inputs like any other player, based only on the s…

too much effort, since you also want to play sounds from hidden sources

Re: Anticheat Update Tracking

#24

Post by unaindz »

fleebee wrote: post #12
chaoz_ wrote: post #11

Ehh, pretty sad there's almost no information on FACEIT anti-cheat. One of the most impactful out there. Wonder if it's just the invasiveness that separates it. Valve can't replicate even part of it, while CS2 game modes are flooded with cheaters. Most people who chase competitiveness (which CS used to be all about – now it's also skins) just install FACEIT directly and ignore 90% of built-in game content. Maybe Valv…

There's a number of good reasons not to make everyone run a kernel level anti-cheat. Linux (and therefore SteamOS) compatibility is a big one. I think the status quo where anyone on any platform can access the vanilla game -- where cheaters may not even be a huge problem depending on one's skill rating -- and the most competitively-minded players have the choice to play on FACEIT, works pretty fine. I do wonder what…

Valve's approach was to avoid the cat and mouse game knowing it doesn't lead anywhere. You can always cheat using DMA or reading the monitor with another computer that simulates a hardware mouse to get aimbot abilities. They wanted a machine learning to detect, flag and ban suspicious behaviour. This didn't work out and I'm not sure they are still trying but there's a few conferences talking about it.

Re: Anticheat Update Tracking

#26

Post by FunnyLookinHat »

fisian wrote: post #25

off topic: What's the font this website uses for the code? The font ligatures seem nice, but I also would have to get used to reading code like that.

Inspector is telling me it's "ZedTextFtl", with "Jetbrains Mono" used for the monospace blocks.

Edit - More info on it here:

1) https://www.typotheque.com/fonts/zed-text 2) https://www.typotheque.com/blog/zed-a-sans-for-the-needs-of-...

Re: Anticheat Update Tracking

#27

Post by nativeit »

maeln wrote: post #10
7bit wrote: post #9

Earlier quoted context omitted.

Most online Games require kernel Level anti Cheat.

No, very few of them actually use kernel level anti cheat. Really the only game that use them is Riot's games and Counter Strike private league FACEIT (as far as I remember).

There’s also this little known title, I think I have this right—“Grand Theft Auto”.

Re: Anticheat Update Tracking

#28

Post by lightedman »

gen6acd60af wrote: post #20
ethan_smith wrote: post #8

Earlier quoted context omitted.

This BattleEye exploit demonstrates a classic failure of trust boundary definition - they effectively created a system where client attestation was accepted without proper authentication or verification.

>a classic failure of trust boundary definition - they effectively created a system where client attestation was accepted Can you elaborate? I'm unsure what a trust boundary definition means in this context and how it relates to attestation.

trust boundary basically means a spot in execution where the trust level of code changes (aka privilege level) and thus needs reverification

Re: Anticheat Update Tracking

#29

Post by close04 »

gen6acd60af wrote: post #20
ethan_smith wrote: post #8

Earlier quoted context omitted.

This BattleEye exploit demonstrates a classic failure of trust boundary definition - they effectively created a system where client attestation was accepted without proper authentication or verification.

>a classic failure of trust boundary definition - they effectively created a system where client attestation was accepted Can you elaborate? I'm unsure what a trust boundary definition means in this context and how it relates to attestation.

It means you trust something with lower trustworthiness without (re)validating, or even trusting it at all if the validation isn't all but guaranteed. The boundary is when you switch between levels of trust.

Trusting something outside of your control is a good example. When your trusted game server trusts the untrusted game client when it says "trust me, it was a headshot" without validating this.

Re: Anticheat Update Tracking

#30

Post by monster_truck »

AnthonyMouse wrote: post #21
nulld3v wrote: post #4

Very nice walk-through on the reverse engineering process. Also, they linked this post that made my jaw drop: https://www.unknowncheats.me/forum/anti-cheat-bypass/667333-... Apparantly BattleEye anti-cheat had an exploit where hackers could permanently ban any player they wanted. BattleEye allowed anybody to log in as a "game server" so hackers simply booted up a fake server, told BattleEye that "player X has logged…

It's crazy that people allow this stuff to effectively run as root. One of these companies is going to have a vulnerability that lets other players run code on your machine in kernel mode.

Happens about as often as games ship UI middleware that uses html and has xss, leading to an rce when the game leaves itself running as admin after an update. So basically all the time.
Post reply on HN