.NET IL Obfuscation

Presented by:

Sarath Chandra Dorbala

Introduction

.NET Compilation Process Microsoft Intermediate Language (MSIL)

Lowest common denominator language for .NET

Assembly stays in the same format unless executed

Just-in-time compiler converts it into machine code each time it is executed

Introduction (..contd)

Introduction (..contd)

Advantages: Developer has a choice on the programming

language The corresponding compilers (for .NET) have to

do little less than other standard compilers The JIT can optimize the code on the fly

depending upon the current state of the system Threats

Reverse Engineering

Decompiling .NET applications

Steps to Decompile Extract the MSIL from a .NET assembly Convert MSIL back to higher level code (C# or VB.NET)

Namespaces used for disassembly System.Reflection.Emit – to emit metadata out of

assembly System.Reflection – provide managed view of loaded

types, methods, and fields to dynamically create them Tools available

ILDASM (Ships with .NET framework) Lutz Roeder’s (an employee of Microsoft) Reflector

Code snippet…

Usage ILDASM

Open .NET Command prompt Type in the command

\> ILDASM <assembly>

Screenshots – ILDASM

Reflector

Reflector is available here http://www.aisto.com/roeder/dotnet/Downl

oad.aspx?File=Reflector Open an assembly inside the reflector

and the rest of the process is self explanatory

Screenshots – Reflector

Cure – Obfuscation

IDEA: Hide the intent of a program without changing its runtime behavior

It different from encryption Result: Assembly functionally similar to

original but hard to reverse engineer

Obfuscation – Process

Dotfuscator Community Edition (DCE)

Essential Techniques used to obfuscate Renaming Metadata Removing non-essential metadata

DCE – Renaming Metadata

Basic Idea: Renaming meaningful names with non-meaningful ones.

Constraints on renaming Three possible scenarios

Application composed of assemblies stand-alone Typically, Windows Forms applications

Application composed of assemblies that are used by other applications Typically, Shared Libraries

Class of applications that plug into existing un-obfuscated frameworks ASP.NET applications

Overload induction – renaming after the extensive scope analysis

Example Overload Induction

Figure 1: Original source code

..contd

Figure 2: Decompiles code without obfuscation

..contd

Figure 3: Decompiled code with overload induction

DCE - Removing non-essential metadata

Basic Idea: Removal of certain details that are not used at runtime

Examples: property names, event names, and method parameter names

DCE removes all these types of metadata when it feels its safe to do so

DCE – Additional Techniques

Additional techniques employed by DCE Control Flow String Encryption Incremental Obfuscation Size Reduction

DCE – Control Flow

Basic Idea: To hide the intent of a sequence of

instructions without changing the logic To remove clues for the decompilers to

reproduce the higher level code Example:

Control Flow Example

DCE – String Encryption

Basic Idea: To encrypt string literals

Less secure because key to decrypt them must exist in the code itself

It helps protect from reverse engineering to one more level.

DCE – Incremental Obfuscation

Basic Idea: To keep track of renaming for code

maintenance purposes Dotfuscator uses a map file to keep

track of name changes

DCE – Size reduction

This does not impede reverse engineering

It removes the code that is not used by the application

Important for applications designed for Compact Devices or distributive applications

Obfuscation – A Word of caution

A little more work need to be done for assemblies with strong name. Tip – Delay signing (sign the assembly after

obfuscation) While working with Reflection APIs

Tip – Insist DCE not to rename dynamically loaded types

Working with bug fixes Tip – Use map file generated by DCE to trace

back to previous version of the code.

Conclusions

Adding another level of machine independent code in process of translation is advantageous

Additional care must be taken for such code for security purposes

Obfuscation certainly impedes the hacker to get the intent of the code

It makes code hard to read

References

http://msdn.microsoft.com/msdnmag/issues/03/11/NETCodeObfuscation/

http://aspnet.4guysfromrolla.com/articles/080404-1.aspx

http://www.15seconds.com/issue/040310.htm http://en.wikipedia.org/wiki/Obfuscated_code