Archived

This topic is now archived and is closed to further replies.

Anti Cheat-tecniques

This topic is 4971 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, I''m working on a MMOG, and currently working on some cheat protection. After playing UT today and again, being the vicitim of an aimbot (http://members.home.nl/utcg/Shot0019.jpg), I came to the conclusion that the cheat protection is one of most important things in a game, cause the game becomes very boring if some guys start cheating. So, I was compiling a small list of ''anti-cheat'' methods, and wondering if anyone here has anything to add, that I might have missed... This list might help you give some new ideas, so it''s worth reading. 1) Packets encrypted 2) Packet ID''s variable 3) CRC32 on important game files 4) Values stored using a different value (eg, multiplying with 0.5) 5) Using a checksum mechanism on important variables (speed, heading, etc) 6) Server side check if speed is faster than the maximum allowed, also check if certain ship properties match (can cloak, etc) 7) Variables allocated at different memory positions (order) every time the game starts. Well, that''s it so far... any ideas further? Almar

Share this post


Link to post
Share on other sites
One idea is to seperate the networking stuff from the main executable (put it in a DLL).

On the one hand, this makes it marginally easier for hackers to zero in on the networking portion of the code (saving them like 3 minutes of hacking time..they can always easily find the networking code in a large disassembly by looking for the winsock calls).

The benefit, though, is that you can easily change large portions of the network protocol and just have users download the new DLL when they connect with an older protocol version, disconnect them and have them reconnect.

This will discourage people from finding network-protocol-related cheats as long as you keep an eye on things and fix any bugs and change the way the network protocol works in fairly superficial but frustrating ways every time a cheat is found.

This is not really an option for most FPS games, since the servers are distributed all over and run by independent admins, but for a MMOG where you control the servers, its a cinch.


The other obvious suggestion is don''t trust the client for anything more than is absolutely necessary. Your #6, for example, shouldn''t really be needed as you shouldn''t even trust the client to report a speed, that should all be handled on the server with the client just letting the server know "I''m going to travel in this direction and this percentage of my total ship speed". The server should know what 100% of the ship speed is, discard any messages where the speed is >100%, etc and then just send updates to the client (and the clients of other players in its vicinity) as to where it is at each tick. Things like cloaking should also be handled on the server, if the player can''t see someone else''s ship, filter that on the server, not on the client where they could write a hack to be able to see invisible ships. Of course, bandwidth and cpu cost is always an issue here..Sometimes you have to put some faith in the client because doing everything server side would cause too much network traffic for dialup users to handle, or would result in too many calculations on the server (especially if you''re a small operation and can''t afford to run like 20 distributed servers). But its always best to do as much as you can on the server, obviously.


The other thing that is important but can be a high-cost factor is keeping detailed database transactions of game events. If the user finds a bug in a game''s economy and can issue him/herself millions of credits, or a super unbeatable ship, or anything that throws game balance way off, its good to be able to rollback to a pre-bug state. The users will bitch and moan but most of them will understand why rollbacks need to be done in extreme cases. This type of thing is rather daunting if you implement it completely yourself. For MMOGs, I suggest using a relational database server-side to hold persistent data. There are some free ones like PostgreSQL and MySQL that you can use.





Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Thank you for your detailed reply!

It really game me some new ideas I would never even thought about.

quote:

The server should know what 100% of the ship speed is, discard any messages where the speed is >100%



Yeah, this is a nice method. Although it basicly comes down to the same, if someone *finds* a method to change the data sent to the server (my encryption algo is really interesting... but ofcourse anything can be decrypted), the cheater can simply enter a certain ''100''instead of a value that might be ''really'' wrong, for the server.

quote:

Things like cloaking should also be handled on the server, if the player can''t see someone else''s ship, filter that on the server, not on the client where they could write a hack to be able to see invisible ships



My current synchronisation code does not allow this, in fact, I was wondering how I would do it anyway. Simply not sending the packets won''t work... the ships will be interpolated, and interpolated...and interpolated, etc. But for example, that''s why I use the checksum. If the checksum does not match the state of certain properties, something has changed, and the game will terminate.

Hull and shield damage will be done serverside... and death too, so it''s virtually impossible to get invincible... Well, I hope.

I might another add one:

8) Have a simple checksum added to the packet data.

Thanks!
Almar

Share this post


Link to post
Share on other sites
Before you just go out and invent all kinds of crazy ideas, you should take a step back and classify what cheating is all about. I generally divide cheats into three categories (I don't think that's an official thing, but it works fine):

- Rule cheats
These are anything which violates the intended game rules, such as getting a super strong/fast ship, getting an infinite amount of money, etc...

- Knowledge cheats
These are basically things like wallhacks and maphacks

- Doping
Anything that improves the skill of a player. The most prominent example of this is the aimbot.

Rule cheats can be quite easily fought in a client/server-environment. Just don't trust anything the client tells you. It's also easy to fight in a peer-to-peer environment if you send say player commands instead of unit data, so every host runs its own simulation of the game world.

In a client-server environment, knowledge cheats can be completely eliminated, but it's really a tradeoff thing. Anything that's stored on the client can be revealed to the player. Ultimately you could just do all the rendering on the server and just send screenshots to the client, but this is of course not feasible in today's networking environment. Just reduce the amount of information a client has to the minimum.
In a peer-to-peer environment, it's a tradeoff between rule cheating and knowledge cheating. You can completely prevent rule cheating, but only if all hosts have complete knowledge about the entire world, which opens the game to knowledge cheats.

Doping cannot be prevented. Full stop.

Now in the cases where cheating can, in theory, not be completely eliminated (i.e. knowledge cheats and doping), you have to at least make the job harder for crackers, i.e. encrypt the entire networking protocol, encrypt critical data in memory (e.g. AOE2 just xors the players' amount of ressources with a randomly chosen value, according to an article on Gamasutra). Additionally, make tampering with your executable as difficult as possible. Encrypt parts of the code, run several different types of checksums, etc...

Oh, and you really should try to disassemble a good protection scheme at least once before you implement your own. You've got to know how crackers work (i.e. how they use tools like SoftIce, BoundsChecker and IDA).

cu,
Prefect

One line of sourcecode says more than a thousand words.

Edited by - Prefect on September 5, 2001 12:36:14 PM

Share this post


Link to post
Share on other sites
intresting concepts..

i built an anti-cheat gaming network that detects certin cheats for games... currently i only support warzone2100, wich detects lots of speed hacks for the game. ... yes i agree, you got to know the cheats be for you can come up with an anti cheat mechnisim to stop it.... and thats what i did with this network. called DirectGames Online.

http://www.directgamesonline.com

it works off of a database that keeps track of users who cheat on the network, i recently just updated the network to version 4.14 BETA, wich is mplayer like, ever since gamespy took over mplayer. its been a project ive been working on for about 2.5 years now...



---------------------------------

A N.E.W.S.T. Member
http://www.newst.org
http://www.directgamesonline.com

Share this post


Link to post
Share on other sites
2.5 years, ditto for my game...

Thanks for all the responses. Maybe doping can''t be prevented... but atleast we can mkae it tougher for people that try =-/

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Really intresting thread guys! Well as mentioned, doping is one of the most difficult cheats to stop. I''m not sure if it''s even possible to stop. Perhaps were looking at it from the wrong angle.

A few people cheat, which ruins the game for everyone. Why spend all the time creating anti-cheating technology for a few cheaters. Rather spend the time in cheat detection technology, which is much harder to circumvent or even detect. Cheater idenitification and indemnification is a much more reasonable goal. After all, with todays internet, it''s not hard to track and label your players, especially with the MMORPGS, which have a centeralized player DB. If a player is identified as a cheater and tagged as such, honest players can block them from even joining their games, thus no more anoying cheaters.

Good Luck!

-ddn

Share this post


Link to post
Share on other sites
Could doping be prevented using some kind of probability system?

For example, you could have your program keep track of the probability of certain events occuring. (eg. the probability of 10 head-shots in a row is 1/10000 for a skilled player, therefore he must be cheating. Or, the probability of shooting
someone ducking behind a crate with no clear line of sight is 1/10. The probability of him doing it 20 times in one minute is
1/10000)

For every event that can occur, you set a probability. THe program could even adjust the probabilities as the game was played if need be. Sure some legitimate players might get nailed, but probably very few.

It may not work as well for Aimbots, since there are some people with incredible aim. But for things like wallhacks, etc. it may work.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Actually such a system should be able to detect even the best aim bot. You''ll have to find statstical correlations within the data, by profiling known good human players. Deviant profiles will stand out and most likely be a cheater. For instance, a great player not only shoots accurately but their types of mouse movements can be statiscially correlated to their shooting skill. If a normal player, whose mouse movement is very different from the great player but whose shooting percent is very high, then you know there is something odd. True they could be a statsicail deviation, however with more profiles, it will give you a much clearer picture. Its a process of refinement, and testing like any software. Virtually impossible to circumvent as almost all the data is processed on the server side and the rule sets unknown to the cheater.

-ddn

Share this post


Link to post
Share on other sites
Hi all,

my 1st comment is...

In my opinion the client game should be just a dumb interface.. nothing more ! it shouldnt make any changes to the player or the game world. All it should do is request changes/actions ie


Client : set speed to 50
Sever : your speed is 50 (or just send a confirmation that the last command was excepted.. or better still just send a message back when the request was declined)

Client : set speed to 20000
Server : (max speed is 100) send message back saying your actual speed is now 100 (also log the atempt to cheat)


now onto aim bots .. 1st am i right in thinking what u meen by an aim bot is some program which basically aims and fires for the user (ie uses the games data to pinpoint exactly where the user is) if so... hmmmm that is a hard one.. i guess these aim bots always aim in exactly the same place ? if so then i think you should log the last 5 shots from the player and if they all match exactly then they must have cheated

ps can someone clarify whats ment by aim bots if im way off target

~tim

Share this post


Link to post
Share on other sites
Doping can not be completely prevented, as anything that''s on the client (and input is always on the client) can be tampered with. Of course you must make the cheater''s job as difficult as possible!

The cheat detection measures are an interesting idea. A combination of both preventive and detective methods would be ideal, of course.
About tagging a player as a cheater: You must be really careful with this. If it''s done purely automatically, for example by checksumming code, or by checking for trainers running in the background, you should be mostly okay. However, don''t allow players to denounce other players (that should really be a common sense thing of course). Maybe a rating system like Slashdot''s (rating and meta-rating) could be used here, but you do have to be careful, and don''t make it a black and white thing (i.e. either non-cheater or cheater).

Another issue about cheat detection: Sometimes it may be not only hard, but impossible to detect a trainer running in the background. Particularly, aimbots implemented as a proxy could run on a different computer - more and more people are using old PCs as a router/proxy for a small home LAN, and they could simply install the proxy on that router.
If they''re really clever, they could use e.g. Linux firewalling packets to automatically filter the game''s packets, even if the player''s computer isn''t sending them to the firewall.

wrathgame: Aimbots just filter the network traffic to build a rudimentary representation of the world. Then they just calculate the optimal view angle for the player, so that their aim is spot-on on the enemy. Many also shoot automatically and have other features.

Yes, you can use heuristics to detect aimbots. Actually, this was even done in QuakeWorld AFAIK. But you''re only going to start a continuing evolution where aimbot programmers will introduce intentional flaws into the aim etc...
So you''re basically going to detect older aimbots, but soon aimbots will have adapted to the heuristics, and you need to tweak your heuristics again. I''m not too sure whether that''s a battle worth fighting.

cu,
Prefect

One line of sourcecode says more than a thousand words.

Share this post


Link to post
Share on other sites
Never thought about "cheat protection and cheat detection difference.

But, determing if someone is using an aimbot using statistics, it''s not a real use. It''s easy to add a few lines of code that will make the aimbot ''less accurate''... so that it will miss every now and then, so it won''t be determined as a cheater. And, some people are ''that good''... and if the server says they are cheaters, all the other users will agree and they will quit playing. (http://www.gamasutra.com/features/20000724/pritchard_01.htm)
(Also for an detailed description of an aimbot, Tim)

And it might be better to have some extra packets that return data like "your speed is 20"... but if the speed can vary so much... it will increase the packet rate with an enormous amount. If people start to cheat with such things, I can add it... but before it happens, I won''t. btw, my player speed is sent with every position packet...

An ''kick'' option would also be very handy I guess, so that people can vote for people that cheat or misbehave in any other way...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
In my opinion, it is possible to thrawt all cheating and this is how it can be done. Firstly, you must assume that your client is evil, untrustworthy and can send any data it wants to over to your server. Its entirely possible for someone to analyse your network protocol and write their own client and you need to program your server so the client does as little work as possible apart from having to collect user input and display any information the server sends.

The fact that aimbots exist is merely due to the structure and rules of the game. There should be limits placed on the speed the user can turn, and you should be only able to fire in your current direction with a few degrees or so of variation. Checksums merely ensure that the data is intact, and provides little protection against cheating. Simularly, if you encrypt network trafic you have to store the encryption keys in memory somewhere. Thus, further encryption of these keys will need another key to decode that.

I therefor think that you should keep the minimal amount of data on the client, this means game graphics, sounds, and other information. If the client wants to attack another player then it would send a message saying "I want to fire my weapon", the server will then check the last known angle of the player, the last time the player fired to make sure the delay between weapon fire and the attack speed laws are obeyed.

If you design your game and network protocols badly, for example, when you need to attack you say:

"Set player X to Y health points." [BAD]

instead of

"Attack the player that I am facing, then return a boolean telling me whether I hit him and another telling me whether he is dead." [GOOD]

then you will have problems. The difference between those two statements is the first is an assertion where the server must trust information sent by the client. The second tells the server to check its own information and calculate what the effects of that will be, ie, how much health will be lost.

If you follow that rule, the only possible cheats will be the ones where you or other developers make mistakes also known as "exploits" which are usually patched up quickly. Although these programming errors may be hard to detect, they can be solved by organising code carefully and doing structured code reviews to check for the potential exploitation of weakly written or bad code.

In companies where writing secure and robust code is nessasary, often they hire hackers to spend weeks and weeks trying to find exploits and crack the game even with the source code and detailed explaination of how the game works. If under these conditions a skilled hacker finds all of the likely exploitable parts of your code and it is fixed then the chance of something making its way into the release-ready code is very unlikely.

The one or two exploits that make it past the extreme testing and evalutation of the game can easily be caught by detailed logging of game activity and searching through internet for trainers and cheating programs for your game, which is in my opinion one of the most important things you could do to prevent cheats. Once you discover these you can disassemble and analyse them and figure out how they work and thereby fix your servers to prevent that from happening. You can also, threaten to have their internet providers or web hosts shutdown so they cannot supply these cheats. This works well if you act quickly, as when people cannot distribute hacks and trainers the impact of exploits in the game will be reduced greatly.

In conclusion, I think that cheating in a well designed system is nothing to worry about. They are merely bugs or mistakes which can be corrected with time and effort, and in this process you might actually find real bugs in the game that could cause crashes, instability, and other wierdness. Thank you for reading, good bye, and happy coding.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
In my opinion, it is possible to thrawt all cheating and this is how it can be done. Firstly, you must assume that your client is evil, untrustworthy and can send any data it wants to over to your server. Its entirely possible for someone to analyse your network protocol and write their own client and you need to program your server so the client does as little work as possible apart from having to collect user input and display any information the server sends.

The fact that aimbots exist is merely due to the structure and rules of the game. There should be limits placed on the speed the user can turn, and you should be only able to fire in your current direction with a few degrees or so of variation. Checksums merely ensure that the data is intact, and provides little protection against cheating. Simularly, if you encrypt network trafic you have to store the encryption keys in memory somewhere. Thus, further encryption of these keys will need another key to decode that.

I therefor think that you should keep the minimal amount of data on the client, this means game graphics, sounds, and other information. If the client wants to attack another player then it would send a message saying "I want to fire my weapon", the server will then check the last known angle of the player, the last time the player fired to make sure the delay between weapon fire and the attack speed laws are obeyed.

If you design your game and network protocols badly, for example, when you need to attack you say:

"Set player X to Y health points." [BAD]

instead of

"Attack the player that I am facing, then return a boolean telling me whether I hit him and another telling me whether he is dead." [GOOD]

then you will have problems. The difference between those two statements is the first is an assertion where the server must trust information sent by the client. The second tells the server to check its own information and calculate what the effects of that will be, ie, how much health will be lost.

If you follow that rule, the only possible cheats will be the ones where you or other developers make mistakes also known as "exploits" which are usually patched up quickly. Although these programming errors may be hard to detect, they can be solved by organising code carefully and doing structured code reviews to check for the potential exploitation of weakly written or bad code.

In companies where writing secure and robust code is nessasary, often they hire hackers to spend weeks and weeks trying to find exploits and crack the game even with the source code and detailed explaination of how the game works. If under these conditions a skilled hacker finds all of the likely exploitable parts of your code and it is fixed then the chance of something making its way into the release-ready code is very unlikely.

The one or two exploits that make it past the extreme testing and evalutation of the game can easily be caught by detailed logging of game activity and searching through internet for trainers and cheating programs for your game, which is in my opinion one of the most important things you could do to prevent cheats. Once you discover these you can disassemble and analyse them and figure out how they work and thereby fix your servers to prevent that from happening. You can also, threaten to have their internet providers or web hosts shutdown so they cannot supply these cheats. This works well if you act quickly, as when people cannot distribute hacks and trainers the impact of exploits in the game will be reduced greatly.

In conclusion, I think that cheating in a well designed system is nothing to worry about. They are merely bugs or mistakes which can be corrected with time and effort, and in this process you might actually find real bugs in the game that could cause crashes, instability, and other wierdness. Thank you for reading, good bye, and happy coding.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
In my opinion, it is possible to thrawt all cheating and this is how it can be done. Firstly, you must assume that your client is evil, untrustworthy and can send any data it wants to over to your server. Its entirely possible for someone to analyse your network protocol and write their own client and you need to program your server so the client does as little work as possible apart from having to collect user input and display any information the server sends.

The fact that aimbots exist is merely due to the structure and rules of the game. There should be limits placed on the speed the user can turn, and you should be only able to fire in your current direction with a few degrees or so of variation. Checksums merely ensure that the data is intact, and provides little protection against cheating. Simularly, if you encrypt network trafic you have to store the encryption keys in memory somewhere. Thus, further encryption of these keys will need another key to decode that.

I therefor think that you should keep the minimal amount of data on the client, this means game graphics, sounds, and other information. If the client wants to attack another player then it would send a message saying "I want to fire my weapon", the server will then check the last known angle of the player, the last time the player fired to make sure the delay between weapon fire and the attack speed laws are obeyed.

If you design your game and network protocols badly, for example, when you need to attack you say:

"Set player X to Y health points." [BAD]

instead of

"Attack the player that I am facing, then return a boolean telling me whether I hit him and another telling me whether he is dead." [GOOD]

then you will have problems. The difference between those two statements is the first is an assertion where the server must trust information sent by the client. The second tells the server to check its own information and calculate what the effects of that will be, ie, how much health will be lost.

If you follow that rule, the only possible cheats will be the ones where you or other developers make mistakes also known as "exploits" which are usually patched up quickly. Although these programming errors may be hard to detect, they can be solved by organising code carefully and doing structured code reviews to check for the potential exploitation of weakly written or bad code.

In companies where writing secure and robust code is nessasary, often they hire hackers to spend weeks and weeks trying to find exploits and crack the game even with the source code and detailed explaination of how the game works. If under these conditions a skilled hacker finds all of the likely exploitable parts of your code and it is fixed then the chance of something making its way into the release-ready code is very unlikely.

The one or two exploits that make it past the extreme testing and evalutation of the game can easily be caught by detailed logging of game activity and searching through internet for trainers and cheating programs for your game, which is in my opinion one of the most important things you could do to prevent cheats. Once you discover these you can disassemble and analyse them and figure out how they work and thereby fix your servers to prevent that from happening. You can also, threaten to have their internet providers or web hosts shutdown so they cannot supply these cheats. This works well if you act quickly, as when people cannot distribute hacks and trainers the impact of exploits in the game will be reduced greatly.

In conclusion, I think that cheating in a well designed system is nothing to worry about. They are merely bugs or mistakes which can be corrected with time and effort, and in this process you might actually find real bugs in the game that could cause crashes, instability, and other wierdness. Thank you for reading, good bye, and happy coding.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
In my opinion, it is possible to thrawt all cheating and this is how it can be done. Firstly, you must assume that your client is evil, untrustworthy and can send any data it wants to over to your server. Its entirely possible for someone to analyse your network protocol and write their own client and you need to program your server so the client does as little work as possible apart from having to collect user input and display any information the server sends.

The fact that aimbots exist is merely due to the structure and rules of the game. There should be limits placed on the speed the user can turn, and you should be only able to fire in your current direction with a few degrees or so of variation. Checksums merely ensure that the data is intact, and provides little protection against cheating. Simularly, if you encrypt network trafic you have to store the encryption keys in memory somewhere. Thus, further encryption of these keys will need another key to decode that.

I therefor think that you should keep the minimal amount of data on the client, this means game graphics, sounds, and other information. If the client wants to attack another player then it would send a message saying "I want to fire my weapon", the server will then check the last known angle of the player, the last time the player fired to make sure the delay between weapon fire and the attack speed laws are obeyed.

If you design your game and network protocols badly, for example, when you need to attack you say:

"Set player X to Y health points." [BAD]

instead of

"Attack the player that I am facing, then return a boolean telling me whether I hit him and another telling me whether he is dead." [GOOD]

then you will have problems. The difference between those two statements is the first is an assertion where the server must trust information sent by the client. The second tells the server to check its own information and calculate what the effects of that will be, ie, how much health will be lost.

If you follow that rule, the only possible cheats will be the ones where you or other developers make mistakes also known as "exploits" which are usually patched up quickly. Although these programming errors may be hard to detect, they can be solved by organising code carefully and doing structured code reviews to check for the potential exploitation of weakly written or bad code.

In companies where writing secure and robust code is nessasary, often they hire hackers to spend weeks and weeks trying to find exploits and crack the game even with the source code and detailed explaination of how the game works. If under these conditions a skilled hacker finds all of the likely exploitable parts of your code and it is fixed then the chance of something making its way into the release-ready code is very unlikely.

The one or two exploits that make it past the extreme testing and evalutation of the game can easily be caught by detailed logging of game activity and searching through internet for trainers and cheating programs for your game, which is in my opinion one of the most important things you could do to prevent cheats. Once you discover these you can disassemble and analyse them and figure out how they work and thereby fix your servers to prevent that from happening. You can also, threaten to have their internet providers or web hosts shutdown so they cannot supply these cheats. This works well if you act quickly, as when people cannot distribute hacks and trainers the impact of exploits in the game will be reduced greatly.

In conclusion, I think that cheating in a well designed system is nothing to worry about. They are merely bugs or mistakes which can be corrected with time and effort, and in this process you might actually find real bugs in the game that could cause crashes, instability, and other wierdness. Thank you for reading, good bye, and happy coding.

Share this post


Link to post
Share on other sites
In my opinion, it is possible to thrawt all cheating and this is how it can be done. Firstly, you must assume that your client is evil, untrustworthy and can send any data it wants to over to your server. Its entirely possible for someone to analyse your network protocol and write their own client and you need to program your server so the client does as little work as possible apart from having to collect user input and display any information the server sends.

The fact that aimbots exist is merely due to the structure and rules of the game. There should be limits placed on the speed the user can turn, and you should be only able to fire in your current direction with a few degrees or so of variation. Checksums merely ensure that the data is intact, and provides little protection against cheating. Simularly, if you encrypt network trafic you have to store the encryption keys in memory somewhere. Thus, further encryption of these keys will need another key to decode that.

I therefor think that you should keep the minimal amount of data on the client, this means game graphics, sounds, and other information. If the client wants to attack another player then it would send a message saying "I want to fire my weapon", the server will then check the last known angle of the player, the last time the player fired to make sure the delay between weapon fire and the attack speed laws are obeyed.

If you design your game and network protocols badly, for example, when you need to attack you say:

"Set player X to Y health points." [BAD]

instead of

"Attack the player that I am facing, then return a boolean telling me whether I hit him and another telling me whether he is dead." [GOOD]

then you will have problems. The difference between those two statements is the first is an assertion where the server must trust information sent by the client. The second tells the server to check its own information and calculate what the effects of that will be, ie, how much health will be lost.

If you follow that rule, the only possible cheats will be the ones where you or other developers make mistakes also known as "exploits" which are usually patched up quickly. Although these programming errors may be hard to detect, they can be solved by organising code carefully and doing structured code reviews to check for the potential exploitation of weakly written or bad code.

In companies where writing secure and robust code is nessasary, often they hire hackers to spend weeks and weeks trying to find exploits and crack the game even with the source code and detailed explaination of how the game works. If under these conditions a skilled hacker finds all of the likely exploitable parts of your code and it is fixed then the chance of something making its way into the release-ready code is very unlikely.

The one or two exploits that make it past the extreme testing and evalutation of the game can easily be caught by detailed logging of game activity and searching through internet for trainers and cheating programs for your game, which is in my opinion one of the most important things you could do to prevent cheats. Once you discover these you can disassemble and analyse them and figure out how they work and thereby fix your servers to prevent that from happening. You can also, threaten to have their internet providers or web hosts shutdown so they cannot supply these cheats. This works well if you act quickly, as when people cannot distribute hacks and trainers the impact of exploits in the game will be reduced greatly.

In conclusion, I think that cheating in a well designed system is nothing to worry about. They are merely bugs or mistakes which can be corrected with time and effort, and in this process you might actually find real bugs in the game that could cause crashes, instability, and other wierdness. Thank you for reading, good bye, and happy coding.

Share this post


Link to post
Share on other sites
Uh, it is not as simple as that.

How do you stop the client from say turning the walls transparent?

How do you put a limit on the speed which the person can turn without making the game sluggish, or making it possible for an aimbot to work anyway since the allowed speed is too high?

While assuming the client is evil is a start, it is by no means the end all solution. When the player has their skill level increased by means of another program, it could still be following all the rules of the game, yet it is still cheating.

The idea is to make it harder for a person to be able to manipulate the state of the game through external software.

Trying is the first step towards failure.

Share this post


Link to post
Share on other sites
quote:

How do you put a limit on the speed which the person can turn without making the game sluggish, or making it possible for an aimbot to work anyway since the allowed speed is too high?



The client can use a local variable (which is Xorred, or something), if the server detects the speed of the player is higher than the maximum allowed speed, it will perform an action like telling everyone that he is a cheater, disconnect him, or whatever...

quote:

While assuming the client is evil is a start, it is by no means the end all solution. When the player has their skill level increased by means of another program, it could still be following all the rules of the game, yet it is still cheating.



Yes. And that''s the biggest problem of all IMO, since the server doesn''t know, but the players can probably see it. Based on statistics the server can detect him as a cheater, but the statistics system... I don''t like it.
That''s why it has to be hard to cheat the game...

Share this post


Link to post
Share on other sites
Just a thought on AimBots

MOST aimbots use a OpenGL32.dll pasthru, this gives the aimbot an awful lot of information about whats happening in the game as it can intercept/modify every opengl call made, a clever programmer can get it to recognise the display lists, or vertex arrays for player models even bullets. Hence getting a bot to regognise objects in the game is a cinch, so all we have to do now is get the current position of where were aiming (oh wait, the game renders a crosshair :o) and jsut adjust out mouse input until were on our target.

THE SOLUTION

Always statically link OpenGL too your game, this way the game will break if the opengl32.dll is altered or replaced.

Most older games are dynamically linked so 3dfx miniGL''s could be used i belive this is no longer needed.

Share this post


Link to post
Share on other sites
Sorry for the double (or more) post, but you are wrong and it is possible to solve it, first for your questions...

Q) How do you stop the client from say turning the walls transparent?

A) Well, firstly, you send the locations of objects which can be seen only, if the walls are transparent that doesnt matter. The client will just be moving in its own dream world, and the server will say "You are here, stop moving into the wall", then again "Stop telling me you are in the wall, you are over here" and finally "You are sending me crap data, you are disconnected, Thank You, Come again". Simple! Its called running the game in the server and telling the client ONLYwhat it NEEDS to know.

Q) How do you put a limit on the speed which the person can turn without making the game sluggish, or making it possible for an aimbot to work anyway since the allowed speed is too high?

A) Firstly, the rate at which you turn is based on time mainly, which is universal. You keep track of the persons angle on the server and the client will send delta values such as "I want to turn right by a specail predefined angle which is programmed in", the server will say "Okay your angle is xxx", if the client just changes its own angle without agreeing with the server then thats its problem. It will be showing the world incorrectly and will be (what i like to call) hullucinating or desyncing. Eventually the server will not understand what its trying to do and disconnect you for telling it crap.

Q) While assuming the client is evil is a start, it is by no means the end all solution. When the player has their skill level increased by means of another program, it could still be following all the rules of the game, yet it is still cheating.

"The idea is to make it harder for a person to be able to manipulate the state of the game through external software."

Listen to yourself, im telling you that the STATE OF THE GAME should be stored on the server alone. The entire game engine should be on the server. The client should be told what happens in the world, and only what it needs to know, and finally should be able to send in a limited amount of data. If only the server can access the data its alot more safer than if you have a client that can be reverse engineered and such, and trust me, its possible and happens with so many commercial games. The difference between games like Diablo and Diablo 2 is that the former has all the RESPONSIBILITIES of maintaining the game state spread out between all clients. Whereas the latter has the server or realm possess all the RESPONSIBILITIES of maintaining the game state. Its all about responsibility, if a client can change a value directly and influence other clients, then it can be used as a weakness. If only a server can do that, and clients indirectly affect this by feeding input to it then its alot stronger.

In conclusion, I say that you can secure your game up alot just by having your server take 100% responsibility for everything. And have the clients as zombies which just sends basic actions and displays images based on data packets. If you want to know whether your game can be cheated then check all outgoing packets with a network monitor. If anything it sends has any affect on other clients or the server directly then its bad, but if its just a simple abstract action which can be refuted by the server or other clients then its good. I cant explain it any better than that, but if you follow rules like that you can create something that is as secure as it will get. And by following my other advice, its just a matter of paying attention and maintaining your game and keeping it working with patches and security fixes.

Share this post


Link to post
Share on other sites
1) Well, realistically you can''t only send the stuff that''ll be on the client''s screen due to ping times. You should always send just a bit more than is actually needed, otherwise there could be strange artifacts.

2) You can''t limit the rate of turn. Some people just set their mouse sensitivity incredibly high, allowing them a 180° turn in what would probably be put into a single network packet.

3) The issue isn''t manipulating the data, it''s accessing it. And you will always have to expose what''s on the screen, plus a little bit more (see above). Voila it''s possible to get at player coordinates and write an aimbot.

I didn''t know that most aimbots used opengl pass-throughs. Quake aimbots certainly used mostly proxies (but then, the source code and thus the protocol of Quake is open). Statically linking to opengl32.dll is not an option because you just can''t link statically to a DLL. Furthermore, the opengl lib is driver dependant on some architectures.

cu,
Prefect

One line of sourcecode says more than a thousand words.

Share this post


Link to post
Share on other sites
So... for example in Unreal Tournament you can choose different drivers, GlideFX, Direct3D, OpenGL.

Now if the ''cheater'' uses OpenGL, he can simply get information from the driver using that special program? Hmm... creative solution.

But I agree with Prefect...accessing the data is the actual problem.

Share this post


Link to post
Share on other sites