Hack resistance?

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

Code (csharp):

1.  
2. var healthdisplay = hmain
3. var hmain = "5"
4.  

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.

 

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.

 

oh

 

This was discussed a couple times before...there's a good post here for one solution.

--Eric

 

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.

 

Thanks guys.

Dreamora: What's GC?

Also, how do you "deallocate and reallocate the handling objects every now and then"? Can you give me an example?

This was exactly my point of UT being able to do something lower level than we can with scripting.

 

GC = garbage collector.
Also be aware that a standalone exposes the DLLs, which can be decompiled in a jiffy with Reflector, then modified and replaced. When hackers can actually read your code, preventing client-side cheating seems just about out of reach. Obfuscation makes it a bit harder but still.
Webplayers package the DLLs in the .unity3d, which to my knowledge hasn't been cracked. Then again it could be just a glorified zip, I have no idea. BUT, you can inject instructions through browser-javascript... obviously knowing what to inject is a big problem, but I'm pretty sure it'd be possible to inject an instruction to, say, save the assemblies somewhere!... back to square one.
This all may seem pretty crude compared to memory sniffers, but I know nothing about those, I'm a managed .NET person .

 

There are products such as Reactor which seems to be able to add some more hoops to jump through. Not just obfuscation but making the decompilers actually choke on the CIL. They mention a 'native code wall', whatever that means.

It's only $179 and supports Mono on OSX. Might be worth taking a look at.

Now if Unity can figure out what they're doing to the assemblies and replicate it, that would be something I would support them spending resources on.

As an aside, I'd certainly like to know what the 'strip debug symbols' checkbox actually does. I had assumed that it would make it so a decompiler would output FLD001 instead of playerPosition.

 

I experimented a bit with encrypted text files, which are then decrypted and executed with eval() on the fly. (Only a few--but important--lines, since eval() has to compile the code and hence is too slow to use for the entire codebase.) It seemed like that would be at least somewhat effective, but I don't know enough about the process to know what could be done to get around that.

--Eric

 

This is related to debugging, an assembly can be compiled with extra info so debuggers or profilers can analyze the code at runtime. There's a post from Joachim somewhere explaining it better than me .

Yeah but... if I have your assembly, then I can reproduce that and see what you're evaluating, can't I?

If you worry about speed, you can emit your own assemblies, it's like the opposite of reflection (which would be... impulse?).
I wouldn't be surprised if that was what eval/Boo is doing anyway, except it's volatile, but it doesn't have to be: you could do that once on start and use it all session long, and it should run as fast as any assembly. Dunno if it's possible in a webplayer though, some portions of the framework are stripped out.
Come to think of it, that's a bit like procedurally generated textures... procedurally generated code! Will the madness ever end?

 

The text file is separate (it gets put in one of the .assets files) and encrypted, so I don't think that would work, would it?

--Eric

 

I get your dll, decompile it, locate the line where you pull out decrypt your text file (which would be the unfun part), add a nice "save to disk". Now I inject the new dll, run the game so your file gets saved, examine it, modify your code again with an eval('whatever I want')... bam.
Where can I find your game? I'd actually be curious to know if I could pull it off, in case it rains this week-end .

 

I was thinking about this preventing cheats/hacks stuff recently.

So, I came up with a few ideas. If they will work, I dont know.


Idea #1:

When programming a game, why not assign functions and variables random names (something that has a absolutely no real meaning).

So for something like "Health", you put in "4hjg23ed". So if they decompile it they'll see the function/variable but wouldnt have any clue what it means or what it does.

Or make the program swap random names between each function/variable every few loops or so. So they can never pinpoint exactly what it does, since it would change from time to time.


Idea #2:

For things like aim-bots, health/ammo hacks, wall hacks.

Cant checks be coded into the game itself?

So say they fire up a aim bot in-game. Have the program check to see if the mouse movement actually took place between point A to point B with "natural flow" instead of snapping between point A and point B without any mouse movement or natural flow of mouse look (which aim bots do).


Or for things like Health, say you set the max health possible to be 100%. Cant it be programmed in to do a check of the health to ensure it never exceeds 100%, and if it does, to automatically kick the user out of game and exit the program.

So something like this:

Code (csharp):

1. if health = greater than 100%
2.    
3.    Exit server
4.    Close down game
5.  
6. end if

Or even if they dont exceed 100% but instead hack it in a way to give them an extra bit of health or ammo here and there.

Code (csharp):

1. if health is increased
2.  
3.    Check to see if player is near health/ammo pack
4.  
5.      if health/ammo pack is not near player
6.        Exit Game
7.      end if
8.  
9. end if

So things like that ... that always check when something changes (like health, ammo, aim, movement, location, etc) and if it doesnt follow a specified set of rules that it kicks the person out.

 

That causes problems when the code flow is, like in actionscript, occurring is something abstract like a 'frame.' However it wouldn't take someone from the FBI to deduce contextually what 4hjg23ed is, when it's updated inside OnCollisionEnter() in the BulletProjectile source file. It also makes it a PITA to debug your own apps!

Beyond cheating, the ability to decompile the source and reconstruct it with 100% fidelity is more dangerous intellectual property wise. If I made a game that actually became popular, I would be losing sleep at night just waiting for my game's actual source code to show up on Usenet.

I think Eric is on the right track. I found a few articles on the interwebs like this one that talk about the problem and solutions in some detail. Basically a C++ wrapper for your encrypted assemblies. I'm guessing that's what the 'native code wall' in the product I linked earlier is.

It's surprising the Unity folks haven't chimed in on this thread yet. With the influx of dot.net savvy people likely to occur with 2.5, you would think this is an issue they would want to address. I'd hate to see what should be a raving success be sullied with posts on forums all over the place akin to, "LOL @ UNITY DON'T WASTES UR MONIES U CAN GETZ AT ALL THEIR GAMEZ SOURCE CODEZ HERE'S HOW!!!"

 

I am not a very experienced programmer by any stretch of the imagination, but a thought did occur to me while reading this thread.

From what I read, Unity has the ability to talk to a web server. If you have a multiplayer game that needs to store information, why not use a popular database like mySQL. I know that the licensing gets a bit tricky with dealing with that type of database, but if you have a script to act as the communication between unity and the database, would that not provide a good solution? In theory, you could use encryption like md5, and have the client handle that encrypting/unencryption. That way, an application like cheat engine would show variable values plain enough, but the client and script could only read encrypted values. Now I am sure there is some giant hole in my theory that I am just not seeing, and anyone who knows the type of encryption you use can get around this, but I will leave you with a thought given to me by my brother-in-law. I noticed one day that the guy never bothered to lock his doors, and upon asking him for a reason he replied, "Locking the door only keeps an honest thief out..." Just a little food for thought.

 

Good point about the "save to disk" thing...I don't have anything currently that actually uses what I was playing around with (sounds like it would have been only marginally effective anyway), sorry.

--Eric

 

@Eric and others: I remember stumbling upon an hack-for-fun website some years ago in university. There was like 10 steps, each time you needed to enter a password to go the next level. First one was javascript-validated, so you only had to "show HTML source" to find the password... I remember failing very early on, maybe step 2 or 3, you were supposed to decompile a Flash file to pass.
...we should do something like that for Unity! Put up a sort of competition to find out effective measures.

 

I ran across this very interesting blog which might have some direct bearing on the conversation.

It appears that Unity Iphone applications already have all the protection we would likely need. They're AOT pre-compiled to native code. They only thing remaining in the assemblies are empty methods. However, they're apparently doing it to save bytes and not to protect intellectual property! I guess that's a side benefit.

If this were done for native application builds, we would then be back to simple separation and obfuscation techniques to guard against memory editors. The intellectual property concerns raised in this thread that spring from using .NET would for the most part vanish into thin air.

I'd like to see it as a checkbox option for web players as well. Being that unity applications are comparatively light on the scripting, stuffing in the pre-compiled binaries for both platforms wouldn't add all that much to the bandwidth weight. Hell, together they would possibly have a -smaller- footprint than including the CIL for a JIT compiler. (not to mention run a little faster)

 

I suspect it's highly unlikely that UT would ever do AOT for non-iPhone platforms. The only reason they did it there is that they were forced to by Apple, and it delayed Unity iPhone by months.

Anyway, this topic has come up at least a couple of times before...UT is aware of the desire for asset protection. (One discussion got kinda heated. ) However, it does seem to be taking a very long time to implement anything along these lines.

--Eric

 

According to the blog they already have the technology pieces, along with the experience fastening them together. If they initially opt out the web player, I don't see it being a herculean task to retrofit it into standalone.

Hopefully that changes, Eric. Like I said before, with all of the .net savvy intel folks soon to join the ranks it'll only be a matter of time before the Unity product gets a big back eye and a slew of bad press if the situation is not rectified. "FUSION FALL MMO CLIENT SOURCE RELEASED ON THE INTERWEBS!"

Unity has a great opportunity to further their path of world domination with 2.5. However, first impressions are always the most lasting. If they wait until after the damage occurs to act, it'll be too late. I love Unity, I've invested in this product for the long term. I'd sure hate to see that happen.

I imagine they are quite aware of, and are very sensitive about the issue. The usually very engaging Unitoids seem to have been avoiding this discussion like the plague.

 

Well, see here. It doesn't sound like something that would be implemented, but there are other ways to approach the problem anyway.

--Eric

 

I remember a thread about AOT compilation for standalones a while back (I guess that was somewhere in the depths of the iPhone announcement thread) and basically, it seems that the major problem with AOT compilation on standalones is that it actually is likely to reduce performance.

Reason is because there's a lot of processor-specific optimizations that JIT-compilers can do - and there's a lot of specific processors out there. So, having AOT with maximum performance does not only mean two binaries for Mac and Windows (actually 3: 1 for old Macs, 1 for Intel Macs, 1 for Windows), it would mean "lots and lots" of different "versions" put into one binary. Since I'm not that much into low-level processor optimizations, I don't remember the details but it shouldn't be too hard to look it up (with friend Google). Given that the Unity engine itself is compiled, I'm not exactly sure what the problem really is but I'm sure there's good reasons the UT guys didn't go much into that direction.

I guess from the perspective of hack-prevention, it might still be worth (re-)consideration as I agree that this could become a very nasty issue if not taken care of (the heated discussions about this on these forums at a time when it was still much smaller compared to now might indicate something).

 

Interesting in that thread where Aras 'sees no reason for AOT on standalones.' And I thought he was a smart guy!

Eric, the methods you discussed previously in this thread such as encrypting the assembly are easily defeated. If they're unencrypted in memory they can found and saved with a simple memory scan. If they're encrypted right up until the time JIT needs them you can simply put a breakpoint into the process and save them off.

I found Video Tutorials on how to use these simple techniques to defeat commercial products like the .NET Reactor I had referenced earlier. There's even a slew of available applications to defeat .NET obfuscators, even the ones that use string encryption.

So it seems to be obvious that as long as you include the CIL/MSIL in your package, no matter what you do to protect yourself, one should just as well look at it as though you're distributing your game's naked source code to everyone.

With that in mind, AOT seems to be the only option.

There's some discussion about that in this blog by Miguel. Myself, I'd easily trade 'slightly slower' and 'slightly larger' for peace of mind.

 

Out of curiosity, since Unity includes all scripts in your project whether they're used or not, what would scrambling unused scripts do to decompiling efforts? I tried this (using a hex editor) and the project continues to run fine, but I don't have any Windows to test decompiling with.

--Eric

 

I think that would be a function of whether or not each individual script is built as a separate assembly. Even if they are, there is a mono merge tool that takes separate binaries and rolls them into one. Maybe that could wreak some havoc combined with your scrambled script, but let the JIT chug merrily along.

However, anyone comfortable with using OllyDbg would still be able to cut out your garbage with minimal effort and reconstruct your game's source code.

I tried getting Reflector to run on my windows partition to play around a bit, but it doesn't appear to like my windows install for some reason. I haven't had time to do too much with it. There is a mono based decompiler and some french guy even has put a GUI on top of it. Unfortunately, the gui by the french guy...is all in french!

 

Is that the same as separate files? There are a maximum of two .dll files for each language used no matter how many scripts you have...a first pass.dll and another one. I'm not sure what the first pass does, but the script stuff that I scrambled was in the other one. I used several repeating lines in the script so I could find them using a hex editor.

Well, at least the more work it is, the fewer people will be able to casually mess around with your source code.

--Eric

 

I took the 5 minutes to install the dot.net framework. Reflector is up and running fine now. It had no problem combing through the bowels of a prototype I'm working on. Neither did it have any issue with disassembling my code as you can see from the above picture.

One curious thing as a byproduct of the way dot.net works, is that it neatly converts all my javascript code into C# when it disassembles! I guess an interesting way for someone to covert all the javascript examples into C#!

Eric, now that I'm up and running if you can give me a simple project you have scrambled I can test what reflector makes of it. You mentioned two DLL's. One appears to be for C# and the other for javascript. They contain all of the scripts in the one dll. Each one conceivably being a separate class within the dll.

WTB: AOT FOR STANDALONES!

 

Not sure if the approach with adding unused code (if I understand that correctly) would really make it any more difficult to understand what's going on. It should be comparatively trivial to simply strip away everything that's not needed [EDIT: As long as you don't use reflection]. Good obfuscators do that automatically.

First time I got in contact with obfuscators was in the Java 2 Micro Edition world - there, it was not that much about protecting your IP but more about getting your whole application into 32kB ... yes, kB ... with such restrictions, having a class ThisClassHasThisSpecificResponsibility makes a significant difference compared to class A - and that was just a few years ago ... the iPhone almost is a Supercomputer compared to that ;-)

Concerning assemblies: In the .NET/Mono world, you can simply compile a whole project into an assembly. And it's possibly to use those assemblies within Unity. AFAIK, there's no restrictions on how many you'd use (except for on the iPhone, I think there's a limit around 8 or 10 or so).

However, spreading your code out to different assemblies for "crack prevention" will make your life significantly harder ... but not really any hacker's life ;-) ... having different "packages" does make a lot of sense from a software-engineering perspective but if you do it that way, it'll make it easier for crackers to understand your code.

 

Cool stuff ... I did have that on my long to-do list but having an automated translation is obviously much more convenient than doing all this "by hand"

 

You javascript bigot you!

What would be laughable, is selecting Visual Basic as an output target. I wonder what it would make of some of the language constructs.

 

Yep, that's been mentioned a couple of times in the past.

OK, try this.

Well, I get a "first pass.dll" for C# and Javascript, and another one for Javascript, for a total of three. Now that I look again, it looks like "first pass" is for stuff compiled first, like in Standard Assets/Scripts and so on.

--Eric

 

It had no problem whatsoever. Null effect for your 'scrambled' script. I imagine that was Ascript2. It simply returned 'invalid member body' but the function prototype was still there.

The mouselook and FPS walker scripts were the contents of the C# and Javascript first pass DLL's. Curious if they were actually in the scene. The actual source code for your project was returned from UnityScript.dll.

 

Hmm...what happens with this update? I ditched the "unused script" idea and am just using "AScript1" now.

No, just in Standard Assets.

--Eric

 

Code (csharp):

1. [Serializable]
2. public class AScript1 : MonoBehaviour
3. {
4.     // Methods
5.     public void Blah()
6.     {
7.         // Invalid method body.
8.     }
9.  
10.     public void Main()
11.     {
12.     }
13.  
14.     public void Update()
15.     {
16.         this.transform.Translate((Vector3) (Vector3.right * Time.deltaTime));
17.     }
18. }
19.  
20.  
21.  

Next!

The most curious thing that I've discovered, good chucks of the unity source code itself appear to be visible. I was looking at pieces of the GUI and Terrain code, for example. I was obviously unable to look at things Audio or PhysX related. I had always assumed that Unity was native compiled C++ code. I guess the compiler they used on windows generated MSIL instead of native binaries.

 

Nope, I'm out of ideas now.

Well, the OnGUI and Terrain builder stuff are in fact Unity C# scripts.

--Eric

 

I'm not. AOT! AOT! AOT!

That would explain that but then so is the TreeRenderer and it's database, the detail and splatmap renderers, the terrain index generator with it's triangle strip code, tree billboard imposter code, etc. It seems like a majority of the terrain engine is written in C# with the source code readily visible.

It's as if someone wrote the terrain engine as a C# plugin for the rest of Unity. A separate DLL in fact from the rest of Unity.