.NET IL Obfuscation Presented by: Sarath Chandra Dorbala.
-
Upload
melanie-copeland -
Category
Documents
-
view
221 -
download
1
Transcript of .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)
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
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
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
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
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