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.
Anti Cheat-tecniques
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.
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.
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.
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.
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.
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.
Author
Check out:
http://www.3dactionplanet.com/features/interviews/xqz2/index.shtml
An interview with someone that made an Aimbot for Counterstrike, and how he did it... might be worth reading...
http://www.3dactionplanet.com/features/interviews/xqz2/index.shtml
An interview with someone that made an Aimbot for Counterstrike, and how he did it... might be worth reading...
Intresting article ajoling.
Here are my thoughts.
Cheating can be defeated by securing all possible paths where the cheater can attack. There are several attack paths the cheater can use, these are:
A)packet protocol
B)clients exe
C)clients resources
D)server flaws
To secure each requires a unqiue solution, for each:
A)packet encryption
B)deeply embeded self checking exes in conjunction to an online exe check (perhaps a daily unique exe download for playing the game)
C)the client has to check and report back to the server, this requires the client to be pure ofcourse. It can check in several ways. Player profiling, data intergerity checks, and others im sure people can think of.
D)packet encryption, secure exe checking, and player tagging should prevent hackers from attacking the server successfully, through proxies, DNS attacks, etc..
The trick is to create a mutually supporting structure so the hacker has to break more than 1 pillar to successfully hack the game, which is much more difficult, but not impossible.
The constantly changing and limited lifespan of the exes prevents, corruption and anaylsis.
The encryption can ofcourse be changed daily with the exes, so no single key would do them good.
The exe builds and key generation process can be automated, an intranet of secure servers can be set up to distribute the exes etc..
The player just joins a secure server, after logging onto a secure website (1 player id / purchase) and demo-players are also tracked and tagged. They download the latest exe in their patch, none the more inconvienced.
It''s an expensive process, but if your game is a multi-million dollar project like HalfLife, it might be worth it.
Good Luck!
-ddn
Here are my thoughts.
Cheating can be defeated by securing all possible paths where the cheater can attack. There are several attack paths the cheater can use, these are:
A)packet protocol
B)clients exe
C)clients resources
D)server flaws
To secure each requires a unqiue solution, for each:
A)packet encryption
B)deeply embeded self checking exes in conjunction to an online exe check (perhaps a daily unique exe download for playing the game)
C)the client has to check and report back to the server, this requires the client to be pure ofcourse. It can check in several ways. Player profiling, data intergerity checks, and others im sure people can think of.
D)packet encryption, secure exe checking, and player tagging should prevent hackers from attacking the server successfully, through proxies, DNS attacks, etc..
The trick is to create a mutually supporting structure so the hacker has to break more than 1 pillar to successfully hack the game, which is much more difficult, but not impossible.
The constantly changing and limited lifespan of the exes prevents, corruption and anaylsis.
The encryption can ofcourse be changed daily with the exes, so no single key would do them good.
The exe builds and key generation process can be automated, an intranet of secure servers can be set up to distribute the exes etc..
The player just joins a secure server, after logging onto a secure website (1 player id / purchase) and demo-players are also tracked and tagged. They download the latest exe in their patch, none the more inconvienced.
It''s an expensive process, but if your game is a multi-million dollar project like HalfLife, it might be worth it.
Good Luck!
-ddn
Author
Hmm, interesting points... I have half of them already in my game 
The updating exe is going me a bit too far. Although It would certainly make the cheat/hack chances lower. But I was going to do some interesting memory CRC checks, and encrypt every important value in the memory. This will probably do well enough
btw, my project is a $0 dollar project Except for the domain name then
Almar
The updating exe is going me a bit too far. Although It would certainly make the cheat/hack chances lower. But I was going to do some interesting memory CRC checks, and encrypt every important value in the memory. This will probably do well enough
btw, my project is a $0 dollar project
Except for the domain name then Almar
With any multiplayer game it is going to be IMPOSSIBLE to ever filter out cheaters. There will always be ways to analyse network protocols, dissasemble exe''s and the like. You can make it hard, yes; But not impossible.
What you can do is also limited by the dial up users. Some of the schemes listed here have been excellent except for one thing. Dial up users cannot check with the server on every single detail. I play games with pings in the area of 300ms. If i were to ask the server whether i could actually turn 60 degrees to the right or move 10 paces forward and then wait for the reply it would take much too long.
As said before, anything put on any computer other than the server can be thought of as tampered with. Crackers can bypass complex copy protection in games in under a day in a lot of cases. They can bypass CRC and other file checks, not to mention any encryption of packets sent to and from the server.
Only giving out what the client needs to know can only go so far. In the case of 3d games, the graphics engine needs to know the locations of the few polygons to be rendered. A clever programmer would be able to piece together much of the world as they walked through it. It would take only a few minutes to map out a complete deathmatch map.
Anyway, i hope that you are able to finally achieve the impossible task of defeating the damn cheaters
-=- eNGIMa -=-
(Its not a spelling mistake damn it !!!)
What you can do is also limited by the dial up users. Some of the schemes listed here have been excellent except for one thing. Dial up users cannot check with the server on every single detail. I play games with pings in the area of 300ms. If i were to ask the server whether i could actually turn 60 degrees to the right or move 10 paces forward and then wait for the reply it would take much too long.
As said before, anything put on any computer other than the server can be thought of as tampered with. Crackers can bypass complex copy protection in games in under a day in a lot of cases. They can bypass CRC and other file checks, not to mention any encryption of packets sent to and from the server.
Only giving out what the client needs to know can only go so far. In the case of 3d games, the graphics engine needs to know the locations of the few polygons to be rendered. A clever programmer would be able to piece together much of the world as they walked through it. It would take only a few minutes to map out a complete deathmatch map.
Anyway, i hope that you are able to finally achieve the impossible task of defeating the damn cheaters
-=- eNGIMa -=-
(Its not a spelling mistake damn it !!!)
Hi all,
This thread is interesting ;-)
One really easy "dynamic" change that could be done is to change the protocal values every day...
ie instead of say 1=Move 2=fire etc.. swap them all arround.. this could easily be done as a very small patch so they may not even notice the download and yeh a pro could then change their bot or whatever to use the new protocal but sad little people who think they are hackers (ie people who use someone elses aim bot) wont have anything that works ;-) and I believe most of the "hackers" cant hack or even program to save their lives :-p
that along with everything else i think you have the best you can get
~Tim
This thread is interesting ;-)
One really easy "dynamic" change that could be done is to change the protocal values every day...
ie instead of say 1=Move 2=fire etc.. swap them all arround.. this could easily be done as a very small patch so they may not even notice the download and yeh a pro could then change their bot or whatever to use the new protocal but sad little people who think they are hackers (ie people who use someone elses aim bot) wont have anything that works ;-) and I believe most of the "hackers" cant hack or even program to save their lives :-p
that along with everything else i think you have the best you can get
~Tim
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement