This is kind of a general question to ask about how difficult it is to hack a Unity game, and if there’s any protection against it.
The reason I bring this up is I know several people who run boutique MMOs using Shockwave 3D. These are small sites, not huge MMOs. Well, from the beginning, players were using tools like “Cheat engine” (Google it) and whatnot to find where their health was stored in memory, so they could boost it. Or send spoofed communication packets across the network.
Again, I want to point out that these weren’t huge MMOs, they were small little sites, and the users weren’t uber-hackers, they were using free programs. It seems that it’s inevitable that it will happen.
So my question is: Is it easy to hack a Unity game using things like “Cheat engine”? Are there ways to prevent it? I know there are methods you can use in Shockwave to constantly scramble the location of variables in memory; which are quite effective in hampering tools like cheat engine.
I’m wondering if Unity does the same? It seems with Unity using Mono, it would be very easy and inevitable that someone could write a cheat engine type of program for Unity games. Apparently there’s already hacks for fusionfall.
I’m quite curious about this. Just wondering if UT has put any thought into this, and what the community’s take on it is.
I think that it would be pretty hard to change it if the users (creator of game) did some things like make the displayed health not the actual health like
var healthdisplay = hmain
var hmain = "5"
because then when the hacker changes the value they find the value by what changes and with this the value is changed to the real one every millisecond so the hack would only change the display since they go by display (what changes). it isn’t UT to do it is the creator and how hack proof they want to be because you can always do an infinite while loop that changes the value every single millisecond plus encrypts it.
As far as I know, Unity itself doesn’t do anything to prevent hacking. But it is possible to take steps against this with what is available: Save scores, health, etc… in multiple locations, Encode important information, and actively fight hacks that have been made for your game with updates/patches. Hacking is inevitable and it will always been a neverending battle between developers and hackers.
It is kind of silly to have an Engine be the one that handles hack prevention. It makes it easier on the hackers. All they have to do is figure it out for one game and they have it figured out for all games. The UT resources are better spent in other places.
like I said while loop changing value every second to value stored in prefs then encrypting that data every time with a new key that is the ultimate hack prevention system.
Bloodtiger: regardless of whether you have a display heath and a real health, if there’s a single variable that controls health, and it stays in the same location in memory, then the Cheat Engine can find it. I’ve downloaded the Cheat Engine a few years ago and did their tutorial: they teach you how to find the real variables (vs the display one).
I am aware that we can do things like encrypt important vars ourselves. That’s partly why I’m asking: Doing it ourselves is something that should be thought out and implemented ahead of time, rather than going back and retrofitting code by finding every piece of code that checks the var and change it to a decrypt function.
The reason I ask if UT has thought of it, is my thinking is that the lower level it’s done, the faster it will be, and in theory harder to crack. When we do it ourselves, there’s a lot more overhead, and we have no idea of what’s going under the hood, so it’s kind of like trying to fix a leak in your roof when it’s not raining.
It’s also a common problem to all games, which is why I think it makes more sense for the UT player to be secure rather than every developer having to home-brew their own safeguards again and again for every game. At the very least UT could publish a document explaining techniques of what works, what doesn’t. Since they wrote the engine it would be much easier for them to tell us this than us doing trial-and-error approaches.
With Shockwave for example, there’s things the you can do via scripting to scramble the locations of variables in memory. Shockwave wasn’t designed this way for this reason; it’s actually just a side-effect of the dynamic variable assignment and lack of strict typing. If UT knows of something like this for their player, it would be great to hear it from them.
I still don’t think UT should be the one’s handling it and it’s better for the developers to take care of it themselves. Though, I like your idea of publishing some sort of documentation that helps people find new ways to fight the problem. Would be nice of UT did this, but it may end up being something community puts together.
Products like Xenocode “Post Build” http://www.xenocode.com/Products/Postbuild-for-NET/ can obfuscate your external assemblies which could control your game logic and hide game variables. Unity can load the external assemblies as assets.
Eric, Thanks for the link. Pretty cool. Seems a bit more targeted to security like login info, but all seems like it could apply in the same way I was thinking re: health.
Shawn, I guess it depends on what you mean by “better”. Why I think I it would be better if the player had some security is that, with most MMOs, cheating does not just equal health. You’re dealing with health, movement speed (already cracked in Fusionfall, from what I hear), player location, ammo count, weapon strength, inventory (which could contain a LOT of variables). It’s just a whole mess of data that you’re reading and changing constantly, any of which could be devastating to other players if someone cheats.
At this point you’re now not just talking about securing a variable. You’re talking about securing all sorts of data, many times a second.
Think about a cheat that moves the player. Cheat-wise, it’s just moving the object’s transform without collision. This would allow a character to teleport through walls. Transform is not like health where we can control how it’s stored. You’d have to hash the location immediately after moving the player, then compare the hash again next time you move it. For every object that you want to secure.
At some point, if this kind of stuff has to be done to keep people from cheating, you’re not just programming a game anymore. You’re building complicated systems that have nothing to do with your game. It can bog down development. That’s the opposite of what Unity is to me. Unity lets me focus on the game, not all the supporting services.
Now, I do admit I’m putting the cart before the horse a little bit (I have no idea whether or not cheating is easy in Unity), but I’m just throwing these things out to see if UT has thought of this at all, and if we have any data on cheating or how easy it is.
I also understand that if UT creates some security, then a hacker could write a cheat engine for all Unity games ( a lot more likely); whereas if you roll one yourself your game is going to fly under the radar for a lot longer.
Are you sure that this was done and it’s not just a rumor? That would be very unfortunate, because any article on MMOs I’ve ever read tells you to not trust the client. Movement speed is something that should really be controlled by the server. For “perceived performance reasons”, the client would obviously move on its own - but the server should never allow the player to change the server state concerning position.
Generally speaking, if a server-based multiplayer game is hacked in that way, I guess it means that the developers didn’t pay attention. And for server-based multiplayer, cheat-prevention is a completely different story from client-only games.
IMHO, there’s just a few problems in server-based multiplayer that you simply can’t fix “once and for all”:
a) Bugs. We all make mistakes, and some of these can be exploited. That’s just life - you can do your best to not have bugs in sensitive areas but … well, we’re human, so this won’t go away.
b) Clients providing information they “should not see” (things like looking through walls). Actually, this is a) because it’s a design-bug but sometimes you might just decide to live with it (for instance, in Traces of Illumination I have “smoke” and a couple of other visual effects that make playing the game more difficult … these are obviously very vulnerable to someone simply switching those effects off in a hacked client; I live with it because “PvP” is not a prior way of playing the game)
This again speaks for the “multiplayer-scenario” which is a very different scenario than single-player (and keep in mind: currently, Unity’s primary focus is on single-player; for larger-scale multiplayer, Unity currently only serves really well as client). The one thing that Unity provides in that area is encrypted data transmission. That’s nice - but you can’t rely on it because eventually, someone will crack it and fiddle with it (no matter how “secure” it’s supposed to be).
So you end up - again - with the advice: “Do not ever trust the client!” If you do - you’re setting yourself up for ugly cheats giving you trouble. I agree with Shawn that this is something that we cannot expect from UT because it’s heavily tied to your game design and game logic.
One thing that I’m doing, for example, on the server is having lots of “sanity checks”. Whenever those fail, I write all the relevant data asynchronously into the database. So, when a player cheats, I’ll find out about it and can take the relevant actions.
There’s a super-thin general layer that could probably used for any type of game. But honestly: It’s so thin you’re better of coding that yourself than trying to make it fit in your game. The interesting stuff is how the “sanity checks” are performed - and that is heavily dependent on your game design and implementation, so it’s not suitable to be implemented “for all Unity users”.
In single-player: If someone does this, oh well, what will be the fun in playing the game anymore? If they ruin their own experience, well, let them. In multiplayer: If you trust the client, it’s your fault. Simple as that. If you don’t trust the client, what is likely to happen is that when the player fiddles with the transforms, he’ll make his char go out of sync with the server. He’ll either get ugly effects (he moves to XY, but then gets teleported back by the next update coming from the server), or get completely out of sync - so his char will be in a different location than the server char, and it will appear as if he’s running into walls where there are no walls and stuff like that.
Again: That only spoils it for the player who’s cheating, so I wouldn’t bother.
I would agree to that. However, I think that’s just one of the challenges you inevitably run into when developing a multiplayer game. It’s one of the reasons why an MMO-type of game will consume significantly more time to develop than a single-player game (and why there is significantly more risk involved).
Currently, Unity provides no MMO middleware. Not sure how SmartFoxServer, for instance, supports these kinds of cases. I would agree that a good MMO middleware should provide frameworks for some of the obvious things (players trying to mess with their position) but I still think it’s pretty “implementation specific” (how can a middleware know the rules of movement specific to my game?)
Single player games are quite easy to protect from memory editor hacks. There’s been a number of threads on that topic.
MMO’s and multiplayer games in general are a totally different story than a single player game. As Jashan and others said, rule #1 is never to trust the client. Anything controlled by the client is vulnerable. Anything sent over the wire as cleartext is easily viewed.
It -is- up to the developer to guard against such things. And even the best of them with unlimited resources can fail miserably. Look at WOW. Ever heard of the ‘Warden?’ They basically gave up trying to do it through code, and took the very controversial path of ‘spying’ on end users computers to make sure they were not running anything that resembled a database of 3rd party hacks.
jashan: Thanks for the detailed reply. I agree with everything you said. And the rules (never trust the client, etc) all make sense. I know nothing is entirely cheat-free.
Quietus: Can you point me to some of these single-player protection posts? I’m interested in them.
My focus, and the reason I posted this, was more about low hanging fruit – the “easy stuff”. Like locking your car door. You’ve got glass on all four sides of your car – hey, if someone wants to break that glass it’s easily done. But we still lock our car doors since it’s SO EASY to do and will reduce the amount of theft.
I want to point out: that’s been the focus of my post: Has UT locked the car doors at all? We still don’t know this (no one has said yes or no on the matter).
How I came to write this post: It occurred to me that Shockwave is VERY easy to hack, unless the game developer implements some scrambling code (which is pretty easy to do in shockwave). But what about for Unity? My thinking that it used Mono which is open source, and therefore trivial to reverse engineer popped into my head. So I wanted to know a bit about what UT has done to curb that. I know well that it won’t stop everyone. I’m not suggesting UT provide us with a magic bullet, either.
Long term I can see the industry-standard mantra “Dont trust the client” as being something that UT could solve globally so that we didn’t have to. These types of global-no-matter-what-game type of problems are ripe for UT to tackle.
Look a couple posts up, Eric linked to one where I even gave some pseudocode on page 2.
You basically want to separate the displayed value on the screen from the value that’s actually being tracked. At that point it’s easy to obscure the original value. The person using a memory editor can pause the game and search for “5000” all he wants. Soon as he changes what he thinks is the memory address of the score it will revert back the next frame/score change and he pulls his hair out in frustration.
The methods you choose to actually obscure the data are as vast as the ocean, and somewhat dependent on the data type. Some fashion of bit twiddling is perfect for scores, energy levels, player lives, game level or most things stored with an Int32 in your average game.
Still nothing you can possibly do is going to stop a determined individual from hacking your game if it’s running on his local machine. Obfuscation and separation will certainly stop the ‘low hanging fruit’ as you put it dead in their tracks.
I disagree unless we’re talking about lightweight methods to obscure networking packets. I haven’t got around to Unity’s networking yet, so I can’t tell you if everything is sent in the clear or not when using their built-in state synchronization.
The reason I disagree is twofold.
First, it’s very easy to guard against the problem yourself.
Second, if the burden would be put onto Unity’s shoulders the minute it’s reverse engineered (from reading the unity documentation) we’re screwed as it’s made worthless for -all- our games.
Quietus: okay, thanks; I wasn’t sure if you were referring to different techniques than what Eric linked to.
Right. The question is how high do you raise the bar. Sounds like people don’t think it’s worth UT’s time to raise it at all; the entirety of it should be the burden of the game developer. Fair enough.
The guy who runs the Shockwave MMO had to do a LOT of crazy things to keep hacking away. And again, this is not a top-tier MMO by any means, it’s not even a blip on the radar in the grand scheme of things.
I guess the assumption of the community is it’s just a Fact Of Life? There’s simply no way around that? If you’re developing an online game: you are going to have to make your code jump through a lot of hoops because there’s nothing UT could do about it?
There’s a bazillion decompilers for flash/shockwave available on the internet, they all seem to be able to give you variable and function names as well. Of course your average shockwave developer won’t think to obfuscate his variable names.
It’s very easy to save the .swf file from your browser’s cache, run it through the decompiler. You simply then edit SCORE = 999999, put it back into your browser cache, hit refresh and you’re now #1 on the high score charts. It’s a bit more involved than a memory edit hack, but not much.
I do remember coming across one game on a forum’s “arcade” that I decompiled, only to discover that the variable names were things like FIZZYWIGAB and JUMBLAOHA and I was shocked to say the least. Actionscript is hard enough for me to decipher with it’s frame this and frame that, without having to deal with that.
Of course, that was the exception by far.
Hanford, I really don’t see how creating a simple 4 or so line function to enable your doing things like displayScore = obfuscate(realScore, false) is “jumping through a lot of hoops.” It just takes a little more planning in terms of your data definitions and very little effort.
If it were just for score, when you updated your score, I’d agree with you. But it’s not. It’s health. It’s weapon strength. it’s weapon range. It’s amount of ammo. It’s speed. It’s jump height. It’s mana. Even with time itself. Every time you want to check them or update them, you gotta go through that hoop. The list goes on and on. The Shockwave guys had to deal with a whole more than just score. It’s something I’d rather not deal with.
Anyway, I want to thank everyone for chiming in. Sounds like the situation with the Unity player is the same with Shockwave; you gotta roll your own. I’m hearing you guys loud and clear
Actually, when it comes to “client-side hack-prevention” I think there are some things that I feel UT should look into. I remember we had some discussions on obfuscating the .NET DLLs (um, sorry, Mono ). I still think that would be a good thing to have “from the engine” because it makes decompiling and changing your scripts much more difficult. I know there are ways of doing it “on your own” but IMHO that’s something that should just work “out of the box” (with the option to save certain classes from obfuscation to make sure you can use those with reflection).
Sometimes I want to publish parts of my source code - and then I do it with comments and instructions - maybe even with an example project, for the community of peer developers. But often I don’t, and then I’d like it hard for someone trying to reverse engineer my IP. Some simple form of encrypting the obfuscated DLLs (and renaming them to *.uic) would add another hurdle, which I think would be nice. Also, encrypting the assets would be nice. Since in the end, someone could read that stuff from memory, the encryption should be “efficient” instead of “super-secure”.
I think it’s really about creating a couple of hurdles on the engine level. You’ll still need to write code that makes it hard to cheat - but quite a few cheat-prevention mechanisms rely on your code being at least “somewhat safe”; and currently, it’s almost trivial to reverse-compile the Mono DLLs of your game, look at what’s going on, change it, recompile it, put the DLL back into the game and start cheating.
There’s a nice article on cheat-prevention in “Massively Multiplayer Game Development II” (Thor Alexander, editor): “2.12 Anti-Cheat Mechanisms for Massively Multiplayer Games”, by Marty Poulin, from Sony Computer Entertainment America. While this is primarily targetted at MMOs, a significant part of it is also relevant to single-player games. To give an overview, the rules (in the article, these are just some of the headlines):
Not sure if that article is available outside of the book. Personally, I found the whole book a pretty good read even though I liked the first one (“Massively Multiplayer Game Development”) better.
I’m pretty sure there should also be really good articles on this at Gamasutra.
The Unity devs can do a lot but there is one important thing you have to realize: You are using a script system when working with unity.
There is no real way to protect anything that only exists on that end as you do not have the slightest control over it. Thats the job of the GC.
On the other hand, the GC already ensures that you do not have static memory positions if you just deallocate and reallocate the handling objects every now and then for example.
If you want to have fullscale hack prevention, go for a source solution and integrate protection measures against black ice and other kernel level debuggers, because thats what you will have to work against if you are really worried about hackers. Scripting will never allow that, independent of the measures you take, as your whole stuff runs within a virtual environment thats seperate from the main application memory and especially operates independent of it.
If that is not what you are after, but only the script kiddies, don’t waste your precious funds and development time by worrying about brickheads. As an indie you are not in the situation that you have half a million for security measure and with $1000 - $5000 at your hand, its wasted funds, that you better put into Ad instead of blowing them out the window.
Update your game regularily and change the related stuff on each update.
That should give you already a pretty fine headstart.
