ILMerge (Merging .net assemblies)

In this article, we will be using ILMerge programming interface to merge assemblies.

The first question which comes to our mind is if we have classes with the same name in two assemblies then what would be the behavior of this utility? To answer this question we ask you a question: What do you generally want in such a scenario? You would definitely want to be notified all such cases so that you can make decision on your own as a developer. This is generally the case and this is also the default setting of ILMerge. ILMerge also allows you to explicitly specify the names of classes which you want to allow having duplicates. All other classes will not be allowed to have duplicates.

But sometimes you want to handle these types of cases differently. You want to rename the conflicting names in order to merge the assemblies successfully. This may be true when you want to merge third party assemblies. In this case, you have no access to the source code.

Command line option: [/allowDup[:typeName]]*

If we want to access ILMerge through our code then AllowDuplicateType(string TypeName) is provided for this purpose. Here TypeName is the type we want to handle if a duplicate is found. If we want to rename all duplicates found then pass null as argument.

Now the biggest question in the world is How we can access a particular definition of a class if there are two classes with same names but with different definition?

Classification of Assemblies:
The assemblies, being merged, can be classified into two types.
1. Primary Assembly: The first of the assemblies being merged.
2. Other Assembly: All assembly other than Primary assembly.

Can obfuscated assemblies be merged?
No! Obfuscated assemblies can not be merged.

We can also sign the target assemblies with a key file. All we have to do is to provide the key file. This also supports delay signing.

What if I need to merge the duplicate definitions into a single type? Can I do that?
Sure! There is a switch provided for this requirement in ILMerge. It is "UnionMerge". This can be used if duplicates are not allowed already using allowDup switch. This options is turned off by default. It would copy the members from all the source assemblies and would result in a new definition in target assembly. Now the question is what if they have same methods with same signatures. We all know that we are not allowed to overload methods with same signatures. Would it generates some errors?

We all know that assemblies can be created as application executables (*.exe) or Dynamic Link Library (DLL). We can specify how we want to create target assembly. I mean whether we want it to be created as Win / Console executable or a dll. By default, the type of target assembly matches with that of Primary assembly. "TargetKind" switch is provided to define the type of the target assembly.

We might have our assemblies in frameworks other than the desired framework of our target assembly. Cuurrently, only 1.0, 1.1 and 2.0 frameworks are supported for the target assembly. To specify a particular framework, we also need to specify the directory in which mscorlib.dll resides for the particular framework. Yes you are right! We can not create target assemblies conforming to 3.0 / 3.5 frameworks.

ILMerge also allows to modify the accessibility (setting as Private) of object types in assemblies other than Primary assembly. During this, it allows to specify the list of exclusions in the form of a file. In this file exclusions are specified in the form of regular expression.

PEVERIFY is part of .net SDK tool. This can be used to verify that the output of ILMerge will be loaded in a .net runtime successfully.

XPATH Injection

Getting user input and using it directly for some verification is always dangerous. When developers discuss about injection attacks, they generally talk about SQL Injection.

These injection attacks can be targeted to any query language. One of them is XPATH. XPATH expressions are used to query XML documents. They provide easy way to access the desired contents avoiding loops and programming language specific constructs.

These kind of attacks can be minimized if direct use of user input to formulate a query is avoided. This is because the attacker might inject the malicious information which allow him to pass the authentication.

Let's see how an attacker uses this.

We assume a typical Login form which has two text boxes. txtUserName and txtPassword and a btnLogin button. The user is supposed to provide his credentials and hit Login button for verification.

The user data is maintained in the form of XML.


<users>
<user>
<username>Shujaat</username>
<password>Siddiqi123</password>
</user>
<user>
<username>Rose2009</username>
<password>MyP@ssword765</password>
</user>
...
</users>


Now the XPATH expression constructed for user verification is as follows:

string query = "/Users/User[UserName='" + txtUserName.Text + "' and Password='" + txtPassword.Text + "']"


Now a user can easily pass through the security check if he enters in either of the text boxes data like this:

txtUserName: ' or 1=1 or ''='
OR
txtPassword: ' or 1=1 or ''='

We assume he enters this in the txtUserName and txtPassword is provided with any text e.g: 'shujaat'.

Now the variable query would be assigned with the following string query:
"/Users/User[UserName=' ' or 1=1 or ''='' and Password='shujaat']".

Since this expression would satisfy all nodes in the document. The SelectNodes() method on XMLDocument object would give the list of nodes with all the nodes in the document (Microsoft.net).

The attacker is finally in the system freely! :)

So be careful when you construct XPATH expressions from user data, otherwise...