Hack resistance?

That's just a repetition of an idea you already had.

Actually, out of curiosity, since C# doesn't have eval(), what happens to a function that uses it when run through the .net reflector?

--Eric

 

I doubt it would choke on that.

Eval is probably just pulled from another linked library in the chain much the same as the Unity methods/functions. Saying otherwise would mean that mono's version of C# isn't C# and mono CIL isn't 100% compatible with .Net MSIL.

One other thing my mind was chewing on tonight, is what this issue does to the security and integrity of any web server/database your game might communicate with on the back end. Gee, I wonder what password, private key or hash string they're using. Of course that can still be done with OllyDBG, but this lowers the bar to the floor. For stand alones, I'd now feel compelled to move that sort of stuff to C++ plugins for safety. A Pro only feature just to mask a string, go figure.

There's also the possibility of moving all of your game logic and state machine over to C++ and taking a minimalist approach to using Unity's scripting. As you wouldn't be interfacing with WIN32 or Core Framework they would be source compatible for each platform.

Beyond state machine and game logic, I'm not sure if you can interface with mono and the Unity engine directly via a C++ plugin. What would a plugin make of things like LoadLevel()?

I'd hate to see that be necessary as it would flush one of Unity's main selling points down the toilet. Unity would no longer be RAD.

 

Well, if you make the private key a public variable which is set in the inspector, you can't really get that from decompiling, can you?

--Eric

 

you set it somewhere and it must be assigned before awake.
want to put bets that its not directly set on the object on compiled as a const althought that would make most sense and would be most performant?

 

Ohh, Excellent point!

It should be noted that things like the server side high score example on the wiki use an in-source hash declaration. I thought that was fine at the time I used that system, as people actually reading my game's source hadn't even entered my mind.

Code (csharp):

1. private var secretKey="mySecretKey"; // Edit this value and make sure it's the same as the one stored on the server

But then that leads into the question of how inspector values are stored. Hopefully it would be something more convoluted than plain text in that main.data file. I see things like my layer and tag strings in there, but don't believe I've ever used an inspector variable to set a string value.

 

Good, because that's what I've been doing.

Nope. However, the next question is, how would you know what data there goes with what variable? In particular, with something like a MD5 hash or password, which can look like any random string, and especially one where I break it up into more than one variable and then combine them, and even more especially if I deliberately put fake data in unused variables, I don't think you'd know what to look for. Or you can get creative and encode the sensitive text data as RGB values in a texture...good luck trying to dig that out of the .assets file....

--Eric

 

Yes I imagine it would be mildly difficult, even with cutting it down to a subset of possibilities through the process of elimination.

It's a moot point though, as I just noticed the MD5 routine used by the high score example on the wiki is written in C#/ Javascript. OOPS!

 

What else could it be written in? Anyway, I'm not sure why it's a moot point, since you can decompile the code all you like, but without the MD5 hash, you don't have anything...the data will of course be validated on the server, thus rendering any attempts at rewriting the code useless.

--Eric

 

You can decompile the code all you like, however you can also edit and inject your modified MD5 javascript routine back into the assembly. You know, the one that prints the hash out to the console? It would take less effort than setting a breakpoint with OllyDBG.

 

Oh yeah...hmmm.

--Eric

 

I would also suggest, once we get AOT, never ever ever to name your MD5 routine MD5. Call it something like CollisionEarlyExitTest() or something as seemingly harmless. Will make it a lot harder for people using OllyDBG to set breakpoints to scarf your hash strings.

That combined with your storing hash data in a texture, would be a very nice feint.

 

FYI: I have asked for some dev commentary on this entire topic, please stand by.

 

Hey Tom - great, I've been kind of waiting for that. Thanks for chiming in and giving us an update!

 

Hanford's question is a very broad one

Just as with any other game, unity games can are also vulnerable to attacks like memory hacks. Network packet sniffing, etc.

You can make it hard to do so, but the persistent hacker will always be able to make its own gameclient say it has 800 points.

Is that bad? Not if you keep it in mind during the design of your game.

Generally, for single player games, nobody cares. You want to show off to your mom, go nuts.

It's multiplayer games where this matters. The best solution here is as others have already mentioned not to trust the client in any way. Make the client merely a display device + user input device. Make sure you don't send the client more information than it needs to know.

That should take care of people just memoryhacking their own score. People can still do that, but only their own client will display 999999, all other players will still see the real score maintained on the server.

Even in this scenario though, some "hacks" are very very hard to protect against. In very fast action FPS games, the client could make a program that auto aims. To the best of my knowledge there is very little that you can effectively do against this. The best thing people have come up with is having a 3rd party tool that checks your machine against a database of known hacking tools.

FPS games also suffer from "wall hacks". basically hacks that go sit in between the 3d card driver and the game, and will try to display enemies in bright pink. Or will render walls as invisible, so the hacker gets an edge in the game.

With regards to the memory hacking: Is there any difference between a Unity game being more or less memory hackable than a c++ game, a flash game, or a shockwave game?

It depends. The main difference is in how easy each of these platforms make it for others to inspect the sourcecode of what is going on.

- flash very easy
- unity pretty easy
- c++ pretty hard.
- shockwave probably even harder.

You can make it harder by obfusciating your code. there are pretty decent tools out there that do this.

Does this matter? A solid design does not build its security around their code being secret. So one could say that if you have a crap design, then it matters.

As a game developer, you should be aware of this though. People will be able to look at the encryption code you're using to send data to your server.

Anyway, this is a very very broad topic, and putting it all under the header "hackable" does not lead to the most objective and informative amount of information possible

A few more sidenotes:
- if you're doing not a multiplayer game, but a singleplayer game + internet highscore, you are also in a rough spot w.r.t. protecting yourself from attackers. You can be attacked from many many different angles. People can memory hack. People can just call your backend highscore reporting script directly. There's a lot of stuff you can do here to make it harder, but it's really really tough to make it impossible. The good news is that you only need to make it harder than it is to actually achieve the score in your game for real
A trick I like to use for games that feature highscores that actually give away prices is to make each highscore submission include the recorded ghost race of the player. That way an admin can always later on replay the submitted ghost race to see if it looks legit. If a hacker actually goes to lengths to reverse engineer the ghost format, and rabricate a fake ghost race that gets a great score. Then they can have the prize

 

I'm not trying to be smug here but did this go from "Implement 4 lines of code to hide your variables" to "your source code is entirely viewable using reactor"? Seriously, I am not 100% following what's going on with the Reactor stuff. And, BTW, this is exactly why I raised the question in the first place.

~Hanford

 

Well there is a lot of broad theory and pondering that can be done on the topic, but what I really wanted was pretty specific:

1. How easy it is to use a cheat engine on Unity games? I don't care about flash, shockwave, or C. Answer: I think the answer here is vars sit in static locations unmasked. Correct?

2. What can we do to help secure our games? Answer: Never trust the client, use hashes masks and checksums, clear out and re-initialize objects to move them around in memory.

3. What is UT doing to help us, if anything? Answer: Tom's checking into it.

The big question on my mind is: Am I understanding the screenshots correctly? Does Reactor let you see a Unity Game's source code (or decompiled code with original var and function names)?

 

Great news, Higgy!

Yes it did. They are two separate issues, your initial concern in the OP of stopping memory editor attacks. As we said that's easy to overcome. But that doesn't really matter when it's trumped by the fact anyone can view, edit and change your game's source code with just a few clicks.

It's my fault for the fork, as it all started back on page 2 when I mentioned how easy it was for me to decompile Flash applications. That's when we remembered that Unity runs on dot.net and you can do the same damn thing! Us Mac folks aren't used to thinking about JIT and IL, unless we've had experience with Java.

Let me try to explain it in a simple of fashion as I can.

When you compile a program or a DLL using the dot.net framework, the output is -not- machine instructions that are executed by the CPU directly, like is done with an old Ansi-C compiler.

Code (csharp):

1. EA F8 D5 E0 A3 C5

Instead, what you end up with is basically a file containing the source code for an 'Intermediary Language.' Conceptually you can think of this as being half way between a high level source and low level assembly, that's executed by something akin to a run time interpreter like in tokenized basic.

You might for example have a javascript program that looks like this

Code (csharp):

1.  
2. document.writeln('Hello, World!');
3.  

The output of the dot.net 'compiler' would look something like...

Code (csharp):

1.  
2. .assembly Hello {}
3. .method public static void Main() cil managed
4. {
5.      .entrypoint
6.      .maxstack 1
7.      ldstr "Hello, world!"
8.      call void [mscorlib]System.Console::WriteLine(string)
9.      ret
10. }
11.  

All languages using the dot.net framework, managed C++, C#, Javascript, Visual Basic...compile into this IL. Since there's a 1-1 relationship between the HL and IL code, you can easily reverse the process with tools provided by Microsoft themselves!

Not only that, but the 1-1 relationship enables interesting things. You can not only reconstruct something very close to your original source, but you can take the IL and output a working program in any of the languages. You may have written it initially in Javascript, but you can change the target language to VB and output a working copy of your source in a totally different language! Funky, no?

I'm glad you did. It's an important discussion to have, considering the number of dot.net savvy individuals soon to be turning their eyes towards Unity.

 

At times it is good to kick up a little dust to see what's what under the hood. Again, the bat signal is up for our dev team so we'll see what insights they have to offer when they chime in.

 

Btw higgy, awesome avatar!

 

Some info from our experience:

It is quite easy to do memory modifications of scores. You can see this at Raptor Safari's leaderboards. We've actually abandoned the original database because it'll be moved to the unified Blurst system, and we didn't care enough to keep scrubbing it. Take a look: http://raptorsafari.com/leaderboards.php

Our original focus was obfuscating the backend/WWW communication. We're reasonably sure this was never successfully tampered. Instead, it became obvious that the in-game score was being changed upstream, at which point our web security code merrily encodes the bad scores.

Our new scoring systems include several mechanisms to address the problem. We keep important numbers in multiple places, in different ways, and actually track and transmit all scoring events for every game (we have 11 million scoring events logged in Minotaur China Shop, which also aids balancing/testing). If there is a disconnect anywhere we just mark the score as invalid. If you want to be devious, still show this score to the offending user. In the unlikely case it was a false positive, they probably won't notice, and if they were trying to cheat they might think they succeeded and move on. Never show a blatant "you cheater!" error message, because they'll keep trying.

Minotaur China Shop hasn't had any successful score hacks to date. The leaderboards are currently only shown in-game, though, and not on the website (yet), so there's also not as much incentive.

There are other vectors into score changes, though. It may be harder to directly attack the scores, but someone could try to change the point value of a scoring event, and not the score directly, or the game timer (so scoring is the same, but they can play longer), or any number of other changes. It will be quite difficult to approach 100% security in an automated way without Unity doing something on their end.

The solution for us will be some due diligence in protecting scores, technically, but also community actions. Banning accounts--even if they're paid subscribers--will probably be enough.

 

@Quietus: ROFL

 

It's Reflector, not Reactor, and yes it allows you to see the source code... or more exactly, the decompiled code (comments, local variables names, etc, are stripped out).
There are even 2 plugins for Reflector, FileDisassembler and FileGenerator, that allow you to entirely decompile an assembly and output it to disk, into a neat Visual Studio project, all ready to be opened, modified and recompiled.

It's actually extremely educational, you can browse the source of the full .NET framework, I can't tell you how much I used that in my ASP.NET days.
You can browse UnityEngine/Editor just the same... up to a point: Unity's dlls are actually mainly wrappers, exposing the actual engine (written in C++) to our scripts.

What you have to understand is that .NET is actually more similar to an interpreted language (like browser-JS) than a compiled language (like C++), which is why it's a great choice for scripting in games. It makes it extremely flexible... and also vulnerable.
But, as Lucas said, when it comes to cheat-protection the point isn't so much in the code as in your architecture.

It's interesting to notice that UT is putting more and more of their code directly inside the .NET API, like the terrain editor, and... wait to see 2.5 ! Proves that even for them C++ gurus, using C# makes sense.

 

Earlier in this thread, someone mentioned that they believed web players to be encrypted and haven't yet been broken. I was curious and thought I'd take a look.

I initially found it interesting that the UnityScript.dll didn't show up in the list of loaded modules for IE when the webplayer was running. The Unity, Mono, and a 'wrapper' DLL did. Unsure if this is normal. So I went hunting with OllyDBG and found it on the second search iteration.

I don't know anything about the DLL format beyond the old dos executable MZ header, so I was unable to extract a DLL that reflection would swallow in the 5 minutes I spent on this. I was able to scroll down and see the CIL for the classes, but was evidently mangling the "where does it end" part of the equation.

So to sum up, even without having a real clue what I'm doing I feel confident I could extract a game's source code from a running web player with relative ease. It would only take a little googling of the expected DLL format, along with some adept cutting and pasting.

I imagine someone who knows a little more about dot.net than a Midrange systems professional like myself could get it done by just snapping their fingers.

 

Really the bottom line is this. Packet sniffers can intercept anything that hits the machine. It is not hard to know where the intended information is targeted. You can use MD5 or RSA even XOR to encrypt your data for transport, that makes life a little harder, but the data is decrypted eventually on the client side, this leads to in-memory byte changes, which are easily monitored, so once the decryption happens, the hacker has the real value.

As was mentioned earlier, single player games, who cares. If they spent the money to buy it and want to hack the crap out of it and give themself a billion health and a billion exp, then go for it. I don't care.

Online games of any type is where it matters, and making hide nor hare of what you are passing to the server can also be interpreted. A hacker knows by the key press what state the game is in, from their they know what packet was sent, but that is about it. Sure they can automate this, look at WOW, people have made game bots that can play a character from creation to level 80 by simply putting the character in an area and start the bot program. This mimics human behavior, identifies results from the server and acts accordingly.

How do you know it is a human at the keyboard playing the game? Honestly, you don't and you never will. What matters is what you do with the data that is received from the client on the server. The server then acts upon this data based on your rules. A person in WOW with a BOT can't change their HP, ATK power, etc, but they can fight a war, harvest material, fish, everything else.

Example:
Player -> scan local enemies by mimic target tab, screen scrape or catch byte result from target where server says target is X, coditional if target is animal, kill, once dead, loot, destroy loot if loot <type wanted, skin, rest till mana full and health full, repeat.

Server -> got packet for attack target, act upon that and return battle result, repeat. Got packet for loot, act on that, repeat, got packet for skin, act on that, repeat.

What is hacked in this example?
Really, nothing. Some ingenious individual found a way to automate the client to perform tasks, they cna't go outside the rules or boundries of the server results, but they can automate what to do about the results.

AKA no one can hack the server actions, anyone can hack how the client reacts to those actions. The dumber the client, the smater the server has to be and more information between client and server, and the oppisite is true.

I used to play Sword of the New World, a free to play MMORPG, was fun, as long as I didn't have to do anything. The game client was programmed to practically play itself. You could simply run your team of 3 characters into a dungeon room and go to bed. Over night your characters would just slay anything that spawned, although you never got the loot, you got experience and your characters were cooler in the morning without countless hours of senselss killing, they since got rid of that, so I stopped playing (not that I ever really played, but it was cool to just watch)

Ultimately it boils down to only this, client = hackable, server = secure.

 

Launch Reflector -> Open. Yeah I would say that's not that hard! That happens to be the very point of this whole discussion.

As shown in the above pictures, they may be compressed in the file but they certainly aren't compressed in memory. It wouldn't be a whole lot of work and reverse engineering. With OllyDBG you can save it right off.

From what I've seen from playing around, there only appears to be a CR/LR encoding issue to work through with the resulting file and that's it. That might have resulted from my using Notepad to cut out the dll from the memory dump.

If someone wants to work that issue here's the two files. Winmerge made me want to puke so I wasn't up to the task.

DLL extracted from active webplayer with OllyDBG.
DLL from OsX standalone Build.

That being said, although you can probably scarf the source from a webplayer without too much effort, modifying and then re-injecting said source back into the running webplayer would take some serious doing.

 

This topic is very interesting to me from an intellectual property perspective.

Our AI system has a lot of code that we don't want exposed to the world, so I am concerned from what I am reading that it might be relatively easy to extract a working assembly of our core technologies from a running Unity web player version of our app.

I know that Unity iPhone compiles assemblies to native code, making it somewhat of a non-issue there, but we do also want to safely deploy our apps to the web as well.

Other than the obfuscation that we're already doing on our part, does UT have any suggestions on ways for us to improve IP security in the context of a Unity runtime?

 

Hi Cog, not sure if you caught Joachim's comment above, but decompiling code from -web player- versions of Unity is quite difficult, because the data is compressed into a proprietary custom format.

It's executables which are more vulnerable (nevertheless a non-trivial task to decompile).

(I'm so excited about what you guys are doing, btw)

 

Quietus demonstrated that it's quite trivial to decompile, actually. Might want to read his posts again.

--Eric

 

Hi Caitlyn,

Yeah, I saw Joachim's posts, and that's good that there's some sort of compression going on in the web version. It was Quietus' posts about grabbing uncompressed assembly data directly from memory that have me thinking.


BTW, we're pretty excited right now as well. The Unity tech is fitting in VERY well with our technology and application roadmap. It's a bit of a perfect fit for several of our target markets.

 

I decited that I wanted to see if I could get the TimedObjectDestructor script out of a complied DLL and use it with unity again.

Code (csharp):

1.  
2. using System;
3. using UnityEngine;
4.  
5. [Serializable]
6. public class TimedObjectDestructor : MonoBehaviour
7. {
8.     public bool detachChildren = false;
9.     public float timeOut = 1f;
10.  
11.     public void Awake()
12.     {
13.         this.Invoke("DestroyNow", this.timeOut);
14.     }
15.  
16.     public void DestroyNow()
17.     {
18.         if (this.detachChildren)
19.         {
20.             this.get_transform().DetachChildren();
21.         }
22.         Object.DestroyObject(this.get_gameObject());
23.     }
24.  
25.     public void Main()
26.     {
27.     }
28. }
29.  

That is the output.. what would i have to do to make it work in unity again?

It also looks like it got converted from JS to C#

 

Hmm.. so this is a vulnerability of all applications using the dot.net framework, correct? Forgive my ignorance, but how do the countless other dot.net applications handle this?

 

I discussed this issue in great detail with David Helgason himself nearly 2 years ago now, and several times after ( as some of you know ;-) ). Through all that discussion, I never felt like I was being taken seriously, and since the issue still remains 2 years later, it seems I wasn't.

I really hope UT decides to take this seriously and do something about it, and hopefully not after yet another 2 years... :-|

@Caitlyn: Yes it is, but there are a few things you can do to help reduce the issue. With Unity there is also a much greater level of flexibility as .Net is being used only as a scripting engine, and not the base runtime.

-Jeremy

 

I think usually they don't. The only reliable method of protection I believe is obfuscation:

Player becomes A
getScore() becomes a()

and so on, which makes the decompiled .Net code much less interesting from a business/stealing perspective. The problem of cheating is still significant though, as some other have pointed out it's quite trivial to figure out what the stuff does by looking at context and actual operations.

Now that I think about it, I'd say it's probably quite good to divide your code into very small functions. This makes it much harder to follow obfuscated code, because there will not be "chunks" of operations to read, but you will have to traverse a very large and complex tree of obfuscated types and methods to actually see what the code does.

Think of it as "un-unrolling" the code. Having small functions is also beneficial from a code quality standpoint.

 

I actually never thought of it, interesting issue.

 

Actually, most obfuscation is actually quite useless, and there are several tools that are quite good at de-obfuscating.

The best methods seem to combine actual encryption, and some anti-reflection tricks to at least make it harder. XHEO makes a tool like this, as do a few others.

-Jeremy

 

Agreed, obfuscation is totally worthless.

Codeveil, the XHEO product, appears to keep the assembly encrypted until right before the runtime needs it. That's a bit harder to beat, as you can only save off assemblies from memory one at a time as the program executes. Still not impossible.

The only Unity code I've encountered so far that I had trouble with, was the AniMate package. I toyed with it a bit with help from Neil on IRC. I was trying to a cheap-and-easy conversion of it into C# for a forum user, but couldn't get something that would recompile. IIRC, the issues revolved around it's use of reflection.

Myself, I'd be happy if unity at least made some crack at this. Doesn't look like AOT is going to be an option, but if it were only to pack the assemblies similar to the webplayer it would be better than what we have. Yeah it would only be a simple task to save them off from memory with OllyDbg as we've shown in this thread. Nonetheless, anything beats the low hanging fruit of having your game code as a separate assembly file just sitting there in the folder.

 

Yeah, I agree. XHEO's stuff also does method-by-method encryption as well if I recall, but last I checked it only supported Windows, as the decryption routines are of course native. I think that goes for their licensing system too.

Of course everything takes time to develop, but UT has known about this for many years now. Hopefully they will do something about it...sometime. ;-)

I am starting to sound like a broken record on this issue now, but we are limited in what we can do to solve this ourselves, unfortunately.

-Jeremy

 

As their encryption routine is native code, it's easily reverse engineered via OllyDBG. It seems to happen quite quickly for all the dot-net 'protection' products. I imagine if you searched about you would quickly discover some chinese hacker website that has an executable that strips the encryption of the assemblies.

*Edit: Yeah I found one for CodeVeil 1.3 in around 30 seconds. Not sure what their latest version is though.

There are even websites around where it's sort of a game to see who can break it the fastest. I probably linked to one somewhere back in this thread.

Well it does have some side benefits too Jeremy. For if you were interested in how a certain game accomplishes something...Oh that's a neat AI routine let me launch reflector and take a look!

 

Even though there are de-obfuscation tools out there to help deal with obfuscated code wouldn't the effort involved still deter many attempts? It seems at least with clever obfuscation a someone can't create a one click tool like can be done for other methods like those used against CodeVeil?

I don't have a lot of experience in this area but I can image many cases where tool assisted de-obfuscation would be more frustrating and time consuming than simply re-implementing the same logic. Is obfuscation really that useless? I've seen plenty of non-obfuscated code that I wouldn't want to attempt to understand let alone use and extend. I'm sure eventually you could understand it and re-factor it to something worth using, but by that time you probably could have implemented something much better yourself from scratch.

 

Codevil is actually one of the more robust and clever attempts amongst the ones I've seen. It offers deterrence and protection at multiple levels, not leaving things unencrypted for long. But with the encryption routines being in native code...yeah it didn't take them long likely.

In terms of deterrence, it's really a function of how popular the game is. Nobody is likely to pay attention to the source code being released of say a casual game like Bubble Panic (except for the poor guy who programmed it.) However when parts of the client source was recently released for Eve Online, people paid attention as it exposed some serious lack of even basic security within it.

We're talking about your intellectual property here and not others. If you think that releasing the source for your game along with the game (which is essentially what you're doing with a .net assembly and a stand-alone) is ok, then there isn't an issue. Others, might have a different opinion.

Of course as mentioned in this thread, it also exposes other things. For example a common thing is communicating with a database for login, high scores, etc. If the hash string used to encrypt communications with your database is simply declared as a variable in the source code...

Now don't get me wrong, with OllyDBG around your game isn't ever secure from mischief, even if they gave us AOT. However with the source code being stored in a .net assembly file that's easily accessible, the fruit is hanging on the lowest branches. This is an issue with .NET in general and not something that's specific to unity.

 

Yeah, I researched CodeVeil, DeployLX Licensing, Salamander, and a quite few other ones that I cannot remember the names of. As you said they are all very crack-able, some being totally useless and only taking about 2 steps to unlock, some taking longer than others, and requiring more advanced steps.

All I really want is that barbed-wire fence. I *can* get over it, bring wire cutters, or some heavy cloth, but do I really want to go to all that trouble? Maybe if I just knock on the front door and ask nicely, they'll let me in, or they will be nice enough to tell me how they did feature "X".

Like you said very well, the fruit is just a little too low for my personal liking.

@snoopbaron:

I have actually tried de-obfuscation tools that were very good. I cannot remember the names right now, but the result was very usable. With .Net languages compiling to IL, it's quite easy to convert it back to a usable form, and for experts, the IL itself is very usable.

That's why tools like XHEO's CodeVeil and other good ones usually mess up the IL as well, illegal characters in method names, messing up the method tables, and so on. When done right, reflection will choke trying to read that code (CodeVeil crashes Reflector), without IL-level modifications by hand first.

Anyway, we'll see what comes!
-Jeremy

 

If you can get some details on exactly how they implement changes that make reflector choke that would be great. If you look earlier in this thread, Eric was throwing various assemblies at me with bogus function names in an attempt to do something quite similar. However, I was still able to extract the source code from all he presented. Maybe there's a trick to it. A name with one of those alt-245234 squiggly and invisible character conventions perhaps?

Fiddling with the assemblies in a manner that makes reflector choke combined with packing all the assemblies similar to a webplayer would be a great thing for Unity to implement. It would at least raise the fruit up a branch or so, requiring the kobolds to raise up on their hind legs to pick it.

AOT for stand-alone builds and webplayers would be the ultimate solution, however that has some drawbacks such as bloating your webplayer with the inclusion of native binaries for both osx and winblows. There were also divided camps on whether or not it would slow down execution.

I don't know, given the chance I would probably click the checkbox myself.

 

I couldn't find good details on how it's done, and I searched pretty heavily. Those who know how to do it seem to keep the info quiet, as it's a main source of their income, heh.

I did, however, find _some_ more in-depth info on it, which might be useful. I will try to dig them up if I still have them, and I will PM them to you. Some of them are cracking sites, so I don't want to post it for all.

-Jeremy

 

Thanks for discussing such an important topic!

So what's the best way to deal with protecting the game?

jeremyace, I would be grateful if you PM this info to me also.

Thanks!

 

Really there aren't any options at the moment. If you distribute a stand-alone game just accept the fact that you're essentially distributing your game's source code along with it, retrievable with literally just two clicks.

A web player is slightly more safe, requiring you to save off the assemblies from memory with OllyDBG. It's just an extra step though.

There are some particular situations with steps you can take to make things a little bit more difficult for the prying eyes. For example, one that was mentioned earlier in this thread is using public editor vars to store hash strings for web encryption, and not declaring them implicitly in the source.

There's not much in the info jeremy sent me that's applicable to our situation. The techniques all revolve around inserting code into the game engine that would fiddle with the assemblies until the minute they're needed by the runtime, method by method. It's not something we can accomplish on our own even with having Unity Pro and Plugins. It would require a source code licensee to effect.

It's up to unity to provide us with a reasonable solution. Here's hoping the issue is addressed with Unity 2.6.

 

Sorry I'm late to the party, I've been busy plugging security holes in FusionFall.

There are several cardinal rules to developing *anything* that has a client/server relationship and the client is out in the wild. The first (and most important IMO) is "Never, never, never trust the client". The hack to FusionFall had nothing to do with Unity. I just got finished with a code review of the server and discovered that one of my developers had a bug where '' should have been '||'. There should have been a test for this, but there wasn't and now there are ogres. It happens and of course those clever, clever players will find a way to exploit it.

I'm of the (unpopular) opinion that once a client is published, you might as well make it open. The details about a game's art assets, network protocol, saved state, etc. are going to be available on someone's blog/wiki eventually (assuming, as someone pointed out, your title is remotely interesting). For example: when I took over the lead role in UO, I asked for documentation regarding the network packets. I was told that although there was documentation somewhere, I'd be better off surfing the net for the packet descriptions, they were more up-to-date. Funny.. but sad.

I've spent quite a bit of time over the years trying to figure out way to encrypt network traffic and mangle assets so users can't poke around. The end result was a complicated system that really only slowed down development and performance, but never really prevented users from figuring out a way to get it anyway. I would have been better off just leaving it. I could have saved that time and applied it to hardening the server.

That being said.. there are some known shortcuts in FF. I'm not telling you what they are, though A decision was made to take some shortcuts during development and if our game was popular enough to attract hackers, we'd invest the time then to shore it up. That.. or there are some terrible mistakes that need to be cleaned up ASAP. I'm going with the former, it makes me seem smarter. Either way, it's not Unity's fault.

 

This article is a good read regarding game security - it's from the old Arena Net website (courtesy of the web archives). Arena Net made Guild Wars, which has had very few hack in its time, and contains a number of ex-Blizzard staff who worked on netcode for Diablo and Starcraft.

 

To add to his debate, I can report that we in many ways had an awakening, as we recently saw a few of our web games hacked, as described in my blog post today.

We hadn't done much to make memory readout/replacement harder, so with the methods discussed here, it was easy for us to replicate the malicious behaviour. The games are now a bit more strengthened, and we'll of course keep investigating various counter-measures for retrofitting into these and other games, as well as for any new releases.

For what it's worth, this is at least indicative that even moderately popular and attractive games are likely targets for this kind of attack.