I run a small independent .NET development consulting firm, in a very competitive business.  There are many factors that determine whether your client gives their business to you or your competition, including proven quality, quick turn-around, security and dependability.

In order to achieve all this, we rely heavily on frameworks that we have developed ourselves.  As things stand, the source code of these frameworks is open for anyone to steal.  This is potentially very damaging to us because these frameworks provide solutions for some of the most common problems we face in almost all of our projects.  Because those frameworks have passed the test of time, we can guarantee their quality.  These frameworks also save us time because they are already done and are quick to deploy, giving us a faster turnaround.

Problem:

We use Silverlight in a lot of the work that we do. Silverlight is a technology that runs on the client’s machine.  This means our code, which includes our frameworks, has to be downloaded onto the client’s machine.  It is easy to use a decompiler such as .NET Reflector  to easily read complied assemblies in pretty much the same way as the actual source code.  This presents us with two problems:

1. Those frameworks are open for anyone to steal.  Especially when we have samples of our work (in Silverlight) on our website that contain those frameworks. 
2. If the inner workings of software that is specific to our client can be inspected, then that could present a security vulnerability for our client. This would lead to a loss of trust in our relationship with the client and probably loss of business. 

You can imagine what a big challenge this is for us when developing Silverlight applications.

Solution:

Both of these problems have a single solution:  Obfuscation.  Obfuscation is a systematic process of preventing attempts by decompilers from showing the actual source code.  Many techniques are used to achieve this.

The most common of those techniques involves changing the names of classes, methods and properties to some machine-generated names using unreadable characters. This alone makes any attempts to understand the code nearly impossible.

There are several other techniques, including string encoding, which is vital for protecting such information as login information, passwords, serials and other secrets.

Let’s get right down into it with a technical demonstration.  Here is a screenshot of a section of some fictitious source code (I am not showing the source code from my actual application for obvious reasons):

This is a precious piece of code as it can predict the future stock prices.  I, for sure, don’t want others to see it.   Unfortunately, anyone with Reflector, a free tool, can see the following even without having access to my source code.

As you see, even though it is not as easy to read as the actual source code, the key information is plainly visible.  So what happened after I obfuscated my code?  Well, here is the screenshot of disassembled version of my obfuscated assembly in Reflector:

You can see for yourself that all other information, except for the public member names, is hidden.

The way we protected our software (mostly Silverlight applications) and maintain our client’s trust was through using SmartAssembly, an obfuscation tool by Red Gate.  Overall the process was pretty straightforward. All you need to do is to compile your application and run their tool: that is it.  Below are some of the screenshots relevant to the obfuscation techniques I mentioned earlier:

Using the above screen I was able to fine-tune the obfuscation of my application’s assembly.

This screen allowed me to encode vital server information.

Here, my objective is to confuse decompilers so they don’t even attempt to disassemble my code.

Conclusion

Sharing is great for learning.  I encourage this amongst students.  But if you are in the business of developing software, then sharing (inadvertently, of course) the inner workings of your customer’s software may not be a good idea.   As the decompilers become more advanced, we must remind ourselves that almost anyone, even the novice users of computers, and not just hackers, can look into the inner workings of your customer’s software.  So my advice is that you should always obfuscate your software.  For me, SmartAssembly does exactly what I need.