YOu're pretty much hosed. The only thing you might be able to do is to create a proxy process, that parses all input, and forwards "good" commands to the server, and as soon as a "bad" command is seen, drops the remote client. That assumes that you know enough about the game to be able to parse command input and tell what's a good command and what's bad.
Easiest thing you can do is change the port the game server uses and not give that out the whomever is hacking your game. That should hold them off for a little while at least...
One thing you could do is writing another program that recieves the incomming connections and it then forwards the data to the game server and back, filtering those messages that *you know* are crashing the game.
Quote:Original post by Rich76 Our multiplayer game has a small community of dedicated players. However, it does not deter a couple of morons from causing problems for us.
If they're connecting to the same location the game client would, a firewall is not going to stop it.
However, you could conceivably use a firewall to blacklist the known morons (at least until they find a proxy server), or whitelist the dedicated players (which would work better, but also prevent new players from joining).
Creating a proxy to run on the server to help filter bad packets is a novel idea, but usually impractical for games. I love the idea and have done similar before, but the cons outweigh the pros.
Pros: * Easiest/fastest solution for a black box problem as no server modifications have to be made, barring port changes. * Achieving such a solution does not require arcane skills, only an expertise in network programming. * Possible to run on another server and does not impact the game server stability.
Cons: * Not fool proof. Invalid packets on a logical level that are accepted can still crash your game server. * Requires a network expert to properly implement. Unless you have ever written server code that can support the number of players your game has, it is not a trivial task. * Requires more resources and is a more costly solution. If you run on the game server, you now have twice as many TCP connections consuming system resources as well as an additional CPU/RAM workload. If you put the program on another server, you pay more for that server as well (assuming you only have 1 server to work with originally) * Can introduce bugs if not coded properly and make things worse.
If you had network programming expertise and thoroughly understand the TCP protocol, then it would be a very practical solution to attempt. However, there is still a good chance that the game hackers find more packet based exploits that are impossible to fix via a proxy program due to there being logical flaws in the server itself.
For example, your proxy program has no idea of game state or what data means as a whole unless you write your own game server emulator, which would be out of the question to fix this problem. As a result, if a player sends valid packets that contain illogical data that the server does not account for, then there is no way you can stop this with this solution and be back to square one.
The alternative I would propose which might be out of the question for you would be to patch the server yourself. I'll go over the pros and cons of this solution as well.
Cons: * Requires arcane knowledge of assembly, reverse engineering, DLL injection, and general debugging. In other words, if you have never done it before, chances are you won't be able to figure out the problem in a reasonable amount of time. * "Theoretically" degrades server stability since you would be changing the code. On the plus side, if you mess anything up, it should be apparent as your server will crash on the spot and not have lingering issues.
Pros: * The most flexible and powerful solution to the black box problem. You have full control over the executable and with it you can fix all your problems. It's just a matter of having the skill to do so. * Requires no extra resources on the server, you are just going to be injecting a DLL into the process.
If you, or anyone part of your team, had the skills to do this type of work, I'd strongly suggest you take this approach. It will work out a lot better for your server compared to the other method and you have a lot more flexibility in protecting your server.
I've actually had experience in helping out people with both approaches as well as fixing a few game clients so I understand how tough both of them are to actually get working. For your situation, I'd suggest you go with the first method as a quick fix to at least block this easy hack but you will need to invest into the second method if you really want to protect your servers in the long run.
Quote:YOu're pretty much hosed. The only thing you might be able to do is to create a proxy process, that parses all input, and forwards "good" commands to the server, and as soon as a "bad" command is seen, drops the remote client. That assumes that you know enough about the game to be able to parse command input and tell what's a good command and what's bad.
Thank you. Antheus suggested this as well.
Quote:One thing you could do is writing another program that recieves the incomming connections and it then forwards the data to the game server and back, filtering those messages that *you know* are crashing the game.
Is this the same as creating a proxy process that parses the input?
Quote:Easiest thing you can do is change the port the game server uses and not give that out the whomever is hacking your game. That should hold them off for a little while at least...
Quote:However, you could conceivably use a firewall to blacklist the known morons (at least until they find a proxy server), or whitelist the dedicated players (which would work better, but also prevent new players from joining).
We currently block their IPs, but they indeed use proxy servers. The whitelist is an interesting idea.
They scan for open/listening ports as well.
Quote:Creating a proxy to run on the server to help filter bad packets is a novel idea, but usually impractical for games. I love the idea and have done similar before, but the cons outweigh the pros.
Pros: * Easiest/fastest solution for a black box problem as no server modifications have to be made, barring port changes. * Achieving such a solution does not require arcane skills, only an expertise in network programming. * Possible to run on another server and does not impact the game server stability.
Cons: * Not fool proof. Invalid packets on a logical level that are accepted can still crash your game server. * Requires a network expert to properly implement. Unless you have ever written server code that can support the number of players your game has, it is not a trivial task. * Requires more resources and is a more costly solution. If you run on the game server, you now have twice as many TCP connections consuming system resources as well as an additional CPU/RAM workload. If you put the program on another server, you pay more for that server as well (assuming you only have 1 server to work with originally) * Can introduce bugs if not coded properly and make things worse.
If you had network programming expertise and thoroughly understand the TCP protocol, then it would be a very practical solution to attempt. However, there is still a good chance that the game hackers find more packet based exploits that are impossible to fix via a proxy program due to there being logical flaws in the server itself.
For example, your proxy program has no idea of game state or what data means as a whole unless you write your own game server emulator, which would be out of the question to fix this problem. As a result, if a player sends valid packets that contain illogical data that the server does not account for, then there is no way you can stop this with this solution and be back to square one.
The alternative I would propose which might be out of the question for you would be to patch the server yourself. I'll go over the pros and cons of this solution as well.
Cons: * Requires arcane knowledge of assembly, reverse engineering, DLL injection, and general debugging. In other words, if you have never done it before, chances are you won't be able to figure out the problem in a reasonable amount of time. * "Theoretically" degrades server stability since you would be changing the code. On the plus side, if you mess anything up, it should be apparent as your server will crash on the spot and not have lingering issues.
Pros: * The most flexible and powerful solution to the black box problem. You have full control over the executable and with it you can fix all your problems. It's just a matter of having the skill to do so. * Requires no extra resources on the server, you are just going to be injecting a DLL into the process.
If you, or anyone part of your team, had the skills to do this type of work, I'd strongly suggest you take this approach. It will work out a lot better for your server compared to the other method and you have a lot more flexibility in protecting your server.
I've actually had experience in helping out people with both approaches as well as fixing a few game clients so I understand how tough both of them are to actually get working. For your situation, I'd suggest you go with the first method as a quick fix to at least block this easy hack but you will need to invest into the second method if you really want to protect your servers in the long run.
Good luck!
Drew Benton, what can I say? Very helpful. Thank you very much. Though, I'm not sure we are capable of any of these options.
This forum never seizes to amaze me. I always get the answer. One final sincere thank you to you all. You all have been beyond helpful. :)
It sounds like your game isn't sanitizing the data it accepts to make sure that the data is in the correct packet format. The solution to this is to not trust data until you verify that it is well-formed.
I hate to say it, but if this is the case, and you don't have the source code, you're kind of screwed.
If it's a TCP socket, then anyone can connect to it - you can't really say "only the game client can connect to it," as the port is either open or not. No matter what you do to put stuff in the way, at the end of the day they can put data in the socket. You may be able to throw a proxy up, but that proxy would need to be able to know what well-formed packets look like anyway.
I'd also be looking at whether or not the server is validating data sent by clients, or just assuming that what they send it is good, valid data (even if well-formed). If it just accepts the client saying "yeah, I'm at full health, nothing hit me," then you've got another attack vector to deal with.
Seriously, try to get the source code. Checking against malformed packets is the FIRST thing you do with a network library after "hello, world." Just telnetting to a port is something that's done frequently in development just to test connectivity. If the people that wrote this code didn't check those things, that is a HUGE danger sign that there are other problems lurking around the corner, and if you have no way to fix these problems you're sitting on a land mine.
If I've understood correctly, even a proxy won't help you. As I understood, the combination of <send whatever> and then immediately dropping the connection will crash the server.
They can do that by launching the genuine client, play for a while, and then kill it with Task Manager. This will force-drop the connection. It may take 2-3 attempts, but eventually they'll get the right timing. Someone with a little programming knowledge and enough criminal energy could probably easily "automate" that process by sniffing packets and killing the process after something has been sent out, or something.
So... you would have to block all legitimate players too, as there's no easy way to tell a malicious user from one who was just unlucky to have a client crash at the wrong moment :(
The only real (obvious!) solution is to either get the source code, or make whoever owns the sources fix it themselves.
Quote:Original post by samoth If I've understood correctly, even a proxy won't help you. As I understood, the combination of <send whatever> and then immediately dropping the connection will crash the server.
If the client drops the connection abruptly (say instead of sending a [disconnect_me] command), a custom made proxy would detect the client has disconnected unilaterally and then it would keep the connection to the server and send the proper message for disconnection.
Making such a proxy would require, for starters, having the complete documentation of the protocol used to comunicate the client and the server.
