This paper intended to teach sophisticated reverse engineering tactics, mainly by using Red Gate Reflector. This article demystifies dissembling and cracking of .NET binaries, step by step, in order to reveal protected targets with confidential information. That includes finding entry points, license keys, passwords, and serial keys. We have done a lot of reverse engineering in earlier articles by employing other cracking tools, such as CFF explorer and ILDASM. Reflector eases the task of dissembling or de-compiling .NET binaries. It’s proven to be a useful reverse engineering tool among security professionals.
A security researcher must have thorough knowledge of .NET supported programming languages. These days, we’re confronting C# and vb.net source code, in addition to IL and hexidecimal code. Playing with source code is relatively easy when compared to byte code or opcodes. A security researcher’s machine must be configured with the following tools:
- Red Gate Reflector
- .NET Framework 2.x version
- VC 2010 IDE
- ILDASM.exe (optional)
Reflector, the dissembling tool, is developed by Red Gate. Although it used to available free of cost, now the vendor has commercialized it. Reflector is used to decompile or dissemble .NET binaries. They could be executables or dynamic link libraries.
This tool is limited to open binaries which are compiled or developed under CLR. It can’t decompile any other native unmanaged assemblies. This limitation poses an advantage where we can easily anticipate the development framework of a DLL or EXE. If the binary is opened or decompiled in the Reflector IDE, then it is .NET assembly.
Reflector has advantages for reverse engineering professionals. It provides an IL code dissembling facility. Opening ILDASM.EXE separately isn’t necessary. It can be integrated with Visual Studio 2010 or 2012 as add-ons. It can convert decompiled code in other .NET supported languages, such as VB.NET, or Delphi. We can run the Visual Studio command prompt directly from Reflector. We can execute or test an executable from Reflector after decompiling its assembly. Finally, we can view decompiled code under any .NET framework 4.5 to 1.0.
After downloading and installing the software, the IDE will display something like this;
NOTE: Apart from such it advantages and features, I would like to address a common misconception that the Reflector is not able to edit .NET source code or opcode in any manner. We can’t save as assemblies like other dissemblers, such as CFF explorer, IDA pro or Ollydbg. It just decompiles .NET assemblies. When it comes to editing .NET binaries, we need to import some sort of open source add-on into the Reflector IDE. We’re provided with other useful features, such as editing hex code, and opcode. We can put our modifications into another file with different name.
We’re not relying on any ready-made software or on other third party downloaded cracking files in order to demonstrate dissembling assembly source code. Instead, we have developed custom cracking software.
It’s called “Champu,” named after my son’s pet. The program can be launched when a vendor initiates a test, and works for a fifteen day period. After the fifteen day period, it expires automatically. That’s the first security feature it has. Other security features include a form to authenticate usernames and passwords, and a license key code, due to piracy. The initial trial version window looks like this:
In the meantime, the user can launch the evaluation version by clicking the Continue button. Then, you must create a username and password.
If the user wants to register a full licensed version of the program, then they are to go to the vendor’s website to get a license key. That key is to be entered in the following window.
Is there another way to get a full version, without paying? Yes, reverse engineering with Reflector is ultimate way to crack a propriatery program.
Dissembling the Target
As you can see, the Continue button is disabled and a trial expiration alert message is showing in a dialog box. We’re not provided a source code of the program, so that we can modify the code to extend or eliminate the trial. We have no other option to operate the program except buying a product key.
Now, it’s time for action. All we have is champu.exe, which is enough. Just launch the Reflector IDE and open Champu.exe with it. When it’s opened, you’ll see the following graphic. We know it’s assembled with .NET framework, because we were able to open it.
The executable is automatically decompiled or disintegrated into its corresponding source code. It has all the rudimentary information associated with this .NET assembly, such as application type, version, cryptographic key, copyright, GUID, and the target framework.
We can also obtain extra information about the external .NET assembly reference in this executable, along with image resources.
We can obtain a lot of information about the target quite easily. Next, Just right click on champu.exe, and the IDE will show you other options such as analyzer, ILDASM, command prompt and run.
Optionally, can add or remove other .NET native assemblies such as system System in Reflector. Now, just expand Champu from the left pane, and you can find the namespace definition referred to as Champu in the source code. Just select it and it will wrap-up everything in the right pane.
You can see that Champu.exe has a namespace referred to as Champu which contains C_Trial, Login and Register classes, along with two static classes, Program and gData. We can presume that these classes contain the actual functionality logic and are responsible for operating the program.
The assembly could contain numerous classes and they all contain two different types of logic. So, it’s very complicated to figure out where we start tracing. We have to identify the entry point of the executable. That’s why you should right click on champu.exe to provide Reflector with an entry point option. In the right pane, the Main() function of the assembly is displayed, and C_Trail class loads.
Up until now, we’ve discovered that the entry point C_Trail class which is where the trial duration logic is implemented. Select that class from left pane after expanding the Champu namespace. The class will give us an overview to the control integrated in the trial class user interface. It contains two methods, RegisteredUser() and TrailCheck().
Go to the TailCheck() method body by selecting it. We’ll find the entire trial duration logic source, as we would in Visual Studio 2010. We can figure out that the program will work for fifteen days from 10/5/2013. In addition, we can find the trial expiration message in the source code.
Here’s the source code of the TrailCheck() method. We’re not sure about the calling or triggering condition of the method. Just select the TrailCheck() method from the left pane and click on the analyze option. It’ll display some useful information such what is using the method (the triggering condition is On_Load()) and what its dependencies are.
With .NET, Reflector shows the source code in C# by default. Some programmers aren’t proficient in the C# language. So we can instantly change the assembly source code into another .NET supported programming language such as VB.NET.
If you’d like to see the MSIL opcode instructions behind the source code, we can change it into its corresponding IL code. We don’t need to use the ILDASM tool.
Reflector also provides another utility for importing and exporting assembly source code into an XML file.
Sometimes we need to look at the global assembly cache, the repository of all .NET assemblies. We can open the GAC in Reflector as seen below.
This article demonstrates dissembling of assembly code by using Reflector. As we explained earlier, it’s not a tool to modify the instruction sets behind source code. It just decompiles source code in order to analyze its logic. This article explores numerous features of Reflector such as importing and exporting assembly, GAC, analyzer, and code conversion, which is useful when dissembling. We’ve analyzed the C_Trail class implementation to get information. In the next article, we’l go through the remaining class implementations in order to crack applications.