How to determine whether a DLL is a managed assembly or native (prevent loading a native dll)?

Question

Original title: How can I prevent loading a native dll from a .NET app?

Background:

My C# application includes a plugin framework and generic plugin loader.

The plugin loader enumerates the application directory in order to identify plugin dlls (essentially it searches for *.dll at this time).

Within the same application directory is a native (Windows, non-.net) dll, which, indirectly, one of the plugin dlls depends upon.

The plugin loader blindly assumes that the native.dll is a .NET Assembly dll, simply because it only checks the file extension. When it attempts to load the native dll, an exception is thrown:

"Could not load file or assembly 'native.dll' or one of its dependencies. The module was expected to contain an assembly manifest."

I basically create a diagnostic report if plugin loading fails, so I'm trying to avoid having this log filled up with messages about not being able to load the native dll (which I don't even want to attempt).

The question:

Is there some .NET API call that I can use to determine whether a binary happens to be a .NET assembly so that I don't attempt to load the native dll at all?

Perhaps longer term I will move my plugins to a subdirectory, but for now, I just want a work around that doesn't involve hard-coding the "native.dll" name inside my plugin loader.

I guess I'm looking for some kind of static Assembly.IsManaged() API call that I've overlooked.... presumably no such API exists?

Answer 1

Answer quoted by lubos hasko is good but it doesn't work for 64-bit assemblies. Here's a corrected version (inspired by http://apichange.codeplex.com/SourceControl/changeset/view/76c98b8c7311#ApiChange.Api/src/Introspection/CorFlagsReader.cs)

public static bool IsManagedAssembly(string fileName)
{
    using (Stream fileStream = new FileStream(fileName, FileMode.Open, FileAccess.Read))
    using (BinaryReader binaryReader = new BinaryReader(fileStream))
    {
        if (fileStream.Length < 64)
        {
            return false;
        }

        //PE Header starts @ 0x3C (60). Its a 4 byte header.
        fileStream.Position = 0x3C;
        uint peHeaderPointer = binaryReader.ReadUInt32();
        if (peHeaderPointer == 0)
        {
            peHeaderPointer = 0x80;
        }

        // Ensure there is at least enough room for the following structures:
        //     24 byte PE Signature & Header
        //     28 byte Standard Fields         (24 bytes for PE32+)
        //     68 byte NT Fields               (88 bytes for PE32+)
        // >= 128 byte Data Dictionary Table
        if (peHeaderPointer > fileStream.Length - 256)
        {
            return false;
        }

        // Check the PE signature.  Should equal 'PE\0\0'.
        fileStream.Position = peHeaderPointer;
        uint peHeaderSignature = binaryReader.ReadUInt32();
        if (peHeaderSignature != 0x00004550)
        {
            return false;
        }

        // skip over the PEHeader fields
        fileStream.Position += 20;

        const ushort PE32 = 0x10b;
        const ushort PE32Plus = 0x20b;

        // Read PE magic number from Standard Fields to determine format.
        var peFormat = binaryReader.ReadUInt16();
        if (peFormat != PE32 && peFormat != PE32Plus)
        {
            return false;
        }

        // Read the 15th Data Dictionary RVA field which contains the CLI header RVA.
        // When this is non-zero then the file contains CLI data otherwise not.
        ushort dataDictionaryStart = (ushort)(peHeaderPointer + (peFormat == PE32 ? 232 : 248));
        fileStream.Position = dataDictionaryStart;

        uint cliHeaderRva = binaryReader.ReadUInt32();
        if (cliHeaderRva == 0)
        {
            return false;
        }

        return true;
    }
}

The missing piece was to offset to the data dictionary start differently depending on whether we are PE32 or PE32Plus:

    // Read PE magic number from Standard Fields to determine format.
    var peFormat = binaryReader.ReadUInt16();
    if (peFormat != PE32 && peFormat != PE32Plus)
    {
        return false;
    }

    // Read the 15th Data Dictionary RVA field which contains the CLI header RVA.
    // When this is non-zero then the file contains CLI data otherwise not.
    ushort dataDictionaryStart = (ushort)(peHeaderPointer + (peFormat == PE32 ? 232 : 248));

Answer 2

How to determine whether a file is a .NET Assembly or not?

public static bool IsManagedAssembly(string fileName)
{
    uint peHeader;
    uint peHeaderSignature;
    ushort machine;
    ushort sections;
    uint timestamp;
    uint pSymbolTable;
    uint noOfSymbol;
    ushort optionalHeaderSize;
    ushort characteristics;
    ushort dataDictionaryStart;
    uint[] dataDictionaryRVA = new uint[16];
    uint[] dataDictionarySize = new uint[16];

    Stream fs = new FileStream(fileName, FileMode.Open, FileAccess.Read);
    BinaryReader reader = new BinaryReader(fs);

    //PE Header starts @ 0x3C (60). Its a 4 byte header.
    fs.Position = 0x3C;
    peHeader = reader.ReadUInt32();

    //Moving to PE Header start location...
    fs.Position = peHeader;
    peHeaderSignature = reader.ReadUInt32();

    //We can also show all these value, but we will be       
    //limiting to the CLI header test.
    machine = reader.ReadUInt16();
    sections = reader.ReadUInt16();
    timestamp = reader.ReadUInt32();
    pSymbolTable = reader.ReadUInt32();
    noOfSymbol = reader.ReadUInt32();
    optionalHeaderSize = reader.ReadUInt16();
    characteristics = reader.ReadUInt16();

    // Now we are at the end of the PE Header and from here, the PE Optional Headers starts... To go directly to the datadictionary, we'll increase the stream’s current position to with 96 (0x60). 96 because, 28 for Standard fields 68 for NT-specific fields From here DataDictionary starts...and its of total 128 bytes. DataDictionay has 16 directories in total, doing simple maths 128/16 = 8. So each directory is of 8 bytes. In this 8 bytes, 4 bytes is of RVA and 4 bytes of Size. btw, the 15th directory consist of CLR header! if its 0, its not a CLR file :)
    dataDictionaryStart = Convert.ToUInt16(Convert.ToUInt16(fs.Position) + 0x60);
    fs.Position = dataDictionaryStart;
    for (int i = 0; i < 15; i++)
    {
        dataDictionaryRVA[i] = reader.ReadUInt32();
        dataDictionarySize[i] = reader.ReadUInt32();
    }
    fs.Close();

    if (dataDictionaryRVA[14] == 0) return false;
    else return true;
}

Answer 3

I'm afraid the only real way of doing this is to call System.Reflection.AssemblyName.GetAssemblyName passing the full path to the file you want to check. This will attempt to pull the name from the manifest without loading the full assembly into the domain. If the file is a managed assembly then it will return the name of the assembly as a string otherwise it will throw a BadImageFormatException which you can catch and ignore before skipping over the assembly and moving onto your other plugins.

Answer 4

As orip suggested, you will want to wrap it in a try {} catch {} block - in particular, you want to be watching out for the BadImageFormatException

foreach (string aDll in dllCollection) 
{
  try 
  {
     Assembly anAssembly = Assembly.LoadFrom(aDll);
  }
  catch (BadImageFormatException ex)
  {
    //Handle this here
  }
  catch (Exception ex)
  {
    //Other exceptions (i/o, security etc.)
   }
}

Check out the other exceptions here http://msdn.microsoft.com/en-us/library/1009fa28.aspx

Answer 5

Using BadImageFormatException exception is a bad way to go, for ex. if your application targets .NET 3.5, it will not recognize let's say assemblies compiled against .NET Core, though the assembly is managed.

So I think parsing PE header is much better.

Answer 6

Extending on Kirill's answer, I've translated it to VB, tuned the Boolean logic slightly for readability and turned it into an extension method for System.IO.FileInfo. Hopefully it can help someone.

Public Module FileSystem
  <Extension>
  Public Function IsManagedAssembly(File As FileInfo) As Boolean
    Dim _
      uHeaderSignature,
      uHeaderPointer As UInteger

    Dim _
      uFormat,
      u64,
      u32 As UShort

    u64 = &H20B
    u32 = &H10B

    IsManagedAssembly = False

    If File.Exists AndAlso File.Length.IsAtLeast(64) Then
      Using oStream As New FileStream(File.FullName, FileMode.Open, FileAccess.Read)
        Using oReader As New BinaryReader(oStream)
          'PE Header starts @ 0x3C (60). Its a 4 byte header.
          oStream.Position = &H3C
          uHeaderPointer = oReader.ReadUInt32

          If uHeaderPointer = 0 Then
            uHeaderPointer = &H80
          End If

          ' Ensure there is at least enough room for the following structures:
          '     24 byte PE Signature & Header
          '     28 byte Standard Fields         (24 bytes for PE32+)
          '     68 byte NT Fields               (88 bytes for PE32+)
          ' >= 128 byte Data Dictionary Table
          If uHeaderPointer < oStream.Length - 257 Then
            ' Check the PE signature.  Should equal 'PE\0\0'.
            oStream.Position = uHeaderPointer
            uHeaderSignature = oReader.ReadUInt32

            If uHeaderSignature = &H4550 Then
              ' skip over the PEHeader fields
              oStream.Position += 20

              ' Read PE magic number from Standard Fields to determine format.
              uFormat = oReader.ReadUInt16

              If uFormat = u32 OrElse uFormat = u64 Then
                ' Read the 15th Data Dictionary RVA field which contains the CLI header RVA.
                ' When this is non-zero then the file contains CLI data, otherwise not.
                Select Case uFormat
                  Case u32 : oStream.Position = uHeaderPointer + &HE8
                  Case u64 : oStream.Position = uHeaderPointer + &HF8
                End Select

                IsManagedAssembly = oReader.ReadUInt32 > 0
              End If
            End If
          End If
        End Using
      End Using
    End If
  End Function
End Module

Answer 7

You could always wrap the DLL loading with a try/except block...

Answer 8

Modern way using System.Reflection.Metadata (included in .NET Core and .NET 5+, or installed as a NuGet package on .NET Framework):

using System;
using System.Collections.Generic;
using System.IO;
using System.Reflection.Metadata;
using System.Reflection.PortableExecutable;

//...

static bool IsAssembly(string path)
{
    using var fs = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.ReadWrite);

    // Try to read CLI metadata from the PE file.
    using var peReader = new PEReader(fs);

    if (!peReader.HasMetadata)
    {
        return false; // File does not have CLI metadata.
    }

    // Check that file has an assembly manifest.
    MetadataReader reader = peReader.GetMetadataReader();
    return reader.IsAssembly;
}

Source: https://learn.microsoft.com/en-us/dotnet/standard/assembly/identify#using-the-pereader-class

---

NOTE: This solution is slower then in answer by Kirill Osenkov, but it enables handling of some edge cases. I'll call linked answer Custom PE parser solution, and my answer SRM solution:

1. Managed modules without assembly manifest (.netmodule files). Such files can be produced by C# compiler using TargetType=module option; they have CLI header, but can't be loaded for execution as proper assemblies. Custom PE parser solution returns true for them, while SRM solution returns false.

2. Corrupted assemblies with correct headers. Let's say we have an assembly file with correct PE headers, but huge part of its other content was corrupted (like, by zeroing out a range of bytes). Custom PE parser solution returns true for it, while SRM solution throws BadImageFormatException, with "Invalid COR20 header signature." message in my test (the exception can be handled).