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 8997 times – thanks for reading.

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

Khawar Yunus

View all articles by Khawar Yunus

Related articles

Also in .NET

Posting Form Content via JavaScript

Web-based applications run smoother if instead of using the traditional form method, they use JavaScript to post data to the server and to update the user interface after posting data: It also makes it easier to keep POST and GET actions separated. SignalR makes it even slicker; it can even update multiple pages at the same time. Is it time to use JavaScript to post data rather than posting via the browser the traditional way?… Read more

Also in .NET Tools

Entity Framework Performance and What You Can Do About It

Without a doubt, Entity Framework is a quick and satisfactory way of producing a database-driven web application. As performance becomes more important, it does, however, require some knowledge of the traps that you need to avoid, and of the wrinkles that impact performance. Ben Emmett gives a practical guide.… Read more

Also in silverlight

Windows Runtime: Fielding the Obvious Questions

WinRT, the Windows Runtime, was launched by Microsoft to some puzzlement. How does it relate to COM? Is it a replacement for .NET or SilverLight? is it the same as Windows RT? Why is it important? Michael answers these questions and more.… Read more

Also in Source control

PowerShell Desired State Configuration: LCM and Push Management Model

PowerShell's Desired State Configuration (DSC) framework depends on the Local Configuration Manager (LCM) which has a central role in a DSC architecture. It runs on all nodes that have PowerShell 4.0 or above installed in order to control the execution of DSC configurations on target nodes. Nicolas Prigent illustrates the role of the LCM in the 'Push' mode of configuring nodes.… Read more

Join Simple Talk

Join over 200,000 Microsoft professionals, and get full, free access to technical articles, our twice-monthly Simple Talk newsletter, and free SQL tools.

Sign up