The dark side of CRM: protection of intellectual property – final part 4

In this series I demonstrated how your compiled .NET code could be decompiled, using free to get decompilers. I showed an example of the SharePoint connector class which I decompiled, revealing all technical details.

In this final article in this series, I demonstrate how you can apply obfuscation to make your code impossible to decompile. As the most of you write complex CRM applications, the most of you implement server side plugins.

These plugins often consists out of multiple dll’s that get merged (using ILMerge) in de post build step within Visual Studio (this is especially needed when you write sandboxed plugins, you need to have all related binaries except Microsoft’s dlls within the sandbox).

In the previous (theoretical) article, I mentioned a couple of obfuscation tools for .NET that you could use. At the moment my favourite tool is ConfuserEx, which can be downloaded free of charge.

First Attempt

After you downloaded ConfuserEx you unzip it, and you are ready to go. First things first, let’s fire up the ConfuserEx executable. You will get the following screen, in which you enter the name of the folder containing the assemblies to obfuscate (Base Directory) and in which you enter the name of the folder containing the obfuscation output.

Once done, you click “Save project”, and you can save your obfuscation project (I chose the name testobfuscator.crproj).


Then you go to the “Protect” tab, and you press the Protect button. Magic starts to happen and a couple of seconds later you have an obfuscated assembly.


We fire up DotPeek (our decompiler) and we drag the obfuscated assembly into it.

*Bugger* we still can see the inner details in our obfuscated assembly!


Second attempt

Seems like I forgot something. Which turned out to be true…  I forgot to specify how the obfuscator should work. In order to do that, I went to the “Settings” tab.

under Modules, I selected Global Settings and pressed the little “+” button on the right. A line appears with the text “true”. Then I went to the small “Edit” icon below the “+” and pressed it.

A window popped up. In the Preset dropdown, I chose “Maximum” preset and after that I pressed the “+” button on the right. Under protection a condition appeared. I Pressed done and voila… all settings that need to be made were made!


I saved my project settings, went to the “Protect” tab, and pressed the Protect button. The code was obfuscated again. A new attempt to see if my code is obfuscated. I dragged the new obfuscated assembly to Dot Peek.

DotPeek indicates that the assembly is not supported!


Now that the source code has been secured, the question arises if we can use the obfuscated assembly in our projects. The answer is simple:

“YES we can”. Even intellisense still works…


Post build script

ConfuserEx als has a command line version. In case we work with build scripts, we easily can embed a final processing step in the post build script. The instruction would look like this:

Confuser.CLI.exe [name of confuserex project file.crproj]

Running the command line version results in the output below:


Some final remarks

In this article I demonstrated how simple it is to protect your source code. Do you always need protection? Depends on the job you are doing. In case you are an in-house developer then you probably don’t need obfuscation.
In case you build commercial solutions on top of Dynamics CRM, you seriously have to consider to use obfuscation. Otherwise you might end up not being paid for your labour.

In the settings tab of the obfuscator I chose the “Maximum” preset. For some projects it might be sufficient to have a lighter version of obfuscation. If for some reason your obfuscated assembly doesn’t function correctly within your environment you might need to lower the degree of obfuscation. Don’t forget that obfuscation is a technique that’s searching the boundaries of the platform. Some combinations of the chosen obfuscation settings and functionality in your assembly might end up at the wrong side of the boundary. Don’t cross it!

In case you need to choose a weaker level of obfucation, you always can do a bit of code protection yourself. In weaker levels, the public access methods of your assembly might be readable after decompilation. In that case, you could opt for moving the implementation of the public functions to internal classes and functions; leaving nothing but empty wrapper functions to those prying eyes.

Thank you for reading…

Leave a Reply

Your email address will not be published. Required fields are marked *