Prevent creation of new namespaces

[antitheory]

I am trying to use obfuscar for a Unity3d project and I am running
into some trouble. One thing is that the Unity Engine looks for
certain method-names within Component classes (things like "Start",
"Update", etc.) The work around for this is simply not obfuscating the
method names. It would be nice if I could specify a base-type in
SkipMethod... so I could still obfuscate method names in classes that
are not Components)

The other problem I cant solve has to do with namespaces. For whatever
reason Unity doesn't recognize components which are in a namespace.
They have to be in the root of the dll. When I look at the obfuscated
dll in Reflector I notice that Obfuscar seems to obfuscate and mix up
namespaces... It would be nice if I could specify thI want the
namespace hierarchy to remain as is, and just obfuscate the names.

[Calvin]

This is as far as I was able to get with my Unity obfuscar work:

https://gist.github.com/1038848

I manually named all the built-in methods that need to be skipped (Awake, Start, Update, etc.).  Also if a method name is surrounded by "_" ( _ExampleMethod_ ) it gets skipped too.  This is so that stuff like SendMessage can still find the method it's looking for.  Protected and Public methods and variables are skipped because they may be called by code that hasn't gone through obfuscation.

What I've been trying to do is obfuscate a web player build, but I haven't been successful yet.

[antitheory]

Good idea with SendMessage. I usually don't use SendMessage but I do often call coroutines with strings because that's the only way to get StopCoroutine to work with them. I am going to try modifying the obfuscar source to deal with the namespace issue I mentioned above and see if I can get it working. I will post back here with results.

[antitheory]

I have managed to make some small changes to get obfuscar working a little better with Unity... It's not 100% there yet but almost

For one I changed line 810 of Obfuscar.cs to:
if (info.ShouldSkip(methodKey) || method.ReturnType.Name=="IEnumerator")

This should prevent your Coroutines called using StartCoroutine(string) from being missed.

Another change on line 436 of Obfuscar.cs
if (type.DeclaringType != null || type.Namespace=="")

Will prevent MonoBehaviours from being put in a namespace.

But of course there are some more issues...

One is that you will get errors (readable in the output_log file with a Stand-Alone build) when you obfuscate the MonoBehaviour derived class names. For example:

The class defined in script file named 'Sun' does not match the file name!
 
(Filename: C:/BuildAgent/work/f724c1acfee760b6/Runtime/Mono/MonoBehaviour.cpp Line: 1650)

Because the Sun class has had its name changed. I haven't yet found where this name is still residing after you obfuscate. Possibly in the .exe itself, which you cant decompile in Reflector as far as I know. It may be possible to search for and replace all of the references wherever they reside if they exist as strings.

To get around this for now you can just skip obfuscating the MonoBehaviour derived class-names (but still obfuscate their innards) by using these directives in the  XML config:

<SkipType name="^[^\.]*$" skipMethods="false" skipFields="false" skipProperties="false" skipEvents="false"/>

So now my game starts but I still have a major issue. It seems Coroutines are still not working... From output_log.txt:

Coroutine 'CoroutineMethodName' couldn't be started!

Which is strange, considering I can look in the obfuscated class in Reflector and see that this Coroutine is indeed there and it looks the same as in the non-obfuscated .dll

[Calvin]

Because the Sun class has had its name changed. I haven't yet found where this name is still residing after you obfuscate. Possibly in the .exe itself, which you cant decompile in Reflector as far as I know. It may be possible to search for and replace all of the references wherever they reside if they exist as strings.

Information about classes gets serialized with the entities saved in the levels.  I'm assuming this includes class name and any of the public fields that show up in the inspector.  I think this might mean that type names shouldn't be changed, regardless of what namespace they are in.  Or at least any class that is marked as System.Serializable.

[Calvin]

Have you seen the obfuscator that's in the Unity Asset Store?

http://u3d.as/content/m2h/obfuscator/1sA

It's not very aggressive with it's obfuscation, but it does work on standalone builds, if that's all you want to obfuscate.

[antitheory]

Ahhh of course...

Well it's easily enough to exclude classes marked as Serializable from being being obfuscated I suppose. However the obfuscation then continues to become weaker and weaker the more you leave out. It would be interesting if there were a way of altering the serialized objects in such a manner that they would work with the obfuscated classes.

[antitheory]

Yeah I have seen it but I'd rather roll my own solution. Save $25 and learn something along the way! The obfuscator you linked to uses Obfuscar by the way.... I suppose I could buy it and then decompile it and see how it was done (assuming the code hasn't been obfuscated... which would be rather ironic)

[Calvin]

I bought it a while ago.  The most useful part in it is a well written build script (documented .cs file) that demonstrates how to apply the obfuscation after a build completes.  Unfortunately it doesn't work with web player builds.