1. .NET IL Obfuscation Presented by: Sarath Chandra Dorbala

2. 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

3. Introduction (..contd)

4. 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

5. 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

6. Code snippet…

7. Usage ILDASM Open.NET Command prompt Type in the command  \> ILDASM

8. Screenshots – ILDASM

9. Reflector Reflector is available here  http://www.aisto.com/roeder/dotnet/Down load.aspx?File=Reflector http://www.aisto.com/roeder/dotnet/Down load.aspx?File=Reflector Open an assembly inside the reflector and the rest of the process is self explanatory

10. Screenshots – Reflector

11. 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

12. Obfuscation – Process

13. Dotfuscator Community Edition (DCE) Essential Techniques used to obfuscate  Renaming Metadata  Removing non-essential metadata

14. 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

15. Example Overload Induction Figure 1: Original source code

16. ..contd Figure 2: Decompiles code without obfuscation

17. ..contd Figure 3: Decompiled code with overload induction

18. 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

19. DCE – Additional Techniques Additional techniques employed by DCE  Control Flow  String Encryption  Incremental Obfuscation  Size Reduction

20. 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 Control Flow Example

21. 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.

22. 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

23. 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

24. 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.

25. 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

26. References http://msdn.microsoft.com/msdnmag/issues/03/11/N ETCodeObfuscation/ http://msdn.microsoft.com/msdnmag/issues/03/11/N ETCodeObfuscation/ http://aspnet.4guysfromrolla.com/articles/080404- 1.aspx http://aspnet.4guysfromrolla.com/articles/080404- 1.aspx http://www.15seconds.com/issue/040310.htm http://en.wikipedia.org/wiki/Obfuscated_code