Client integrity - several questions!
by Kevin Krumwiede · in Torque Game Engine · 03/04/2005 (4:45 am) · 4 replies
I'm considering using TGE to test some design ideas in a relatively simple MUD/MORPG. Developing a robust multi-layered security model is one of the major goals of this experiment. Given the number of griefers and asshats out there, I'm concerned about the kinds of attacks that could be mounted against the game engine, and what steps could be taken to deter them. I'm thinking of exploits like replacing models and textures, adding unintended components to the GUI, or creating a bot client.
Examining the demo, I see that the client-side scripts are distributed as source. Is this a necessity, or can scripts be distributed in object format? If so, how resistant would they be to decompilation?
Is there a hook in the client code for some kind of resource integrity check?
How generic is the communication between the client and the server? Would it be trivial for someone with a TGE license to build their own client for my game?
How hard would it be to wrap all the network communication in SSL?
Thanks,
Krum
Examining the demo, I see that the client-side scripts are distributed as source. Is this a necessity, or can scripts be distributed in object format? If so, how resistant would they be to decompilation?
Is there a hook in the client code for some kind of resource integrity check?
How generic is the communication between the client and the server? Would it be trivial for someone with a TGE license to build their own client for my game?
How hard would it be to wrap all the network communication in SSL?
Thanks,
Krum
#2
1) As Stefan pointed out, you have complete control over what functionality the final client has. First, .cs files do NOT need to be released. Torque byte-code compiles .cs files into .cs.dso files (not human readible) at runtime, and all you need to do is to release these. Finally, as Stefan did, you don't even have to release these, you can put the functionality directly into the .exe (although to be honest, I personally don't know how he did that).
2) During client connection to a server, it has checksum hooks for all of the files/functionality the dedicated server expects the client to have (including the exe itself). This wasn't put in as a security measure, but simply to make sure the client has the most recent/synchronized version before they are allowed to connect. It can, however, be expanded/enhanced to provide stronger security.
3) Torque's initial connection sequence is designed to validate the connecting client via a handshaking process (see my writeup on the connection sequence in the Resources section if/when you purchase the license). This handles most client spoofing attempts.
4) Torque's networking model is designed (if used properly) to handle most of the common "hacks" that players have been known to use. Specifically, (again, as long as you design and implement your project properly) the client does nothing more than render, and send moves to the server--the server is responsible for all game mechanic implementation. The client doesn't even know the "actual server id" of any of the game objects at all--it is told what it's own, personal id's are for objects, and the server maps each client's object id's to the true server id's before doing any work.
5) "bots" are a special case, because the most common technique used now in online gaming is to run an app that captures mouse inputs and keyboard inputs, and then scripts them into a sequence. The app is then used to carry out this sequence over and over again, sending the inputs to the OS, which then hand them off to the game client as if they were entered by a "real" player. There is nothing from a technology perspective that Torque (or any other client) can do to stop this, since it's outside of the Torque client app completely. Higher level game design is needed to handle this case.
6) TGE primarily uses UDP instead of TCP/IP for all game packet traffic (this is pretty standard by the way), so SSL isn't -really- applicable. You could certainly (and quickly) add in packet encryption if you know what you are doing with lower level net code.
7) Just recently a resource was released to store all of your client (or even server) info in encrypted containers, which I think is a very good step forward on client file security, but you really need to keep in mind one thing: they (client hackers) have ALL the time, ALL the resources, and ALL the interest to do whatever they can to "hack" your client--and they will! If you realize from the beginning that the client is NEVER to be trusted, and design accordingly, you'll be in very good shape!
03/04/2005 (6:44 am)
Stefan kind of hits on the fact that as a test/demo/tech validation, security is one of the harder things to do--mostly because a lot of what you do is part of distribution and release of the game itself. I'll try to cover some of the things that aren't readily apparent about Torque that will help you feel a lot better about security:1) As Stefan pointed out, you have complete control over what functionality the final client has. First, .cs files do NOT need to be released. Torque byte-code compiles .cs files into .cs.dso files (not human readible) at runtime, and all you need to do is to release these. Finally, as Stefan did, you don't even have to release these, you can put the functionality directly into the .exe (although to be honest, I personally don't know how he did that).
2) During client connection to a server, it has checksum hooks for all of the files/functionality the dedicated server expects the client to have (including the exe itself). This wasn't put in as a security measure, but simply to make sure the client has the most recent/synchronized version before they are allowed to connect. It can, however, be expanded/enhanced to provide stronger security.
3) Torque's initial connection sequence is designed to validate the connecting client via a handshaking process (see my writeup on the connection sequence in the Resources section if/when you purchase the license). This handles most client spoofing attempts.
4) Torque's networking model is designed (if used properly) to handle most of the common "hacks" that players have been known to use. Specifically, (again, as long as you design and implement your project properly) the client does nothing more than render, and send moves to the server--the server is responsible for all game mechanic implementation. The client doesn't even know the "actual server id" of any of the game objects at all--it is told what it's own, personal id's are for objects, and the server maps each client's object id's to the true server id's before doing any work.
5) "bots" are a special case, because the most common technique used now in online gaming is to run an app that captures mouse inputs and keyboard inputs, and then scripts them into a sequence. The app is then used to carry out this sequence over and over again, sending the inputs to the OS, which then hand them off to the game client as if they were entered by a "real" player. There is nothing from a technology perspective that Torque (or any other client) can do to stop this, since it's outside of the Torque client app completely. Higher level game design is needed to handle this case.
6) TGE primarily uses UDP instead of TCP/IP for all game packet traffic (this is pretty standard by the way), so SSL isn't -really- applicable. You could certainly (and quickly) add in packet encryption if you know what you are doing with lower level net code.
7) Just recently a resource was released to store all of your client (or even server) info in encrypted containers, which I think is a very good step forward on client file security, but you really need to keep in mind one thing: they (client hackers) have ALL the time, ALL the resources, and ALL the interest to do whatever they can to "hack" your client--and they will! If you realize from the beginning that the client is NEVER to be trusted, and design accordingly, you'll be in very good shape!
#3
I agree. You can't do much against this except build the game in a way so it more or less makes the bots useless.
I modified this resource to fit my needs. Hope it helps.
03/04/2005 (6:52 am)
Quote:
5) "bots" are a special case, because the most common technique used now in online gaming is to run an app that captures mouse inputs and keyboard inputs, and then scripts them into a sequence. The app is then used to carry out this sequence over and over again, sending the inputs to the OS, which then hand them off to the game client as if they were entered by a "real" player. There is nothing from a technology perspective that Torque (or any other client) can do to stop this, since it's outside of the Torque client app completely. Higher level game design is needed to handle this case.
I agree. You can't do much against this except build the game in a way so it more or less makes the bots useless.
Quote:1) As Stefan pointed out, you have complete control over what functionality the final client has. First, .cs files do NOT need to be released. Torque byte-code compiles .cs files into .cs.dso files (not human readible) at runtime, and all you need to do is to release these. Finally, as Stefan did, you don't even have to release these, you can put the functionality directly into the .exe (although to be honest, I personally don't know how he did that).
I modified this resource to fit my needs. Hope it helps.
#4
03/04/2005 (7:47 pm)
Thanks for the replies. This is all very reassuring. :o) 
Torque Owner Stefan Lundmark
From what I know, there are basic MD5 checksumming in place for this. This works against the casual player.
If I change a model, and the server doesn't recognize it, I'll be booted. Of course someone could manipulate this to always return the same MD5.
I don't know how you could make it better.
There are no checks in place for this, simply because it is not such a big problem with FPS games which TGE was designed for. I used a few techniques against this, though. When the client is executed, a integrity check was made to check all relevant files, their bytesize and checksum. If the integrity check fails, the engine exits.
If someone would to replace a file anyway and pass the integrity check, somehow: I've modified the DSO's and how they are compiled and structured so that normal TGE DSO's don't work without some hassle. Also, the client can't and doesn't know how to compile these, I've made a seperate TGE build for that.
I've removed most of the DSO scripts (not the GUI's) and placed them inside the executable, instead.
This way they can't be edited in the normal sense, and they can't be replaced. Simple solution, not very effective but works for the time being.
There are many other problems I don't know how to face myself. And honestly, I don't care. Why? Because when I'm done with the game, I'll think about it further. But at the moment, it's so much left to develop that it's just a waste of time to throw hours and hours into these kind of things. But as I understood your original post, your intentions was to test the security for a simple game, so sorry I can't help you better. I find my methods described here to lock out the casual player and the lousy griefer/hacker, but doesn't stop anyone with some knowledge of TGE and how reverse engineering works.
Good luck and happy Torqueing :)