Obfuscation - [Community requested]

Hi all,

I am trying to use the Darktable's Obfuscarator to obfuscate my webBuild.
I few time ago, i succed to obfuscate a build but the build was so obfuscated that i could not work.
So i tried many ways to improve the template.xml and the Obfuscarator.cs - with no succes.
Even worst, i could not figure out how i made it work the first time ...
Darktable told me on his site that he had no time for support.

When doing my research on obfuscation over the unity forums and answers, i realised that obfuscation was something
requested by the community.
I am making a multiplayer game using a*Path + PhotonCloud, because of the non-server kind of the game people can cheat easily and ruin the game.
I can imagine also that people dont want to have their code stealed ( me too btw) - the guys that sells things on assets store for example.

So if you feel concerned, feel free to give a little help.

What i got so far:
-the unity package:
https://dl.dropbox.com/u/27431359/Obfuscarator.unitypackage

- the xml template that seems to work for angrybots:
https://gist.github.com/darktable/3942495

- here is the gitHub page:
https://github.com/darktable/Obfuscar

-here are two other ...
https://github.com/AngryAnt/obfuscar
https://github.com/remobjects/Obfuscar

i found that the "combinePath" at line 227:
var frameworksPath = CombinePaths(EditorApplication.applicationContentsPath, "Frameworks", "Mono", "lib", "mono", "unity_web");
had to be changed for web build by:
var frameworksPath = CombinePaths(EditorApplication.applicationContentsPath, "Mono", "lib", "mono", "unity_web");

also i found that all the DLL detection have to be hardcoded too.

I got not many time, but i will update this topic every time i got something new.

Paradoks

 

Don't forget there are perfectly working deobfuscators for most of the obfuscators . . .

 

I think it is worth trying,
First of all, it will eliminate the little low level code stealers.
Then, i really thing that this obfuscator is pretty good - you should try to help

 

Personally i think it's a waste of time, i don't do it for my own software which i sell for 10K+€
It makes 0 sense, think it through and you'll see you get 0 benefits out of this

 

I agree with Ronan. Just put the time and effort into making a game better and cooler so no one wants that lame ripped copy clone game of the one that stolen your code. A great example is Ridiculous Fishing which beats the clone Ninja Fishing by far.

 

guys,

I really think that code obfuscation is necesary.

As i said in the first post, i am running a client side game running with photon cloud.
I want my game to be funny to play, wich will not be the case if someone modifiy my client code and get for example lvl 20 at the begining of the game instead of lvl 1 - thats a example - and it is so easy to do for little coders.
Also, i talked many times on the chat with guys that are selling their products on the asset store, especially scripts.
they dont put webplayer links on their asset store description because they know that the code can be stealed in about 5 minutes by a totally inexperimented guy.
By not putting a working link on the description they loose a certain amount of money, people often want to test the script running before buying it.
And experimented people will not steal anyway, so its potentially a money loss.

If you are exprerimented, wich i am not, you could have made the obfuscator work by the time you wrote those lines.
So please help and dont try to make me change my mind.

 

That's where you're wrong
1) If it's possible to be lv 20 then your client code doesn't need to be obfuscated but needs to RUN ON THE SERVER, you never trust the client period
2) Anyone who knows how to patch a game, can do it AS EASILY if it is obfuscated, period, it adds ZERO protection, simply making reading the code "marginally harder" at best, if you send me obfuscated code, i can pass it in a deobfuscator and the output will be nearly as easy to read as the original!

Edit: making the obfuscator work is not the problem, understanding it doesn't protect you AT ALL is the problem, it's MUCH EASIER to deobfuscate a program (there's a simple command line tool that does this and support almost all versions of all obfuscators) than to read the unobfuscated code, so if you can do the later, you can do the former.

 

Been looking into this issue for the last couple of days, and while it saddens me that my code will be essentially exposed to anyone and nothing can be done about it, it also helped open my eyes early in the development process on how to never rely on the client side for processing any crucial data.

However I would still like to implement even some basic obfuscation to my code, just so that the sucker peeking at my code would have a slightly harder time stealing it. I know it's pretty much useless but it should at least keep the kids out.

 

Ironically it won't keep anyone but yourself out (harder to debug if you get crashes on a client machine and need to figure out what happened)
How do you like a bug report saying an exception has been thrown: outofmemoryexveption in method ÿùù3244?

 

You're right, I probably won't waste any time on this...that time is better spent polishing the game.

 

I don't think obfuscation is useless, and I do think it will make the cracker's life much harder reading r.d(a) type of code all over than compared to myGuy.AddLife(life). Specially when your game code is complex to start with. I don't think the deobfuscation would turn r.d(a) back into myGuy.AddLife(life) since that data is already lost.

Having said that, 90% of the crackers would just walk away but if someone is really determined, obfuscation would not stop him, just slow him down.

 

But most of the code won't be r.d(a) type of code
You're not going to be able to obfuscate code you don't own, so all the external calls will stay as is (anything in unity for exemple)
Anything you want to expose publicly will also stay as is (so anything visibile in the editor for exemple)

So if you sell a player asset, and you have a public property life in it that is accessible from unity editor, and a private method named removelife, at most it will become

void thezihtizth(int thezith)
{
this.Life -= thezith;
}

Not that cryptic now?
All you've won there is if this.Life is a nullable<int> and it throws an exception because you have a bug that left it as null you'll get customer reports saying "your plugin is crashing in Method theizth, nullreferenceexception" instead of "your plugin is crashing with a nullreferenceexception in Method ChangeLife"
So yea you get crappy customer relationships 0 advantage in protecting your code, your code will still be crystal clear readable based on what you can't obfuscate around it, you can obfuscate decently only if the following 3 hold (code is still readable but harder)
- You mostly use your own code, not external code
- You don't expose any form of public API (standalone program as a single assembly with no public classes/methods)
- You're not constrained by unity (the good obfuscation methods won't work due to performance or api limitations like no code gen allowed on iphone etc)
Anything you do that fits none of those 3 criterias is basically giving you 0 protection, as i said try it, then pass it in a deobfuscator, you'll see you've lost pretty much no info except private variable names such. Any public method will still be properly named as well as it's parameters (else it wouldn't be callable).

 

Based on the fact that I've only bothered obfuscating a native android game I made, and never a Unity game I made I will say: "Perhaps you are right!" But that's because I have no clue what obfuscation in Unity is like. In native Android code, when I obfuscate, everything looks super cryptic.

Based on what I understand you're saying, having any public properties in my class, the property name would not be obfuscated is that right? Is that because of the serialization? If so, what if I make that property not realizable, would that obfuscate that particular property then?

thx. p.s. my response is for learning.

 

No it has nothing to do with serialisation, it's just the way .net / mono / whatever based on the CLR code works, it's fully readable because all metadata is encoded. So there's no headers / lib whatever like in native to "find functions" , they're in the dll self documented by the dll, so it's not possible to remove that information if that information is actually necessary, anything you expose publicly, has to be fully unobfuscated, or it simply won't be callable.
If you want i can make a small sample dll show you the dll in 3 states
Unobfuscated
Obfuscated with a basic obfuscator
Deobfuscated with a free tool.
It should make things clearer.

 

Sure that'd be great! But from what you say, that kinda sucks. In Java you can obfuscate the crap out of your code even when using 3rd party libs, it even obfuscates the 3rd party libs for you. My background is Java by the way so I know nothing much about c# except coding it as if it's Java lol

 

The system is similar, except unity libraries aren't 3rd party libs, and programs you make with unity aren't your programs, so you can't treat it that way as it's unity that embeds your code, that references unity code, so 0 chance at obfuscating unity code (which means any code "calling" unity will be pretty readable), same for any code you actually want to expose.

 

when you say "Code I want to expose" What do you mean could u give an example? I'm talking about games, perhaps give me a game example.

 

This only applies for selling dlls on the store (where the public API the calls to unity would be visible), if you're talking about making a game with unity shiping that obfuscated then that's even more complex, there are 2 cases:
1) most of your code resides in a dll that you obfuscate, if you call that code from unity you're still going to have the same issue, anything you need to call will be public, and thus the signature will be as readable as in plain code.
2) your code only resides in source form in unity, then it's even more complex as unity is in charge of building it, i don't even know what unity ships as but definately not as a .net assembly in all platforms so it wouldn't be easy to simply obfuscate the output as the output is embededing the assembly, the whole thing isn't .net at all (on ios android etc), so i don't think it's anywhere near doable, regardless of the merits of obfuscation.

 

Also, can you give me an example of "Any code calling unity will be pretty readable".

For example, if my game has 100 classes that extends MonoBehavior
All my variables in there are not exposed to the editor, e.g. they are either private or public with [System.NonSerialized].
Will the obfuscation obfuscate all the code in my classes? if not, then which parts.. any part in the Update for example? I'm not clear on how this works.

 

System.NonSerialized changes nothing to the fact it's public so callable from elsewhere, MonoBehavior is unity specific but it changes nothing, as long as something is public, it's exposed to outside assemblies, so your obfuscator won't touch the signature (it can touch the code inside), or the dll won't be usable from outside (unless you want your customers to actually call methods like MyClass.[["[#[ù;;()

 

OK. I think I see what's going on now. I didn't know that's how this worked. I always imagined it working like how Android does, where my custom code and and libs it uses including Android itself is really all just 1 big pile of a program. I guess that's a downer. Do you know if Unreal is about the same thing in terms of what we've been talking about?

 

GuaranteedProtection.com

​

App Being Stolen? Use Guaranteed Protection to protect your code today!

With top secret and patent pending algorithms GP detects miscreants instantaneously! It then, at a random time, sends one of its specially trained negotiators to 'explain things' and reach an amenable resolution! Some negotiations have been so successful that in penance the third party has offered appendages such as ears or toes as restitution! Why wait and longer, call us today or we'll send *you* a negotiator!

 

lol

 

Your own code will be obfuscated, basically if you have something like this

Then you could hope for something like this at best :

For unreal no clue, just keep in mind that .net is a managed language with reflection capabilities, it's not comarable to compiled code in term of complexity to reverse engineer as by it's very nature it's self documenting, you can strip "some" of that, but unless you're in a very speficic scenario and know what you're doing, you can actually strip VERY little

 

Hm.. what if Change is called by your own code only, e.g. You got another class called DriverBehavior and it references NewBehaviourScript.Change() and Driverbehavior is obfuscated too.. then Change() should be able to be obfuscated right?

 

No, it doesn't matter who calls what, what matters is that it's public and getting compiled into a dll, how is the obfuscator supposed to guess that "no this method isn't going to get called from elsewhere"?
In any case if that's your use the method shouldn't be public, it should be internal, in which case i guess it can be fully obfuscated.

 

Hm.. almost all of my code are called by my own code. The only code that unity calls are it's Update methods, and some methods NGui calls via reflection, e.g. onButtonClick() etc. Any other methods and vars are all called by my own code regardless if they are public or private.

For Android I use ProGuard and it processes the entire game to see what calls what. So any references are all updated accordingly and obfuscated. The compiler knows what gets called by what so does the obfuscator. So if the compiler detects that Change() gets called by Classes A, B, and C, then the callers in those classes will be obfuscated to call the new name for Change(), e.g. z() will be called by A.z() B.z() etc.. Unless you specify explicitly in the ProGuard config not to obfuscate something, everything referenced at compile time gets obfuscated. If things are called via names by reflection then that's a different story, the callee will still be obfuscated but at runtime it will just crash. I find it strange that .Net would be different.

 

For point 1, you can kiss reflection goodbye if you obfuscate unless, once again, you only reflect upon public things that aren't going to be obfuscated.

For point 2, .net doesn't "work diferently", it's just that unity isn't .net, it HOSTS .net , so it's native on some areas, you can't give your obfuscator the whole unity game because the whole unity game isn't a .net assembly, it's more complex than that, if it was a standalone C# game made in visual studio by hand, then you could obfuscate the whole thing including cross references.

 

Ahh.. I got you... ... so yup.. then as said 10 posts ago.. I think you are right! It's useless lol. I wonder if unity should have been design differenly(no clue how) so that the product produced is not a host with stuff in it but a whole program... no clue what I'm talking about but anyhow.. it's a bummer in a way. Guess you could use the obfuscator to try to reduce a few kb of code but that's about all.. and cause head aches when debugging production stacktraces..

 

It's not possible, .net / mono don't run on all those platforms, the reason unity is cross platform is because it compiles to (different type of per platform) native platform code and use that to host the mono runtime. So if unity had been designed as you said, it would be basically limited to win / mac os / linux / maybe some consoles.
I guess they could have gone hybrid, having the assembly as a separate file in a prebuild process, letting you change it, and then embarking that in their final build, but really all that would do is allow for you to complexify your code to make it harder to debug, potentially lower performing and as i said it would still be trivial to decompile, if you want something hard to decompile your best bet is a heavily optimising native language compiler, not a managed language that keeps assembly metadata as part of available (even at runtime) information.

 

oh well.. I guess when it comes down to reality, how many games have actually been stolen and published as their own. Who would steal a game unless it's reallllllly worth stealing, and if it's that worth stealing you have probably already made enough money by the time it's stolen. probably less than 1% of the players will even try to do anything hackish to make a difference in your income.

 

No one does that, if someone wants to re publish the same game they don't need to read the source or understand it, they just re publish it.
If they want to steal things it's probably the assets, those aren't gonna get obfuscated
If they want to steal your code, they're wrong, it's going to be more work in most case to understand a whole codebase (obfuscated OR NOT) than to rewrite it unless they're doing in in a triple A game and are looking at stealing just a specific, research heavy, subsystem.

 

Yeah exactly what I'm thinking. Writing a game from scratch is way easier than understanding someone else's code. most people's code without obfuscation already look obfuscated haha. If I don't look at my own code for a month and look back I often would not know what goes on and I'd have to read my comments to get reminded.

 

My friend, did you succeed? android obfuscation ..

 

Hi not with Unity. I didn't bother anymore.

 

Kind of guessed "obfuscate" was a waste of time with unity.

Not so worried about code, more focused on hacked clients. Can cause some nasty problems, and its not just cheating.
It seems an authoritative layer is the only way to really protect a game.

Problem I'm facing and revealed from most recent auth tests on an EC2 instance, is the memory use on the server, a unity project sits in at 10mb under -batchmode and that's a blank project lol.

I have been looking for some sort of micro unity instance, that will burn tiny resources while offering limited functionality.

I haven't tested it yet but a hosted photon server could be the solution, still trying to work out how to use it at the moment.

 

10MB is a ridiculously low amount of memory, don't mix startup memory with average memory, they're unrelated, there's a fairly large runtime, it needs to be in memory, doesn't mean your memory usage will grow (it will still be 10MB + whatever you use, not 10X whatever you think you'd use)

 

I do paid-for consulting on this type of security questions. I won't go into details because the topic is deep, but in summary, I tell almost all of my clients to forget about obfuscation. Minification for Javascript, for example, has its own benefits and that it gives you some obfuscation as well is a nice side-effect, so by all means, do it.

But a pure obfuscator is rarely worth it, and if I read that it made your code stop working, if it did that even once, that's a massive reason to never, ever, touch it again.

Reasons in a really tiny nutshell: Your "casual" hackers will give up as soon as it's mildely complicated, which it will almost always be anyways. Your determined hacker will break your obfuscation wide open anyways, period. All you are doing is giving yourself a false sense of security, when what you should really be doing instead is giving your game some real security, by server-side checking.

Your code is broken. If I can cause you nasty problems by hacking the client, I can cause you nasty problems by ignoring the client and just submitting data directly. And if I can cause you nasty problems by user-submitted data, then your code is broken.

Quasar got that right. If you rely on the client for anything important without at least verifying it server-side, your design is fundamentally broken and no amount of obfuscation, authentication or magic will save you.

 

I think obfuscation it's worth it. Nothing is 100% protected, but not obfuscating for that reason is like not closing your house door because any determined thieve can open it anyway. You lock the door anyway.

 

You cannot protect client side code, the obfuscation WILL get circumvented if you get enough players (no joke, there is whole scene dedicated to cracking them). Either do abusable actions serverside or forget about it.

 

Except closing your door, unlike obfuscation, doesn't have much of a downside. Solid obfuscation (the non trivial ones) has performance and quality downsides, as well as API restrictions makes debugging bugs on clients a total mess.

If closing your door has 1% chance of setting up a fire, made your wife uglier and your house smaller, all while making it forbidden for you to practice some activities, would you not think about wether it's worth it?

It's all a matter of tradeofs

 

this whole thread is extremely worrying to me, it could be very damaging to an indie dev, apparently Infiniminer was given up on because people reverse engineered it and the code was not obfuscated

further i do not see why this would cause debug issues if I keep and work on the un-obfuscated code

https://en.wikipedia.org/wiki/Infiniminer#Infiniminer

i can't believe that .net retains the function names!


should i say that i would not care further down the line when there is copyright, but in an early stage u want to share a demo or something and you have to worry about this!?!?! wtf



could we have some response from Unity here!

 

It hinders post deployment debugging (debugging issues on end user computers).
And of course .net keeps function names, how else do you think reflection works?

 

I know you guys are saying don't bother with obfuscation, but I'm curious what your thoughts are on this. ..
http://forum.unity3d.com/threads/183225-CodeGuard-(Obfsucation-and-code-protector-editor-extension)

 

"I know you don't like obfuscation."
"What's your opinion on this obfuscator."

Hrmmm... I wonder what the response will be.

It's an obfuscator. Who ever designed it, designed it to deal with the fact that in Unity a lot things are referenced by name loosely. So then it works. Giving you obfuscation capabilities.

Either you're asking what we think of the usefulness of the product. Which the answer is a big obvious, they aren't going to think it's useful.

Or you're asking how we think the quality of the product is at performing the task? Too which, why would anyone who doesn't find it useful care about how good it is at doing it?

As I'm not part of this we technically because I was not part of the original discussion. So I'll take a once over of the first post. And already I see a problem... all the methods that are important like 'Update' and 'Awake' have proxies wrapped around them and the originals still obfuscated. WHY!? So now my call to Update requires 2 calls? Nothing obfuscated now! Why not just obfuscate the code in Update, and leave the damn name of the method alone.

Not putting any more effort into caring what this thing does as I find the product useless in the end.

 

Thanks @lordofduct
I appreciate that you even looked at any of it. My curiosity lay in the fact that you guys are saying that Unity is not designed to be properly obfuscated (which I don't dispute), therefore I was wondering why this other guy even attempted to create an obfuscator for Unity, and I was further wondering if what this guy created was a total sham, since if Unity can't be properly obfuscated, then what did that guy actually end up creating?! Of course a small part of me was hopeful that that guy figured out a magical way to properly obfuscate Unity, but alas you pointed out that is not the case. Thanks for your time and analysis.

 

the main problem with obfuscating unity is the fact that, like most game engines, unity references things a lot by name. For instance you can add/get component on a gameobject by a string name of the class. Thing is, if you obfuscate that class name... the string will no longer match. The same goes for coroutines, messages, and other things that can be referenced this way.

Another problem comes with serializing and the sort. This to can have issues when obfuscating.

All you have to do to obfuscate it is make work around for these parts.

So yes, it is possible... it's just traditional methods overlook this stuff because .net is usually written in a strongly typed manner. Unity is usually not written in a strongly typed manner... thus the problem.

This does mean though that you'll have to work within the boundaries of how the obfuscator expect your code to be. Things can still break... things like reflection and the sort. But these same things also break in regular .net/mono projects. If you use reflection to call things via strings and the sort in a regular .net project, and obfuscate it, it will break.

And there in lies the biggest issue with obfuscators. They have the potential to introduce bugs.

 

Thanks
So do Unity games get hacked more often than non-Unity games? (since they are less likely to be obfuscated, and thus quicker/easier to hack)?

 

To be honest... I don't know. I don't really look into it.

Games get hacked all the time, it's just a thing that happens. And personally I think it's cool. We wouldn't have the great mods that Minecraft have if Notch/Mojang were all like "don't hack our game... ugh". No instead Notch was like, "awesome, that's really cool", and even some times repurposed hacked ideas into the vanilla game.

Think about all the hacking that occurs in games and becomes awesome. All the mods/customs/hack versions of things. Counter-strike started out as a mod/hack. S*** even the first team fortress was a Quake mod.

So what if players hack your game and change the experience for their own.

We all have "house rules" for Monopoly I bet.

I don't know anyone who ever played MouseTrap correctly.

If someone hacked your game, and the turned around and profited off of said hack be reselling it for instance. You have grounds to sue them under copyright infringement.

But if some kid hacks your game so they can get to level 20... WHO CARES.

If it's because it's a multiplayer game and the community will be ruined. Then you control the level on the server side so that people can't hack that version.

But the home version they play on in their own time. WHO CARES? It may actually attract more people to play them. Like Minecraft.



Note, I'm not getting into copy protection here. That's a whole other thing. And obfuscation does not assist copy protection.

Obfuscation is just trying to make it difficult to have people read your code if decompiled... and I don't see the point really. Why spend so much time and resource trying to thwart it when it's really not that big a deal.

 

LOL
I guess I'm more worried about people profiting off of copying my game. Thanks for your insight ☺