TestClass is a class that has a property of type List<int>:

class TestClass
{
    public List<int> Value { get; set; }
}

Goal: create an instance of this class, set the property and print the second element in the list. Simple, huh? The code without reflection is:

TestClass c = new TestClass();
c.Value = new List<int>() { 4, 5, 6 };
Console.WriteLine(c.Value[1]);

Seems straight forward to use reflection for this, right? Here is my attempt:

//TestClass c = new TestClass();
object c = new TestClass();
//c.Value = new List<int>() { 4, 5, 6 };
Type t = c.GetType();
PropertyInfo prop = t.GetProperty("Value", BindingFlags.Public | BindingFlags.Instance);
prop.SetValue(c, new List<int>() { 4, 5, 6 }, null);
//Console.WriteLine(c.Value[1]);
int valueToOutput = (int)prop.GetValue(c, new object[] { 1 });
Console.WriteLine(valueToOutput);

Can you see the glitch? I can tell you that line 10 throws TargetParameterCountException. You know why?

Looking at the IL disassembled code for the program without reflection gives the answer (I added some comments for clarity and removed unnecessary lines):

//TestClass c = new TestClass();
IL_0001:  newobj     instance void ConsoleApplication1.TestClass::.ctor()
//c.Value = new List<int>() { 4, 5, 6 };
IL_0008:  newobj     instance void class [mscorlib]System.Collections.Generic.List`1<int32>::.ctor()
IL_0010:  callvirt   instance void class [mscorlib]System.Collections.Generic.List`1<int32>::Add(!0)
IL_0018:  callvirt   instance void class [mscorlib]System.Collections.Generic.List`1<int32>::Add(!0)
IL_0020:  callvirt   instance void class [mscorlib]System.Collections.Generic.List`1<int32>::Add(!0)
IL_0027:  callvirt   instance void ConsoleApplication1.TestClass::set_Value(class [mscorlib]System.Collections.Generic.List`1<int32>)
//Console.WriteLine(c.Value[1]);
IL_002e:  callvirt   instance class [mscorlib]System.Collections.Generic.List`1<int32> ConsoleApplication1.TestClass::get_Value()
IL_0034:  callvirt   instance !0 class [mscorlib]System.Collections.Generic.List`1<int32>::get_Item(int32)
IL_0039:  call       void [mscorlib]System.Console::WriteLine(int32)

Line 3 in the original program gets translated to a property get in order to obtain the List<nt> object and then, on that object, the get_Item method is called with the same arguments as the indexed property. This is where I was wrong, I was calling the property with the arguments that were supposed to be for method and, of course, not invoking the method. The correct approach is (changed lines are highlighted):

//TestClass c = new TestClass();
object c = new TestClass();
//c.Value = new List<int>() { 4, 5, 6 };
Type t = c.GetType();
PropertyInfo prop = t.GetProperty("Value", BindingFlags.Public | BindingFlags.Instance);
prop.SetValue(c, new List<int>() { 4, 5, 6 }, null);
//Console.WriteLine(c.Value[1]);
object listObject = prop.GetValue(c, null);
MethodInfo mtd = listObject.GetType().GetMethod("get_Item", BindingFlags.Public | BindingFlags.Instance);
int valueToOutput = (int)mtd.Invoke(listObject, new object[] { 1 });
Console.WriteLine(valueToOutput);

In the end, two observations:

1. A method can’t have a default indexer and a method get_Item with the same argument. The following code will not compile because the method is defined twice.

class TestClass
{
    public int this[int index]
    {
        get
        {
            return 0;
        }
    }
    public int get_Item(int index)
    {
        return 0;
    }
}

2. You can replace indices with calls to get_Item. This method is hidden by the Visual Studio Intellisense but it perfectly legal.

TestClass c = new TestClass();
c.Value = new List<int>() { 4, 5, 6 };
//Equivalent with Console.WriteLine(c.Value[1]);
Console.WriteLine(c.Value.get_Item(1));

• WinDbg
• CFF Explorer

The second part of the article discusses how to modify binaries that are obfuscated. For simplicity and clarity, I will not use obfuscated binaries. Doing this, allows the reader to understand what is actually happening. In the demo I will completely ignore the name of the methods or the actual, non-obfuscated, code.

I recommend reading the first part, if you didn’t already. It provides some information that might be needed to understand theis second part.

The same ‘TrialApp.exe’ binary is used. The current approach, as opposed the the former one, is:

1. Load the application in debugger and break the execution when the trial message is displayed.
2. Get the call stack
3. Find the address of the trial check method
4. Remove the call

1. Load the application in debugger and break the execution when the trial message is displayed

WinDbg can be obtained for free from Windows SDK (see the Microsoft Downloads website). If you are running a 64 bit OS, make sure you start the 32bit version of WinDbg (should be in Program Files (x86)).

Load ‘TrialApp.exe’ in WinDbg by clicking File -> Load Executable. In order to run it you have 3 options:

1. Type ‘g’ and press ENTER
2. Press F5
3. Click Debug -> Go

The application will start and the execution will stop when the message box is displayed. Is actually waiting for the user to click OK. At this point break the execution by pressing Debug -> Break.

Before being able to debug the .NET application, 2 DLLs needs to be loaded. They help the debugger ‘understand’ the .NET internals. The actual paths might differ on your configuration. Anyway, make sure you load the 32 bit version of these files (the 64 bit version are in the Framework64 folder). The .load command loads external libraries.

.load c:\Windows\Microsoft.NET\Framework\v4.0.30319\SOS.dll
.load c:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll

2. Get the call stack

A call stack is associated with a thread. Before getting the stack we need to figure out which is the thread for which we want it. Execute the following command and inspect the output…

!threads

There are two thread having IDs 0 and 2. Is quite easy to decide which is the main thread since just one of them is Single Thread Apartment (STA). Switch to the main thread and display the CLR stack using the following commands:

~0s
!clrstack

3. Find the address of the trial check method

OK! You’re still with me? If yes, then take a look at the result of the last command. It displays the call stack of the main thread. Notice that OnCreateControl calls OnLoad, OnLoad calls From1_Load, etc. In the case of obfuscated code, the name would probably be strange and you would have to analyze each method in depth. Because the code was JIT compiled the call to the trial check was inlined.

Let’s take a look at the IL code for Form1_Load. To do this, first we need the address description of the MethodDesc structure of method. The ip2md command returns the structure. The argument is the IP address of the method. After this, just dump the IL for the address specified in MethodDesc. I want to make on observation here: if you look at the MethodDesc structure you can see the mdToken field. This field specified the table and the row in the table for the this method (the row corresponding to this method is the 6^th, because the index starts at 0).

!ip2md 003f01f9
!dumpil 00176304

In case of obfuscated code, you would probably see just a call instruction to some cryptic method. It makes no difference. We can see that at IL_0001 (relative to the start of the method) we have a call and this instruction uses 5 bytes in the file (0006-0001 = 0005; in hex)).

Having the size of the instruction, its position and the row of the method in the methods table we can proceed further. Open CFF Explorer and load the assembly.

Navigate to .NET Directory -> MetaData Streams -> #~ -> Tables. Look for the Method table in the new tree and select the entry with number 5. Copy its RVA value.

4. Remove the call

With the RVA in hand (on clipboard :-) ), remove the call just like in the first part of the article. Replace the call bytes with zeros. One observation: we must also remove the instruction before the call (ldarg_0; opcode 02; no arguments). So, zero 6 bytes starting at the first in the method.

In other words, replace:

00 00 0A 02 28 08 00 00 06 2A 1E 02 28 06 00 00
06 2A 66 02 7B 02 00 00 04 2C 10 72 01 00 00 00

with

00 00 0A 02 28 08 00 00 06 2A 1E 00 00 00 00 00
00 2A 66 02 7B 02 00 00 04 2C 10 72 01 00 00 00

Run the application. The trial check is gone.

Before reading any further you should understand that each protection measure (as long as the cracker can access the source code) is useless. Is just a matter of time, for a motivated person, before she will bypass any protection.

For the demo, we are going to use a very simple Windows Forms Application that will display a message box with a trial message and will exit after that. The goal is to show a few techniques that will prevent the application from exiting (and will remove the trial message).

The code for the ‘trial’ application is kept in just one class. There is just one variable for checking the trial and we’ll consider that is always true – it makes no difference if there was a function call to determine if the trial has expired.

public partial class Form1 : Form
{
    bool hasExpired = true;
    public Form1()
    {
        InitializeComponent();
    }
    private void Form1_Load(object sender, EventArgs e)
    {
        CheckTrialApp();
    }
    private void CheckTrialApp()
    {
        if (hasExpired)
        {
            MessageBox.Show("Trial has expired");
            Application.Exit();
        }
    }
}

The binary used was compiled on the x86 Release configuration with VS2010 having .NET 4.0 as target framework. The IL Disassembler from VS2010 and a free application called CFF Explorer are used to view and edit the binary.

Opening the ‘TrialApp.exe’ file (the target binary) in IL Dissasembler will reveal all the statements from each method. This is important but, more important is the RVA of the method containing the trial check, the bytes for each statement and their position relative to the RVA.

By knowing the RVA you are able to navigate to that address using CFF explorer and locate the bytes for the calls. Even without seeing the actual bytes, one is able to locate the calls (and their length) by looking at the offsets (ie: the byte 2C is located 0006 bytes from the beginning of the implementation) – more on this in Part2.

Having access to all this information gives not one but many possibilities of bypassing the trial check:

1. Remove the two calls to Application.Exit and MessageBox.Show.
2. Change the if check.
3. Remove the ‘CheckTrialApp’ call from ‘Form1_Load’.

This post will cover just the first two possibilities, since the third is similar to the first.

1. Remove the calls to Exit and Show

The bytes from the method implementation:

         02 7B 02 00 00 04 2C 10 72 01 00 00 70
28 16 00 00 0A 26 28 17 00 00 0A 2A

A call to a method has the opcode 28. The next 4 bytes following the opcode represent the location of the method in the methods table (you can see this table using CFF explorer).

Now here comes the magic: in order to remove the calls to Exit and Show, one must  replace with NOP, all the bytes associated with these methods. Basically we are going the introduce a NOP byte (00) for each byte in the call.

         02 7B 02 00 00 04 2C 10 72 01 00 00 70
00 00 00 00 00 26 00 00 00 00 00 2A

That’s all. Save the file and the trial is bypassed.

2. Change the if check

If you look in the disassembled IL you can see that at offset 0×6 we have a brfalse.s opcode. This is a branch instruction that will branch to offset 0×18 (IL_0018) if false. However, in the case of ‘TrialApp’, since hasExpired is always true, the branch will never take place and the code following it will be executed.

In order to change the meaning of the code – in other words “give the trial message if the application has NOT expired” – the check will be changed. Currently, is checking against false using the instruction brfalse.s, having the opcode 2C. By looking on MSDN, the opcode for brtrue.s can be found: 2D. Replacing 2C with 2D will make the branch happen always.

The method inside the binary, after replacing the brfalse.s opcode:

         02 7B 02 00 00 04 2D 10 72 01 00 00 70
28 16 00 00 0A 26 28 17 00 00 0A 2A

That’s all. The message box will not be displayed since the body of the if statement is no longer executed.

There are some techniques that will make cracking difficult. Obfuscating the code is one of them. However, part 2 of this article will cover the modification of obfuscated binaries.

If you somehow use a non-fractional data type for storing the result, you will always get the result 3. And that should not surprise you.

int result = 7/2; //expression is 3

However, if you choose to use a fractional data type, things will change …

double result = 7/2;

… or not. The value stored in the variable result is still 3 (actually 3.0 or something really close to 3.0 – since floating point data types store the approximation of a number).

Why is this happening?

Let’s take a look at the expression, result = 7/2. There are two operators: / and =. Based on their precedence, the first evaluated is the division operator; it is a binary operator so, it has two operands. The general definition of the / operator in C# is:

public static TYPE1 operator /(TYPE2 op1, TYPE3 op2)

In our case 7 and 2 need to be matched to TYPE2 and TYPE3. In most languages, the operators for primitive types are defined only for the same type of operands (TYPE2 = TYPE3). In this way, for n types n operator overloads have to be defined, otherwise it could go up to n² overloads.

The compiler will try to match the operands with one of the operator signatures. In our case, both operands are integer so, it will call operator / (int, int) which returns int (!!). The expression on the right hand side (RHS) of = is evaluated as an int.

After that, the = operator will be evaluated. Because its RHS operand is an int, a conversion will be performed to double, in order to match the type of the left hand side of the operator. At this point, is to late to get the fractional part because it was already disposed. The final result will be an integer represented as a double.

The following drawing shows the abstract syntax tree and its evaluation for the previously mentioned expression.

In order to fix the problem, you need to explicitly state that a certain part of the expression must be evaluated as double. The best way to do this is to make one of the operands double. For example:

double r1 = 7.0/2;
double r2 = 7/2.0;
double r3 = 7.0/2.0;
double r4 = 7d/2d;
double r5 = ((double)5)/2; //This is not recommended but will work

In this above cases, the conversion node will be evaluated sooner, before any precision is lost, hence allowing you to get the expected result. The next image shows the AST for the expression double result = 7 / 3.0.

Understanding how an expression is evaluated is very important because non trivial statement can make your life harder. Take a look at the following examples and try to guess the results (r4 is similar to a bug we encountered).

double r1 = 7 / 2;
double r2 = 6.0 + 7 / 2;
double r3 = 5 / 2 + 7 / 2;
double r4 = DateTime.Now.Millisecond * (1000 / 3600);
double r5 = 6.5 / (1 / 2);
double r6 = 10.0 * (1 / 2);
double r7 = 11.0 * 1 / 2;

If you use Windows Vista/7 then you know that buttons and links which elevate privileges are preceded by a shield icon. This is the way Microsoft decided to inform the user about the effect of clicking that control.

The first idea that might pop up is the reinvention of the wheel (or shield). In other words you could draw the shield on a button. This is OK except that:

1. Is not easy
2. Will require you to recompile the interface if Microsoft decides to change the icon
3. You need the icon in many sizes 16×16, 24×24, 32×32, etc. (extract it from MS’ DLLs)
4. Will create a lot of overhead with layout (position icon relative to text size/position)

The second method is easier, safer and recommended by MS. All you need to do is send a specific message (BCM_SETSHIELD) to the button if the user has limited privileges and pressing that button will trigger the UAC window. Actually there is a second, tricky, thing that must be done: the style of the button must be “System” (in C# “System.Windows.FlatStyle.System”). Without this you will not be able to see the shield.

The code provided in part 1 of this article will be modified in order to display the shield on the two buttons. Moreover, the shield will be displayed only when the user runs under an account with limited privileges or non-elevated administrator.

In order to display the shield one needs to send the BCM_SETSHIELD (=0x0000160C) message to the button. This can be done by using the SendMessage function from user32.dll. This article will not cover what is and how to use SendMessage, if you need more information about it follow the previous link.

To set the shield of the “Elevate this application” button one needs to send the message in the following way:

SendMessage(btnElevate.Handle, BCM_SETSHIELD, 0, 1);

The first parameter is the handle of the button, the second one is the message, the third one is not used and must be ’0′ and the last argument must be non-zero in order to draw the shield, zero otherwise.

If you try this it will not work :) Remember the ‘tricky’ thing told before? This is the full code to display the shield for btnElevate:

btnElevate.FlatStyle = FlatStyle.System;
SendMessage(btnElevate.Handle, BCM_SETSHIELD, 0, 1);

There is only one thing that must be done in order to work properly. Remove the shield if the user has elevated privileges. I don’t know if this is against MS’ recommendation but in my opinion one must not be shown information that cannot be used in that context; in our case don’t show the elevate shield if there is nothing to elevate.

Part 1 described how to check if a user has full rights. Now we are just using that boolean variable:

if (!hasAdministrativeRight)
    SetUACShields();

Where SetUACShields will send the message to all buttons that require the shield drawn.

The full updated code from Part 1: UAC Code 3 (10.13 KB)

When the C# compiler encounters an #if directive, followed eventually by an #endif directive, it will compile the code between the directives only if the specified symbol is defined. Unlike C and C++, you cannot assign a numeric value to a symbol; the #if statement in C# is Boolean and only tests whether the symbol has been defined or not.

A predefined (by default) symbol on the “Debug” build configuration is DEBUG. Using this symbol you can define code that will be compiled only in Debug; for example, a debug window will be shown only when needed.

using System;
using System.Text;
 
namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
#if DEBUG
            Console.WriteLine("Debugging information");
#endif
            Console.WriteLine("Code that always executes");
        }
    }
}

The code above will print “Debugging information” and “Code that always executes” when build on Debug and will display only “Code that always executes” when build on another configuration.

You can suppress the definition of the DEBUG symbol from the project properties or by removing the DEBUG from the build argument “/define:DEBUG”. Also, you can define your own symbols in order to accommodate your needs.

Define as many build configurations and symbols you need but don’t abuse this feature!

It was an interesting experience because of the train which was 30 late. Got to Bucharest later than expected and I had to (almost) run to the exam center -  got there 1-2 minutes before the exam start.

The exam itself was a little different than what I was expecting (from the practice tests). I had 40 questions instead on 45 (why?) and there were a lot of .NET globalization questions. I would rate it as medium to hard but the time was more than enough and I was able to recheck my questions 3 times and still got out of the room with 50 minutes before deadline.

After the exam I took a walk through Bucharest and took some pictures. That city is so green (compared to Brasov)…

Guess what? When returning the train, again, was late. Just this time there was almost an hour.

NOTE: I.R. stands for “I are” (see the animated TV series “I Am Weasel”).

This book is interesting for beginners because it has a lot of drawings and diagrams that explain better the concepts described by text. It could be used by persons migrating from C++ or VB to C# or it could even be the support material for a course.

In 730 pages the author, Daniel Solis offers a very visual approach – with lots of figures, diagrams and code samples – that will help you get to work with C# fast.

Go here to download your copy.

However there are some situations when an application cannot be run without administrative rights. For example a system configuration utility requires administrative rights to change some global policies.

In order to force an application to run only if the current user is administrator or can provide administrative credentials you must add a manifest to the C# project.

The manifest is an XML file named <application_name>.exe.manifest with the following content:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="UACApp" type="win32"/>
      <trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
      <security>
         <requestedPrivileges>
            <requestedExecutionLevel level="requireAdministrator"/>
         </requestedPrivileges>
      </security>
   </trustInfo>
</assembly>

What is important is the requestedExecutionLevel element. It specifies what permissions (execution level) the application needs in order to start. If the current user does not have the required level then an elevation window is displayed (see part one of the tutorial that describes the elevation window).

The default value of requestedExecutionLevel if it is not specified in the manifest or the manifest does not exist is asInvoker. Except asInvoker and requireAdministrator there is another execution level. All three are described below:

In order to embed the manifest in the aplication’s executable you can choose one of the following options:

1. The hard way – mt.exe

The Mt.exe file is a tool that generates signed files and catalogs. It is available in the Microsoft Windows Software Development Kit (SDK). Mt.exe requires that the file referenced in the manifest be present in the same directory as the manifest.

The manifest will be embedded after a successful build so we need to add this the call of Mt.exe in the post-build event. In order to do this right click the project -> Properties -> Choose “Build Events” from the vertical left tabs.

Mt.exe is found in many places on disk so the path to it might be different on your configuration. The post build command is:

“C:Program FilesMicrosoft.NETSDKv2.0 64bitBinmt.exe” -manifest “$(ProjectDir)$(TargetName).exe.manifest” –outputresource:”$(TargetDir)$(TargetFileName)”;#1

Make sure the paths to mt.exe and the .manifest file are correct. You should get something like this:

This method has a drawback. If you start the application with debugging from Visual Studio it will start with limited privileges. Running without debugging will ask you to elevate the parent process (in our case Visual Studio).

2. The easy way – designer

Just create the manifest file, include it in visual studio, go to the “Application” tab in project’s properties and choose the manifest file from the Manifest combo box.

Build.

This method that has another advantage. Even if running with Debug you will still be prompted to elevate Visual Studio.

The source code can be downloaded below (it is the application from part 1 but includes the manifest file):

Download source

IMPORTANT: This tutorial is useless if you disabled UAC because all you processes (considering you are the administrator) run elevated.

Why should we use this? Most applications DO NOT require full privileges. Think to the applications you have written and ask yourself if most of the job can be done without full writes (if you write to disk think if you could write in the user’s folder or an isolated storage, if writing in registry to HKLM think if you could write to HKLU, etc). The answer is mostly sure “Yes”.

So why run applications with full privileges when they can be run with limited? Running with more privileges than required is just a security vulnerability -  If an attacker exploits a vulnerability in your application he will gain more control.

There are two mistakes developers tend to do:

1. Request the end-user to run an application with full rights even though this is not necessarily (most of the time because of bad design practices)
2. Do not request to user to run the application elevated but try to perform operations that require more rights

By design UAC can only elevate code at process level and only at process’ startup (means that a running process cannot be elevated). In the .NET world this also means that you cannot elevate code running in another app domain because the app domain is part of a running process. In order to elevate an existing application this must be closed and reopen with more privileges.

There are two types on UAC dialogs: blue and yellow. When you see a blue dialog you can be sure that the application requesting privileges is signed and trusted. The yellow dialog shows for any application that is not digitally signed and is not fully trusted.

User Account Control also prevents a lower privilege process to do the following (list below taken from MSDN):

• Perform a window handle validation of higher process privilege.
• SendMessage or PostMessage to higher privilege application windows. These Application Programming Interfaces (APIs) return success but silently drop the window message.
• Use thread hooks to attach to a higher privilege process.
• Use Journal hooks to monitor a higher privilege process.
• Perform DLL injection to a higher privilege process.

Let’s see how an UAC aware application should look.

It should be composed of two executables (one that will be run with limited privileges and another one that will be started only with needed and with full rights) or two working modes (a mode for limited rights and another one for full rights). Either way you must remember that once you elevated the application and finalized the administrative tasks, the process should be destroyed in order to reduce an attacker’s privileges.

In order to launch an elevated process in Windows Vista the process must be started with the “runas” verb. The Verb property is part of System.Diagnostics.Process.StartInfo class. The code snippet that launches “notepad.exe” with full rights is showed below:

    ProcessStartInfo processInfo = new ProcessStartInfo();
    processInfo.Verb = "runas";
    processInfo.FileName = "notepad.exe";
    Process.Start(processInfo);

If you choose to have only one executable file that acts differently based on permissions you should check if the user is part of the administrative group. In Vista even if your user is part of the Administrators group it runs with reduced privileges by default and gains his full rights on demand. The code below stores true in the hasAdministrativeRight boolean variable if the user’s privileges are administrative and false otherwise.

    WindowsPrincipal pricipal = new WindowsPrincipal(WindowsIdentity.GetCurrent());
    bool hasAdministrativeRight = pricipal.IsInRole(WindowsBuiltInRole.Administrator);

To elevate the current application you must create a process with elevated rights and close the existing instance. However you cannot start a process with limited privileges – I couldn’t find a solution. Anyone knows how to start a less privilege process from a higher privilege one? The sample creates an elevated instance of the current executable and closes the existing one.

    RunElevated(Application.ExecutablePath);
    this.Close();

RunElevated is a method that takes the name of an executable and spawns it in a new elevated process (see the attached code).

I have created a sample application that illustrates all the things written so far: it displays the user’s rights, elevates the current application and starts a process with more privileges. In order to see all features of the application you must have UAC enabled. You can download the code from this link.

Please note that here I recommend to run applications with limited privileges but there are situations when applications need to run unrestricted – this is the case of system configuration utilities or other special applications. What I want to say is that you should run applications in an unprivileged environment when possible.

This is part one of the tutorial. Part 2 will explain how to use the manifest file to specify that an executable must be always run with full privleges.

Download Source Code