4 ms·

I wonder what they're doing about cheating? I guess this type of game is not so easy to 'cheat' with but I'm sure it is possible. I was thinking about building

by shocks 14y ago

I wonder what they're doing about cheating? I guess this type of game is not so easy to 'cheat' with but I'm sure it is possible. I was thinking about building an Unreal Tournament clone in WebGL, but I'm still not sure what to do about cheating.

Drakim 14y ago
This is not a problem specific to HTML5. Although it's a lot harder to mess with a binary than some JavaScript, everything that runs on client side is fundamentally compromised and untrustworthy. The trick is to have as many checks and balances on the server side as possible (to prevent walking though walls, warping, etc).
- shocks 14y ago
  Very true, however I am not aware of a specification that, for example, makes it easy to check the scripts/resources that are being used are the correct ones. Of course any system to do this can be broken, but it strikes me a much bigger problem with Javascript in the browser than a binary. One idea that's just crossed my mind is the idea of serving different Javascript to each client? It could be obfuscated uniquely every time someone loads the page in a detectable way. I,e you can serve IP x.x.x.x with obfuscation seed y and then you know to expect a certain behaviour. Variables and program flow can be changed to confuse nieve would be hackers, but important the structure of the network communication can be changed in a subtle way. Any hack scripts would need to counter for this which would make things far more complicated. I wish my university term would be over so I can start hacking away on this idea! :)
  - entropy_ 14y ago
    You will still fail to prevent cheaters using an approach like this one. Even a game that is only distributed as a binary but with no or few checks on the server for cheating will be compromised very fast. It only takes one person to figure out how to do it and then release a proof of concept. It is, in fact, not a bigger problem if the code is readily readable. Someone with the technical chops to read the source code and figure out weaknesses that can be exploited for cheating wouldn't be stumped by a binary blob for very long. My usual approach when trying to figure out "cheats" for most such things is to bypass the client altogether and analyse the network traffic to figure out the underlying protocol. Then come up with a client that reproduces those(simple replay attacks at first to see what works and what doesn't) and as my understanding of what does what evolves make it more sophisticated and flexible. Having your source code fully available to any would-be attacker will force you to not make the mistake of hoping that nobody figures out how things work to be able to attack you. It forces you to pay attention to server-side checks to enforce the constraints of your game(what? that guy just changed his position in a way that's way too fast? not possible!).
    - smrtinsert 14y ago
      Very true, no security through obscurity. Anti-cheats should be just another category of development topics under game development. So you wanted to be a game developer...
  - de90 14y ago
    The way you prevent cheating in a game like this is that the game itself runs on the server. The client side is merely showing a representation of the server state. If people want to edit the scripts to show an invalid state who cares. Granted latency becomes a huge challenge, but in a perfect world (no latency) having the scripts on the clients side and having people edit them isn't a big deal
    - T-hawk 14y ago
      Easily said, but the challenge is making absolutely triple damn sure that the game running on the server is bulletproof against malicious input by the client. It took years for early games like Diablo and Everquest to get it right in ignoring a client sending position updates to move a character faster than nominally allowed by the game logic. And that's the tip of the iceberg. You also have the problem of hidden information. Most games have a fog of war or simply walls that should obscure some part of the game state. If this is sent to the client, somebody will expose that information: maphack. It's not at all a trivial problem to define and send only exactly the slices of the game state that the client should have access to. And any game where timing matters is subject to auto-aim bots and other such cyborg-style assistance to the players. Bomberman is subject to this: imagine a browser plugin that automatically moves your character out of range of a bomb in the last few instants before it explodes.
      - dubcanada 14y ago
        The "fog of war" is actually really easy to do. And most games that use "fog of war" already have parts in place for this. Checking client input is rather difficult, but it's no more difficult then developing the game itself. Just a lot of hassle and checking. Even if you do all this stuff, people can still break it. Look at pretty much every game made. There are ways to cheat.
bayesianhorse 14y ago
In this case they don't have any trouble with cheating because the game logic seems to be entirely server-side. Also cheating is only trouble when it degrades other player's experience or when they are hacking/hurting the monetization.
- shocks 14y ago
  In this case it seems okay, but not in all cases. Consider an FPS. Javascript tweaks could be used to automatically change to a shotgun when close range, assist in aiming, highlight players behind walls, etc. I wonder what the most effective ways to combat such cheating would be?
  - jacobparker 14y ago
    You won't be able to prevent Javascript aim bots. The best you can do is server side detection of aim-bot-like behaviour, but this will always be a losing battle (better aim bots) and you may punish good players.
  - martinced 14y ago
    "I wonder what the most effective ways to combat such cheating would be?" As stated, if the logic is performed on the server-side then the only way a client can cheat is by modifying the inputs. The one thing that makes it hard for client to know in which way to cheat the inputs is... Randomization. Do not make something where players are recompensed when doing a super skilled move, like a headshot. Or you'll have aimbots. As simple as that. Player has a shotgun? Make it fire 30 miny bullets at once with some server-side randomization (that's how many shotguns work btw). Do not want to give info about the other side of the map so that a rogue bot cannot shift to the correct strategy automatically ? Use server-side fog of war. That way the very info needed to "map hack" simply is NOT available on the client. It is hard to combat all forms of cheating. But maphack can definitely be mitigated and randomization can really help with many aimbots. Regarding the "highlight players behind walls": two things to do. 1) do not allow to fire through walls (unless the first Counter-Strike, which was totally silly in that you could fire through 2-meters wide wall with a simple pistol) and 2) server-side fog-of-war. Do simply not send to the client the info that would allow the client to determine that an ennemy is behind the wall too early. Sure, at one point you need to give the info: give it as late as possible and make is so "super crazy high reflex" are not rewarded in an insane way. For example make it slower to "switch gears", etc. It all comes to a balance between fun and anti-cheat but many things can be done to make cheaters life way harder and, most importantly, way less efficient.

by shocks 14y ago

Drakim 14y ago

This is not a problem specific to HTML5. Although it's a lot harder to mess with a binary than some JavaScript, everything that runs on client side is fundamentally compromised and untrustworthy. The trick is to have as many checks and balances on the server side as possible (to prevent walking though walls, warping, etc).

shocks 14y ago
Very true, however I am not aware of a specification that, for example, makes it easy to check the scripts/resources that are being used are the correct ones. Of course any system to do this can be broken, but it strikes me a much bigger problem with Javascript in the browser than a binary. One idea that's just crossed my mind is the idea of serving different Javascript to each client? It could be obfuscated uniquely every time someone loads the page in a detectable way. I,e you can serve IP x.x.x.x with obfuscation seed y and then you know to expect a certain behaviour. Variables and program flow can be changed to confuse nieve would be hackers, but important the structure of the network communication can be changed in a subtle way. Any hack scripts would need to counter for this which would make things far more complicated. I wish my university term would be over so I can start hacking away on this idea! :)
- entropy_ 14y ago
  You will still fail to prevent cheaters using an approach like this one. Even a game that is only distributed as a binary but with no or few checks on the server for cheating will be compromised very fast. It only takes one person to figure out how to do it and then release a proof of concept. It is, in fact, not a bigger problem if the code is readily readable. Someone with the technical chops to read the source code and figure out weaknesses that can be exploited for cheating wouldn't be stumped by a binary blob for very long. My usual approach when trying to figure out "cheats" for most such things is to bypass the client altogether and analyse the network traffic to figure out the underlying protocol. Then come up with a client that reproduces those(simple replay attacks at first to see what works and what doesn't) and as my understanding of what does what evolves make it more sophisticated and flexible. Having your source code fully available to any would-be attacker will force you to not make the mistake of hoping that nobody figures out how things work to be able to attack you. It forces you to pay attention to server-side checks to enforce the constraints of your game(what? that guy just changed his position in a way that's way too fast? not possible!).
  - smrtinsert 14y ago
    Very true, no security through obscurity. Anti-cheats should be just another category of development topics under game development. So you wanted to be a game developer...
- de90 14y ago
  The way you prevent cheating in a game like this is that the game itself runs on the server. The client side is merely showing a representation of the server state. If people want to edit the scripts to show an invalid state who cares. Granted latency becomes a huge challenge, but in a perfect world (no latency) having the scripts on the clients side and having people edit them isn't a big deal
  - T-hawk 14y ago
    Easily said, but the challenge is making absolutely triple damn sure that the game running on the server is bulletproof against malicious input by the client. It took years for early games like Diablo and Everquest to get it right in ignoring a client sending position updates to move a character faster than nominally allowed by the game logic. And that's the tip of the iceberg. You also have the problem of hidden information. Most games have a fog of war or simply walls that should obscure some part of the game state. If this is sent to the client, somebody will expose that information: maphack. It's not at all a trivial problem to define and send only exactly the slices of the game state that the client should have access to. And any game where timing matters is subject to auto-aim bots and other such cyborg-style assistance to the players. Bomberman is subject to this: imagine a browser plugin that automatically moves your character out of range of a bomb in the last few instants before it explodes.
    - dubcanada 14y ago
      The "fog of war" is actually really easy to do. And most games that use "fog of war" already have parts in place for this. Checking client input is rather difficult, but it's no more difficult then developing the game itself. Just a lot of hassle and checking. Even if you do all this stuff, people can still break it. Look at pretty much every game made. There are ways to cheat.

bayesianhorse 14y ago

In this case they don't have any trouble with cheating because the game logic seems to be entirely server-side. Also cheating is only trouble when it degrades other player's experience or when they are hacking/hurting the monetization.

shocks 14y ago
In this case it seems okay, but not in all cases. Consider an FPS. Javascript tweaks could be used to automatically change to a shotgun when close range, assist in aiming, highlight players behind walls, etc. I wonder what the most effective ways to combat such cheating would be?
- jacobparker 14y ago
  You won't be able to prevent Javascript aim bots. The best you can do is server side detection of aim-bot-like behaviour, but this will always be a losing battle (better aim bots) and you may punish good players.
- martinced 14y ago
  "I wonder what the most effective ways to combat such cheating would be?" As stated, if the logic is performed on the server-side then the only way a client can cheat is by modifying the inputs. The one thing that makes it hard for client to know in which way to cheat the inputs is... Randomization. Do not make something where players are recompensed when doing a super skilled move, like a headshot. Or you'll have aimbots. As simple as that. Player has a shotgun? Make it fire 30 miny bullets at once with some server-side randomization (that's how many shotguns work btw). Do not want to give info about the other side of the map so that a rogue bot cannot shift to the correct strategy automatically ? Use server-side fog of war. That way the very info needed to "map hack" simply is NOT available on the client. It is hard to combat all forms of cheating. But maphack can definitely be mitigated and randomization can really help with many aimbots. Regarding the "highlight players behind walls": two things to do. 1) do not allow to fire through walls (unless the first Counter-Strike, which was totally silly in that you could fire through 2-meters wide wall with a simple pistol) and 2) server-side fog-of-war. Do simply not send to the client the info that would allow the client to determine that an ennemy is behind the wall too early. Sure, at one point you need to give the info: give it as late as possible and make is so "super crazy high reflex" are not rewarded in an insane way. For example make it slower to "switch gears", etc. It all comes to a balance between fun and anti-cheat but many things can be done to make cheaters life way harder and, most importantly, way less efficient.