Kudos for transparency. On the other hand it reads the same as any other breach press statement I've read. It seems to be clearly carved to not include a single bit more information than necessary(undeniable).
Wish these were written by security people instead of a PR/Compliance/legal taskforce.
They did say they'll have a full report with more technical details forthcoming. Having been involved in a few incidents which had substantial public post-mortems, they need to go through a LOT of revision and approvals. They generally take more than a week to release, especially when they have security implications.
The timeline of events might explain why they're proceeding with caution. Last Wednesday, 46 people were let go[1]; that Friday, Riot tweets that their development systems were compromised "earlier in the week." Insider job, perhaps? I wonder.
> Wish these were written by security people instead of a PR/Compliance/legal taskforce.
Additional transparency is always better for the consumer. However, one must ask - what would that achieve for the business? Providing technical details may open them up to additional scrutiny from the general public, and potentially regulatory bodies.
Another additional risk is that the more information disclosured, the harder it is to control the narrative. As someone who used to work in reputation management, ensuring a cohesive and correct narrative in mainstream & social media is an essential component of reputation damage control.
IIRC the source code for League's engine is originally licensed and derived from a shovelware racing game. Presumably it was rebuilt from scratch, but who knows.
Do you have any more details? If they licensed an engine, a racing game’s engine seems like a bad fit.
All Wikipedia says is: “A demonstration of League of Legends built in the Warcraft III game engine was completed in four months and then shown at the 2007 Game Developers Conference.”
Haven't seen the code but it's almost certainly C++. The next option would be C#, but it's not a Unity game so that's unlikely.
Maybe Java is used in some backend services here and there, but almost certainly not for the game client, and I'd be very surprised if the game server is written in Java.
I wonder if it started life as a DotA fork. Guinsoo was the DotA developer who originally recruited Icefrog, and as far as I know has been working at Riot on League since day 1.
With a project that big with random features bolted on for 15 years, I bet it's the typical giant hairball of 'legacy code' every coder loves to complain about ;)
They mentioned "legacy anticheat system" so it seems unlikely. Given that the source code for that internally is probably much more guarded, smaller specialized team, I would be surprised if it got included.
ICYMI Riot makes players install a kernel-level driver to play games, so we might be witnessing the start of a once-in-a-decade cybersecurity Chernobyl.
If the lasting tragedy of Chernobyl was the curtailment of nuclear power in favour of burning hydrocarbons, then will the victim of Cheriotnobyo be thsy society turns against MOBAs?
This is why I begrudgingly had to build a separate PC for nothing but gaming. Furious that it is the only way to firewall the cowboy coding what-is-security development practices of the industry.
If the drives live in the same host system, they should be mountable by the other OS. The untrusted gaming partition/drive could then manipulate the trusted one.
In practice, that would require the malware to be specifically targeted to dual-booters (representing a tiny fraction of users). Much better to go after the millions of Windows gaming PCs that also host the entirely of someone’s digital life. Which is to say the physical separation likely buys me little real security, but it does make me feel better.
You should be encrypting your secure drive so stuff like this doesn't happen. Also so burglars can't grab your physical disk, put it in their machine, and read all your files. When installing most distros, they give you a checkbox to enable LUKS.
The untrusted OS could ransomware encrypt the already-encrypted trusted one. The attacker is denied access to my SSH keys, but so am I.
Fully willing to confess this feels an outsized threat model, but it is something. Going forward, this separation will allow me to undersize my next linux workstation which requires far more modest hardware if never running games.
At this point, it's up to the user to make that trade-off, but most of the players don't have enough information to make that decision.
Sure, I wouldn't want any cheaters on my games, but these systems are not fool-proof and cannot circumvent every single cheater out there.
Dedicated enough cheaters are getting what they want anyway, while the unknowing user is left with a backdoor on their systems (in the event of a compromise)
The goal isn’t to stop every cheater, the goal is to reduce the number of cheaters. They achieve this by making the monetary cost of cheating so high that it doesn’t happen often enough to affect the vast majority of players. “Private cheats” are expensive, “public cheats” get killed off quickly, pushing up the cost of “private cheats”.
None of this was as big a problem twenty years ago, despite cheats being easier to make. We had community run servers with occasional admin presence. All you need is an IP and username based banlist. I don't care if occasionally an admin is a power hungry 12 year old, I can just go next door.
Detecting superphysiological maneuvers is probably a trivial way to do this, for certain gameplay scenarios. There's established limits on reaction time, for example, it's just a matter of differentiating between reaction and preemption which converge at the highest echelons.
There are limits on the reaction time, but you can own all humans by consistently hitting close to that limit and achieving useful things when you do. Adding a bit of delay to all bots would not make them useless.
Cheating is a lot more sophisticated than the simple aimbots you're thinking of. A lot of cheats focus on giving the player extra information. In the context of big money online tournaments this motivates some pretty extreme behavior, like folks running a PCI card set up to access memory directly and find the game state for player positions, then indicate that to the player somehow. This defeats even kernel level anti-cheat.
Well supposedly Riot’s server side interest management was supposed to solve this, perhaps by ray casting to the subjects’ bounding box. But I’m aware that wall hacks do get made for Valorant so it would appear that’s not the case. Which is understandable given the difficulty of juggling peeker’s advantage.
> A lot of cheats focus on giving the player extra information.
Why are clients being sent that extra data in the first place? The server should track players and only push the information each player should have to that player's client. No need to hand every player the locations of other players when they're across the map and behind several walls.
Even with no extra data at all, at a certain point they're going to run into the analog hole. Cheaters will be able to point a camera at their screen and have it connected to their mouse/keyboard (real or not) so they can send inputs with speeds beyond what a human is capable of. Maybe it's not feasible to stop every cheater on Earth and the whole concept is incurably broken. There's always the option of letting people host their own servers to play with friends and other people they trust to play the game fairly. It's a hell of a lot more fun to play with people you know anyway. Tournaments can be done in person on dedicated trusted hardware under direct observation.
> Why are clients being sent that extra data in the first place?
Performance reasons, usually. Easier to draw an enemy on the screen (and figure out occlusion, etc) than have the enemy pop in from nowhere due to lag. Also prevents lag (or netspeed in the UT days) hacking (used to be a thing, not anymore).
> Why are clients being sent that extra data in the first place?
Because FPS games don't run in lockstep. They run in server ticks, which the client interpolates or even extrapolates with prediction for smoothness. This means the server has to send player positions a bit earlier than they would be visible via strict occlusion culling.
If you tried to run FPS in lockstep it's atrocious. This is literally why John Carmack originally implemented client side prediction for QuakeWorld. Do you think he was just too stupid to do the obvious simple correct thing? Or maybe the problem is actually a bit more complicated?
Again, hnews is anchoring on aimbots when that's by far the least interesting way to cheat.
> Do you think he was just too stupid to do the obvious simple correct thing? Or maybe the problem is actually a bit more complicated?
No, but both hardware and software have changed dramatically since the 1990s. We even have cloud gaming services that run games remotely with very little being done on local hardware. They do currently over-promise when it comes to performance, but it's not unthinkable that we're at (or soon will be at) a point where games don't have to depend as much on the random PC at the player's end of the connection even though that's the way things have always been done.
Latency is still relatively high in LOTS of areas around the world. Not high enough to make online FPS games unplayable, but high enough to make sending packets in lockstep unplayable. Discriminating against those people wouldn't be fair (especially since they're not a particularly small minority).
It's even worse than that. Corner peeking is absolutely key in FPS games, and a laggy player can actually gain an advantage if there's pop in or rubber banding artifacts. It's like they teleport around the corner.
I always thought this was a super interesting problem, because you're balancing a bunch of stuff - emergent behavior, latency, and server load.
Latency is the obvious one - you have to be able to tell not only if a client can see another client, but whether they might be able to see each other in, say, 500ms. That's pretty hard and computationally intensive, at-least compared to just checking whether bounding boxes have line-of-sight.
Where things get interesting is when we come to emergent behavior tied to rendering. A good example is shadows - you can have no LOS to a player, and not be in a position where you could get LOS quickly, but be able to see their shadow. So your client needs to know where the other player is so the shadow can be rendered correctly. Sound is also hard, and forces you to balance server load and client trust. Lets say someone really far away takes a step that's audible within 10m. You can't hear that, but the server would have to check distance against every player to confirm that. If you have a directional sound system (where sounds from inside a room will originate from the doorway for those outside) it's even harder, as the server is having to calculate the shortest path not blocked by the enviroment. Even if you do all this, you're still screwed - since when you determine the dishonest player can hear something so you tell their client client to play a sound, you have to send them the coordinates of the origin, so you're telling them where the other player is anyways!
You can get rid of causal cheaters by having a secure boot all the way to the game. This would make it so people would have to use hardware cheats if they wanted to cheat.
From the perspective of a server-sided anticheat as client side exists as a barrier to entry so it must be intrusive to work. I know of non-cheat devs who have bypassed Vanguard accidentally while implementing low level windows stuff.
No, this isn't possible. There will always be purely client sided cheats that don't touch anything sent to the server. For example, seeing enemies through walls gives a huge advantage but isn't detectable. This can be mitigated only sending entities the client can see, but latency makes it so you can't fully stop this.
You can also attack latency which doesn't directly affect protocol. Rewind enemies slightly forwards or backwards in shooters so you land the shot when you aim slightly off. These cheats exist in CSGO.
However, an anticheat's job is to prevent other players from noticing you cheating rather than to prevent cheating. This key distinction does let you simply ignore a lot of purely client side cheats as insignificant.
You also can't do much about aimassists that slightly correct aiming. Machine learning can help here but falls apart quite fast when humans are covering up the machine's aiming patterns. Algorithmic inputs and random human inputs still result in random-ish human inputs.
Yeah, it's called plug your mouse and keyboard into a game console - on a more serious note, a realistic idea for serious gamers who care about the sovereignty of their P.C. buy a completely corporate anti-cheat CPU that runs a separate system and uses GPU pass-through so you don't need to build an entire new rig.
The main issue, and this pervades computing, is that people don't care enough about owning their computers and controlling the software that runs on them.
I remember that back in my console days, COD MW2 on Xbox 360 was full of glitchers and cheaters. I don't think the situation on PC vs console is all that much different.
Console security has significantly improved since the Xbox 360 days. All the "trustable computing" stuff is heavily utilized there, and this is like the third time these companies have taken a swing at "Unhackable" consoles. There still isn't a way to exert control over a Switch that doesn't have the old backdoor.
The OS is already "intrusive" by that definition. What you described has a different issue though; my own computer letting some software run in some container that I can't touch is insane. That's Black Mirror kind of spooky and I hope it never becomes a reality.
That's clearly been the plan for quite some time with all the "trusted computing" rubbish. Online shopping or banking or playing games (or streaming DRM'd content) won't be allowed on hardware you actually control by like 2035 at the very latest, IMHO.
There’s probably a few metrics you could come up with. I’d be thinking about ways to quantify awareness, then comparing average awareness vs. some distribution near the players’ skill level.
Awareness would be like: average travel distance between combat engagements, % of time fully occluded players receive gaze from a player, etc.
If Microsoft succeeds with their full plan for "trusted computing" (project Palladium), they'll be able to do anti-cheat at the operating system level.
The basic idea is the BIOS verifies the kernel (secure boot), and the kernel verifies all running software. The hardware TPM chip signs a message from the kernel attesting that this has all happened using the on-device crypto signature embedded by the hardware vendor (eg ATI). So the signature is tamper-proof, even by the computer user. And all that can validated over the internet via remote attestation.
The message would presumably include the hash of the game's binary files, and the signature & hash of all loaded kernel modules. So yeah, hardware level, "unhackable" anti-cheat on commodity hardware.
I can't tell whether to be terrified or impressed with the audacity of the plan.
While the whole signature verification thing sounds water-tight in theory there are lots of holes still being patched so I don't buy it this will 'change everything'. Making everything tamper-proof could even prevent some holes from being closed.
The only tamper proof part is the hardware TPM. Everything else uses a chain-of-trust model based on signatures. Most of the complex work will be in windows; and that code can be updated just fine so long as updated versions of the kernel are digitally signed.
I’m sure there will be security holes early on. But the people pushing this stuff seem to be playing a long, patient game. I think they’re going to get what they want.
> I can't tell whether to be terrified or impressed
I recommend the former, since this is another nail (maybe the final one?) in the coffin of "personal computers", hastening their replacement by hypertelescreens or whatever. (A computer you don't own, but merely access.)
Now announcing ButlerCheat™, installing a live human supervisor into every home in the latest anti-cheat technology. Included now with its own refrigerator where you can store your snacks and drinks for those long gaming sessions.
> ...entire game code for League of Legends and its tools, as well as Packman, your usermode anti-cheat. We understand the significance of these artifacts and the impact their release to the public would have on your major titles, Valorant and League of Legends
Mate you are chastising him for not reading the article and you are contradicted by the first paragraph.
And in your own quote they stated it’s the user mode anticheat, and in Riot’s statement they said it’s an old/legacy anti cheat. This is not Vanguard, the kernel level anti cheat.
Code running in the kernel context is different than code running in the user context. Another process can modify user context, whereas it is expected that code running in the kernel context is "much harder".
A dedicated attacker could write kernel code which does the modifications, however this raises the bar and the anti cheat software could the game from running if it detects any unsigned drivers.
All this does is raise the bar to where the game is run into virtualization where the host OS can inspect the guests memory and infer details that way. The cat and mouse game goes on forever, the trick is to make it just hard enough so that the average person who wants to cheat will not not have the time, patience or financial incentive to do so.
You're quoting something from Valorant, not League of Legends. They use two different anti-cheat systems.
As a person who actually plays the game on a M1 Pro MacBook running in x86 emulation, which is not supported by kernel mode drivers, I can tell you with absolute certainty (unless of course Riot has found an exploit that allows installation of unsigned system drivers), that my computer has no non-apple drivers installed.
I know people have strong prefs for/against different styles, but please post alternative links in the comments and keep the top-level URL for the canonical source.
This is in the site guidelines ("Please submit the original source. If a post reports on something found on another site, submit the latter." - https://news.ycombinator.com/newsguidelines.html).
The vice article[0] seems more substantial than the twittering (although it does reference these tweets it also includes a copy the ransom demand and the lack of reply from riot)
When the TF2 code was leaked, it resulted in new vectors of attack on the servers being found and the development of bots that are still ruining the game.
Imagine if you could simply deploy an army of fuzzers on a piece of code, vs what could be derived from client side probing. Yes, having access to the source is a problem.
Which wouldn't have been an issue for too long if Valve was still maintaining TF2. For a game still being maintained and developed like LoL, a new vector of attack would probably only last for a few days before it is patched or mitigated.
What's interesting is the very specific sum they are asking for. I wonder how they arrived at that sum. Although it is a good question, how do you value the src for a multimillion dollar game?
Honestly, what would happen if a company like Riot Games would just release their source code? As far as I can see, perhaps the two most relevant "risks" are the following:
1. Competition: now your competitors know exactly how to program a game like League of Legends. Well, guess what: they already knew that before.
2. Attack vectors: if your game's security relies on the code not being available, that basically boils down to "security by obscurity".
I don't quite get from the vice.com link whether the assets were also stolen but I understand that there's probably more value in them than in the code.
I guess one risk is that they see a copy pasted chunk of GPL code. Or that a portion looks suspiciously like something a former Dev wrote for you before moving to riot.
Worse still a bunch of competitors suddenly have insight into prospective future features.
I'm sure the source code is part of the company's net worth should things go tits up.
Yeah, that's definitely a risk for any company. If a competitor gets their hands on their code, it could be a major setback for them. And if someone sees a copy-pasted chunk of GPL code, it could lead to legal trouble. But, the real problem is that it's hard to put a number on the potential losses. A leak could lead to all sorts of unforeseen consequences that can't even be predicted. The best thing a company can do is invest in protecting their source code. It's not just a line item on a balance sheet, it's a crucial part of a company's net worth.
The idea that "security through obscurity is not security" is a dumb meme that needs to die. In the real world security through obscurity is absolutely security. Your threat model is not super hackers with unlimited resources, obscurity helps, in some cases it helps a LOT.
(to be clear I'm responding specifically to your second point, I believe RIOT is institutionally incompetent and it is fully possible to have a game with an open source core that has less cheating than LoL, I also believe that the folks at RIOT are incapable of such a thing because of a combination of bad incentives and incompetence)
>Your threat model is not super hackers with unlimited resources, obscurity helps, in some cases it helps a LOT.
You don’t know who is going to try to hack the system, and the security strategy should handle the fact that the system is going to be compromised at some point. Otherwise you don’t have a security policy, but simply a more or less efficient palliative to fear that risks generates.
Yes, if you know who is going to have a will to attack, in which timeframe and with which resources at hand, security by obscurity surely can help a lot. Otherwise this is just buying the comfort of delusion, in my humble opinion.
> Otherwise this is just buying the comfort of delusion
The same goes for any other security "guarantee". Security isn't something you rely on, it's a constant fight, obscurity is a reasonable thing to have in your arsenal. If you're at some point claiming "this is secure" you're deluding yourself, the only reasonable claim is "we have a lot of barriers to being compromised" or perhaps "we are secure against this vector", if obscurity is one of those barriers that's real and it provides a tangible benefit. Penetration is stochastic, the measures you take to prevent it change the odds.
Yep. Too often people fall into a binary way of thinking - it's either perfectly secure, or not secure at all. It's like that bell curve meme with the dunce at one end ("we should obscure our system"), the midwit at the peak ("security through obscurity is not security"), and the genius at the right ("we should obscure our system").
Obscurity *by itself* is a poor security measure, but it can decrease the surface area for automated attacks substantially. A determined human can figure them out eventually, but if their bot never sees you in the first place, the human might never even attempt the attack.
Obscurity is not a bulletproof shield, it's another layer of Swiss cheese.
Security is only partly about the threat model. The other part is the failure mode. If your failure mode is “our company goes out of business if our code ever leaks out” then you’re probably too heavily invested in security by obscurity.
The argument that security through obscurity isn't security is that when it is open there are more eyes that can see security flaws within the code and get it fixed vs. just the people attempting to exploit it. Not having access to the source might obscure potential vectors from attackers, but at the same time, those vectors might be fairly discoverable without the code, or they might be quickly fixed if more people were looking at the code.
I don't think anyone in this comment thread has the data to truly argue one way or the other. The open source world is obviously the easiest example here - there have certainly been plenty of exploits that people started using in the wild before any of the "Good Guys" caught it. But there's also been huge numbers of security bugs quietly fixed because some random person saw it and contributed a fix. And plenty of the highest visibility exploits over the past decade have been found by security researchers unrelated to the projects utilizing the open source code was part of their toolkit in finding issues. If it was closed source, would the "Good Guys" have found it before the "Bad Guys"? Who knows!
You'd need to actually compile and analyze all this data to have a strong argument that isn't just people going off of what sounds the most logical to them, and there's also all sorts of confounding factors that would need to be accounted for, like value of the potential target, overall popularity of the codebase, etc.
In games obscurity isn't really a thing. They are prime targets for memory scanning and getting extremely accurate results.
Here's how to build a simple "bot" for any game in about 30 seconds.
Step 1, Scan memory for Hp using a tool like cheat engine.
Step 2. Since you know simple C programming, you know HP is kept in a structure, most likely the player structure. Look at surrounding memory and you'll have something like this.
Step 3. Now you have a basic structure, how do you find what uses it? Well, you know what a getter setter is from your CS 101 class. So you set a HW breakpoint on Read for the hp, and a HW Breakpoint on Write for the hp. Now you have GetHp(); And SetHp();
Step 4. You also remember how linkers work from your Compilers class, so knowing this, just like the structure has similar variables in memory, the binary will also have similar functions next to eachother(Or you can use class/variable passing from your struct.). So Right below GetHp, is 99 % of the time going to be GetMana.
Step 5. Now you have your structures, and know what functions use it, so find the global variable or scrape how these functions get the address to update.
Step 6. Repeat for other players using exact same steps, congrats, you now have all you need for a wallhack, bot, or whatever you want.
So as we can see, no code is needed, no big brain hacks are needed. A cs 101 student can do this(And alot do, this is why cheats are filled with skids). And it's all done through super simple dynamic analysis. Games are different, since in a regular application, you won't be able to memory scan as easily.
Here's a #3: It would probably make running LoL private servers much easier. Riot has been extremely aggressive with shutting down private servers (of old versions of the game that people want to be allowed to play, but cannot).
It's ridiculous that source code leaks happen so frequently. Even if it's inevitable to a certain degree, it sometimes seems like companies aren't doing enough to protect it. It's a shame that valuable company assets like source code can be so easily compromised.
161 comments
[ 2.8 ms ] story [ 229 ms ] threadWish these were written by security people instead of a PR/Compliance/legal taskforce.
[1] https://www.eurogamer.net/riot-games-reportedly-making-layof...
Additional transparency is always better for the consumer. However, one must ask - what would that achieve for the business? Providing technical details may open them up to additional scrutiny from the general public, and potentially regulatory bodies.
Another additional risk is that the more information disclosured, the harder it is to control the narrative. As someone who used to work in reputation management, ensuring a cohesive and correct narrative in mainstream & social media is an essential component of reputation damage control.
It's an geeky in-joke from the old Warcraft3 DotA and early LoL days. Please don't murder me.
https://www.reddit.com/r/dotamasterrace/comments/4pozfx/can_...
You need some abstraction to represent "a thing in the world" and usually a way to say if a thing is subordinate to another thing.
Minon, GameObject, Actor, Item, etc., are all solving the same problem.
I experienced less distress when discovering Santa wasn't real.
more seriously, resources explaining why and how not to do this:
CppCon 2014 Mike Acton Data Oriented Design and C++ https://www.youtube.com/watch?v=92KFSD3ObrY
Richard Fabian's book: https://www.dataorienteddesign.com/dodbook/
Handmade Seattle 2021 Andrew Kelley A Practical Guide to Applying Data-Oriented Design https://media.handmade-seattle.com/practical-data-oriented-d...
No, they made a big deal about rewriting the code a few years back to help make things more stable, easier to maintain, and easier to expand.
All Wikipedia says is: “A demonstration of League of Legends built in the Warcraft III game engine was completed in four months and then shown at the 2007 Game Developers Conference.”
Maybe Java is used in some backend services here and there, but almost certainly not for the game client, and I'd be very surprised if the game server is written in Java.
https://news.ycombinator.com/item?id=22855600
In practice, that would require the malware to be specifically targeted to dual-booters (representing a tiny fraction of users). Much better to go after the millions of Windows gaming PCs that also host the entirely of someone’s digital life. Which is to say the physical separation likely buys me little real security, but it does make me feel better.
Again, talking low likelihood that dual booters are a worthwhile target. Much more available low hanging fruit.
https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup
Fully willing to confess this feels an outsized threat model, but it is something. Going forward, this separation will allow me to undersize my next linux workstation which requires far more modest hardware if never running games.
Sure, I wouldn't want any cheaters on my games, but these systems are not fool-proof and cannot circumvent every single cheater out there.
Dedicated enough cheaters are getting what they want anyway, while the unknowing user is left with a backdoor on their systems (in the event of a compromise)
If you reduce amount of cheaters from 1000 to 10, then it's still huge win for the player base and average player's experience
Why are clients being sent that extra data in the first place? The server should track players and only push the information each player should have to that player's client. No need to hand every player the locations of other players when they're across the map and behind several walls.
Even with no extra data at all, at a certain point they're going to run into the analog hole. Cheaters will be able to point a camera at their screen and have it connected to their mouse/keyboard (real or not) so they can send inputs with speeds beyond what a human is capable of. Maybe it's not feasible to stop every cheater on Earth and the whole concept is incurably broken. There's always the option of letting people host their own servers to play with friends and other people they trust to play the game fairly. It's a hell of a lot more fun to play with people you know anyway. Tournaments can be done in person on dedicated trusted hardware under direct observation.
Performance reasons, usually. Easier to draw an enemy on the screen (and figure out occlusion, etc) than have the enemy pop in from nowhere due to lag. Also prevents lag (or netspeed in the UT days) hacking (used to be a thing, not anymore).
Because FPS games don't run in lockstep. They run in server ticks, which the client interpolates or even extrapolates with prediction for smoothness. This means the server has to send player positions a bit earlier than they would be visible via strict occlusion culling.
If you tried to run FPS in lockstep it's atrocious. This is literally why John Carmack originally implemented client side prediction for QuakeWorld. Do you think he was just too stupid to do the obvious simple correct thing? Or maybe the problem is actually a bit more complicated?
Again, hnews is anchoring on aimbots when that's by far the least interesting way to cheat.
No, but both hardware and software have changed dramatically since the 1990s. We even have cloud gaming services that run games remotely with very little being done on local hardware. They do currently over-promise when it comes to performance, but it's not unthinkable that we're at (or soon will be at) a point where games don't have to depend as much on the random PC at the player's end of the connection even though that's the way things have always been done.
Latency is the obvious one - you have to be able to tell not only if a client can see another client, but whether they might be able to see each other in, say, 500ms. That's pretty hard and computationally intensive, at-least compared to just checking whether bounding boxes have line-of-sight.
Where things get interesting is when we come to emergent behavior tied to rendering. A good example is shadows - you can have no LOS to a player, and not be in a position where you could get LOS quickly, but be able to see their shadow. So your client needs to know where the other player is so the shadow can be rendered correctly. Sound is also hard, and forces you to balance server load and client trust. Lets say someone really far away takes a step that's audible within 10m. You can't hear that, but the server would have to check distance against every player to confirm that. If you have a directional sound system (where sounds from inside a room will originate from the doorway for those outside) it's even harder, as the server is having to calculate the shortest path not blocked by the enviroment. Even if you do all this, you're still screwed - since when you determine the dishonest player can hear something so you tell their client client to play a sound, you have to send them the coordinates of the origin, so you're telling them where the other player is anyways!
- Server-side actor occlusion.
- Server-side physics with client-side prediction that's been in use since 1996.
No, this isn't possible. There will always be purely client sided cheats that don't touch anything sent to the server. For example, seeing enemies through walls gives a huge advantage but isn't detectable. This can be mitigated only sending entities the client can see, but latency makes it so you can't fully stop this.
You can also attack latency which doesn't directly affect protocol. Rewind enemies slightly forwards or backwards in shooters so you land the shot when you aim slightly off. These cheats exist in CSGO.
However, an anticheat's job is to prevent other players from noticing you cheating rather than to prevent cheating. This key distinction does let you simply ignore a lot of purely client side cheats as insignificant.
You also can't do much about aimassists that slightly correct aiming. Machine learning can help here but falls apart quite fast when humans are covering up the machine's aiming patterns. Algorithmic inputs and random human inputs still result in random-ish human inputs.
The main issue, and this pervades computing, is that people don't care enough about owning their computers and controlling the software that runs on them.
Then it is just OS being intrusive...
Awareness would be like: average travel distance between combat engagements, % of time fully occluded players receive gaze from a player, etc.
The basic idea is the BIOS verifies the kernel (secure boot), and the kernel verifies all running software. The hardware TPM chip signs a message from the kernel attesting that this has all happened using the on-device crypto signature embedded by the hardware vendor (eg ATI). So the signature is tamper-proof, even by the computer user. And all that can validated over the internet via remote attestation.
The message would presumably include the hash of the game's binary files, and the signature & hash of all loaded kernel modules. So yeah, hardware level, "unhackable" anti-cheat on commodity hardware.
I can't tell whether to be terrified or impressed with the audacity of the plan.
https://en.wikipedia.org/wiki/Next-Generation_Secure_Computi...
I’m sure there will be security holes early on. But the people pushing this stuff seem to be playing a long, patient game. I think they’re going to get what they want.
I recommend the former, since this is another nail (maybe the final one?) in the coffin of "personal computers", hastening their replacement by hypertelescreens or whatever. (A computer you don't own, but merely access.)
That's about as feasible as making a perpetual motion machine.
Mate you are chastising him for not reading the article and you are contradicted by the first paragraph.
Code running in the kernel context is different than code running in the user context. Another process can modify user context, whereas it is expected that code running in the kernel context is "much harder".
A dedicated attacker could write kernel code which does the modifications, however this raises the bar and the anti cheat software could the game from running if it detects any unsigned drivers.
All this does is raise the bar to where the game is run into virtualization where the host OS can inspect the guests memory and infer details that way. The cat and mouse game goes on forever, the trick is to make it just hard enough so that the average person who wants to cheat will not not have the time, patience or financial incentive to do so.
As a person who actually plays the game on a M1 Pro MacBook running in x86 emulation, which is not supported by kernel mode drivers, I can tell you with absolute certainty (unless of course Riot has found an exploit that allows installation of unsigned system drivers), that my computer has no non-apple drivers installed.
That's the anti-cheat which only Valorant uses
// because Sylas
Granted that their motivations are purely financial, they would try to sell first. And if it's not worth anything, they'd release it then.
I know people have strong prefs for/against different styles, but please post alternative links in the comments and keep the top-level URL for the canonical source.
This is in the site guidelines ("Please submit the original source. If a post reports on something found on another site, submit the latter." - https://news.ycombinator.com/newsguidelines.html).
[0]: https://www.vice.com/en/article/qjky8d/hackers-demand-dollar...
For example: https://www.reddit.com/r/tf2/comments/rbpyh0/this_happened_w...
1. Competition: now your competitors know exactly how to program a game like League of Legends. Well, guess what: they already knew that before.
2. Attack vectors: if your game's security relies on the code not being available, that basically boils down to "security by obscurity".
I don't quite get from the vice.com link whether the assets were also stolen but I understand that there's probably more value in them than in the code.
Worse still a bunch of competitors suddenly have insight into prospective future features.
I'm sure the source code is part of the company's net worth should things go tits up.
(to be clear I'm responding specifically to your second point, I believe RIOT is institutionally incompetent and it is fully possible to have a game with an open source core that has less cheating than LoL, I also believe that the folks at RIOT are incapable of such a thing because of a combination of bad incentives and incompetence)
You don’t know who is going to try to hack the system, and the security strategy should handle the fact that the system is going to be compromised at some point. Otherwise you don’t have a security policy, but simply a more or less efficient palliative to fear that risks generates.
Yes, if you know who is going to have a will to attack, in which timeframe and with which resources at hand, security by obscurity surely can help a lot. Otherwise this is just buying the comfort of delusion, in my humble opinion.
The same goes for any other security "guarantee". Security isn't something you rely on, it's a constant fight, obscurity is a reasonable thing to have in your arsenal. If you're at some point claiming "this is secure" you're deluding yourself, the only reasonable claim is "we have a lot of barriers to being compromised" or perhaps "we are secure against this vector", if obscurity is one of those barriers that's real and it provides a tangible benefit. Penetration is stochastic, the measures you take to prevent it change the odds.
Obscurity *by itself* is a poor security measure, but it can decrease the surface area for automated attacks substantially. A determined human can figure them out eventually, but if their bot never sees you in the first place, the human might never even attempt the attack.
Obscurity is not a bulletproof shield, it's another layer of Swiss cheese.
Then what is it? Script kiddies? I doubt that they are going to benefit from gaining access to a complex code base.
I don't think anyone in this comment thread has the data to truly argue one way or the other. The open source world is obviously the easiest example here - there have certainly been plenty of exploits that people started using in the wild before any of the "Good Guys" caught it. But there's also been huge numbers of security bugs quietly fixed because some random person saw it and contributed a fix. And plenty of the highest visibility exploits over the past decade have been found by security researchers unrelated to the projects utilizing the open source code was part of their toolkit in finding issues. If it was closed source, would the "Good Guys" have found it before the "Bad Guys"? Who knows!
You'd need to actually compile and analyze all this data to have a strong argument that isn't just people going off of what sounds the most logical to them, and there's also all sorts of confounding factors that would need to be accounted for, like value of the potential target, overall popularity of the codebase, etc.
There are plenty of historical examples of source code leaks leading to new attack vectors being discovered (e.g. TF2).
Here's how to build a simple "bot" for any game in about 30 seconds.
Step 1, Scan memory for Hp using a tool like cheat engine. Step 2. Since you know simple C programming, you know HP is kept in a structure, most likely the player structure. Look at surrounding memory and you'll have something like this.
struct LocalPlayer { INT32 CurHP; INT32 MaxHp; INT32 CurMana; INT32 MaxMana; Position Pos; }
Step 3. Now you have a basic structure, how do you find what uses it? Well, you know what a getter setter is from your CS 101 class. So you set a HW breakpoint on Read for the hp, and a HW Breakpoint on Write for the hp. Now you have GetHp(); And SetHp();
Step 4. You also remember how linkers work from your Compilers class, so knowing this, just like the structure has similar variables in memory, the binary will also have similar functions next to eachother(Or you can use class/variable passing from your struct.). So Right below GetHp, is 99 % of the time going to be GetMana.
Step 5. Now you have your structures, and know what functions use it, so find the global variable or scrape how these functions get the address to update.
Step 6. Repeat for other players using exact same steps, congrats, you now have all you need for a wallhack, bot, or whatever you want.
So as we can see, no code is needed, no big brain hacks are needed. A cs 101 student can do this(And alot do, this is why cheats are filled with skids). And it's all done through super simple dynamic analysis. Games are different, since in a regular application, you won't be able to memory scan as easily.