Curious on what others with multiplayer combat oriented games have found in practice. I’m strongly favoring cheating a bit for the time being to avoid complexity, until it actually becomes an issue. My gut is it would take a fairly large player base before someone would hack this.
Basically the way the code works that I’m dealing with is memory hacking wouldn’t really get you anything. The simplest attack vector is the network level, rewriting protocol buffers messages on their way out. Which really isn’t all that easy.
The last time I worked on a game big enough where we actually tracked hacking attempts, was several years back and on a simpler game. We had a ton of people using memory hacking tools, and funny enough that actually didn’t work but we had youtube videos out there showing them ‘hacking’ the game when it was just their client they were hacking. We never had anyone hack stuff at the network level that I know of. Now that was a more casual game, but a huge number of players.
So anyone actually seen sophisticated network level hacking in multiplayer games of their own? If so how long did it take to start?
FYI the worst damage that could be done, that I can think of, is you could register misses as hits, and always hit what you are aiming for (like hitting a specific turrent vs just anywhere on the ship). But the server already knows where all the ships are, you couldn’t hack it to give you unlimited range for example.
The vast maority of hacks are when there is data on the clientside that can be manipulated to trick the server or easily modify it to get what you want. If you’re server authing everything then there’s only a very small chance you’ll see any hacks for the game. If you do, they’ll probably not be widespread since the action required starts to get illegal.
This is something I’ve wondered about as well. It seems to me that games would be very easy to exploit because people often rewrite their networking code for new games. I can’t imagine they are able to make it secure within the time/budget they are allowed.
Some seem to think just adding encryption is sufficient, however if you consider every client has the key then it’s not that useful. Unity games can be decompiled using a tool like ILSpy, so a hacker would not have to try very hard to find out how your game works. He can use a tool like CECIL to inject code. He could even make it so that the game logic simply feeds modified data to the network stack.
There are actually a couple of levels of hacking I would be worried about: First, hacking for the purposes of cheating, such as writing a movement hack, aimbot, etc. These can be mitigated mainly by using a client-server model and having the server be authoritative over all game logic. The second level of hacking would target the server itself in the hopes of crashing the instance (and potentially taking over the machine), or corrupting the server state data is some advantageous way. This could be far more serious because it could result in your server being subverted for a different use entirely - on your dime. The solutions here are a combination of external watchdogs, robust logging system in your server and supporting services, and spending that extra time in your server code to make it as solid as possible.
We have a small web-based multiplayer game. We believe there may have been some attempts to hack the server, however we have engineered in several checks in our multiplayer system specifically to catch malformed data. So far no one has been able to actually crash the server, and we haven’t seen any evidence of an exploit that changed game state. Perhaps if the game becomes more popular we’ll see some more issues crop up. The best we can do is be vigilant.
Encryption is worthless as you said. Assuming you aren’t doing stupid stuff, then basically what you have to worry about is people that know what they are doing. And for those people, if it’s not server authoritative, they can get around it if they really want to. I’m just curious how many of those are out there now, compared to several years ago.
Doing bad things to data on the server that you shouldn’t, that is a fairly well known domain. Just good basic input validation is the best thing you can do. Designing your api’s and messaging so you update specific properties not whole objects, and baking in some kind of input validation on all of your data models.
Unity is just a bit easier to hack because it uses IL code which can be reverted back to C# even when obfuscated. You need to protect you multiplayer code as any other engine would need. If you auth everything on server it will probably be a clunky experience. You need to find a good middleway.
In the context of hacking and Unity and multiplayer, there is really just one thing that makes security more difficult then say any normal web app. And it’s that Unity is like a red headed stepchild on the server. There is just no good easy way to scale it at all. You can do it, but I will understand games that say screw that and end up with parts that are not secure.
I consider myself somewhat of an expert at this, and even I am making some concessions on security for the time being because of the cost/complexity of doing it right at this stage. But at the same time obscurity is a road I won’t personally cross. I think once you hit the point where it matters, you have a lot of players, it’s then cost effective to fix it right.
Its like saying the banks could stop with secure certificates etc, if they just made sure the client side code is encrypted. It does not work like that, the security must be on the end point. If your game gains traction it will attract hackers that make money on creating hacks for cheaters to buy.
edit: With your logic a single page application with code you can read in plain text if you press F12 in chrome would be less secure than a native c++ app using the same rest service
You’re misunderstanding him then. He’s not saying it will eliminate hacking. He’s saying it will slow it down. Slowing the process allows you more time to come up with ways to counter hacking including simply rearranging some of the code enough that IL2CPP spits out a sufficiently different binary that they have to basically start much of the process over.
Just look at the script extenders for Bethesda’s games as an example. The developers behind them are extremely talented but every time a patch is released they have to sit down and verify that the code hooks are properly aligned and adjust them if they are not. It’s a very extensive process even with multiple people who know how to do it.
Ya there are kind of two issues here. One is as you say, there is a place for obscurity if you understand it’s place. In that the correct understanding of it is that it’s one of the simpler things for a hacker to get past, but when using a security in depth strategy you are inherently not relying on any single thing anyways.
The other thing is that most people don’t know this. So a lot of us are just loathe to suggest using obscurity because we know how most developers with no real background in this stuff will take that. They will add encryption and obfuscation and call it a day.
I was always very impressed by the guy that added LAN modes to games that had no LAN modes, including adding new menu entries etc… Don’t know which engines those games used, but definitely not Unity. It was a long time ago, not sure if he’s still doing it.
Reminds me of the people who try adding multiplayer modes to Bethesda’s games. At least one attempt is inevitably made for each new game they release but none of them seem to make any real progress.
If you’re concerned about the people who will pick up encryption believing it to be the ultimate solution with no additional effort put forth then just preface the information with an appropriate warning, but at the end of the day those people are likely a lost cause regardless of whether you make the information available to them.
Withholding info from the people who were barely afloat may allow them to make it a little further before they sink, but the people who were successfully swimming along would be worse off if we hid it completely.
Even if your game has only a few thousand players there’s probably several ‘good hackers’ in your player base who can rewrite network packets. I wouldn’t consider this sophisticated by any means, although the way this capability is leveraged to influence game outcomes can itself be quite sophisticated.
There are many threat vectors, here’s a few categories:
Attacks based on malformed data - Attempts to influence games outcomes via low level attacks against the underlying server infrastructure (buffer overflows, SQL injection, etc).
Attacks based on well formed data that contains invalid actions - Attacks against the server side simulation and validation code, for example a jump action while already in the air when the game doesn’t allow double jump.
Attacks based on well formed, valid, but unauthorised actions - For example using a sniffing or MITM attack to replay a legitimate transfer of gold over and over again.
Attacks based on well formed, valid, and authorised actions - for example aim bots which play better than a human could (potentially leveraging data that is available to the game client but not to the legitimate player).
In protecting against these you need to consider the level of effort vs the level of damage.
For example an exploit of type 4 might involve showing enemies on the map of an altered client that are not visible to legitimate players. If this provides only a small advantage to a small pool of players, and its imperceptible to the average player, its probably not worth re-engineering the game to fix it. At least until someone packages up the capability as an easy to install mod that becomes wide-spread.
An attack of type 3 might be significant for a popular persistent world MMO, but may be of little concern if the transactions are within the scope of an FPS where currency is transient between games.
Will your game get targeted? The more popular it is the more likely it will be targeted. The more it fosters a competitive player-vs-player scenario the more likely it will be targeted. The more it provides long-term persistent prestige the more likely it will be targeted. If it has potential to provide real world value (gold trading, cash prizes, etc) then lets take maybe out of the equation… it will be targeted.
Sample analysis: Snake.io is competitive but its very casual and there’s no long term prestige associated. Its not a high value target. That said because of its massive player-base its almost certainly been exploited. However it probably doesn’t matter because the vast majority of players can’t perceive the exploit.
As to your game: Your game is multi-player and combat oriented. If its not casual and your have persistent prestige (leaderboards, tournaments, ranks, etc), then its likely to be a target. If this game is something you are basing (or hoping to base) your livelihood on then I would definitely be thinking about protecting against threats like those discussed above. Otherwise see how it goes
Since, as far as I know, unity stores all your c# code into a single file when you build your game, called “Assembly-C Sharp” in the managed folder I think, and since its a c# clr or whatever file that can be easily decompiled, read and edited, if your network code is in there then Id assume it would be very easy to alter the networking packets since they can just alter the code that makes those packets.
