Preventing artificial latency or "Lag Hacking" in multiplayer games

  • There is an attack that some people have dubbed "lag hacking", and its gaining popularity in multiplayer games. There are at-least two ways of creating artificial latency. One method of introducing artificial latency is using a lag switch, where the user intentionally disconnects their network cable. Another method is using a flood of syn or udp packets to cause controlled and predictable disruption in the game so that a player can gain an unfair advantage. Artificial latency attacks affect a large number of multiplayer games.

    Some game companies have been made aware of this attack by their users, but are ignoring this vulnerability because they don't have a solution. The tools to carry out this attack are simple to construct, readily available and easy to use. They will often spoof the source IP address to make the attack difficult to trace.

    So security.se, lets come up with a solution to this problem. But first lets talk a bit about game protocols. Online games commonly use UDP due to decreased latency and overhead, but this also increases the susceptibility to spoofing. Game protocols can use Latency Hiding to decrease the "perceived latency", but this may increase the impact of artificial lag. Multiplayer games often use a p2p architecture, for example Hydra: Peer-to-Peer architecture for games, and a peer is easy to flood. The Unreal network architecture is well documented, and is also vulnerable to this attack. (If there is another resource I should list, let me know!)

    I believe there is also the similarly related issue of lag switches, whereby a cheater can 'disconnect' their game for a a few seconds by literally disconnecting the cable along the line somewhere.

    I like the `lets come up with a solution to this problem`. That kind of thing doesn't get asked her often...and we have a lot of smart people. I hope it becomes a trend.

    Couldn't this simply be solved by establishing an acceptable number of packets per minute? Take starcraft 2 for example as I remember they had this problem. Each structure that was built would only need to transmit about N packets per minute, same with every unit currently in the game. The user however is a modifier of this and the best players can have an APM around 400 but maybe we'll say 1,000 for high intensity situations. So given the number of structures/units currently in the game and that modifier, there should be a maximum of X packets per second. Anything else is ignored.

    @D3C4FF good call, updated

    @Eric then legitimate traffic would be "drowned out".

    OK, well then what if each peer had a randomly generated seed which only it and the server know. Then each packet is sent with a sequence and a random number using that seed. If there are any "out of sync" issues, the server could then determine if and which peer is flooding by analyzing the last couple of packets each peer received. This may not prevent someone from ruining a game by doing this but it would prevent someone from cheating.

    @Eric. For a number of reasons I do not believe that solution will work. You cannot expect a player not to know the seeded random number on their own computer. And if you banned them, in free to play games, they can easily make a new account.

    @Rell3oT "You cannot expect a player not to know the seeded random number on their own computer." Mind explaining that in single negative form? From what it sounds like you're saying that you can expect the player to know his own seed which is absolutely fine. What you don't want is for your opponent(s) to know your seed. This is of course based on there being a central server which controls the player statistics and can be used as an arbitrator. As for them creating new accounts on free to play games, that's a whole other problem. I'm not even suggesting they get banned, just lose the game.

    I salute your intention of finding a real solution to a real problem. However, I don't except you to be very successful, no offense... DDOS is just the darndest thing and there is almost nothing you can do against it. Especially not if you are talking about DDOSing a private home computer.

    @fgysin I work as a penetration tester. I am the .001% of software developers that solve the most difficult security problems that others deem impossible. This would not be the most difficult problem I have solved and I already have a partial solution. Also, Thomas Pornin's answer is awesome.

    @Rell3oT The reason this doesn't get asked here often is because it isn't a good fit for the SE format. It will generate (and has already) a lot of debate and discussion, where SE looks to have questions which can be uniquely and definitively answered. This would be a good topic for chat though.

    @Iszi That is very true, but you would think a group of smart people might have a brainstorming session together once in a while about how to solve problems. I think it is in the nature of types of people who end up answering the questions on SE sites who also like to ask questions.

    @Rell3oT I don't disagree that this is a good discussion to have, I'm just saying it's not a good fit for the SE Q&A format. SE does have chat rooms for this sort of discussion, though. In fact, discussions like these, in chat, often *lead to* questions that *are* a good fit for the site.

    More of a question. Can the game server using and acceptable threshold (IT pro's step in), ping the clients ISP. Using acceptable tolerances, couldn't artificial lag be detectable? If this question should be addressed elsewhere my apology....

    Most of the answers below are incredibly naive.

  • I see two conceptual paths for dealing with lag attacks:

    1. Punish lags. When an "artificial" lag is detected, evict the offender and enforce a ban period. This is hard to do in practice because there is a delicate balance to be found between people who cheat through lagging, and people who simply suffer from an occasional hiccup in their Internet connection. It is bad business practice to smite your own customers. Such kinds of solutions will necessarily end up with a threshold to distinguish between bad people and unlucky people. Cheaters will stick close to the threshold and this will probably be sufficient to gain some strategic advantage.

      One promising approach along the punishment line is to apply small but cumulative penalties for each lag: whenever a packet is lost or shows up late, remove one hit point, make the player flash, whatever... this can even be integrated in the game universe (for instance, for a FPS convert the detected lag into a rifle jam). This implies that people with reliable Internet connections and big computers will be at an advantage -- and I believe that players are ready to accept that, on the basis that similar things happen in a lot of other leisure-competition situations (e.g. if your hobby is skateboarding, you know that a better skateboard will not replace talent, but will help nonetheless, and skateboarder accept that as a fact of life). Ultimately, this might incite ISP to work a bit on their latency, which would be good for everybody, not just gamers.

    2. Don't trust clients. Massively online games are distributed computing. Most of their security issues are due to the fact that many game rules, i.e. the properties of the world in which the players act, are maintained by the client systems. The players themselves, and in particular the potential cheaters, have extensive control of their machines. Existing countermeasures tend to have limited effectiveness for the same reasons that software DRM and antivirus may fail: this is an arms race in which attackers and defenders are locked into a fast-paced battle of patches and counterpatches which is tiresome and requires expensive, continued maintenance.

      The generic architectural response is to maintain the game rules server-side only; clients become "thin" and are just display interfaces. This is unfortunately hard to implement, because display performance (hence game experience) becomes very sensitive to latency, artificial and natural alike; and ADSL links will have a minimal latency close to 50 ms, which is high with regards to average gamer reflexes. Also, this means that the game servers need more CPU muscle. But the security advantage is huge: when a player induces lagging, he inherently punishes himself and none other.

      Maintaining all game state and rules on the servers is not completely science-fiction either. Back in the late 1980s, one of the very first MMO games was "CarCrash", an offspring of the defunct French magazine Jeux et Stratégie; it was played over the Minitel, another old French technology where users simply had text terminals (with limited graphics) with no local computing abilities; the central server(s) maintained the game rules and computed the screen updates for everybody, and it worked. Computers at that time had far less CPU muscle than today; a 20 MHz CPU was enough to be deemed a "supercomputer". A 35$ home router of 2013 is more than ten times as powerful as a big server of that era. And yet it worked.

      Maintaining game rules on the server implies departing from the way games are usually architectured. Historically, most games were local and became multiplayer by connecting clients with each other, with possibly a central server which only served as rendez-vous point. To take a political metaphor, games became multiplayer by forming confederations, but security against cheaters requires a federation.

    Mixed strategies are possible, of course. The core idea is the same: give as few sensitive data as possible to client systems; and when you must trust them for something, use a big stick or a big carrot to maintain them in line.

    (If you understand that players should be handled like cattle herds, well,... there is truth in that, indeed. You don't want your cows to be unhappy, but you will not let them choose their walking direction and pace either.)


    Edit: just got an insight while waiting for my tea to cool a bit. A game architecture could include several (possibly dozens) of cooperating "trusted" servers spread worldwide, which "play the game" like game clients do today. Each gamer would connect to one server which is "close by" (in a network sense) so as to have a low latency, allowing for the display-only strategy outlined above. If ISP themselves can be involved in the deal (each ISP would host a few servers in its own infrastructure) then this could make sense in a business way.

    If games didn't have algorithms to forgive lags, there wouldn't be a temptation to exploit them. So if you reduce the level of lag-forgiveness as lags appear, you can consider yourself warned.... next lag, and you're a sitting duck.

    Wow.. The topology you're describing is a whole lot like how Netflix handles its streaming video deployment. Would never have thought about using it as an anti cheating mechanism. Basically the same premise just with CPU power instead of disk space. I've been wondering about the same issues Root outlined for years. Very well stated.

    +1 this is a creative approach to the problem. Detection and punishment is the general theme of the solution. I especially like the last edit, applying collusion-solution to detect cheating could be fruitful. I am still looking for a more technical solution that can be peer reviewed and applied.

    Things to look for (for historical value) - DISA/HLA

    The solution in "edit" would only work when there is a great locality in the game's maps. Many popular real time MMOs have regional servers for exactly that reason, to force players in certain countries to group together into a single cluster, which can be acceptable since most players don't care about not being able to play with players from faraway countries.

    The "display-only" idea really is harder said than done. Many games where multiplayer is a core part of the gameplay (rather than just a tacked on feature) already did implement that, where important game states are maintained on trusted servers and client are effectively display only. But in real time games, it still doesn't protect from many forms of lag cheating.

    As someone who has actual lag hiccups every 15-30 minutes, I would be **incredibly** pissed if I had to deal with lag *and* get banned for it (even temporarily).

    @LieRyan and now of course google has built an entire gaming "console" on top of the display-only idea. Whether or not it will succeed is another question of course...

License under CC-BY-SA with attribution


Content dated before 7/24/2021 11:53 AM