Live data from Hacker News

Riot Games Approach to Anti-Cheat

engineering.riotgames.com

231–240 of 412 posts

Re: Riot Games Approach to Anti-Cheat

#231

Earlier quoted context omitted.

I'd curious to know what strategies make secrecy a necessity. I come from a WebDev background and open-source libraries are almost always always secure and safer then your own (due to the sheer amount of developers and ingenuity working on one repo). Admittedly, game development is a different beast and has to deal with far more client-code so I'm admitting my ignorance here.

The attackers are literally already able to run arbitrary code on the same machine, which is normally game over from a security perspective. Your secure webdev libraries also break under the same constraints.

> Your secure webdev libraries also break under the same constraints.

No argument there. Different design goals. But I still stand by quality of engineering that open source allows.

Re: Riot Games Approach to Anti-Cheat

#232

Earlier quoted context omitted.

I see. The problem is the server needs to know all of the values it expects. And if the server knows the values a cheat can figure them out too. For example, a cheat could hook OS functions and report on values in certain memory regions (e.g . the games loaded .text as some cached values). Same with reading heap locations, hook the memory read functions. Computing a hash doesn't have to be emulated, though, right? A…

I think what you are getting at is that it's impossible to 100% fully prevent cheating. This is true, but I don't think that's the goal; the goal is to make it difficult enough that it's not worth the effort. The value gained from cheating in a video game is low enough that the vast majority of people would not be willing to go through such lengths to do so.

The average user doesn't have to go to such lengths, they just subscribe to a cheat company that does. That's literally how it works today. Cheats are big business.

Re: Riot Games Approach to Anti-Cheat

#233
post #178

Earlier quoted context omitted.

The anticheat team at a videogame company might not know/care about this. This has definitely been the case with past European data privacy regulations.

Or it might be deemed reasonable. E.g. you may not film public road in the Netherlands because of privacy, but you may film the patch that your car stands on it if there have been car fires in your neighbourhood in the past month and you are concerned about your car.

> you may not film public road in the Netherlands because of privacy

So does this effectively make dash-cams illegal?

Re: Riot Games Approach to Anti-Cheat

#234
post #92

Earlier quoted context omitted.

These problems are inherent to nature of being in the real-time PvP genre. And AFAIK LoL was designed from scratch, it's Dota that actually based on the code of the WoW mod. Not that it matters today, that code is long gone.

I wasn't talking about the code. Btw, you are thinking of Aeon of Strife (Starcraft mod). World of Warcraft hasn't even been released back then.

He's thinking of DotA, the Warcraft mod.

Re: Riot Games Approach to Anti-Cheat

#235
post #155

Earlier quoted context omitted.

With enough mechanical aides, the game balance breaks. For example, SC2 has a very cheap unit called the roach. When burrowed, it can't attack, but regenerates health incredibly quickly. It's trivial to write a cheat that will, whenever one of your roaches starts taking damage, causes it to burrow, and whenever it stops taking damage, unburrow. The unit is balanced around human control - no human can, with perfect ac…

>With such a cheat, roaches punch way above their weight, completely breaking the rock-paper-scissors balance of the game. Against marines, sure. But against siege tanks/disruptors? Sirlin's spiel about there being more counters than people think ( http://www.sirlin.net/ptw-book/introducingthe-scrub ) seems applicable here.

Yes, they start punching way above their weight against tanks, too. Even moreso if you throw in an auto-scatter script.

https://www.youtube.com/watch?v=IKVFZ28ybQs

Re: Riot Games Approach to Anti-Cheat

#237
post #155

Earlier quoted context omitted.

With enough mechanical aides, the game balance breaks. For example, SC2 has a very cheap unit called the roach. When burrowed, it can't attack, but regenerates health incredibly quickly. It's trivial to write a cheat that will, whenever one of your roaches starts taking damage, causes it to burrow, and whenever it stops taking damage, unburrow. The unit is balanced around human control - no human can, with perfect ac…

I do not deny that the game mechanics would vastly change. The strategy would shift away from "How can I micro these roaches" vs "How can i effectively attack burrowing/unburrowing roaches" to "How can i ensure I get roaches" vs "How can I frustrate/prevent my opponent from getting them in the first place"... As an aside, ANY change to a game is going to disrupt the equilibrium in some manner and I assume would requi…

> How can i ensure I get roaches

Which is trivial for any skilled player, because they are an incredibly cheap, low-tech unit, and passive base defenses are currently very good at fending off very early aggression.

> As an aside, ANY change to a game is going to disrupt the equilibrium in some manner

Yes, and sometimes, the equilibrium settles on an incredibly shallow, uninteresting game-space.

StarCraft is a game of a number of rock-paper-scissors cycles, all operating at the same time. Greedy expansion - versus rushing versus safe plays. Economy versus army versus tech. Roaches versus marauders versus zerglings.

Sometimes, due to patch changes, poor balancing, or because player skill improved, the game ends up stuck in a quagmire, where the risk/reward ratio for many of these options is completely out of whack. The game stagnates, and becomes incredibly unfun to play, and to watch.

Throwing a wrench into balance, by allowing auto-scripts, which have an incredibly uneven effect on the different units, mechanics, and races in the game is far more likely to push it into an unfun equilibrium, then a fun one.

Re: Riot Games Approach to Anti-Cheat

#238

Back when I worked in games we would detect cheaters and then shadow ban. Quarantine them by only matching them into games with other cheaters. You may still have to ban them from certain elements of your game, like player economies (auction house, etc). But the more legitimate their experience looks the better. The idea is that instead of fully banning them and triggering the next iteration of the arms race, you tra…

This is an interesting approach because even though they may be cheaters they are _still_ people that are interested in your game. The percent of cheaters with the objective to utterly destroy the game they're cheating at is probably negligible.

I mean... sure but they're also only willing to interact with the game when they're making the experience bad for everyone else.

Re: Riot Games Approach to Anti-Cheat

#239

Earlier quoted context omitted.

"If I have all your code and am running it on my computer it will be a matter of time before I can back out whatever obfuscation or technique you are doing and undo it." sure try to undo a block-chain and see what happens. The code will be encrypted with a unique key that will need to be registered on the server with your account. Change that code and it invalidates your entire build along with your account. case clo…

I think you are missing my point. This concept in client computing security basically chains back to the halting problem. You can't /know/ what I am doing with my computer. You can build a very elaborate trap / obfuscation and it might be hard, really hard, to defeat it or circumvent it, but it is a certainty that I can. The block-chain has absolutely nothing to do with client code security because it has a network e…

You are absolutely correct, but it occurs to me that CPU designers could actually implement a kind of RSA style memory fetch instruction. The CPU would generate a public/private key pair, where the private key is not accessible by any means. The client would send the public key to the server, which would in turn encrypt the memory location(s) that it wishes to inspect. There would then be an instruction on client's CPU which would accept that encrypted memory location and return the contents, without divulging location. The CPU could regenerate the public/private key values for each request. I can't imagine defeating that kind of scheme without hardware hacks. The more that I think about it, the more I wonder why no-one has done it before, because it seems useful. Probably there is something I'm missing...

Re: Riot Games Approach to Anti-Cheat

#240

Earlier quoted context omitted.

Not necessarily. GDPR isn't a blanket ban on collecting/using this info without consent, it's a policy that consent is required for non-essential collection/usage. You could argue that anti-cheat is essential for an online multiplayer game like this. I think it's sketchy to collect this much info, but I don't think it's explicitly illegal.

It's a bit more complicated than that. You have to do a few things. First you have to tell the customer that you are collecting their data. Then you have to tell them under what lawful basis you are collecting their data. The user then has various rights (depending on the lawful basis you choose) to object, etc. If you must collect and use the data in order to fulfil the contract (i.e., there is no other way to do it…

> I think you could make a pretty strong argument that it doesn't apply, as long as you take pains to ensure that you can't identify the person from the information.

That would entirely defeat the purpose of an anti-cheat system. You have to have some sort of personally identifiable information attached to the data being sent in to the server, otherwise how are you going to ban the cheaters? Even IP addresses are personal identifiers as far as the GDPR is concerned and even if they're not storing it long term, just sending the user data over the wire is enough to trigger the data collection portions of the GDPR.

Post reply on HN