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

Riot Games Approach to Anti-Cheat

engineering.riotgames.com

Post reply on HN
Print view View original

321–330 of 412 posts

Re: Riot Games Approach to Anti-Cheat

#321

Post by s_m_t »

m3rc wrote: post #292
s_m_t wrote: post #254

Earlier quoted context omitted.

I don't think it is really the cheaters that degrade the experience, it is the knowledge (right or wrong) that cheaters exist that reduces trust that makes for not fun experiences. I've played online games for many thousands of hours over the past two decades and I can count the number of times I encountered a blatant cheater on my hands. Every time it actually happened people had a good laugh about it and either hop…

Wait, what? Why would allowing cheaters to run rampant mean people accused others of cheating LESS?

Sorry, in "if cheaters are allowed to completely run rampant this isn't the case." I meant "the case" as something like "the perception of cheating is more damaging than the actual cheating". Poorly written on my part.

Re: Riot Games Approach to Anti-Cheat

#322

Post by jonjojr »

lucb1e wrote: post #190
jonjojr wrote: post #99

Use blockchain. It is a very simplified comment, but behind that you can expand the topic to include many advantage a blockchain can provide during multiplayer games. EDIT: yes it is a very unpopular topic, but deep down many of you who are developers, know that blockchain can solve many of these issues with cheater.dll

Reason for downvote: you seem to have no clue about blockchain or cheater.dll whatsoever.

Blockchain is all I work on and you seem to not understand my suggestion.

cheater.dll needs to be loaded in memory along with the game. Correct, right? If the original build of the game has already generated an encryption key that is stored on a server or a distributed ledger using your account, then tampering with the origonal build in memory will result in generating and invalod key thus changing the ledger or the stored key on the server, and not matching the ledger. If this happens then it invalidates your build and the distributed ledger would need to updated, but since that is not allowed in this instance all ledgers would reject your change and flag the block and the account. Making it easier to find who attempted a change. Sure this can be done on a server but because of the tamper proof inherited by a distributed ledger it would make it harder for this code to be shared. The cheater can still change the code but it would not be able to share it.

Re: Riot Games Approach to Anti-Cheat

#324

Post by BenjiWiebe »

jonjojr wrote: post #322
lucb1e wrote: post #190

Earlier quoted context omitted.

Reason for downvote: you seem to have no clue about blockchain or cheater.dll whatsoever.

Blockchain is all I work on and you seem to not understand my suggestion. cheater.dll needs to be loaded in memory along with the game. Correct, right? If the original build of the game has already generated an encryption key that is stored on a server or a distributed ledger using your account, then tampering with the origonal build in memory will result in generating and invalod key thus changing the ledger or the…

How would it invalidate the build? How would the server find out the build was tampered with? Why would my hacked game add anything to a blockchain? I've followed blockchain tech closely since '13 and your comment makes no sense.

Re: Riot Games Approach to Anti-Cheat

#325

Post by matheusmoreira »

Teknoman117 wrote: post #317

I have mixed feelings about anti-cheat, especially in the last few years. A lot of them are getting rather intrusive. Take Player Unknown's Battlegrounds for instance, which uses BattlEye. It actually injects a kernel mode driver into Windows that spies on whatever else your system is doing and exfiltrates unknown data in the name of "guaranteeing a fair game experience." I didn't even realize that this is what it wa…

I agree with everything you say. It's ironic because game companies themselves use virtual machines with obfuscated instruction sets in their games as a copy protection mechanism. It's pretty hard to feel any sympathy for them once hackers get around their pathetic countermeasures.

To add to your post, here's an example of why game developers can't be trusted to run code in kernel mode:

https://mobile.twitter.com/TheWack0lian/status/7793978407622...

Re: Riot Games Approach to Anti-Cheat

#326

Post by meowface »

rmrfrmrf wrote: post #296

These are all just various degrees of obfuscation that will be defeated if it's worth the money. In particular these approaches seem weak to hardware, firmware, and driver side-channels.

All anti-cheating techniques are fallible. It's impossible to build a perfect cheat detection/prevention, just like it's impossible to build something that will always detect all malware, etc. The client code is always going to be on the player's computer and has to execute on the player's computer. There's no way around that.

You can't guarantee effectiveness, but you can make it very hard to reverse engineer and circumvent, and you can constantly change techniques so that adversaries need to put in more work. It's an ever-evolving cat-and-mouse game.

Re: Riot Games Approach to Anti-Cheat

#327

Post by matheusmoreira »

RussianCow wrote: post #191
bitexploder wrote: post #166

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 value gained from cheating in a video game is low enough

Many people made serious money botting MMORPGs and selling gold. It's so prevalent it accelerates the inflation of the in-game currency.

If people make it too difficult to hook into the client, cheat developers can always reverse engineer the network protocol and make their own custom client. This bypasses all client-side annoyances. They might even create a headless client that can be run on servers.

Re: Riot Games Approach to Anti-Cheat

#328

Post by matheusmoreira »

jonjojr wrote: post #135
bitexploder wrote: post #118

Earlier quoted context omitted.

If you restrict the machine code it makes it that much easier for me to write an emulator to execute your machine code and return the result. It might even be trivial. It is a never ending Ouroboros. You build a more clever mouse trap, I will design a more clever mouse. 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…

"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…

A server can't validate the integrity of the game remotely. A program on the user's computer must do that for you. You're trusting that the program will do what you expect it to do.

All one needs to do is modify the program to make it always tell your server the build is valid. Problem solved.

Re: Riot Games Approach to Anti-Cheat

#329

Post by jrockway »

I am surprised people don't virtualize the game and do their analysis at a level that the OS and game can't detect. Ultimately, these games trust that the hardware they're running on behaves according to specification. That is clearly an unwise assumption. Cheaters may not be taking this path today, but it gets easier and easier as time goes on, and it sounds like they're not prepared at all. (Some other comments mention that current games look for virtualization software installed on the same OS install that the game is running on and fails the integrity check if found. I can't imagine that stops anyone actually determined to cheat. I imagine it annoys people that test their Docker images on the same machine they play the game on, though.)

Even if virtualization is detectable, you can also take the computer entirely out of the loop. The state of the art for aimbots seems to be reading game memory and applying synthetic mouse movements at the OS level. That is quite a blunt instrument to apply and I'm sure that no game has a major problem with this kind of aimbot. A more elegant aimbot would look at the video of the game, look for targets, and provide the necessary mouse movements over USB. At best, the only countermeasure is to make enemies harder to see or to learn some heuristic in mouse movement that differentiates the bot from a human... but injecting randomness is straightforward and nobody needs a 100% accurate aimbot anyway. The pros destroy you with 30% accuracy.

Finally, it's unclear if there is even any advantage to be gained by cheating. If you want a higher rank in a competitive game, you can just pay someone to play on your account. From what I've read on Reddit... many of the people offering these services are apparently professional players. No anti-debugger hook is going to detect that.

It should be interesting to see how this advances. While games that rely solely on mechanics or information hiding are clearly doomed in the long run, it's probably good news for the rest of the software industry. What is your cloud provider really doing? Is your own software compromised? The tools used to cheat in games will be quite valuable in answering these questions and protecting your users from people that actually have something tangible to gain from these actions.

Re: Riot Games Approach to Anti-Cheat

#330

Post by sdoering »

civilitty wrote: post #240
mikekchar wrote: post #230

Earlier quoted context omitted.

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 per…

Exactly this. The moment you send it via IP you have the IP address and therefore have PII data. And the moment you take screenshots you cannot not be sure what you collected.

This does go further beyond GDPR as it is imho an intrusion into the inner most personal space. I believe a German court of law would have a field day ripping this practice apart, if a case would be presented.

Esp. if they do not totally make it clear upfront what they are doing. In a way every layman is able to understand.

Post reply on HN