.NET DLL / EXE PE是否令人困惑？

Question

I've been inspecting a .NET DLL out of interest, using the ECMA-335 for reference, and as far as I can tell, I am making a grave mistake since it seem to be wrong. My error comes from the fact that the PE file header doesn't appear immediately after the PE signature.

The ECMA-335 states that:

"II.25.2.2 PE file header
Immediately after the PE signature is the PE File header consisting of the following:

Offset Size Field Description
0 2
Machine Always 0x14c."

Now, when I use the following code, this works for normal, non managed DLLs and EXEs.

unsafe static void Stuff(Stream stream, byte[] buf)
{
    int read = stream.Read(buf, 0, 1024);
    // skip the first 128 bytes 
    // since that's the header 
    fixed (byte* ptr = buf)
    {
        // get the position of the signature?
        int PEHeaderStart = *(int*)(ptr + 0x3c);
        char PEsig1 = (char)*(ptr + PEHeaderStart); // P
        char PEsig2 = (char)*(ptr + PEHeaderStart + 1); // E
        char PEsig3 = (char)*(ptr + PEHeaderStart + 2); // \0
        char PEsig4 = (char)*(ptr + PEHeaderStart + 3); // \0 

        ushort machine = *(ushort*)(ptr + PEHeaderStart + 4);
        ushort noSections = *(ushort*)(ptr + PEHeaderStart + 6);

        uint secondsFrom1970 = *(uint*)(ptr + PEHeaderStart + 8);
        DateTime timeOfCreation = new DateTime(1970, 1, 1) + new TimeSpan((long)secondsFrom1970 * 1000 * 10000);

        uint pointerToSymbolTable = *(uint*)(ptr + PEHeaderStart + 12);
        uint numberOfSymbols = *(uint*)(ptr + PEHeaderStart + 16);
        ushort sizeOfOptionalHeader = *(ushort*)(ptr + PEHeaderStart + 20);

        ushort characteristics = *(ushort*)(ptr + PEHeaderStart + 22);

        // flags from characteristics 
        bool IMAGE_FILE_RELOCS_STRIPPED = (characteristics & 0x0001) == 1;
        bool IMAGE_FILE_EXECUTABLE_IMAGE = (characteristics & 0x002) == 1;
        bool IMAGE_FILE_32BIT_MACHINE = (characteristics & 0x0100) == 1;
        bool IMAGE_FILE_DLL = (characteristics & 0x2000) == 1;

        int optionalHeaderStart = PEHeaderStart + 24;

        // PE optional header 
        ushort magic = *(ushort*)(ptr + optionalHeaderStart);
        byte lmajor = *(ptr + optionalHeaderStart + 2);                
        byte lminor = *(ptr + optionalHeaderStart + 3);

        uint codesize = *(uint*)(ptr + optionalHeaderStart + 4);
    }
}

The machine number is the magic number, and the timeOfCreation makes sense and the magic number in the PE optional header is correct. At the pointer specified in 0x3c, the signature 'PE\\0\\0' is there, and the PE file header comes directly afterwards.

However, when I try and inspect a .NET managed DLL, I can successfuly find the signature 'PE\\0\\0', but the PE file header doesn't come immediately afterwards. So the number I get afterwards are garbage. This becomes apparent when the machine number is 34404 (0x8664) rather than 332 (0x14C) which the ECMA-335 says must be the case.

I must be doing something wrong, or not read a specific part, but I can't work out what that is at the moment.

Answer 1

They are PE conformant, however, they do not contain sensible machine instructions. Try running dumpbin /disasm on one of them. You will see it try to interpret the IL code as machine instructions, which gives you nonsense results. For example:

Microsoft (R) COFF/PE Dumper Version 14.16.27026.1
Copyright (C) Microsoft Corporation.  All rights reserved.


Dump of file hello.exe

File Type: EXECUTABLE IMAGE

  00402000: 80 23 00           and         byte ptr [ebx],0
  00402003: 00 00              add         byte ptr [eax],al
  00402005: 00 00              add         byte ptr [eax],al
  00402007: 00 48 00           add         byte ptr [eax],cl
  0040200A: 00 00              add         byte ptr [eax],al
  0040200C: 02 00              add         al,byte ptr [eax]
  0040200E: 05 00 68 20 00     add         eax,206800h
  00402013: 00 E4              add         ah,ah
  00402015: 02 00              add         al,byte ptr [eax]
  00402017: 00 01              add         byte ptr [ecx],al
  00402019: 00 00              add         byte ptr [eax],al
  0040201B: 00 01              add         byte ptr [ecx],al
  0040201D: 00 00              add         byte ptr [eax],al
  0040201F: 06                 push        es
  00402020: 00 00              add         byte ptr [eax],al
  00402022: 00 00              add         byte ptr [eax],al
  00402024: 00 00              add         byte ptr [eax],al
  00402026: 00 00              add         byte ptr [eax],al
  00402028: 00 00              add         byte ptr [eax],al
  0040202A: 00 00              add         byte ptr [eax],al
  0040202C: 00 00              add         byte ptr [eax],al

This is fine, however, since the Windows loader knows how to load .NET assemblies so that the managed code is parsed and run instead.