Disassembling With Reflector: Part 2

Before reading this article, I highly recommend reading the previous part:

• Disassembling with Reflector: Part 1

Abstract

We already have a taste of Reverse Engineering with Reflector in the previous paper. It was basically a kick-start about this dissassembling tool in terms of presenting its features and advantages. We have been doing the entire Reversing Engineering of our custom-made software called Champu. This software offers many security restrictions and we have obtained sensitive information about the trial duration restrictions in the previous article. We will now encounter the rest of the security constraints such as revealing the License Key and understanding the user authentication mechanism.

Target Software

As we have seen that our target software offers a 15 day trial 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 on the vendor website. But we have no idea of 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, we will try to disassemble the source code of this target software. Perhaps we will get some useful information and can then bypass this mechanism thereby saving dollars.

Dissembling to Crack Serial Keys

Software code typically resides in multiple modules and they are interlinked together such that code placed in one module and is 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 deduce the results.

If we examine champu.exe rigorously via reflector, we can gather a small 2 peices of information from the given classes as such during the OnLoad() method triggering, the C_Trail class is calling the RegisterUser() method that contains another class's gData information as well as some enable and disable constructs as in the following:


From the figure mentioned previously, we can conclude that on behalf of the status value of gData, some significant form control related operations occur implicitly, such as changing the text value, visibility and so on.

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



It is rather complicated to determine actually whether this class value is consumed or linking with other modules. We can also figure out such information by Analyzer, that virtually states that a gData class member is used by both the C_Trail and Register classes as in the following:



Until now, we have 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 in the following:



When we click 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 in the following:



If we expand this btnReg_Click() method, the entire picture becomes clear. This software isn't doing any complex operation to manipulate the key codes. It is basically hard-coding the License Key as AB123AB as in the following.



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



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 using Reverse Engineering, because it is not possible to directly edit the hex code with Reflector.

Dissembling the Authentication Mechanism

Ok. Now the remaining leap is to confront with the Login form where the user must validate himself by entering the correct user name and password, but unfortunately the New User option is not visible after the trial has expired even if we bypass this License Key code.



The user name and password information is not provided to a free user depending on the software internal mechanism. So, all we need 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 examining the source code, we found a class Login that contains two buttons Login and Cancel and we can easily conclude that here the actual authentication code is as in the following:



By expanding the btnLogin_Click() method event, we can see that the user name and password validation is not being done from a database and they are not in an encrypted form. Rather, they are hard-code as “test” and “user” as in the following:



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



Summary

This paper reveals the remaining mystery behind the Champu software. It shows how to reveal the license code information by dissembling its corresponding classes after backtracking the code flow execution. We have learned the importance of reflector in the context of getting significant information. Finally, we circumvent the last and important login restriction mechanism by examining the code rigorously. In this series of articles, we have been trying to get information only, not doing the binary code editing depending on the limitations of reflector. In a future article, we shall show how to modify the .NET binary code by employing Reflector as an additional add-on.

Statuary Warning

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