Silverlight Security – Code Obfuscation – Part Two

Seems like many .NET developers nowadays are concerned with deploying their apps without applying any form of protection on them beforehand.
As mentioned in a previous post silverlight code must be downloaded to the client machine, this makes it possible to recover the original source code using tools such as ILDasm & .NET Reflector.

Most of us, when we think of obfuscating silverlight apps, refer to a form of obfuscation called ‘symbol renaming’ which means changing the names of classes, methods & variables to meaningless names. The result is a much harder code to read, that makes it more difficult for someone to follow the semantic meaning of the internal structures included in the obfuscated assembly.

This doesn’t come without a price, often due to usage of reflection API either directly by the programmer who wrote the assembly or indirectly by the .NET class library relying on reflection API (e.g. xml serialization, web services) the code would break.
In addition symbol renaming makes it more difficult to understand exception stack trace information collected from production environments as original method names are no longer available. The image below demonstrates how an exception stack trace may look like:

Obfuscated call stack

Developers searching for non-invasive solutions, one that doesn’t suffer from the flaws mentioned above may be interested to look at CliSecure .NET Obfuscator, this is a code protection solution that offers new forms of obfuscation that are effective, easy to configure and integrate with your existing silverlight apps or others still under development  (support for windows phone 7 included).

CliSecure .NET Obfuscator site

On top of symbol renaming CliSecure .NET obfuscator introduces advanced forms of control flow obfuscation and a new obfuscation technique called ‘method call obfuscation’.

Control flow obfuscation aims to destroy existing code patterns and transforms them to different ones that are much harder to follow, the image below shows how a simple for loop would look like after using this method.

Control flow obfuscation demonstrated

Even more interesting is to see the IL representation of the method as shown in .NET reflector, it appears that .NET reflector fails translating the byte code to C# or any other .NET language:

Method call obfuscation hides calls to external library calls, either ones that reference the .NET class library or ones that reference other assemblies developed internally. External calls normally survive symbol renaming as method binding occurs during run time using the method name, however using this method binding is attempted using the method token, an internal token stored within the metadata section that can be used to resolve methods calls.

Method call obfuscation code snippet

As seen in the image below the call to Console.WriteLine is replaced with a call to a delegate method that hides the original call. This method effectively breaks the application code flow, making it harder to browse through the code flow using standard reflection tools.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s