   Preventing cheating (Python & Twisted)
  I'm just getting started on my first multiplayer network game.After some research I'm leaning towards using Python and Twisted (if any of you would recommend otherwise, I'd love to hear about it).  I'm pretty knowledgeable and experienced with C++, and plan to handle graphics & other data-intensive stuff with C++.  I'm going to use Python for the higher-level logic and anything not data-intensive (for the sake of quicker development time).  Since I naturally want to minimize the game data that needs to be sent over the network, the networking stuff seems to belong on my Python side.My main concern is what I can do to minimize cheating.  I know... hackers will always find a way, but are there known best practices I can use to minimize this?  Unlike compiled C++ code, Python scripts are very accessible...  If the code that handles the networking is in the Python scripts, it seems easy for users to glance at it, change a few things on the client end, and get higher scores as a result.Any tips on minimizing cheating?  And any general multiplayer networking advice to someone just getting started in this aspect of game programming (though fairly experienced in other areas)?   
  The Forum FAQ has some pointers. Unfortunately, the real answer is something like "use a server and put all rules determination on the server," so if your game is P2P, that won't help much.Some people put important values (stats, hitpoints, gold, random seeds etc) in a class that "shrouds" the value by XOR-ing it or similar in memory. This will help with naive RAM scanners. Also, some people will store the data in more than one place, and verify that they update in sync. However, doing all this from Python is a lot harder (although you could turn every quantity into a python property...);  Thanks for the reply.  That was the impression I had gotten: keeping the important stuff on the server is the only way to prevent tampering.  Next best thing: make client data encrypted/confusing/obfuscated...  This won't prevent cheating, but weeds out the casual, lazy cheaters.   ;  I have had to deal a lot with hackers and cheaters in an online RPG I wrote. You do for sure want to keep as many decisions on the server as possible. Confirm that all packets are correct with a check sum value and encrypt the packets.I had a problem with a guy who was using a decompiler to get at my code so he could get at my encryption/decryption functions. I then used Themida to protect my EXE. I would recommend against using Themida as I found out people who write viruses use Themida to obfuscate their code to trick virus scanners. As a result a lot of virus scanners will catch any program protected with Themida and consider it a virus. Other EXE protectors may have the same problem.;Quote:Original post by hplus0603The Forum FAQ has some pointers. Unfortunately, the real answer is something like "use a server and put all rules determination on the server," so if your game is P2P, that won't help much.Some people put important values (stats, hitpoints, gold, random seeds etc) in a class that "shrouds" the value by XOR-ing it or similar in memory. This will help with naive RAM scanners. Also, some people will store the data in more than one place, and verify that they update in sync. However, doing all this from Python is a lot harder (although you could turn every quantity into a python property...)You could also have each peer maintain a an internal state and periodically check the consistency between the various peers to ensure that they all match. This doesn't necessarily prevent cheating (again), but it does make it a bit harder.   ;Quote: Confirm that all packets are correct with a check sum value and encrypt the packetsEncryption doesn't really help -- as you say, users will disassemble the running code. They have to be able to do that, else the CPU couldn't run the code. VMWare and similar virtualization tools makes client-side mitigation fruitless.Instead, you have to make sure that your network packet handling is 100% bulletproof. A checksum doesn't really help. However, verifying each and every field of each and every packet will help. As well as verifying that packets decode correctly: suppose someone sends the data "here comes 10 bytes" but then sends 100 bytes of crap, or sends the data "here comes 10,000 bytes" but your internal buffer is only 256 bytes. You have to deal with all those kinds of problems.A good way of testing your code is to run a special client which, at some point, starts sending the output of rand() instead of real packets, and make sure that the server doesn't crash, no matter how many times clients like those connect.;Quote:Original post by hplus0603Quote: Confirm that all packets are correct with a check sum value and encrypt the packetsEncryption doesn't really help -- as you say, users will disassemble the running code. They have to be able to do that, else the CPU couldn't run the code. VMWare and similar virtualization tools makes client-side mitigation fruitless.Instead, you have to make sure that your network packet handling is 100% bulletproof. A checksum doesn't really help. However, verifying each and every field of each and every packet will help. As well as verifying that packets decode correctly: suppose someone sends the data "here comes 10 bytes" but then sends 100 bytes of crap, or sends the data "here comes 10,000 bytes" but your internal buffer is only 256 bytes. You have to deal with all those kinds of problems.A good way of testing your code is to run a special client which, at some point, starts sending the output of rand() instead of real packets, and make sure that the server doesn't crash, no matter how many times clients like those connect.Aye, and you have to make sure you take appropriate action too, just disconnecting the end user if they send bad data isn't always a good idea... sometimes you will get bad data and your checksums will all match up. Other times it will be intentional... this is where having things like error metrics can help.   ;  If you are trying to prevent bot development is pretty much impossible.With the right tools your .exe and packets can be reversed engineered.Even easier than creating a "Protocol" robot is to create a GUI robot which doesn't even need to know what's in the packets cause it will emulate the user through Windows messages.   ;Quote:Original post by hiigaraIf you are trying to prevent bot development is pretty much impossible.With the right tools your .exe and packets can be reversed engineered.Even easier than creating a "Protocol" robot is to create a GUI robot which doesn't even need to know what's in the packets cause it will emulate the user through Windows messages.And with just tiny variations in input times + lag, it is impossible to tell from the server side if the bot is a human player or not. Even sending PMs and other things can be handled.A good example is EvE online, where bots were able to successfully mine and/or run missions for long periods of time (23 hours a date...then downtime!) with little need for human interaction. They would run the missions, loot them, return to station, deposit the items, get another mission, go out, and repeat.You would then just have other bots that would collect all that gear, aggregate it at a trade hub and either reprocess it for base materials, or sell it in bulk on the market.   ;  Yes encryption does help, and yes having a check sum helps. It depends on the skill level of the hacker. Every level of defense helps. I have had experience where these things have for sure helped stop hackers.By hackers I'm also including people who use packet sniffers and different cheat programs to send packets to the server. Many people don't have the ability to understand decompiled code and they will have problems with encrypted packets. If you don't encrypt then the door is wide open to them and they will use it.   