Hackers demand $10M from Riot Games to stop leak of ‘League of Legends’ code
vice.com
vice.com
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.
Wish 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.
// because Sylas
For example: https://www.reddit.com/r/tf2/comments/rbpyh0/this_happened_w...
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.
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.
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.
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.
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...