Application security

Anti- Reverse Engineering (Assembly Obfuscation)

This article illustrates these contents in detail:

Abstract

Obfuscation

The .NET Application

Anti-Reversing Implementation

Obfuscated Code Analysis

MSIL Code Analysis

Final Note

Abstract

The purpose of this paper is to demystify the .NET assembly obfuscation as a way to deter reverse engineering. The primary concern for organizations is typically protecting their source code (as intellectual property) from reverse engineering. Obfuscation is a tactic that provides unified retitling of symbols in assemblies as well as other tricks in order to foil decompilers. Properly applied obfuscation increases protection against disassembling and decompilation by orders of magnitude, while leaving the application undamaged. A cracker can utilize the sensitive information from decompiled or disassembled code easily, so this article given a detail analysis of both obfuscated and de-obfuscated code.

Prerequisite

It is supposed that the following software and tools have been installed on the security researcher's machine:

• Dotfuscator Professional Edition
  
• Red Gate Reflector
  
• Ildasm.exe
  
• Visual Studio 2010 or later version IDE
  
• .NET built assembly ( The target Software)
  

Obfuscation

Obfuscation is a distinctive anti-reverse engineering approach to cipher the actual source code by making it harder to comprehend because, as we have seen in earlier reverse engineering papers, the .NET written assembly could be decompiled or disassembled to the full source code very easily by employing various tools, such as Reflector, ILSPY, and Ildasm. The .NET code that executes under CLR is typically compiled into platform-independent intermediated code and such MSIL code is observable through reverse engineering. The hacker or reverse engineer can analyze almost the entire software mechanism and subvert the built-in security mechanism by obtaining sensitive information, such as copy protection mechanisms, and by exposing software licensing code, proprietary business logic and much more. Attackers can inspect the details of a software application for security flaws to exploit unique ideas to steal or crack the program information.

The goal of obfuscation is to create misperceptions about the actual source during decompilation. The interpretation analysis skill declines as the confusion builds. The source code is replaced with symbols and bizarre specifications in an obfuscated code, while the executable is preserved. As a result, attempts to reverse engineer the instructions fail because the translation is ambiguous. Thus, we can say that any obfuscator that confuses a decompiler poses even more deterrence to a human attempting the reverse engineering undertaking.

The .NET Application (Target)

This paper is committed to demonstrating or implementing obfuscation, usually referred to as an anti-reverse engineering approach. Hence, we have developed a custom C# windows form application that requires a license to register the user before activation. Such a mechanism, however, can be defeated through decompilation and disassembling and sensitive information, such as serial keys (here in this scenario), can be revealed easily.

Figure 1.1

So we shall execute the obfuscation tactics on the aforesaid application in order to make it secure in order that the hacker or reverse engineer cannot easily comprehend the source code of this application.

Anti- Reversing (Obfuscation) Implementation

Dotfuscation analyzes applications and makes them smaller, faster, and harder to reverse engineer and is a post-development recompilation system for .NET applications. The following section explaining the merits of obfuscation in synopsis view:

• Dotfuscator decreases the .NET executable program size by removing unneeded segments of an assembly. It is proven to be a performance-oriented process.
  
• It protects the .NET application from reverse engineering by mean of securing the source code so-called intellectual property.
  
• Dotfuscator dramatically increase the execution speed of the program by remove superfluous elements.
  
• It can integrate many assemblies into one by linking them and can implement the watermarking over source code to claim ownership.
  
• Dotfuscator verifies your application integrity at run time. If it detects some kind of tampering, then one of its notification services informs the corresponding organization about this misdeed.
  
• All the assembly names, classes, methods, and fields are renamed via the overload induction (patented algorithm) mechanism in obfuscated code.
  
• The Dotfuscator allows us to hide a user's sensitive strings that are present in your assembly so that the reverse engineer could not utilize them for cracking.
  
• It detaches senseless metadata or unused code, compression, duplicate elimination.
  

Getting Started

Dotfuscator comes in a community edition and a professional edition. Some features are enabled and disabled in both of versions. There are typically three ways to run the dotfuscator projects:

• Standalone GUI
  
• Visual Studio integrated GUI
  
• Command line
  

We demonstrate obfuscation implementation via the Standalone GUI method. First, download the dotfuscator software from its vendor website (preemptive), and then install it properly. Launch the dotfuscator; when it runs, it prompts to select a project type as follows:

Figure 1.2

After selecting New Project, just give a meaningful name to the project and go to the Input tab. Here open the .NET target file:

Figure 1.3

After loading the .NET assembly, dotfuscator loads the corresponding files of the executable into IDE and displays a couple of obfuscation options. Here choose the contents that you want to protect:

Figure 1.4

Now we come to the Settings tab, where we can make some significant configurations for the impending obfuscated code. Here, we have to enable the control flow, smart obfuscation, and instrumentation options and leave the rest as the default. But one of the essential options is String Encryption, which enables or disables the encryption of the in-built strings in the assembly code, as follows:

Figure 1.5

Apart from the aforesaid setting, configure the "Rename" and "Control Flow" configuration, as follows:

Figure 1.6

After enabling the string encryption option from the general setting, you can configure the rest of the settings related to string encryption, because an attacker can locate sensitive code sections by looking for string references inside the binary. As per this assembly reference, the attackers can search for the serial key inside the disassembled or decompiled output. Dotfuscator addresses this problem by allowing you to encrypt strings in these critical segments of the .NET binary, providing an effective barrier against this type of attack, as follows:

Figure 1.7

After finishing with the necessary settings, build the projects in order to obfuscate the code by pressing the Ctrl +B button or hitting the "Build" button, as follows:

Figure 1.8

The build process usually consumes some time. After successfully obfuscating, you can see the build output in the form of logs showing what exactly happened behind the scenes, as follows:

Figure 1.9

You can refer to the Output tab in order to confirm whether the source code's sensitive segments are encrypted or not. You can see in that tab that entire critical members, such as method name, property, and fields are renamed with a strange string name (eval), as follows:

Figure 1.10

So the aforesaid figure proves that the assembly code is obfuscated and it is relatively hard to analyze the source code even if you apply disassembling via reflector.

When the build process is over, a new version of this assembly is created in the project directory under the Dotfuscated folder, as in the following figure. The amazing thing about obfuscation is that the new version of this target executable is still intact and produces all the functionality as the previous version.

Figure 1.11

Obfuscated Code Analysis

It is time to determine to what extent the obfuscated code provides protection to the existing sensitive information in the assembly code. We can accomplish this objective through Reflector because it decompile the entire source code, as a reverse engineer usually does, in order to obtain or analyze critical data from the target executable.

So, launch the Reflector IDE and first open the original assembly (deobfuscated code). Here, it produces raw C# code but, as we know, the method getValidate is our prime interest because it has the serial key validation implementation. We can observe that this application would be registered if we enter the code #ABC12@ as the serial key.

Figure 1.12

Now, consider the effect of the obfuscated source by opening the executable in Reflector from the previously created Obfuscated folder. Here, the following figure first displays the encrypted code, which has some strange name as members of the RegisterUser class and later, in the second column, its deobfuscated counterpart code is the following:

Figure 1.13

The obfuscated code in the RegisterUser class creates a great amount of confusion for reverse engineers, because they cannot easily figure out the members of this class due to having the members in encrypted form. Take another sample code from the Button Register, which is basically calling the getValidate() method as defined in the original assembly, but in the obfuscated code it has a different name and is calling a strange method which does not exist in the assembly:

Figure 1.14

Finally, we move on to the most sensitive segment of the source code. As we have seen earlier, by decompiling the actual logic behind the serial key implementation in the original code, one can easily obtain the serial key information. But as the getValidate() method underwent obfuscation, it shows each and every sensitive string in a bizarre form that is almost impossible for a reverse engineer to guess:

Figure 1.15

So we conclude that the obfuscation process makes the reverse engineering job very hard in terms of guessing or obtaining sensitive information from the aforesaid decompiled figures both in obfuscated and de-obfuscated form. By applying proper obfuscation techniques, we can prevent the critical information from being revealed and thus justify the anti-reverse engineering.

MSIL Code Analysis

This section demonstrates the disassembled MSIL code of the corresponding source code in Ildasm. As we know, Ildasm is the key interest for reverse engineers in terms of getting sensitive information from the IL code itself, and even a target executable can be crafted to new specifications by modifying the bytes, rather than relying on the actual source code. So we have done much research on obfuscated code by decompiling it through Reflector and we are firmly convinced that this binary is not revealing any sensitive information. All in all, the binary intellectual property is protected from the hacker.

But reverse engineering can be advantageous with MSIL code, as we have seen in the previous reverse engineering papers, so we also have to ensure that the obfuscation is implemented on the MSIL code through dotfuscator. Either such .NET byte code exposes critical data or obfuscation is applied on both source code and MSIL code. Thus, we will first examine the de-obfuscated MSIL code by Ildasm.exe:

Original Code (De-obfuscated)

[c]

.method private hidebysig instance void getValidate() cil managed

{

// Code size 126 (0x7e)

.maxstack 2

.locals init (bool V_0)

IL_0000: nop

IL_0001: ldarg.0

IL_0002: ldfld class [System.Windows.Forms]System.Windows.Forms.TextBox obfTarget.RegisterUser::txtKeyCode

IL_0007: callvirt instance string [System.Windows.Forms]System.Windows.Forms.Control::get_Text()

IL_000c: ldstr ""

IL_0011: call bool [mscorlib]System.String::op_Inequality(string, string)

IL_0016: ldc.i4.0

IL_0017: ceq

IL_0019: stloc.0

IL_001a: ldloc.0

IL_001b: brtrue.s IL_0070

IL_001d: nop

IL_001e: ldarg.0

IL_001f: ldfld class [System.Windows.Forms]System.Windows.Forms.TextBox obfTarget.RegisterUser::txtKeyCode

IL_0024: callvirt instance string [System.Windows.Forms]System.Windows.Forms.Control::get_Text()

IL_0029: ldstr "#ABC12@"

IL_002e: call bool [mscorlib]System.String::op_Equality(string, string)

IL_0033: ldc.i4.0

IL_0034: ceq

IL_0036: stloc.0

IL_0037: ldloc.0

IL_0038: brtrue.s IL_004f

IL_003a: nop

IL_003b: ldstr "Registration Successful"

IL_0040: call valuetype [System.Windows.Forms]System.Windows.Forms.DialogResult

[/c]

As we can see from the aforesaid MSIL, especially in the colored line, it reveals the serial key along with another reference string's value.

IL_0029: ldstr "#ABC12@"

So the reverse engineer could easily manipulate cracking to expose such critical information. It is not secure yet. Now open the obfuscated executable and analyze the effects, as follows:

Obfuscated Code

[c]

IL_000a: ldarg.0

IL_000b: ldfld class [System.Windows.Forms]System.Windows.Forms.TextBox obfTarget.RegisterUser::txtKeyCode

IL_0010: callvirt instance string [System.Windows.Forms]System.Windows.Forms.Control::get_Text()

IL_0015: ldstr ""

IL_001a: call bool [mscorlib]System.String::op_Inequality(string, string)

IL_001f: ldc.i4.0

IL_0020: ceq

IL_0022: stloc.0

IL_0023: ldloc.0

IL_0024: brtrue.s IL_0094

IL_0026: nop

IL_0027: ldarg.0

IL_0028: ldfld class [System.Windows.Forms]System.Windows.Forms.TextBox obfTarget.RegisterUser::txtKeyCode

IL_002d: callvirt instance string [System.Windows.Forms]System.Windows.Forms.Control::get_Text()

IL_0032: ldstr bytearray (F2 D0 F4 B4 F6 B5 F8 BA FA CA FC CF FE BF )

IL_0037: ldloc V_1

IL_003b: call string obfTarget.RegisterUser::b(string, int32)

IL_0040: call bool [mscorlib]System.String::op_Equality(string, string)

IL_0045: ldc.i4.0

IL_0046: ceq

IL_0048: stloc.0

IL_0049: ldloc.0

IL_004a: brtrue.s IL_006a

IL_004c: nop

IL_004d: ldstr bytearray (F2 A1 F4 90 F6 90 F8 90 FA 88 FC 89 FE 8D 00 60

02 77 04 6C 06 68 08 67 0A 2B 0C 5E 0E 7A 10 72

12 70 14 70 16 64 18 6A 1A 7D 1C 68 1E 73 )

IL_0052: ldloc V_1

IL_0056: call string obfTarget.RegisterUser::b(string, int32)

…………………………………….

[/c]

We can see that this time the sensitive string is not showing in the MSIL and, especially, the hard-coded serial key in the source code is encrypted in the byte array:

IL_004d: ldstr bytearray (F2 A1 F4 90 F6 90 F8 90 FA 88 FC 89 FE 8D 00 60

02 77 04 6C 06 68 08 67 0A 2B 0C 5E 0E 7A 10 72

12 70 14 70 16 64 18 6A 1A 7D 1C 68 1E 73 )

One of the splendid features of dotfuscator is that it even prevents disassembling the MSIL in Ildasm so that the cracker cannot view any .NET byte code. To do so, just enable the Suppress IIdasm feature in the setting tab, as follows:

Figure 1.16

This special option would not allow the MSIL to be disassembled in any editor, such as Ildasm or Reflector. After obfuscating the targets with the Suppress Ildasm option enabled, open the target in the Ildasm. This time, we can observe that Ildasm denies opening the MSIL code:

Figure 1.17

Obfuscation Drawbacks

There is no doubt that the obfuscated code thwarts reverse engineering, but this mechanism is not reliable in the developer community because it has some pitfalls. The obfuscated code is especially subject to dependence on the platform and compiler characteristics. This creates many problems if either the platform or the compiler is changed. Code obfuscation just makes the process of reverse engineering a time-consuming and resource-consuming exercise; the cracker even can bypass the application from the obfuscated code by employing special approaches and obfuscated code might make debugging more difficult. So, finally, obfuscation makes the job complicated for cracker and reverse engineer but it does not claim 100% full-proof protection. There are a lot of ways to bypass the application from the obfuscated code and we will explain these tactics in the next paper soon.

Final Note

11 courses, 8+ hours of training

Learn cybersecurity from Ted Harrington, the #1 best-selling author of "Hackable: How to Do Application Security Right."

See Courses

This paper illustrates the protection mechanism for intellectual property by implementing the obfuscation techniques over the .NET source code. We have achieved this process through Dotfuscator software and we have explained its various features, such as assembly member renaming, linking, pruning, and string encryption. This artifact applies the obfuscation in step-by-step fashion over a simple .NET application that asks a serial key to register the software so that a cracker cannot easily manipulate the disassembled or decompiled code through Reflector or the Ildasm utility. Finally, this article analyzed the obfuscated code with its counterpart original code and explained the special feature of dotfuscator of not allowing the disassembling of the MSIL code in Ildasm.