As the title says, how to tell if an exe will load a DLL statically or dynamically by looking at the PE file header?
In other words, how to tell if the DLL is part of the executable, or will be called by the loader?
Thanks
Let me first clarify some terminology to avoid confusion.
Anything executed within a DLL is by definition dynamic. But, a DLL may be statically bound or dynamically bound to an executable.
With static binding, the EXE links against a DLL's import library (actually a .LIB file that is built alongside the DLL). Corresponding DLL function prototypes in header files will usually be declared with __declspec(dllimport). This results in the EXE being filled with stubs for each DLL symbol that are filled in by the Windows loader at runtime. This is facilitated by the final EXE having an import section structure in its PE headers listing all the DLLs to be resolved by the Windows loader at runtime and their symbolic names (e.g. functions). Windows then does all the dirty work to find and load these DLLs and referenced symbolic addresses before the EXE starts execution of the primary thread at its entry point. If Windows fails to find any DLL(s) or referenced symbolic addresses, the EXE won't start.
With dynamic binding, the EXE explicitly invokes code to load DLL(s) and resolve symbolic addresses. This is done using the two KERNEL32 API functions: LoadLibrary() and GetProcAddress(). If an EXE does this, there will be no associated import section describing this DLL and its symbols, and the Windows loader will happily load the EXE knowing nothing said DLL(s). It is then application defined as to how to handle success or failure of LoadLibrary() and /or GetProcAddress().
It is worth noting at this point, that libraries like the C-Runtime may be provided in DLL form (dynamic library) or static form (static library). If you link to one of these libraries statically, there will be no DLL import section in the built EXE's PE header and no function stubs to resolve at runtime for that library. Instead of stubs, these symbols (functions and/or data variables) become part of the EXE. Static library functions and/or data are copied into the EXE and are assigned relative addresses explicitly by the linker; no different than if those symbols were implemented directly by the EXE. Additionally, there will be no LoadLibrary() or GetProcAddress() resolution either implicitly (by the Windows loader) or explicitly in code for these functions as they will be directly present and self-contained within the final EXE. As a side-note, debugging symbols may be used in this case to try and differentiate between EXE implemented functions and library implemented functions (should you care) but this is highly dependent on the settings used to build both the EXE and the static library.
With terminology cleared up, let me attempt to answer your question! :) Let me also add I'm not going to go into the specifics of bound and unbound import symbols for a module's import section because this distinction has nothing to do with the original question and have more to do with speeding up the work done by the Windows loader. If you are interested in those details however, you can read up on Microsoft's PE COFF Specification.
To see if an EXE is statically bound to a DLL, you can either parse the PE headers yourself to locate the DLL imports section or use one of dozens of tools to do this for you, such as Dependency Walker. If you load your EXE in Dependency Walker for example, you will see a list of all statically bound DLLs in the top-left pane underneath the EXE itself. If any of these DLLs are not found at runtime, the program will fail to load. In the right pane, top table, you will see symbols (e.g. functions) that are referenced in the EXE for the selected DLL. All of these symbols must additionally be found for the EXE to load. The lower table simply shows all of the symbols exported by the DLL, referenced or not.
If the EXE uses dynamic binding (also called it manual binding) for a given DLL, there will be no import section for that DLL and thus you won't see it referenced in tools like Dependency Walker. BUT, you can click on KERNEL32.DLL in Dependency Walker (all EXEs will have this dependency, though there are exceptions to this rule I won't get in to here) and locate references to LoadLibrary() and GetProcAddress(). Unfortunately most EXEs reference these functions in boilerplate code such as the C-Runtime so this won't tell you too much.
If you want to dig deeper into trying to figure out which DLLs are manually loaded by an application, the first thing to try is to and locate that DLL name string by searching the EXE for the DLL name. Note that the DLL name string need not end in ".DLL" as LoadLibrary() automatically assumes this extension if not provided. The standard tool for searching for strings within a binary module is Sysinternals Strings. This works great for modules that make no attempt to hide what they are doing.
With that said, obfuscated code (found in unpackers, viruses and the like) may obfuscate or encrypt DLL names as well as the functions referenced. Code may even choose to resolve LoadLibrary() and GetProcAddress() at runtime to further hinder efforts to figure out what they are doing. Your best bet in these situations is to use a tool like Sysinternals Process Monitor or a debugger with verbose logging enabled to watch the DLLs being loaded as the program runs. You can also use a disassembler (such as IDA) to try and piece together what the code is doing. To find out what DLL symbols are being used, you might start the EXE in a debugger and wait for the initial break at the entry-point. Then add a breakpoint on the first instruction in KERNEL32.GetProcAddress. Run the program. When that breakpoint is hit, the stack arguments will contain the symbol trying to be resolved.
As you can see, if an application resolves DLL symbols manually (dynamic binding), the process of figuring out what DLLs are being referenced is not as straightforward.