• 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.

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”).

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

Let’s assume that we have a simple class with a private field called “someHiddenValue”.

class ClassThatHidesSomething
{
    private int someHiddenValue = 5;
}

We want to modify that field from outside the class. This can be done extremely easy through Reflection. First of all we need to get the Type of the ClassThatHidesSomething and get some information about the someHiddenValue field.

Type classThatHidesSomethingType = typeof(ClassThatHidesSomething);
FieldInfo field = classThatHidesSomethingType.GetField(
                         "someHiddenValue",
                         BindingFlags.NonPublic | BindingFlags.Instance);

• BindingFlags.NonPublic specifies that we want to search in all fields; by default it searches only the public fields – actually here is the trick that violates encapsulation.
• BindingFlags.Instance specified that we want to search in instance fields also; by default it searches only in static ones.

Now that we have the FieldInfo of that specific field we can do whatever we want with it. Let’s display its value. But first, because the field is an instance field we need an instance of ClassThatHidesSomething.

ClassThatHidesSomething c = new ClassThatHidesSomething();
 
int hiddenFieldValue = (int)field.GetValue(c);
Console.WriteLine("Hidden field value: {0}", hiddenFieldValue);

Using the same instance c we can set the private field’s value.

field.SetValue(c, 6);

Below you can see the entire code (it is a console application):

using System;
using System.Reflection;
 
namespace Reflection
{
    class ClassThatHidesSomething
    {
        private int someHiddenValue = 5;
    }
 
    class Reflection
    {
        const int ANumber = 10;
 
        public static void Main(string[] args)
        {
            Type classThatHidesSomethingType = typeof(ClassThatHidesSomething);
            FieldInfo field = classThatHidesSomethingType.GetField(
                                     "someHiddenValue",
                                     BindingFlags.NonPublic | BindingFlags.Instance);
            //It is good to check this because
            //we don't want a NullReferenceException
            if (field == null)
                Console.Write("Field not found");
            else
            {
                ClassThatHidesSomething c = new ClassThatHidesSomething();
 
                int hiddenFieldValue = (int)field.GetValue(c);
                Console.WriteLine("Hidden field value: {0}", hiddenFieldValue);
 
                field.SetValue(c, 6);
 
                int newHiddenFiledValue = (int)field.GetValue(c);
                Console.WriteLine("New hidden field value: {0}", newHiddenFiledValue);
            }
        }
    }
}

The code outputs:

Hidden field value: 5
New hidden field value: 6

Part one of this tutorial will show how to bind properties of the same type while the second one will also anlyse type conversion.

Using data binding you can synchronize object properties. The source of the binding is the object or property that is changing the value and the destination is the one who receives it (the new value).

There are two types of binding:

• one way binding – there is only one source that updates the information and as many destinations who receive the update.
• two way binding – every binding element can update and can receive updates so there is no distinction between source and destination.

The central element of binding is the Observer. It manages the process – chooses whether to send or not the notifications, performs type conversions and keeps the list of subscribers.

The diagrams below illustrate the two binding situations (one way and two way) when the source and destination have the same data type.

In the first diagram, the arrows suggest that the information comes from the source object and the Observer distributes is to all subscribers. In the second one every subscriber is also a source. “Update” is the process of informing the Observer that one source changed its value and “notify” is the process of sending, to all subscribers, the new value. Even though in the first diagram is not suggested, the source performs an update and the observers performs three notifications.

All we need to do is to create the observer. As seen in the diagrams this will have an Update method and a mechanism of notifying the subscribers about the new value. The notification can be implemented as an event and the update like a method.

Because we don’t know what data type will be used for binding and we want type safety, the observer will be generic.

class Observer<T>
{
}

The event sends the new value and the source (class) of it. The source is needed because if the one who sent the information is also a subscriber it should not react to notification.

public delegate void ValueChangeDelegate(object sender, T value);
public event ValueChangeDelegate ValueChangeNotification;

The Observer holds the current value (last value sent) and if an update contains it there is no need of notification because no changes take place. The update method compares the new value with the current one and checks for subscribers. If the values are different and subscribers exist it raises the event.

public void Update(object source, T value)
{
    if (currentValue != null)
    {
        if (!currentValue.Equals(value) && ValueChangeNotification != null)
            ValueChangeNotification(source, value);
    }
    else
        if (value != null && ValueChangeNotification != null)
            ValueChangeNotification(source, value);
    currentValue = value;
}

Combining the code above and adding constructors we obtain the Observer.

class Observer<T>
{
    public delegate void ValueChangeDelegate(object sender, T value);
    public event ValueChangeDelegate ValueChangeNotification;
 
    private T currentValue;
 
    public Observer()
    {
        currentValue = default(T);
    }
 
    public Observer(T initValue)
    {
        currentValue = initValue;
    }
 
 
    public void Update(object source, T value)
    {
        if (currentValue != null)
        {
            if (!currentValue.Equals(value) && ValueChangeNotification != null)
                ValueChangeNotification(source, value);
        }
        else
            if (value != null && ValueChangeNotification != null)
                ValueChangeNotification(source, value);
        currentValue = value;
    }
}

Let’s create a small test application that has two text boxes and syncronizes their texts.

1. Create a new Windows Forms Application in Visual Studio and add two text boxes on the main form.
2. Create events for text change (double click each text box).
3. Now add the Binding class to your project and create a new Observer object for string as a member the form’s class. Let’s call it textObserver.
4. Now create a method for the update event – a method with two parameter: an object and a string – and subscribe to the event.
5. Update the observer when the text changes in one text box.

If you are having problems in creating the application you can download the final version from here. Change the text in one text box and it should also update the other one.

Part 2 of this tutorial will explain how to synchronize properties that have different values and need conversion. It will be posted soon.

The test procedure is simple. Perform a number of cross-domain and non cross-domain operations (get the value of NextNumber() from same domain and from another domain) and measure the time elapsed. For each value I have runned the application 3 times, recorded the time (in milliseconds) and created the mean of this three.

For this I’ve created a Console Application containing two classes, the main class and “NumberClass” which has a method that returns the next long. The code for this two is below:

NumberClass:

//MarshalByRefObject is used because this object will cross domain boundary
class NumberClass:MarshalByRefObject
{
    public ulong number = 0;
    public ulong NextNumber()
    {
        return number++;
    }
}

The Main method from the main class:

static void Main(string[] args)
{
    //Uncomment this two lines to load the class in another app domain
    //System.AppDomain appDom = System.AppDomain.CreateDomain("TestAppDomain");
    //NumberClass n = (NumberClass)appDom.CreateInstanceAndUnwrap("AppDomain", "AppDomain.NumberClass");
    NumberClass n = new NumberClass(); //Comment this line if uncomment the two above
    DateTime start = DateTime.Now;
    //We are going to change the value of i 
    for (ulong i = 0; i < 10; i++)
    {
        n.NextNumber();
    }
    DateTime end = DateTime.Now;
    TimeSpan elapsedTime = end - start;
    Console.WriteLine("Elapsed time: {0} ms", elapsedTime.TotalMilliseconds);
    Console.ReadLine();
}

The values of i are: 1, 10, 100, 1.000, 10.000, 100.000, 1.000.000 so a total of 42 measurements were performed. The test system is a Core2Duo 2Ghz, 2GB Ram 667 running Windows Vista Business x32 and Visual Studio 2008 Professional.

Let’s see the results:

Please note that the tallest bar from the left graph is almost the smallest from the right one :)

Conclusion: using AppDomains is cool, is useful but use them wisely because a large number of cross domain operations drastically affect performances.

Reflection is the process by which a computer program can observe and modify its own structure and behavior. The programming paradigm driven by reflection is called reflective programming. [Wikipedia]

Working a few days ago on a plugin architecture on .NET Framework I’ve found something very interesting. The method System.Reflection.EventInfo.AddEventHandler does late-binding. You’ll probably say “so what?”. Let’s see the problem with an example:

Using Visual Studio 2005/2008, create two C# projects (a windows forms application project and a class library one). Rename the class from the class library project to “TestClass.cs”.

We are going to dynamically load the dll and add his public methods that begin with “Method” to respond to some menu item clicks.

First we need the dll code. Let’s add three methods (don’t forget to add a reference to System.Windows.Forms because we’ll show some message boxes):

public class TestClass
{
    public static void Method1()
    {
MessageBox.Show("Method1");
}
    public static void Method2()
    {
        MessageBox.Show("Method2");
    }
    public static void Method3()
    {
        MessageBox.Show("Method3");
    }
}

That’s it, we have finished with the class library :-)

Now go the the windows forms project, in Form1.cs and add a MenuStrip (name it “menuStrip”) and on this add one MenuItem (named “menu1″).

It’s time to write some code that loads the dll. First add the needed using, “using System.Reflection”, and then, on the Load event of Form1 write:

Assembly classLib = Assembly.LoadFrom(AppDomain.CurrentDomain.BaseDirectory + "ClassLibrary.dll");
Type t = classLib.GetType("ClassLibrary.TestClass");

Ok, now we have the assembly loaded and we want to subscribe with each of it’s methods that begin with “Method” to a menu item click. Let’s find the methods that begin with “Method”, create a menu item and subscribe to the event, using AddEventHandler, with a delegate that invokes the method from dll.

foreach (MethodInfo method in t.GetMethods())
{
    if (method.Name.IndexOf("Method") == 0)
    {
        ToolStripItem newMenuItem = menu1.DropDownItems.Add(method.Name)       
        EventInfo e = newMenuItem .GetType().GetEvent("Click");
        e.AddEventHandler(newMenuItem, new EventHandler(delegate(object sender, EventArgs ev)
            {
                method.Invoke(null, null);
            }
        ));
    }
}

The code compiles, and our form shows with the menu we wanted :D (oh yeah!!).

Let’s click a Method1 item… Huh? Exception… Something is strange. I’ve subscribed with static methods and I receive “Non-static method requires a target.”.

Just adding a watch on “method” reveals the truth… I’ve subscribed with “GetHashCode()” which is not a static method. Probably my fault – bad code. Add a break point where the method is added to the delegate and surprise: “Method1()”. When I first saw this I was so confused. I didn’t knew if this is a bug, my fault or something normal. Searching on MSDN revealed the “supreme” truth:

All actions are performed using late binding.

This way I’ve found out that you cannot subscribe directly to an event with a set of methods and get the right result. If you watch every delegate from the event above you’ll see that all of them are pointing to “GetHashCode()” even though you subscribed with something else.

Is it a bug or not?