Reverse Engineering with Reflector

Abstract

We have already got the taste of reverse engineering with Reflector in the previous paper. It was basically a kick-start about this dissembling tool in terms of presenting its features and advantages. We have been performing the entire reverse engineering tactics over our custom made software called Champu. This software offers many security restrictions, and we have obtained sensitive information about the Trail Duration restriction in the previous article. Now, we are going to encounter the rest of security constraints, such as revealing the license key and understanding the user authentication mechanism.

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.

Start Learning

[download]

Target Software

As we have seen, our target software offers a 15 day trail, and after that it will expire automatically. In the meantime, we can continue with the evaluation version.

If the user decides to buy the full version, it is obvious to obtain the License key code by registering over the vendor website. But we have no idea how this mechanism works implicitly, how the vendor provides the license key to the user. These questions frequently occur in the reverse engineer's mind if he is not willing to pay any amount.

So, if we try to dissemble the source code of this target software, we might get some useful information and could bypass this mechanism in terms of saving dollars.

Fill out the form below to download the accompanying lab files.

Dissembling to Crack Serial Keys

Software code typically resides in multiple modules and it is interlinked together so that code is placed in one module and called from a different module. So, it is not easy to trace back the calling of a crucial module. That is why a reverse engineer's prime task is to anticipate or backtrack the path of execution and conclude the results.

If we examine champu.exe rigorously via Reflector, we can gather a little information from given classes as such during OnLoad() method triggering, the C_Trail class calling the RegisterUser() method which contains another class gData of information, as well as some enable and disable constructs as follows:

From the aforementioned figure, we can conclude that on behalf of the status value of gData, some significant form of control-related operations occur implicitly, such changing the text value, visibility etc…

If we investigate deeper the gData class necessity, we can achieve that it has a Boolean variable status which determines whether a registered user is trying to login or if he is carrying on in trail period. Based on the value of this variable, some implicit actions are performed as described earlier.

It is rather complicated to determine actually whether this class value is consumed or linked with other modules. We can also figure out such information by Analyzer, which virtually stated that a gData class member is used by both C_Trail and Register class as follows:

Up 'til now, we successfully extracted the functioning of registered and unregistered users. Furthermore, we can determine that the Register class is responsible for License code manipulation where the btnReg_Click() method event is the key hack to execute such implementation as follows:

When we click over the Register button, another class Register is called, from where we can get the license key information. This class only contains a button click method as follows:

If we expand this btnReg_Click() method, the whole picture becomes clear. This software doesn't do any complex operation in order to manipulate the key codes. It is basically hard-coding the license key as AB123AB as follows:

Finally, we bypass the second security restriction. Fortunately, it is not in encrypted form and we can directly use it on the User Register interface. Here, the bypass demo is as follows:

As we said earlier, in the article we are not practicing the tactics of modifying the .NET binary code. Rather, we are dissembling the source code, and based on getting some crucial information, we are executing the reverse engineering because it is not possible to directly edit the hex code with Reflector.

Dissembling the Authentication Mechanism

Okay. Now the remaining leap is to confront with the Login form where the user must have to validate himself by entering the correct user name and password but unfortunately, the New User option is not visible after expiring the trail, even if we bypass this License key code.

The user name and password information is not provided to a free user as per the software internal mechanism. So, all we have to do is to crack such significant information manually by dissembling the source, because we are not sure again how this mechanism works internally.

By examine the source code, we find a class Login which contains two buttons, Login and Cancel, and we can easily conclude that here the actual authentication code is as follows;

By expanding the btnLogin_Click() method event, we can notice that user name and password validation is not performing from a database, and they are not in encrypted form. Rather, they are hard-codes as "test" and "user" as follows:

So, if we try to use this authentication information against the Login form, we can successfully bypass the Login restriction and we could enter into the main function of this software as follows:

Summary

This paper unfolds the remaining mystery behind the Champu software. It displays how to reveal the license code information by dissembling its corresponding classes after backtracking the code flow execution. We have learnt the importance of Reflector in the context of getting significant information. Finally, we circumvented the last and most important login restriction mechanism by examining the code rigorously. In this series of articles, we have been trying to get information without performing the binary code editing, as per the limitation of Reflector. In the forthcoming article, we shall demonstrate how to modify the .NET binary code by employing a Reflector add-on.

Statuary Warning

This paper is not practicing any illegitimate theory or methods. The author has intended to present this paper in terms of learning the defensive tactics and making the job of programmers easier in terms of providing better debugging strategies. The motive behind this article is to ascertain the developers of protecting the sensitive information which can be revealed during de-compilation.

Reference

https://resources.infosecinstitute.com/reverse-engineering-reflector/

https://resources.infosecinstitute.com/net-reversing-reflexil/