How to protect your server and client files?
by Jorge Luis Gandulfo · in Torque Game Engine · 04/14/2004 (9:52 pm) · 51 replies
There is any way i can protect my code?
I mean the scripts are there for all to see and modify, also the exe contains both server and client code isnt that a bad thing to distribute?
I can protect the exe with some envelope software i bought, y can use enconding to protect scripts, but still is hard to make a protection for a MMO.
Any suggestions?
Maybe i have to get rid of some of the basic scripts, i dont know.
I mean the scripts are there for all to see and modify, also the exe contains both server and client code isnt that a bad thing to distribute?
I can protect the exe with some envelope software i bought, y can use enconding to protect scripts, but still is hard to make a protection for a MMO.
Any suggestions?
Maybe i have to get rid of some of the basic scripts, i dont know.
#22
I currently have my textures in a zip file (isn't a wad file a fancy form of a zip file). The engine extracts them from the zip file when the game is played. This doesn't stop anyone from unzipping the files offcourse. But you could perform some kind of check on the zip file, or.... pass protect it and even change the file enxtension (but then some c++ changes would be required... I think...). And I'm not only mentioning this for textures, this can be done for the scripts too (Tribes 2 had this too, but they weren't pass protected), but offcourse this would be a bit pointless since you could simply delete the .cs files.
04/16/2004 (4:00 am)
Quote:For me if its possible to WAD (something similar) all the textures without loosing performance
I currently have my textures in a zip file (isn't a wad file a fancy form of a zip file). The engine extracts them from the zip file when the game is played. This doesn't stop anyone from unzipping the files offcourse. But you could perform some kind of check on the zip file, or.... pass protect it and even change the file enxtension (but then some c++ changes would be required... I think...). And I'm not only mentioning this for textures, this can be done for the scripts too (Tribes 2 had this too, but they weren't pass protected), but offcourse this would be a bit pointless since you could simply delete the .cs files.
#23
The biggest threat then becomes the filtering of incoming data, and the protection of the server itself from outside attacks. The list of possible ways to get at a server - denial of service attacks, spoofing data, hacking passwords is far too long to go into, but they all involve one thing - you must present something to the server in order to get something you want back.
Potential misusers of your game have both the client software and the game conent in their physical possession. Given enough time and resources they will get out anything in those portions of game that they want. However, to get anything out of the server part of the game they must present something to the server. So the major part of server construction and the major defense you have, is to carefully filter ALL incoming input and ruthlessly throw away any packet of data that is in the least incorrect, without even telling the client why.
By not telling the client if a packet has been thrown away (and why it was thrown away) you deprive the hacker of vital feedback on the success of his attempts to hack your game. Was the packet thrown away or did it not get thru? Was it filtered out by the firewall, the game server, the database request agent? No feedback makes hacking MUCH more difficult.
This is one of the beauties of UDP for MMO game design. It is intended as a protocol which does not expect acknowledgement. By choosing UDP as the basis for their network communication, torque gained in both speed and security. Had the network protocol been TCP then hackers would have had a big leg up in cracking or sabotaging games like Tribes (not to mention it would have been much slower in fact, probably not even functional).
So in the torque network model the system sends confirmation packets back to the player using UDP packets, in certain circumstances, but even those acknowledgements are expected to be lost occasionally.
A second defense which is related to the server acting as "guardian of the game" is the idea that the server makes ALL critical decisions. While it is typical to have clients announce "I have been hit" in a typical peer-to-peer style game, this can lead to widespread cheating. In the server/client MMO model the server makes all critical decisions for everything from player movement, to combat, to inventory control.
Nothing that the player does in the game should ever be more than a request to the server. The player requests of the server that he move north. The server moves the player. The player requests an inventory list, The server gives him the inventory list. The player requests that the gun be fired at a particular angle and trajectory. The server fires the gun, follows the trajectory and determines if the player hit anything. Again, this is reflected in the torque network model where the player client is a "ghost" of the real client - which only exists on the game server.
The client is, and should be, a passive requestor, in the MMO world.
My 2 cents. Good luck with your MMO - look forward to trying it.
04/16/2004 (4:59 am)
Artistic content in an MMO is essentially unprotectable, as is the client code itself. Your best protection is to isolate essential funcions in server code. So, for example, combat code should take place exclusively on the server where it is less subject to interference. Note that I said "less". Even being on the server does not completely protect your code from interference, but it does help limit the exposure.The biggest threat then becomes the filtering of incoming data, and the protection of the server itself from outside attacks. The list of possible ways to get at a server - denial of service attacks, spoofing data, hacking passwords is far too long to go into, but they all involve one thing - you must present something to the server in order to get something you want back.
Potential misusers of your game have both the client software and the game conent in their physical possession. Given enough time and resources they will get out anything in those portions of game that they want. However, to get anything out of the server part of the game they must present something to the server. So the major part of server construction and the major defense you have, is to carefully filter ALL incoming input and ruthlessly throw away any packet of data that is in the least incorrect, without even telling the client why.
By not telling the client if a packet has been thrown away (and why it was thrown away) you deprive the hacker of vital feedback on the success of his attempts to hack your game. Was the packet thrown away or did it not get thru? Was it filtered out by the firewall, the game server, the database request agent? No feedback makes hacking MUCH more difficult.
This is one of the beauties of UDP for MMO game design. It is intended as a protocol which does not expect acknowledgement. By choosing UDP as the basis for their network communication, torque gained in both speed and security. Had the network protocol been TCP then hackers would have had a big leg up in cracking or sabotaging games like Tribes (not to mention it would have been much slower in fact, probably not even functional).
So in the torque network model the system sends confirmation packets back to the player using UDP packets, in certain circumstances, but even those acknowledgements are expected to be lost occasionally.
A second defense which is related to the server acting as "guardian of the game" is the idea that the server makes ALL critical decisions. While it is typical to have clients announce "I have been hit" in a typical peer-to-peer style game, this can lead to widespread cheating. In the server/client MMO model the server makes all critical decisions for everything from player movement, to combat, to inventory control.
Nothing that the player does in the game should ever be more than a request to the server. The player requests of the server that he move north. The server moves the player. The player requests an inventory list, The server gives him the inventory list. The player requests that the gun be fired at a particular angle and trajectory. The server fires the gun, follows the trajectory and determines if the player hit anything. Again, this is reflected in the torque network model where the player client is a "ghost" of the real client - which only exists on the game server.
The client is, and should be, a passive requestor, in the MMO world.
My 2 cents. Good luck with your MMO - look forward to trying it.
#24
04/16/2004 (6:36 am)
.dso are easily openable with the GUI Editor as long as they actually contain GUI. and then saved to a new file, decompiled and all. so it's not THAT great if you don't do everything separate.
#25
All the .mis, .cs and .gui becomes .dso (I don't use the regular MissionInfo reading) and gets packed inside the executable, in the end the game directory looks like this:
game.exe // UPXed and protected game executable (with all .dso's inside)
DefOpenAl32.dll // Required DLL (OpenAL DirectSound Wrapper)
opengl2d3d.dll // Required DLL
glu2d3d.dll // Required DLL
config.dat // Preferences (custom format, not exec() like prefs.cs)
base.glz // Zip containing all artwork&sound (no compression)
The reason of all this client protection is that I need to trust in some client data, I don't have enough money to support any server (except for the master), so the clients must host a game in his machine and only send the scores to the main server.
Anyone have any idea of how to send scores to a master server preventing fake scores? I've thought of some approachs but no one seems secure enough.
04/16/2004 (8:35 pm)
I've implemented a TORQUE_SECURE compiler directive that strips out the editor, console, telnet, debugger, .dso compilation, .cs reading, object.save(), all development stuff.All the .mis, .cs and .gui becomes .dso (I don't use the regular MissionInfo reading) and gets packed inside the executable, in the end the game directory looks like this:
game.exe // UPXed and protected game executable (with all .dso's inside)
DefOpenAl32.dll // Required DLL (OpenAL DirectSound Wrapper)
opengl2d3d.dll // Required DLL
glu2d3d.dll // Required DLL
config.dat // Preferences (custom format, not exec() like prefs.cs)
base.glz // Zip containing all artwork&sound (no compression)
The reason of all this client protection is that I need to trust in some client data, I don't have enough money to support any server (except for the master), so the clients must host a game in his machine and only send the scores to the main server.
Anyone have any idea of how to send scores to a master server preventing fake scores? I've thought of some approachs but no one seems secure enough.
#26
(Might I add, if you find one, you will probably be able to retire in short order. ;))
04/16/2004 (9:05 pm)
There are no secure possibilities for this.(Might I add, if you find one, you will probably be able to retire in short order. ;))
#27
04/16/2004 (9:35 pm)
Is'nt there a way for (especially for online games) for the server to check all of the files and see if they're correct? And if anyone has messed with them, then you could have them not be granted access, and they would have to visit the support or whatever, if there was another issue.
#28
You can hack the EXE to send the right CRC values all the time, or hack the kernel to intercept file reads and return the right data sometimes, hacked data other times.
Or you can modify the data on the video card after it's been uploaded.
Or you can run a man in the middle attack by using another PC (or a local application).
04/17/2004 (9:16 am)
There are no secure possibilities for this.You can hack the EXE to send the right CRC values all the time, or hack the kernel to intercept file reads and return the right data sometimes, hacked data other times.
Or you can modify the data on the video card after it's been uploaded.
Or you can run a man in the middle attack by using another PC (or a local application).
#29
04/20/2004 (7:06 am)
An idea i had on stopping people changing things for an MMO, is you could compare client files(which they might have changed) to a copy of how they are meant to be on the server, and if they aren't the same don't let them connect. Not sure how you could compare them, maybe by file size?
#30
That's how "loaders" work, for different games.
04/20/2004 (7:26 am)
Daniel... you can still manipulate the data that is sent from the client to always be the same as the server. In MANY ways.That's how "loaders" work, for different games.
#31
04/20/2004 (7:28 am)
The easiest way to protect your client/server files is to never complete your game.
#32
04/20/2004 (8:39 am)
Joshua, that is the security scheme I've been using for a long time now ... :-D
#33
The reason I've been investigating this is because of the same problem everyone describes above, people having access to code is sometimes a very *bad* thing. For example, I wrote a mod back in the days of T2 that sent player stats to a perl script on my webserver. I just included the code to track player ranking (I was using it to restrict equipment and inventory to players with certain "certifications") as a .dso with the distro of my mod... within a few weeks people were using packet sniffers and hex editors to send my server fake packets and giving themselves instant-unlocks on equipment. Of course this is disheartening, but methods like Checksums (MD5 is my personal favorite) and such can be used to prevent editing of files (a really simple method for checking for packet editing is to simply include an MD5 checksum of the packet WITH the packet, then compute it on the server and check the checksum, anyone with the intention to get around it will do so easily, but it can keep the small-time punks from messing with it). In addition, you can also use various methods of encryption, but be aware that those also take up processor overhead on both client and server, how much is entirely dependant upon the level of encryption you want to use.
I don't think there is any concrete, solid way of preventing people from modifying content, cracking protection, using keygens etc., but I do think they're worthwhile to pursue.
My 2(0) cents,
Jeff
(sorry for the length of the post, had a lot to spill)
04/20/2004 (9:13 am)
Hate to tell you guys, but even .dso files aren't entirely secure, I've seen a method in action for exporting datablocks from .dso's (so to speak, technically this is not the case but I'd rather avoid going into the method used to avoid this becoming a widely used technique).The reason I've been investigating this is because of the same problem everyone describes above, people having access to code is sometimes a very *bad* thing. For example, I wrote a mod back in the days of T2 that sent player stats to a perl script on my webserver. I just included the code to track player ranking (I was using it to restrict equipment and inventory to players with certain "certifications") as a .dso with the distro of my mod... within a few weeks people were using packet sniffers and hex editors to send my server fake packets and giving themselves instant-unlocks on equipment. Of course this is disheartening, but methods like Checksums (MD5 is my personal favorite) and such can be used to prevent editing of files (a really simple method for checking for packet editing is to simply include an MD5 checksum of the packet WITH the packet, then compute it on the server and check the checksum, anyone with the intention to get around it will do so easily, but it can keep the small-time punks from messing with it). In addition, you can also use various methods of encryption, but be aware that those also take up processor overhead on both client and server, how much is entirely dependant upon the level of encryption you want to use.
I don't think there is any concrete, solid way of preventing people from modifying content, cracking protection, using keygens etc., but I do think they're worthwhile to pursue.
My 2(0) cents,
Jeff
(sorry for the length of the post, had a lot to spill)
#34
No they didn't.
Simple, you search the engine for ".zip" with the quotes, and change the two finds to anything you choose like ".xxx" or even ".MyPersonalExtension" and then once you zip all your files with WinZip you can manually change the extension of the Zip archive to the extension you placed in the engine.
Keep in mind though, it wont take but 10-20 seconds for someone to try to change your extension to Zip and click on it. Worse still is they dont even need to change the extension. If they choose to "Open with" WinZip or Winrar, its going to open right up.
Now what I dont know is, if you password your archive if the engine can access it at all, or if it is unaffected. What would be nice is if you could password it and give the engine the password to access it. If you password the archive and change the extension, they will still need the password to open it even if they figure out its just a zip.
Anyone tried to password one and run it through the engine yet? Couldn't this feature be added to the engine since it already includes Zip support?
04/20/2004 (9:24 am)
Quote:The point I am getting at is that I noticed once that Legends achieved their graphics and scripts into a different file format.
No they didn't.
Quote:
How big of a change to the engine would it be to actually put the files into an achieve like that?}
Simple, you search the engine for ".zip" with the quotes, and change the two finds to anything you choose like ".xxx" or even ".MyPersonalExtension" and then once you zip all your files with WinZip you can manually change the extension of the Zip archive to the extension you placed in the engine.
Keep in mind though, it wont take but 10-20 seconds for someone to try to change your extension to Zip and click on it. Worse still is they dont even need to change the extension. If they choose to "Open with" WinZip or Winrar, its going to open right up.
Now what I dont know is, if you password your archive if the engine can access it at all, or if it is unaffected. What would be nice is if you could password it and give the engine the password to access it. If you password the archive and change the extension, they will still need the password to open it even if they figure out its just a zip.
Anyone tried to password one and run it through the engine yet? Couldn't this feature be added to the engine since it already includes Zip support?
#35
Any time you spend trying to "protect" your client-side content from being extracted or modified is absolutely wasted; don't bother.
The broken-into-car analogy doesn't really fit here (just as almost all real-world to virtual content analogies don't fit), because your car is not going to be a in a location where thousands of random car theives can go poke around it at their leisure without worrying about anyone coming by and seeing what they are doing.
If your game content is interesting, someone will find a way to get at it, no matter how many locks you put into place. Once that person figures it out, he or she is likely to make this information public over the Internet, allowing anyone to get at it. So all of the time you spent protecting this content has just been put to waste. Rely on copyright instead of technology to protect you here.
Look back at history. Commercial games used to go out of their way to use esoteric formats and various forms of data protection... but they realized that not only is this time wasted, but it inhibits a small, but important group of people from easily tinkering around with your game and making modifications. If they really want to do this -- let them. id Software does, Epic does, Dynamix did... It just plain makes sense.
04/20/2004 (9:44 am)
It would only take someone a couple extra minutes to trace the binary code and find the zip password.Any time you spend trying to "protect" your client-side content from being extracted or modified is absolutely wasted; don't bother.
The broken-into-car analogy doesn't really fit here (just as almost all real-world to virtual content analogies don't fit), because your car is not going to be a in a location where thousands of random car theives can go poke around it at their leisure without worrying about anyone coming by and seeing what they are doing.
If your game content is interesting, someone will find a way to get at it, no matter how many locks you put into place. Once that person figures it out, he or she is likely to make this information public over the Internet, allowing anyone to get at it. So all of the time you spent protecting this content has just been put to waste. Rely on copyright instead of technology to protect you here.
Look back at history. Commercial games used to go out of their way to use esoteric formats and various forms of data protection... but they realized that not only is this time wasted, but it inhibits a small, but important group of people from easily tinkering around with your game and making modifications. If they really want to do this -- let them. id Software does, Epic does, Dynamix did... It just plain makes sense.
#36
Still, it might slow them down some..
04/20/2004 (9:45 am)
Hex Editor + game.exe == cracked zip password :)Still, it might slow them down some..
#37
That is, well, the server needs to be hosted, the company who will host it, no matter what, wont be in your home, mostly if you are a indie developer, so whats the problem.
You have all the server files on a machine who is operated and controlled for other people, that might just simply upload that anywere in the world, making your expectations to win any money at all useless.
Even when im trying to make a free game for the players, but get money on some kind of publicity system, i will get nailed bad by this matter.
So the only protection y have is to buy a hardware key protection and protect my EXE and the scripts it uses.
I found a decent solution for hardware key, wich is the HASP key services.
I dont really came up with other ideas to protect my server files, maybe anyone have one better.
04/20/2004 (12:47 pm)
Mm today i was thinking on a big problem a MMO might have in security.That is, well, the server needs to be hosted, the company who will host it, no matter what, wont be in your home, mostly if you are a indie developer, so whats the problem.
You have all the server files on a machine who is operated and controlled for other people, that might just simply upload that anywere in the world, making your expectations to win any money at all useless.
Even when im trying to make a free game for the players, but get money on some kind of publicity system, i will get nailed bad by this matter.
So the only protection y have is to buy a hardware key protection and protect my EXE and the scripts it uses.
I found a decent solution for hardware key, wich is the HASP key services.
I dont really came up with other ideas to protect my server files, maybe anyone have one better.
#38
04/20/2004 (6:57 pm)
It think something like Punk buster is the only real solution for cheats. Well, that and the Steam Client. Even punkbuster reportedly can be fooled.
#39
Copyright? I have yet to see a copyright protect anyone from cheaters. I know I can sue someone if they distribute code that is not public, I personally am not concerned with that. Cheaters that rip code to gain advantages however I do have a major problem with. I'm more concerned with protecting my stuff from cheaters. As for wasted time, not so. Your case in court will be MUCH much stronger is you can present evidence that you took extra steps in your production to greatly limit the ability to get into the code. It would show beyond any doubt that the hacker didn't just click on it and it opened accidentally. Putting in even basic stuff may not stop even the least skilled cracker, but it show proof that you made an effort to protect your product, and someone else made an effort to steal or damage it.
@ Nicolas Quijano
It might not stop any crackers, but it will definately stop the general public from casually browsing your files.
04/20/2004 (7:22 pm)
Quote:Rely on copyright instead of technology to protect you here.
Copyright? I have yet to see a copyright protect anyone from cheaters. I know I can sue someone if they distribute code that is not public, I personally am not concerned with that. Cheaters that rip code to gain advantages however I do have a major problem with. I'm more concerned with protecting my stuff from cheaters. As for wasted time, not so. Your case in court will be MUCH much stronger is you can present evidence that you took extra steps in your production to greatly limit the ability to get into the code. It would show beyond any doubt that the hacker didn't just click on it and it opened accidentally. Putting in even basic stuff may not stop even the least skilled cracker, but it show proof that you made an effort to protect your product, and someone else made an effort to steal or damage it.
@ Nicolas Quijano
Quote:Hex Editor + game.exe == cracked zip password :)
Still, it might slow them down some..
It might not stop any crackers, but it will definately stop the general public from casually browsing your files.
#40
For example i make a deal with a big TELCO, to host my servers for free in their nodes, then an employee there or someone in the company simply take my server files and do as they please with all my work.
For a MMO the SERVER files is the most valuable thing.
04/20/2004 (8:26 pm)
Well im not only talking about cheating, what about server distributions, everybody could host a game server of my game if i dont protect the files correctly, thats my main concern really.For example i make a deal with a big TELCO, to host my servers for free in their nodes, then an employee there or someone in the company simply take my server files and do as they please with all my work.
For a MMO the SERVER files is the most valuable thing.
Torque 3D Owner Jorge Luis Gandulfo
Even when it can be hacked etc, as its right now, all users (and i mean my granpa also) could change all of the game content to their pleasure.
Im not telling this is bad or good, some of the developers in this community just disagree with their views in this point.
For me if its possible to WAD (something similar) all the textures without loosing performance, i will, but for now i wont waste time in that as i dont have textures :), im actually building up from scratch in 3d art.
What i will do is run a envelope application (anti debugger, disasembler) over the exe file, it doesnt cost me anything as i already bought an evelope application for another proyect.