Assemblies Embedding

Assemblies embedding allows to embed assembly's dependencies into assembly itself. This may be beneficial from the deployment and security points of view.

Assemblies embedding is similar to merging. The main difference is that the assemblies are not merged into single assembly when they are embedded. They just get encrypted and packed as the assembly resources. As a result, there is a single assembly at the output and it contains the packed dependencies at the same file.

Assemblies merging delivers the best performance for the resulting assemblies. They can be NGEN'ed, they work in all constrained environments (Windows Phone, Compact Framework etc.). File mappings and JIT'ted code can be cached by the operating system for such assemblies, bringing the blinding fast application startups. Assembly merging definitely rocks.

The only downside of merging is that it's not always possible to apply it without breaking the application. So this is the point where assemblies embedding comes to the rescue.

Embedded assemblies are easy goals to achieve and they work out of the box. Downsides? Well, they are present. Embedded assemblies can not be NGEN'ed, they do not work in some constrained environments (Xbox, Windows Phone and Compact Framefork). The extraction of embedded assemblies during the application load is a performance penalty (penalty is pretty small, so it's unlikely you are able to notice it).

Assemblies embedding brings some benefits as well. The embedded assemblies are encrypted, so this is a securty hardening against the hackers. Embedded assemblies are compressed, bringing the size reduction of the resulting assembly. And of course assemblies embedding is the easiest way to achieve single-file deployment, making your application to consist of a single .exe (or .dll) file.

Embedded assemblies are compressed and encrypted by default. You may prefer to turn off the compression, encryption or them both. In order to do that, please read the notes below.

The full notation of a custom attribute for assembly embedding has the following form:

[assembly: Obfuscation(Feature = "embed [flags] XXXXXX.dll", Exclude = false)]

where [flags] is an optional enumeration of flags separated by spaces.

The list of available flags is presented in the table below.

Let's take a look on examples.

using System;
using System.Reflection;

[assembly: Obfuscation(Feature = "embed [no_compress no_encrypt] XXXXXX.dll", Exclude = false)]

using System;
using System.Reflection;

[assembly: Obfuscation(Feature = "embed [no_encrypt] XXXXXX.dll", Exclude = false)]

using System;
using System.Reflection;

[assembly: Obfuscation(Feature = "embed XXXXXX.dll", Exclude = false)]

using System;
using System.Reflection;

[assembly: Obfuscation(Feature = "embed satellites", Exclude = false)]

using System;

class Program
{
    static string GetEulaPath()
    {
        var assembly = typeof(Program).Assembly;
        // string location = assembly.Location; // Please do not use this. This is a flawed approach
        string location = new Uri(assembly.EscapedCodeBase).LocalPath; // <-- Use this instead
        return Path.Combine(Path.GetDirectoryName(location), "EULA.rtf");
    }
}

Issue summary.  Some applications, libraries and technologies use custom assembly loading mechanisms that go beyond locating assemblies by strong names. They typically rely on some domain-specific properties of an assembly. It may be special assembly name convention, specific custom attribute applied to an assembly etc.

What may go wrong?  A particular property of a custom assembly loading mechanism is that it looks for an assembly either at the list of loaded assemblies or at the probing paths for the current AppDomain. This is where Assemblies Embedding may become a breaking change for the custom algorithm – the assembly is no longer there, it is embedded.

Solution.  Use immediate_load flag for the embedded assembly. This will instruct Eazfuscator.NET to immediately load the assembly at the module startup.