An obfuscated wristwatch displaying the timeOne of the key features of the .NET is that assemblies (a fancy name for DLLs and EXEs) created in a .NET language are compiled to an intermediate step and use a common language runtime, or CLR, rather than being compiled to machine code.  This creates the downside of making it child’s play to reverse engineer a .NET program using the .NET Reflector.  This utility reads a compiled .NET DLL or EXE and displays the underlying source code.  This makes it far too easy for an unscrupulous person to steal trade secrets, hack license keys, or, worse, recreate your program as though they had written it.

To clarify a point, .NET code obfuscation is NOT an issue for web-based applications (with a single exception – Silverlight).  Web-based applications are executed on your web server and they generate an HTML file that is sent to the user’s browser – the underlying .NET source code is not sent.  (Obviously, if you use Javascript in your web application, that code is sent, but Javascript obfuscation is an entirely separate topic.)  Now, we mentioned Silverlight.  Silverlight is a bit of an exception.  The guts of your Silverlight application are contained in a .xap file.  That file is actually just a plain old zip file.  You can rename it to have a .zip extension, open it up, and extract anything that interests you (including its CLR-based DLL).

So what most programmers concerned with preventing their code from being stolen will do is to feed their assemblies to an obfuscator, for example, the Dotfuscator which is included with Visual Studio.  These programs make several changes to hide the intent of the code.  The first is obvious – they rename all function names and variables so that someone looking at it will not immediately realize its purpose.  Some will encrypt literal strings.  Others will change your code from using intuitive structures like for loops and switch statements to using confusing and hard-to-follow code sequences with lots of goto statements.

An alternative is to place any particularly sensitive formulas in C++ DLLs.  In C++, you can turn off the common language runtime for an individual source file, resulting in the generation of machine binary code for that file.  (Even machine binary code can be reverse engineered, but at least it requires effort and isn’t something that you can do in thirty seconds with a free, widely available utility.)  Unfortunately, this can cause problems depending on your circumstances.  For example, applications using C++ modules require additional Microsoft run-time libraries, which can be annoying to install under certain circumstances (think one-click install).  But for environments that don’t have such restrictions, writing CLR-free C++ can offer you a good solution to keep your technology secure.

For more about .NET code obfuscation and the .NET Framework in general, contact our eBusiness Solutions team of software engineers, database administrators, web application programmers, web developers, and systems engineers in their bat cave here.

image source: tom purves on flickr

Enjoy Your 30-day Free Trial!
inbound marketing software free trial Learn how Inbound Marketing Software can help your business grow!

Click here to get started with your free trial.

One Comment

  1. .NET code obfuscation is NOT an issue for web-based applications. Agree? | JASE Digital Media

    […] Code Obfuscation :: http://blog.jasedigitalmedia.com/index.php/2011/01/19/net-code-obfuscation :: One of the key features of the .NET is that assemblies (a fancy name for DLLs and EXEs) created […]

Comments are closed.