Obfuscation Explained…


Hi Vineet Batta here….

Background

Programs written for .NET are relatively easy to reverse engineer. You can use free tools like Lutz Roeder’s .NET Reflector to load .NET assemblies and view all the code (IL) contained within them. This is not in any way a fault in the design of .NET; it is simply a reality of modern, intermediate-compiled languages. These intermediate files have identifiers and algorithms that are immediately observable and ultimately understandable.

Why?

So anyone with a freely available .NET decompiler can easily reverse engineer code. Suddenly, software licensing code, copy protection mechanisms, and proprietary business logic are much more available for all to see – whether it’s legal or not. Anyone can peruse the details of software for whatever reason they like. They can search for security flaws to exploit, steal unique ideas, crack programs, etc.

For organizations concerned with their intellectual property in their .NET code there is a solution to help thwart reverse engineering. Obfuscation is a technique that provides for seamless renaming of symbols in assemblies as well as other tricks to foil decompilers. Properly applied obfuscation can increase the protection against decompilation by many orders of magnitude, while leaving the application intact.

Goals

An obfuscation tool alters an executable to conceal information and confound analysis. In other words, it alters an executable in a way that resists decompilation efforts without altering the integrity of the computing processes itself.Obfuscation tools remove context from compiled code that humans (and reverse-engineering tools) would use to decipher the code’s meaning. The objective of obfuscation is to remove context from an application while preserving its execution integrity.

Note: Obfuscation is not 100 percent protection.The goal of obfuscation is to make the reverse engineering process extremely time consuming and painful so that it’s not worth the effort, stopping all casual hackers and as many serious hackers as possible.

Additional benefits

1 . Better Performance

Obfuscation can also improve performance by compacting applications. During Obfuscation it will reuse identifier names, and other functions will prune unused classes, methods, instance variables, and design time metadata. The size reduction can range from 20-40% or more of an application’s size.Thus, these compacted programs often load faster and run in less memory.

2. Reduces the size of .NET program

Due to Compaction the size of the assembly is reduced by 20%-40%. This helps in networked distribution of components because application size is reduced.

Dotfuscator tool is a leading .NET obfuscator and works solely on compiled .NET assemblies. This tool gives you lot of options to apply and customize when you want to obfuscate your well written assembly and hide intellectual property.

In my next blog I will explain how to use Dotfuscator tool that comes with Visual Studio 2008. Stay tuned….

Comments (3)

  1. int19h says:

    Of course, obfuscated assemblies are also so much harder to troubleshoot, because you can’t properly debug them, and even stack traces are screwed.

    Here, we not only avoid obfuscators, but also install PDBs (/pdbonly) even in release builds and even for boxed software. Because we like our error reports nice and clear!

  2. Anonymous says:

    When I’ve done offensive research in the past, I found that debugging .NET assemblies was an incredibly easy way to avoid having to de-obfuscate an obfuscated assembly.

    Of course, I was using Reflector with the Deblector plugin instead of the normal Mircosoft CLR debugger.

    As for Dotfuscator, I think Salamander DeProtector still reverses it in seconds.  Why would you bother obfuscating?  Every single reverse engineering website that is worth it’s weight mentions DeProtector and Deblector.  Anyone armed with a search engine and a few hours can get around the restrictions of .NET assembly obfuscation one way or another.  There’s got to be at least 5 easily locatable PDF/CHM books out there that describe a detailed process to reverse engineering any .NET assembly, no matter how bad – including Reversing: Secrets of Reverse Engineering.

    As for the performance increase, can’t you just use a minifier instead to do that – and also get better results?

  3. Anonymous says:

    Is Obfuscating a shared assembly right approach?

    It will be tough to use an obfuscated assembly in some other application because all private symblos are scrambled in assembly’s metadata tables which will mean no IDE support and no public informaive interface.

    Other question that I’ve is, how do we decide when to obfuscate and when not to obfuscate?

    Like, when we implement

    server-side components (Web service or Web form), our assembly

    resides on the server. No one outside of our company can access the assembly,

    no one outside of our company can use any tool to see the IL.