Live data from Hacker News

A Message About Vanguard From Our Security and Privacy Teams

riotgames.com

81–90 of 103 posts

Re: A Message About Vanguard From Our Security and Privacy Teams

#81
post #21
post #10

Earlier quoted context omitted.

> Years and years ago, I developed with a friend of mine a completely undetectable cheat for all games on the HL2 platform. > It involved a second computer, which man-in-the-middled all network data to the client computer. Out of interest, was there no transport level encryption to deal with here? Or did you need to do something special to capture keys on the client?

That heavy lifting wasnt done by myself so I unfortunately dont have a answer for you. This was around a decade ago however, so I would not be surprised if the traffic was unencrypted.

Source did not encrypt network traffic until DeepBlueSea released NetShark for CS:GO.

Now it uses ICE, a 64-bit block cipher from the DES era. The key is obtained from the Steam servers over the normal Steam encrypted channel.

Re: A Message About Vanguard From Our Security and Privacy Teams

#82

Potentially dumb question: how do cheats even work in a game like LOL? I understand aimbots in a FPS and how they can give a pure mechanical advantage, but the LOL equivalent isn’t obvious to me. Does the client have access to data that’s not supposed to be exposed to the player?

There are still aim bots in lol because there are aimed skill shots for most of the champions. Scripting is abilities is probably the main method of cheating though.

This anti cheat software is for their new game valorant which is a counter strike like shooter.

Re: A Message About Vanguard From Our Security and Privacy Teams

#83
post #65

Earlier quoted context omitted.

Most anti-cheats and some "DRM solutions" do not allow you to run inside a VM, trying to mask the fact you do might be enough to get banned. Even with PCI passthru you can't expect full performance (CPU is also still virtualized). It's much simpler to just have a second PC/laptop or dual-boot (less secure).

>or dual-boot (less secure). There shouldn't be any risks to that if your main OS is encrypted and the keys are sealed by a TPM.

The untrusted system could flash malicious firmware to a component with DMA (e.g. GPU VBIOS) to infect the second system.

Re: A Message About Vanguard From Our Security and Privacy Teams

#84
As someone who mainly deals with web services, this all seems really weird to me. I was told from very early on "never trust the client". There was a lot of emphasis on server-side validation; client-side validation was only ever for UX, e.g. highlighting the field in red instead of making the user submit the form first.

Reading through this, it seems the game development world is doing the exact opposite and pushing all the "security" measures to the client. Is that incorrect? If it's correct, does anybody have any idea why?

Re: A Message About Vanguard From Our Security and Privacy Teams

#85
post #17

Earlier quoted context omitted.

> unless you're running a dedicated PC for gaming That's the approach I've been taking for a long time now. If you don't, you will always a) have your fun ruined by trying to be security conscious b) in the end, most likely give in and allow things you really shouldn't allow on a trusted machine because otherwise you can't achieve your task (getting a game to run). So I have a game box, try to make sure that nothing…

My next gaming PC will run a Linux hypervisors and use PCI passthru to run Windows as a full-performance guest. Then if I need to use a web browser, I can switch to a Linux guest without interrupting the game.

Are you sure that you've researched this thoroughly and there would be no problems with that PCI thing (compatibility, unknown errors, performance regressions)?

Re: A Message About Vanguard From Our Security and Privacy Teams

#86
post #84

As someone who mainly deals with web services, this all seems really weird to me. I was told from very early on "never trust the client". There was a lot of emphasis on server-side validation; client-side validation was only ever for UX, e.g. highlighting the field in red instead of making the user submit the form first. Reading through this, it seems the game development world is doing the exact opposite and pushing…

You’re a bit out of your depth. Of course “trust the server” is preferred but many forms of cheats are purely client side. For example an aimbot that steadies your cursor on someone’s head or dodges automatically when a projectile is inbound. Maybe the client hijacks the UI to hide terrain and walls.

I’m not saying what valorant has done here is right, there are other things you can do. But you’re oversimplifying the problem.

Re: A Message About Vanguard From Our Security and Privacy Teams

#87
post #72
post #67

Earlier quoted context omitted.

So let me ask you a question then.. Do you feel the same way about Microsoft and Apple, and every other company that provides a hardware driver for a modern computer, and whether state governments (USA included) put pressure on them to let them advance their agenda by using back doors in their drivers or software? Why is Riot special in all this? What, in your view, makes them more likely to be so secretly and so dee…

Your argument boils down to, "If one country has access, then every country should have access." I don't agree with that. It's clear the US has backdoors. That doesn't mean it's wise to invite China to add backdoors as well.

I am not arguing anything, and would never say anything that ridiculous.

I just find it tedious and irrational to see people up in arms about this contrived and unlikely scenario (a video game company is going to spy on you - a random nobody - for a big bad foreign power), while not being up in arms about the much bigger and more likely vectors of compromise they are exposed to constantly (like your operating system or cell phone).

But of course protecting yourself from those possibilities would require real sacrifice and inconvenience, so let's not talk about it.

Re: A Message About Vanguard From Our Security and Privacy Teams

#88
post #84

As someone who mainly deals with web services, this all seems really weird to me. I was told from very early on "never trust the client". There was a lot of emphasis on server-side validation; client-side validation was only ever for UX, e.g. highlighting the field in red instead of making the user submit the form first. Reading through this, it seems the game development world is doing the exact opposite and pushing…

You’re a bit out of your depth. Of course “trust the server” is preferred but many forms of cheats are purely client side. For example an aimbot that steadies your cursor on someone’s head or dodges automatically when a projectile is inbound. Maybe the client hijacks the UI to hide terrain and walls. I’m not saying what valorant has done here is right, there are other things you can do. But you’re oversimplifying the…

I understand that but it feels like there's a lot of focus on client-side anti-cheat while cheats that should be trivially detected server-side still exist (like flying through the air in a game where that shouldn't be possible).

Plus, there seems to be a lot of focus on client-side anti-cheat when a lot of it could be addressed server-side:

> For example an aimbot that steadies your cursor on someone’s head or dodges automatically when a projectile is inbound.

This sounds like a similar problem to "like" fraud and things like that. Couldn't it be addressed by measuring the number of incidents? If someone is able to headshot or dodge at an abnormal/superhuman level, that can be detected server-side and the user banned (or flagged for human review).

> Maybe the client hijacks the UI to hide terrain and walls.

Someone mentioned a solution for this elsewhere in the thread: don't send positions of important resources to the client if it doesn't need them. Keep the client about as blind as the player.

And again, you should be able to detect this server-side. If somebody has an abnormally high kill-rate for enemies coming around a corner, flag them for review.

Re: A Message About Vanguard From Our Security and Privacy Teams

#89
post #87
post #72

Earlier quoted context omitted.

Your argument boils down to, "If one country has access, then every country should have access." I don't agree with that. It's clear the US has backdoors. That doesn't mean it's wise to invite China to add backdoors as well.

I am not arguing anything, and would never say anything that ridiculous. I just find it tedious and irrational to see people up in arms about this contrived and unlikely scenario (a video game company is going to spy on you - a random nobody - for a big bad foreign power), while not being up in arms about the much bigger and more likely vectors of compromise they are exposed to constantly (like your operating system…

You've thrown out two, new arguments:

1. "Nobody playing this game is important enough to be spied upon."

It might surprise you to learn that some people in the military, congress, the DoD, and even important individuals in significant companies play video games.

2. "Some vulnerabilities exist, therefore any new vulnerabilities should be ignored or not discussed."

All vulnerabilities should be considered, especially new ones that will affect 10s or 100s of millions of people. That's why we're discussing it. Since you find it tedious, you're free not to participate.

Re: A Message About Vanguard From Our Security and Privacy Teams

#90
post #88

Earlier quoted context omitted.

You’re a bit out of your depth. Of course “trust the server” is preferred but many forms of cheats are purely client side. For example an aimbot that steadies your cursor on someone’s head or dodges automatically when a projectile is inbound. Maybe the client hijacks the UI to hide terrain and walls. I’m not saying what valorant has done here is right, there are other things you can do. But you’re oversimplifying the…

I understand that but it feels like there's a lot of focus on client-side anti-cheat while cheats that should be trivially detected server-side still exist (like flying through the air in a game where that shouldn't be possible). Plus, there seems to be a lot of focus on client-side anti-cheat when a lot of it could be addressed server-side: > For example an aimbot that steadies your cursor on someone’s head or dodge…

Humans can and do in fact do all the things you suggest. False positives are generally to be avoided, and mitigations for reverse engineering are still required (anti debuggers, anti dll injection measures).

All the stuff mentioned like not sending positions of people who aren’t visible are typically already done, but sometimes the position is needed for reasons you don’t understand. Like some gameplay ability to suddenly see through walls, etc.

This thread just has a lot of backseat programming.

I think I would find your post a little less irksome if you approached it from a neutral questioning tone as opposed to “what about these obvious things every junior engineer learns” :/

Post reply on HN