Programming Forums - View Single Post - Trying to setup an anti-cheat system for a game friend and I are creating

Dameon · Jan 9th, 2006, 6:37 PM

1. If the user downloads/purchases the game, then don't be a content nazi. They cannot use the content without your permission, but modifying game content is not only common but a good way to increase user involvement and playability. You don't have to release any file formats or specs...they will figure it out if they want to. Or you could be like Valve/Epic Games/Bioware/etc and release the developer tools for free with the game and have insane amounts of user content...

2. Redundancy checking on files is useless. What? My file doesn't match the CRC? Oh noes!one1 That means I have to change the locally stored expected CRC. Gasp. The server is requesting the military grade SHA-1 hash of the map? OMG, I have to replay the known good hash to the server.

3. Clientside anti-cheat detectors are borderline useful, but only a stopgap solution. Where to begin. First off, how do you plan to detect them? Enumerate the processes attached as debuggers you say? That's right, they have no right to touch my precious memory! Check for known "bad guy" processes? Right. Slows ya down, sure, but our friends at Sony have kindly provided a rootkit that hides processes with image files beginning with $sys$ World of Warcraft had a slight inconvenience with that little tidbit. Or you could use a real rootkit. That brings me to #4

4. Kernel mode. There's that sad fact that there is some code with higher priveleges than you that can stomp on your memory, bounce your api calls off satellites, and steal candy from defenseless orphans. Rootkits fall into this category. But this broadens your view of the fact that you do not control the computer.

Move server side. I advise that you download the source code for an open source game known as BZFlag. Nice 3D tank shooter. However, the server is mostly a relay while the client can do whatever it feels like. An example. A classic BZFlag cheat is to notify the server that a shot has exploded...except that it isn't one that you fired. Being a good relay, it kindly notifies the other clients that the shot has exploded. I took some liberties with the idea. Whenever notification of a shot arrives, my client ends the shot. Mapped that to a key to toggle that. Suddenly, everyone was wondering why their bullets disappeared at the end of their barrels. Commenting out the line that notified the server that you died was entertaining as well. So was turning off gravity.

Moral of the story? Everything that the client sends is a risk. Online login form? SQL injection. Multiplayer game? Send something that shouldn't work that does (or conversely don't send something when you should). The server is authoritave. The only way to change the experience of the other players is if the server notifies them. The only way to change your own data, be it health mana ammo or otherwise, is if the server thinks so. You accomplish this by maintaining state on the server (why BZFlag is an example of bad practice) and by doing insanely large amounts of sanity checking. More sanity checking than makes sense. If somewhere down the line you realize that you disallowed something that needs through (such as a future modification), that's when you change it. Whitelist versus blacklist. Methods on objects along the lines of canFire or canCastSpell can help make this more maintainable. What you do with sanity checking depends on several things. Can the problem be attributed to lag (ex trying to fire shortly after being killed)? Ignore it, but make sure the client stays in sync. Is it something that should never, ever happen (attempting to learn a skill that is blatantly disallowed by the rules, such as a level 1 wizard taking Epic Spell Focus in D&D)? Disconnect or ban.

You'd be surprised how much you can learn just by observing the behavior of games and game servers, be it learning about defense from cheating or good practice in general. THe Neverwinter Nights server was smart enough to reject my attempt to break D&D 3rd edition rules while levelling up, even though that is the client's job. World of Warcraft scales player updates based on distance, apparent by the jitter of party members on the world map that are on the other side of the zone (update every few seconds) versus those near you (smooth, at least once a second). The Source engine used in CS:S and HL2:DM at one point allowed a command to be executed by the client that allowed them to spawn effects. Picture strobe lights and skulls appearing from nowhere.

I could prattle on about the ins and outs of multiplayer game design. All in all, be careful on the server, but the client is uncontrollable. Who cares if they piss in their own sandbox when nobody else is around?

Jan 9th, 2006, 6:37 PM	#10
Dameon Troll Join Date: Apr 2005 Location: Texas Posts: 732 Rep Power: 4	1. If the user downloads/purchases the game, then don't be a content nazi. They cannot use the content without your permission, but modifying game content is not only common but a good way to increase user involvement and playability. You don't have to release any file formats or specs...they will figure it out if they want to. Or you could be like Valve/Epic Games/Bioware/etc and release the developer tools for free with the game and have insane amounts of user content... 2. Redundancy checking on files is useless. What? My file doesn't match the CRC? Oh noes!one1 That means I have to change the locally stored expected CRC. Gasp. The server is requesting the military grade SHA-1 hash of the map? OMG, I have to replay the known good hash to the server. 3. Clientside anti-cheat detectors are borderline useful, but only a stopgap solution. Where to begin. First off, how do you plan to detect them? Enumerate the processes attached as debuggers you say? That's right, they have no right to touch my precious memory! Check for known "bad guy" processes? Right. Slows ya down, sure, but our friends at Sony have kindly provided a rootkit that hides processes with image files beginning with $sys$ World of Warcraft had a slight inconvenience with that little tidbit. Or you could use a real rootkit. That brings me to #4 4. Kernel mode. There's that sad fact that there is some code with higher priveleges than you that can stomp on your memory, bounce your api calls off satellites, and steal candy from defenseless orphans. Rootkits fall into this category. But this broadens your view of the fact that you do not control the computer. Move server side. I advise that you download the source code for an open source game known as BZFlag. Nice 3D tank shooter. However, the server is mostly a relay while the client can do whatever it feels like. An example. A classic BZFlag cheat is to notify the server that a shot has exploded...except that it isn't one that you fired. Being a good relay, it kindly notifies the other clients that the shot has exploded. I took some liberties with the idea. Whenever notification of a shot arrives, my client ends the shot. Mapped that to a key to toggle that. Suddenly, everyone was wondering why their bullets disappeared at the end of their barrels. Commenting out the line that notified the server that you died was entertaining as well. So was turning off gravity. Moral of the story? Everything that the client sends is a risk. Online login form? SQL injection. Multiplayer game? Send something that shouldn't work that does (or conversely don't send something when you should). The server is authoritave. The only way to change the experience of the other players is if the server notifies them. The only way to change your own data, be it health mana ammo or otherwise, is if the server thinks so. You accomplish this by maintaining state on the server (why BZFlag is an example of bad practice) and by doing insanely large amounts of sanity checking. More sanity checking than makes sense. If somewhere down the line you realize that you disallowed something that needs through (such as a future modification), that's when you change it. Whitelist versus blacklist. Methods on objects along the lines of canFire or canCastSpell can help make this more maintainable. What you do with sanity checking depends on several things. Can the problem be attributed to lag (ex trying to fire shortly after being killed)? Ignore it, but make sure the client stays in sync. Is it something that should never, ever happen (attempting to learn a skill that is blatantly disallowed by the rules, such as a level 1 wizard taking Epic Spell Focus in D&D)? Disconnect or ban. You'd be surprised how much you can learn just by observing the behavior of games and game servers, be it learning about defense from cheating or good practice in general. THe Neverwinter Nights server was smart enough to reject my attempt to break D&D 3rd edition rules while levelling up, even though that is the client's job. World of Warcraft scales player updates based on distance, apparent by the jitter of party members on the world map that are on the other side of the zone (update every few seconds) versus those near you (smooth, at least once a second). The Source engine used in CS:S and HL2:DM at one point allowed a command to be executed by the client that allowed them to spawn effects. Picture strobe lights and skulls appearing from nowhere. I could prattle on about the ins and outs of multiplayer game design. All in all, be careful on the server, but the client is uncontrollable. Who cares if they piss in their own sandbox when nobody else is around? __________________ MD5(sig) = bcef75433db02e9ad9bf81d6f7c5c270