Code Reverse Engineering – How To Reverse Engineer Your Expired Software
This article is designed to demonstrate the subversion mechanism of an expired version of software including validation check, modify the existing behavior of an executable binary without even access or analyzing its source code by exercising advance reverse engineering mechanism. In simple term, we have mere the executable file of a particular application which is already expired as well as in locked state right now because of the non-availability of the vendor who had developed it earlier. We, therefore, shall first unlock it and then used its functionality by entered into inside it like earlier by Reverse Engineering. To achieve this foot, it is requisite of having a thorough knowledge of assembly language instruction as well as the deep operating skills of the OllyDBG tool.
Reverse Engineering –
It is quite often possible that the vendor who had developed the software, is not into existence now or might be shut down. Now the product is expired or maybe showing some strange run-time error, or might be producing weird results. Now the burning challenge is that how to remove such security validation, copy protection rights imposed by the erstwhile company because we don’t have the software source code as we had only signed a mutual contract for software executable package, not the source code too. Fortunately, it is still possible to modify or patch the expired software by analyzing its binary code is typically referred to as Software Engineering.
So, when we run the software, it reflects a blunt message that it is expired and in order to continue the trial version, purchase a full copy. It literally transpires that the vendor had imposed a copy protection schemes to minimize the ease with which they will be bypassed by unsolicited users. The copy protection mechanism often comprises a practice in which the software checks the functionality to be exposed by running it. Apart from that, it allows the software to activate until a certain duration. As you can observe below, the following software trial version is expired and not operational. Besides, showing an error message when we try to execute it.
To bypass this copy protection restriction and extend its trial period, we must first collect the binary metadata as we are awfully unaware of its origin, in which the development environment, it has complied. It is easily concluded from the CFF explorer that it is a PE 32-bit binary file, compiled in VC++ language.
At the point when we endeavor to execute the
demoBinary.exe file, it will won’t run in light of the fact that the present date is past the date on which the approved preliminary lapsed. How might we utilize this product paying little respect to the lapse of the time for testing? So in order to do so, we first load and debug the binary in OllDBG to understand its back-end functionality, then edit the section that never comes to the code path trial expiration by tracing backward. Now the real assault begins, download the OllyDBG tool from its official website and then install/configure it properly. Later on, open the demoBinary.exe binary in the IDE from File/Open option. It starts decompiling and loads the assembly code of the executable as showing in the coming figure. From the very instruction 00401204 we can conclude the entry point of the execution flow from top to down as follows;
Now the question is occur that how to determine which section of assembly code in the aforesaid will be manipulated, and which shall be left intact. As a rule of thumb in reverse engineering, trace the execution by following the strings displayed anytime. The company who wrote this software has provided you with a very helpful message indicating the trial period has expired. Hence, our prime target is to locate that string error message “Sorry, this trail software has expired” displayed, can lead us to the desired section. Start debugging in the IDE by pressing F9 and trial duration restriction code, once we got it to pause the execution and get the responsible section for the error message. From the call stack (Alt+ K) the trail error text is a parameter to MessageBoxA is visible as following;
Then, Select the USER32.MessageBoxA and right click and choose show call to get the starting point in which the assembly call to message box. Here in the following figure, before the 004011CE instruction that is a call to the MessageBoxA, 4 parameters are pushed onto the stack as follows.
Select the PUSH 10 instruction located at 004011C0 address, the line of code that references the selected line is displayed in the text area below about the jump from 00401055 to 00401063, right-click in the above image to open the shortcut menu as following;
The context menu displays that both 00401055 and 00401063 contains JA to the PUSH 10 used for MessageBoxA. The JA is used to jump when the current date is later than the trial date. Then, right-click the 0x00401055 instruction inside the CPU window and select binary where click over Fill with NOPs as following;
This operation fills all the corresponding instructions for 0x00401055 with NOPs (no operation) which prevents the program from hitting the error code path as well as effectively wipe-out the JA code path to the expiration code path as following.
Now, back to PUSH 10 by pressing hyphen (~) and fill with the NOPs for the instruction 0x00401063 also as following;
Finally, saves the modifications by right-clicking in the CPU windows and click to Copy to Executable, hit All Modifications as shown below.
Finally, save as the final patched binary and execute it, !Hurray!!…….. Congratulation message……… no expiration error message is shown. We successfully defeated the expiration trial period restriction.
This article shows one approach to challenge the quality of the copy protection measure utilizing OllyDBG and distinguish approaches to make your product progressively secure against unapproved utilization. By endeavoring to vanquish the duplicate security of your application, we can gain proficiency with a lot about how hearty the protection mechanism. By doing this testing before the item become publically accessible, we can change the code to make the go-around of duplicate security progressively modern before its discharge.