02 June 2010

Obfuscating Silverlight with SmartAssembly

If you are in the .NET Software business, you have a problem. .NET assemblies can be read, and debugged, by the purchaser with almost the same ease as if you'd distributed the source code. This isn't always what you wanted or intended, so you'll need an application such as Smart Assembly. Khawar explains the simple process of protecting your company's assets.

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):

1046-Obfuscate1.JPG

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.

1046-Obfuscate2.JPG

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:

1046-obfuscate3.JPG

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:

1046-obfuscate4.JPG

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

1046-obfuscate5.JPG

This screen allowed me to encode vital server information.

1046-obfuscate6.JPG

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.

Keep up to date with Simple-Talk

For more articles like this delivered fortnightly, sign up to the Simple-Talk newsletter

This post has been viewed 9047 times – thanks for reading.

Tags: , , , , ,

  • Rate
    [Total: 10    Average: 4.2/5]
  • Share

Khawar Yunus (MCTS - WPF) - Sr. Programmer / Architect, brings 12+ years of industry experience in developing, architecting online, desktop and client/server software using Microsoft technologies. He is Microsoft Certified Technology Specialist in WPF application development. He has provided consulting services to some of the most recognized companies including Mary Kay, Wells Fargo and Hill Holliday. He specializes in WPF, Silverlight and ASP.net application development using .net and SQL Server.

View all articles by Khawar Yunus