Abstract
The triggering point behind this article is to bypass the various security checks by modifying binary code directly rather than source code using the CFF Explorer. We however have already been confronted with the diverse ways of circumventing IL code earlier. There we have accomplished such crucial tasks by playing with IL byte code instructions. This article basically teaches how to identify the corresponding binary code instructions using the IL disassembler and then explains how to modify such binary code (hex code) using an editor such as the CFF Explorer.
Prerequisites
It is assumed that the user must have a thorough understanding and knowledge of binary coding manipulation and have an installed fresh copy of the CFF Explorer software in order to edit the binary code instructions. Apart from that, the user is supposed to have a deep understanding of MSIL code instructions as well.
The Victim .NET Application
Here, we are developing a demo C# Demo application to illustrate the bypass of the security constraints that typically perform a calculation or conversion of Centigrades to Fahrenheit. Here, the code for the trial expiration implementation is as in the following.
public partial class Conversion : Form
{
bool isTrailExpired = true;
public Conversion()
{
InitializeComponent();
}
private void TrialExpiredCheck()
{
if (isTrailExpired)
{
MessageBox.Show(@"Trail Duration has expired!
Installed Free copy", "!!!!Alert Message!!!!");
Application.Exit();
}
}
private void Conversion_Load(object sender, EventArgs e)
{
TrialExpiredCheck();
}
#region Calculation code
private void button1_Click(object sender, EventArgs e)
{
double c = Convert.ToDouble(textBox1.Text);
double f = (c * 9 / 5) + 32;
label3.Text = f.ToString();
}
#endregion
}
Here, after carefully going through the code, we can easily figure out that the TrialExpiredCheck() method is responsible for product expiration. We don't need to bother with the calculation conversion code and others.
After successfully compiling this source code, the CLR produces an executable file. During the trial duration, the user interface prototype of this product would be as in the following.
But, the vendor of this product released its beta version and provides only a free trial version in the market that works for a specific duration once this duration is complete, it will expire automatically and an alert message will flash on the screen as well as after clicking the OK button it will automatically unload the application file as in the following.
Now, there are two options to carry out your operation, either buy the product key (full version) which of course requires some money, or reverse-engineer the logic implementation to bypass the security checks. But we don't have the source code, so how to do this? Yes, it is still possible to change the binary code of the executable using CFF Explorer.
IL code Disassembling
Although we don't have the source code of this product, instead we are only providing the executable version. So, all we need to modify is the binary code of this product in order to alleviate the security restrictions using the .NET shipped ILDASM.exe; we have already seen a couple of manipulations with the ILDASM in the previous articles of the reverse engineering series but at the point of this article view, the ILDASM role is slightly different. This time dump the executable file in search of the Relative Virtual Address (RVA) instruction that is obtained when we perform the compilation with the corresponding line number option. So first open the target assembly in the ILASM as in the following.
Opening the target binary in the IL Disassembler will reveal all the statements from each method in a line-by-line format. The RVA column typically allows the runtime to calculate the starting memory address of the MSIL that defines the method that contains the trial check, the bytes for each statement, and their position relative to the RVA. The disassembled or decompiled file, however, produces a large number of raw IL code but our main concern is the TrailExpireCheck() method corresponding code as in the following.
.method private hidebysig instance void TrialExpiredCheck() cil managed
{
// Method begins at RVA 0x2134
.maxstack 2
.locals init ([0] bool CS$4$0000)
.line 16,16 : 9,10 ''
IL_0000: /* 00 */ nop
.line 17,17 : 13,32 ''
IL_0001: /* 02 */ ldarg.0
IL_0002: /* 7B (04)000004 */ ldfld bool Fahrenheit.Conversion::isTrailExpired
IL_0007: /* 16 */ ldc.i4.0
IL_0008: /* FE01 */ ceq
IL_000a: /* 0A */ stloc.0
IL_000b: /* 06 */ ldloc.0
IL_000c: /* 2D 18 */ brtrue.s IL_0026
IL_000e: /* 00 */ nop
.line 19,20 : 17,81 ''
IL_000f: /* 72 | (70)000041 */ ldstr "Trail Duration has expired!”
IL_0014: /* 72 | (70)0000EA */ ldstr "!!!!Alert Message!!!!"
IL_0019: /* 28 | (0A)000020 */ call valuetype [System.Windows.Forms]System.Windows.Forms.DialogResult [System.Windows.Forms]System.Windows.Forms.MessageBox::Show(string,string)
IL_001e: /* 26 */ pop
.line 21,21 : 17,36 ''
IL_001f: /* 28 | (0A)000021 */ call void [System.Windows.Forms]System.Windows.Forms.Application::Exit()
IL_0024: /* 00 */ nop
.line 22,22 : 13,14 ''
IL_0025: /* 00 */ nop
.line 23,23 : 9,10 ''
IL_0026: /* 2A */ ret
} // end of method Conversion::TrialExpiredCheck
PRANAV SINGHPosted Nov 14, 2014, 1:38 AM
Nice article. Reflector even converts unsafe exe/dll to .net code. But now most of good software uses strong name signing, obfuscation, compression & encryption & thus not vulnerable to this.