First,
I want to indicate that I know that any information sent from the client cannot be trusted as it can be spoofed. I am interested in methods of security through obscurity to deter 99.9% of potential cheaters and ability to detect programs that do get around the security in real time.
Some ideas I had for this included verifying file and memory check-sums of both the game it is securing and also any potential cheat apps by allowing the client-side to scan on request from the server (via TCP), both for detecting memory injection cheats and or a cheats memory footprint. Therefore the bypass hack would have to listen for all TCP information being sent to it on SSL, and then unencrypt the message by disassembling the encryption/decryption function to understand what it wants. Similarly, the client itself may be self changing and allow for it to add/remove features as needed at random (but keep by the server) so that it would be hard for a cheat to learn how to bypass it. This may be pointless?
I only find this to be moderately difficult for the more experienced, so I am open to other methods that may be hard to bypass.
I am only interested in possible implementations and not how it's impossible to have a client-side anticheat, I just want to make it really really hard.
Added minecraft and java tag, and it's for Minecraft, and I know the community is large enough that someone is likely to beat my system, but I hope through the use of constant updates and changes that I can beat them through ingenuity and perseverance.
Edit: I found this post: How to prevent cheating in our (multiplayer) games? and I am adding his suggestions so not to duplicate things, as I am looking for more ideas than the obvious (and I am not sure if his aren't bypassable)
1) Open all other processes, and hook their WriteProcessMemory functions so that they can't write to the memory in your game's process. Done right this one step will block 90% of all cheats and cheat engines.
2) Do the same thing, hooking the various mouse and keyboard emulation functions. This will prevent a lot of aimbots and other types of automation bots.
3) Hook into the VirtualProtectEx/VirtualAllocEx/etc functions in your game's own process and monitor which modules are changing protection levels or allocating new memory chunks. You have to be crafty with this in order to prevent it from being too CPU intensive when your game does a lot of allocations, but it can be done.
4) Hook into the LoadLibrary functions and monitor any DLLs that are being loaded dynamically, to prevent DLL injection.
5) Use some lightweight polymorphic encoding on your game connections.
6) Use some anti-debugging techniques to prevent debuggers from attaching to your processes. Google anti-debugging and you should be able to find lots of stuff.
7) Use a custom proprietary PE packer to prevent useful disassembly of your game.
8) Hook into your OpenGL or Direct3D functions and methods that deal with transparency and alpha blending.
9) If using shaders, checksum your shaders and the shader constant values.
10) Use additional occlusion culling techniques on player characters to prevent them from being rendered at all when the line of sight to them is blocked by other geometry. It may or may not help with your performance also, but it will prevent many wallhacks.
If you want your customer to respect you and the game, you should be respectful of your customer and realize what you see as a game client machine may be used to store valuable information.
allowing the client-side to scan any part of memory given at random by the server
the client itself may be self changing and allow for it to add/remove features as needed at random
Just be careful you're not opening an attack vector into the clients machine. Reading "any part of memory given at random" sounds scary. You could make it less so by hashing a (not small) block of memory and checking for a known value.
Letting the server send "random" code is probably going to make your software look like a virus/botnet to anti-virus/security tools. It also leaves the client wide open to potential exploit.
Update:
1) Open all other processes, and hook their WriteProcessMemory functions
If you do this, and you have a bug in the injected code, you could destabilize your customer's entire machine. This seems aggressive. And what version of Windows are you running on? With what permissions? I'm pretty sure a cracker could arrange to run his exploit from a process you don't have permission to hook (like an admin process where you're running in a normal user process). Also you'll need to hook GetProcAddress for obvious reasons.
4) Hook into the LoadLibrary functions and monitor any DLLs that are being loaded dynamically, to prevent DLL injection.
This one's not as bad as it sounds because you only need to do this in the local process.
6) Use some anti-debugging techniques to prevent debuggers from attaching to your processes.
Certainly worth doing (if you have the time), but it's just a speed bump for an experienced cracker. Remember he can always trace your code from startup and observe or bypass your anti-debugging. (It takes time but some crackers enjoy this.)
7) Use a custom proprietary PE packer to prevent useful disassembly of your game.
This is another one that's going to get you noticed by Anti-Virus software.
I personally don't think that it make sense to observe the memory and so on. I could imagine that you need to handle it also when somebody implements the protocoll and makes some crap wich may also let your server crash.
But you are right that it is possible to check the memory for bad software which is typically used by cheaters e.g. like wallhacks in egoshooters.
IMHO you need to check if the data from the client looks valid and react than on cheating.
About your update:
Please don't hook all other progamms this is a little crazy and also it may let your programm to be detected as a root kit or something like that.
I completely agree with what the other folks here say -- some of these (opening all other processes and hooking WriteProcessMemory, mouse/keyboard emulation functions) are crazy and ludicrous -- especially since the user can bypass this by dropping privileges to your process. Doing this will most certainly inspire ire from some users.
But if you really want to go all out and do crazy stuff like malware, why not write a kernel driver which patches the Protected flag (for Windows Vista and later) or patch OpenProcess? The latter is a more common approach (seen in AV software and malware); the prior is less common, but still doable -- if you can load a KMD, you can patch the flags and bypass the Microsoft signature requirement.
来源：https://stackoverflow.com/questions/13826786/how-to-secure-client-side-anti-cheat