3

It is known that Visual Studio library *.lib file is an Unix "ar" archive containing object modules in COFF format. But I found that libraries for importing DLL is an archive of small chunks (or stubs) that are not COFF objects. An example is the library VS15\lib\ucrt\ucrt.lib. These chunks contain the name of function and the reference to DLL library that defines this function. Here is an example (hex dump) of stub for "puts" function:

00-00-FF-FF-00-00-4C-01-39-E9-80-55-26-00-00-00 ......L.9..U&...
93-00-08-00-5F-70-75-74-73-00-61-70-69-2D-6D-73 “..._puts.api-ms
2D-77-69-6E-2D-63-72-74-2D-73-74-64-69-6F-2D-6C -win-crt-stdio-l
31-2D-31-2D-30-2E-64-6C-6C-00                   1-1-0.dll.

It is definitely not COFF object (although it contains 386 architecture signature 0x14C specific to COFF). I can't find any documentation on the format of these import objects. Does anybody know this format?

May be unofficial specs?

May be some source code that can process this format?

Serge Goncharov
  • 488
  • 1
  • 6
  • 13
  • Does this help: https://blogs.msdn.microsoft.com/ronpih/2006/10/28/new-version-of-the-microsoft-pecoff-spec/ ? – Richard Critten Jun 03 '17 at 14:14
  • I know this documentation well, this is my handbook. Alas, it describes only traditional COFF object modules, but not import stubs. – Serge Goncharov Jun 03 '17 at 14:26
  • 1
    Note that the ucrt import libs are even more special than normal import libraries: they might contain special logic to load specific versioned dll's. See e.g. https://mingwpy.github.io/ucrt.html for why just generating an import lib for the ucrt dll does the wrong thing. – rubenvb Jun 03 '17 at 18:20
  • @rubenvb Inspecting ucrt.lib I didn't noticed any special logic other than enumeration of modules instead of names. From the technical point of view it is plain library but COFF modules are replaced by these chunks. There is a simple method to get the similar result - just convert DLL (via DEF) to library. I made a simple test.def containing single function definition and made *.lib. The result is quite the same. – Serge Goncharov Jun 06 '17 at 13:41
  • @Serge ok. Then the problem described in the link lies elsewhere. Perhaps it is the fact that generating a def file from the ucrt dll and linking to an import library generated from that won't work. Unrelated to you issue though, I believe. – rubenvb Jun 06 '17 at 14:07

1 Answers1

3

This is so-called Microsoft "short import" object. Basically, it consists of 20 bytes header (the same size as a regular COFF header), followed by two zero-terminated strings: import symbol name, and DLL name, respectively.

"Short import" header differs from a regular COFF header in the first four signature bytes: 0x00 0x00 0xFF 0xFF (no regular COFF can start with this, because it would read as "unknown machine, 65535 sections", which is nonsense).

The format of "short import" header is fully described here: MSDN PE Format.

So in the example above we have:

0x00 0x00 0xFF 0xFF --> "short import" signature
0x00 0x00 --> Version 0 (unused)
0x4C 0x01 --> Machine I386
0x39 0xE9 0x80 0x55 --> Time/Date stamp (17 Jun 2015, 6:27:53 UTC)
0x26 0x00 0x00 0x00 --> size of the strings following the header (38 bytes)
0x93 0x00 --> ordinal/hint (147)
0x08 0x00 --> bit field ("code", import by "name")

0xC0000022L
  • 20,597
  • 9
  • 86
  • 152
Matt
  • 13,674
  • 1
  • 18
  • 27