The dark side of CRM: protection of intellectual property – part 2

Welcome to part 2 of the dark side of CRM. In the previous article I scattered your view on the world: People are not always willing to pay for your labour. However as developers, we can fight back and make it very hard to decompile our intellectual property. That’s rights, we are going to talk about Obfuscation.

As I mentioned already, when we compile our .NET source code into an assembly, the source code is compiled into a Common Intermediate Language (CIL). CIL was formerly known as Microsoft Intermediate Language (MSIL).

MSIL/CIL is the lowest-level human-readable programming language defined by the Common Language Infrastructure (CLI). The CLI is a runtime environment which executes the MSIL/CIL binaries, bla bla bla. * Please, stop before it gets boring *

Ok, what is the takeaway: Your compiled .NET assembly is compiled into a human readable format. With the proper tools your assembly can be decompiled and your intellectual property is up for grabs. Ouch!  

Before we come to the subject of obfuscation, I’ll show you how easy it is to decompile existing source code and how the decompiled source code looks in comparison to the original code.
For this opportunity I take some of the compiled classes I wrote before when developing the SharePoint connector classes for CRM.


There are several tools available (free, open-source and commercial) that can be used to decompile, compiled .Net binaries. A couple of years ago Reflector was king of the hill.
As soon as the free version of Reflector disappeared from the market and became commercial, several new contestors stood up like Dot Peek and IlSpy. My personal favourite is Dot Peek, which is free and can be downloaded at the JetBrains website.

As soon as the decompiler is installed, decompiling .Net assemblies is as simple as dragging them onto the software. A couple of seconds later you can browse the decompiled assembly.


As an example, I have the AddFile() method in the SharePointConnector class opened in Visual Studio.


After decompiling the assembly by dragging it into DotPeek, I can browse the entire object tree; classes, methods, properties. It doesn’t matter if they are private, internal or public. The source code is up for grabs.

See the AddFile method in the decompiled file below. The example might be shocking for some readers  .


The comments are gone, and the markup of the code is slightly different. The code is perfect readable, meaning your intellectual property is not protected.

In the next part of this article, I’ll demonstrate how you can use obfuscation to protect your intellectual property, and what you can do to make your code even safer.

Stay tuned, more to this this week…