1
\$\begingroup\$

In popular multiplayer first person shooter games, there are often hacks such as Aimbot, Noclip, Speed, and other similar hacks which I know game developers deploy anti hack features to combat, but, wanting to know why some of these hacks are able to get past these systems, I looked up a hack for the game I'm currently playing and they claim to deploy "counter measures" against the anti hack systems.

My question is, when everything happening is being seen by the game server, how can hacks avoid the anti-hack system? Movement that's too fast for example seems impossible to hide. Moving through walls also seems impossible to hide. Finally aimbot is a difficult one, maybe there's no very good solution to detecting it, if the hack developer, for example, purposely makes it imperfect.

My question to game developers is: How can anti hack systems fundamentally detect speed, noclip, and aimbot hacks, and how can hack developers fundamentally deploy counter measures against systems to detect those three types of hacks?

\$\endgroup\$
5
  • \$\begingroup\$ If my question's too broad I can refine it, just let me know. I'm new to this site, so Im not exactly sure about the scope. \$\endgroup\$
    – J.Todd
    Commented Dec 29, 2015 at 0:35
  • \$\begingroup\$ Similar question had been asked in this site before. I remember asking for editing game memory, some of the answers apply to your question too. While ideal, It's not cost wise (time and money) to make everything happening in the server and then inform the clients. Real world games place as much as they can in the clients, then synchronize between all clients in the same zone, some times only including visible parts of a zone. Link to my related question: gamedev.stackexchange.com/questions/103367/… \$\endgroup\$ Commented Dec 29, 2015 at 0:41
  • \$\begingroup\$ @HatoruHansou Ok, well to fix that I bet game developers can use "after-the-fact" checking, and to eliminate server load for this feature, deploy it in all clients, and stream data chunks to random clients who have sufficient network speed when they have the game active, but not being played, and use the client / player's CPU to process this data randomly for hack activity and send it back. Yes, hackers could then falsely process the data and make it look like innocent players were hacking, but the server could double check the specific cases against their own logs. \$\endgroup\$
    – J.Todd
    Commented Dec 29, 2015 at 0:49
  • \$\begingroup\$ It sounds like a good idea. They sure have their good reasons, maybe a hidden cost that we cannot see. \$\endgroup\$ Commented Dec 29, 2015 at 5:50
  • 1
    \$\begingroup\$ Possible duplicate of What are some ways to prevent or reduce cheating in online multiplayer games? \$\endgroup\$
    – Vaillancourt
    Commented Dec 29, 2015 at 19:03

2 Answers 2

2
\$\begingroup\$

There are three types of "hacks" used for video games.

  • Packet modification: Modifying the data sent to the server.
  • Server hack: Gaining access to the server and performing unauthorized commands.
  • Client modification: Modifying the client to perform something that only affects how you see the game.

We can sort these into different categories for examples.

Speed hacks: These are "packet modification" hacks. These modify the data that is sent to the server.

The best way to prevent this is to validate the information sent. Check if the player is moving faster than the default move speed.

Aimbots: These can be either "packet modification" or "client modification".

If it's client modification, it will just point yourself towards an enemy when it sends data to a server. To prevent this, make the player not able to turn extremely quickly, as that will be the result of this type of hack.

If it's packet modification, it will make your projectiles always point towards the nearest enemy. To prevent this, don't let the client update details about the bullet while it is moving.

Noclip: Another type of packet modification. Allows the player to move through walls, and if the server doesn't check if the player's in the wall, then this is possible.

See through walls/similar: This is client modification. There's no way to prevent this currently (correct me if I'm wrong).

\$\endgroup\$
3
  • \$\begingroup\$ Long story short: assume the client is always a lying, cheating bastard when it sends packets. Don't let the client dictate any aspect of the simulation (i.e. validate everything). Preveting things like seeing-through-walls, there are some moderate prevention measures that can be taken, but are imperfect (such as MD5 checking the textures being used, but the client can lie about that if modified) and there's no way to insure integrity without having the server supply all game textures as well (and even then, if the client is modified...). \$\endgroup\$ Commented Dec 29, 2015 at 18:30
  • 1
    \$\begingroup\$ @TechNick6425 Though I can't back it up with reference, I believe some games do not send information about unseen (even nearby) enemies, so the client doesn't access the information. This is most important in strategy games and MOBAs like DotA, Starcraft, LoL, etc. \$\endgroup\$
    – akaltar
    Commented Dec 30, 2015 at 0:15
  • \$\begingroup\$ That's a good point. If you don't send any data that shouldn't be used, the client can't access. For example, if you have a shooter, only send data for enemies that the player can see. This prevents the client from showing players that the unmodded client shouldn't show. \$\endgroup\$ Commented Dec 30, 2015 at 0:45
2
\$\begingroup\$

Moving through walls also seems impossible to hide

Let's look at a simple scenario: An image depicting dropped packets, causing the server to observe odd movement

In this diagram, a player is running around this protruding wall. However, due to some connection issues, all packets along the red line are dropped and the server never receives them. The connection improves and the server starts receiving packets with the player now on the other side of the wall. Did the player cheat? Of course not, they moved correctly around the wall on the client side, but the perception of the server is now that they moved through the wall. This kind of situation is exactly what makes anticheat so difficult to implement. As a result, they tend to focus on other situations/methods for detection of cheating.

I saw VAC mentioned in another answer, however I feel the information provided there is either misleading or wrong. VAC accomplishes cheat detection by looking for known cheats in the game, using a library of previously discovered cheats. Getting around VAC detection is as simple as writing your hack in a novel way. As long as it's not similar to some other hack in it's execution, it'll likely be undetected by VAC. VAC Documentation Punkbuster works in a similar way, along with scanning game files in memory to verify they've not changed periodically.

So, I guess to put it simply. Circumvention of anticheat really is not too hard; It's as simple as coming up with a new way to hack the client.

\$\endgroup\$
1
  • \$\begingroup\$ I did assume, that the server teleports you back where your last packet was recieved from. Or only calculated your position from the movement packets and doesnt get the updated position from the client, but sends their position from the server to the client. That would be the "Running into a wall"-Lag \$\endgroup\$
    – PSquall
    Commented Aug 10, 2018 at 8:58

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .