Preventing artificial latency or "Lag Hacking" in multiplayer games

Question

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!)

Answer 1

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.

Answer 2

With tongue only partly in cheek, I'm going to suggest that Xbox Live already has controls to limit the damage caused by lag switches. I'm going to channel my inner Schneier and say that where technical controls may be problematic to implement, reactive and societal controls are perfectly valid options:

• Mark the player to "Avoid" - makes it unlikely you'll get matched up with them again
• File a complaint for "System Tampering" - makes it possible their account will be revoked

This has proven to be an effective set of controls against the "mod" hackers in the game I play regularly, "Call of Duty: World at War". The one difficulty I see is that lag switching is difficult to prove; unlike someone flying through the air with noclip, it's not unusual to see innocent players with laggy connections that seem to help them sometimes.

Answer 3

Consider the arbitrary example:

The server keeps a stack of data for each player that contains the position of the player and the time this update was received. The server expects an update every 10 ms because it is programmed in the client that way. Each update that is received is checked with the previous update.

Let assume the server is accepting X and Y coordinates for the player and the game only allows the change of 1.0 for X and Y every update, (because that is the maximum speed of the player). If the current time is 0.00 and the position of the current player is at (1.0,1.0), the maximum update position could be (2.0,2.0) at the current time of 0.01. We may have to allow some margin of error in this positioning such as +-(0.1,0.1).

However UDP packets are going to be dropped and the server will have to calculate the acceptable limits for the player given the current update. If in the previous paragraph, the update was dropped, and the player also sent a new update with time = 0.02 and position (2.0,2.0), this would be a legitimate update. The server would check and flag updates that are not real where if the time to change coordinates couldn't not have possibly been achieved, in this example, moving to (1000.0,1000.0) in the next update.

Since the server is expecting update every 10 ms, it needs to have an acceptable limited to the dropped packets it didn't receive. The limit may be 100 ms and if the server hasn't received an update within that time frame, we can consider that there is some lag. Once this lag has gone away the server will tell the player where they currently are so they can start sending new updates.

This lag should not effect other players because it is not their problem. It is quite frustrating to see other players in the game "teleporting" around because they are lagging. Lag happens and it is always the reason why I die in video games.

Answer 4

If lag spikes, or whatever the term is, has been detected, the server should simply start to mute the players' bullets for x seconds. It's not the enemies players' fault network issues are causing him to lose.

If the lag spikes continue over the match, continue to raise the dropped bullets time delay. Log this stuff on players account. Log additional info such as is this happening when players are around, with distances, and whatnot so the player can be investigated if need be. If it's never happening while in open field with no one around... why? I understand networks get more involved when in battle, but if it's always .5 seconds before he shoots, because he runs behind a rock engages his lag switch, then attacks, this stuff gets to be pinpoint obvious.

If you have a bad network, then you will be like ok, I have a bad network, but I like the game, so I realize I may lose some bullets... Fair Enough. That will be accepted. People who have bad networks know they have bad networks. Kicking because of spikes is not an answer, unless it's a continuous spike throughout entire client connection to server life.

As for the lag hacker, eventually he'll have to play fair. The extended loss of bullets will mean he won't use the hack. If anything it will turn into a tool to just run away, which will further expose that he is hacking. A bad network player won't realize he is lagging and losing bullets.

And finally, is the client having such a bad network because it is a bad network connection? Send an email saying, "Your network is showing signs of disarray, please seek support from your ISP to look into possible line problems. This is a courtesy warning, not a flag of cheating, however it does affect our servers and gameplay, so you might be queued with others who are having similar issues to be fair to our competitive players looking for a quality service we are trying to provide."

Answer 5

my answer would be to baseline everyone and use heuristics. If peoples pings are way out of wack then start looking for the commonality, such as the same player is in all these games where players pings are messed up or people are disconnecting out due to dos. I dont think this would even be hard. You would need to keep data of the user, ping, and their normal location region so if they are playing with buddies and are connected outside of their region we give their ping a higher response threshold.

Answer 6

Add a basic system monitor and check for dropped packets vs resends:

• a hacker will have multiple resent packets (0x06)
• a person being lagged by outside forces will have congested packets (0x08)

Here's another concept:

A person eating lag will get targeted by a hacker with lagger/dropper tools, standard hacker tools indeed.

A hacker sending out lag will have his net drop ping times first, as he is the source, this is something trackable by a log, and in both situations, the source of the lag is the hacker, and it can be handled at the server, at the ROUTER, at the client, or even at a subclient.