Question Abount Multiplay and Anti-Cheat Code
Author
Just a got a question here about multiplayer and incorporating anti-cheat code.
I would like to incorporate as much anti-cheat code in the server code as possible and make it virtually impossible to cheat online.
the question is how much anti-cheat detection can i put in without comprimising server load and player connections?
is is viable to have the game send a data packet to the game server with all the games file versions? and last modified date?
and the files size?
This would be to ensure that all files match the servers files exactly.
if this is not viable what types of anti-cheat options are?
suggestions?
THanks in advance.
One simple solution might be a checksum of all the files included in each level. Check that sum against the server''s version.
That is a simple protection, though it can be broken. I''d like to see what else is suggested by other people here.
daveandrews.org - a Christian Programmer''s Weblog
That is a simple protection, though it can be broken. I''d like to see what else is suggested by other people here.
daveandrews.org - a Christian Programmer''s Weblog
File time stamps and sizes can be cheated out even if modified, so that is not bulletproof, file version numbers could be hacked.
Everything what client send could be modified.
Ofcourse file checks cut down quite number of wannabe hackers, but not all, those who handle these things it is like nothing to them around these checks.
Do checks as much as possible on server side, that way I use on my projects, it add some load on server but prevent quite much abusing, as you mentioned.
I dont mind if someone thumbling my game dat files, if someone want do some changes in graphics etc, so do it. There is no harm to others on that.
Suggestion as mentioned, use as much as possible server side checks on all incoming data.
-A-
Everything what client send could be modified.
Ofcourse file checks cut down quite number of wannabe hackers, but not all, those who handle these things it is like nothing to them around these checks.
Do checks as much as possible on server side, that way I use on my projects, it add some load on server but prevent quite much abusing, as you mentioned.
I dont mind if someone thumbling my game dat files, if someone want do some changes in graphics etc, so do it. There is no harm to others on that.
Suggestion as mentioned, use as much as possible server side checks on all incoming data.
-A-
Author
thanks for the quick replies.
i do relize that any method is hackable, but i want it to be as hard as possible to cheat in a multiplayer game as possible while still allowing the game to be easily moddable by game players and the game modding community.
i do relize that any method is hackable, but i want it to be as hard as possible to cheat in a multiplayer game as possible while still allowing the game to be easily moddable by game players and the game modding community.
Sending checksums of data on the client computer is totally useless.
Someone smarter than you will find out, hack the program code to always send valid kays/hashes/checksums, puts it online, and compromises your anti-cheat tricks.
I think the only way to prevent cheating is having the server check for invalid information from the client (player moves too fast/turns too fast/doesn''t take damage when hit/doesn''t die when health reaches zero --> they all depend on your game of course).
Someone smarter than you will find out, hack the program code to always send valid kays/hashes/checksums, puts it online, and compromises your anti-cheat tricks.
I think the only way to prevent cheating is having the server check for invalid information from the client (player moves too fast/turns too fast/doesn''t take damage when hit/doesn''t die when health reaches zero --> they all depend on your game of course).
There is also another problem with sending information regarding the content of a users harddrive even if its only file sizes and dates and that is from a legal point of view. I believe you have to get an agreement from each user that it is ok for you to "read" from their disks and send that information over the internet for you to check otherwise you can get into serious trouble.
I remember this was getting alot of attention from the Everquest hacking community =)
I remember this was getting alot of attention from the Everquest hacking community =)
The first step in cheatproofing your multiplayercode is to implement a stable and correct client/server-architecture. This means that the client is basically a whore that ONLY does what the server tells it to, and nothing else. When the user presses ''forward'', the client doesn''t move forward and tells the server it did. It tells the server it wants to move forward, the server moves the player, and sends the result of the move back to the client. ALL the game logic should be handled in this way, leaving the client to simply take user input and pass it to the server, and render the graphics. This is pretty much how a client/server-solution should always behave, and if everyone implemented it like that, we would see a lot less of both cheating and hacking.
--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.
--
MFC is sorta like the swedish police... It''''s full of crap, and nothing can communicate with anything else.
Here are some common cheats found in client/server games:
1) See-thru walls - A "camping" sniper is hiding on the corner to your left after exiting the tunnel. With this cheat, you can see the sniper as if the wall does not exist.
2) Giant Flag/Model - The client's display driver is hacked to scale the flag to two thousands times. Result: I can see where you're hiding your team's flag a thousand miles away.
3) Aimbots - A proxy exists between the client and the server. When the client sends an "attack" command, the proxy intercepts it. It then adds a "mouse move" command to point to an enemy's head. Instant headshot.
1 and 2 can easily be fixed if the server will be sending only what the client should only see. Which means that the server should keep track of each client's field of vision. Unfortunately, there's two problem to this approach, Server load and lag.
Obviously, tracking each client's fov will be taxing to the server.
As for lag, if a client is lagging terribly, the player will be surprised if his opponent suddenly pop into view. Of course, we can attribute the problem to lag, but if the server sent that a player is accelerating forward from behind the wall, the Lag would be cleaner.
You will be balancing on a fine needle here.
3 is a little tough. Some games (*cough**cough*Quake*Cough*) keeps a statistics on how accurate your aim is. If it's too good (like say 95% head shot), the client will be kicked out. This raised a lot of controversy... especially from railgun gods. (Quoted from some forgotten source. Kudos to who can remind me :-)). Increasing the accuracy percentage will not help. Modern aimbots intentionally misses some shots (damn bastards).
Some obsolete cheats includes Super Speed (A client sends 10,000 pockets of "forward" commands in a few milliseconds), Infinite Ammo/Life, Nuke (Kill all the players with command "player A Life 0;player B Life 0;") could easily be eliminated by not trusting any commands the client send regarding world data (Just stating the obvious
)
[edited by - s_cloudx on November 13, 2003 7:42:43 AM]
1) See-thru walls - A "camping" sniper is hiding on the corner to your left after exiting the tunnel. With this cheat, you can see the sniper as if the wall does not exist.
2) Giant Flag/Model - The client's display driver is hacked to scale the flag to two thousands times. Result: I can see where you're hiding your team's flag a thousand miles away.
3) Aimbots - A proxy exists between the client and the server. When the client sends an "attack" command, the proxy intercepts it. It then adds a "mouse move" command to point to an enemy's head. Instant headshot.
1 and 2 can easily be fixed if the server will be sending only what the client should only see. Which means that the server should keep track of each client's field of vision. Unfortunately, there's two problem to this approach, Server load and lag.
Obviously, tracking each client's fov will be taxing to the server.
As for lag, if a client is lagging terribly, the player will be surprised if his opponent suddenly pop into view. Of course, we can attribute the problem to lag, but if the server sent that a player is accelerating forward from behind the wall, the Lag would be cleaner.
You will be balancing on a fine needle here.
3 is a little tough. Some games (*cough**cough*Quake*Cough*) keeps a statistics on how accurate your aim is. If it's too good (like say 95% head shot), the client will be kicked out. This raised a lot of controversy... especially from railgun gods. (Quoted from some forgotten source. Kudos to who can remind me :-)). Increasing the accuracy percentage will not help. Modern aimbots intentionally misses some shots (damn bastards).
Some obsolete cheats includes Super Speed (A client sends 10,000 pockets of "forward" commands in a few milliseconds), Infinite Ammo/Life, Nuke (Kill all the players with command "player A Life 0;player B Life 0;") could easily be eliminated by not trusting any commands the client send regarding world data (Just stating the obvious
) [edited by - s_cloudx on November 13, 2003 7:42:43 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
