dynamic linking the program must manually load the right module in runtime
and find the right function to call by searching through the target executable’s
headers. Runtime linking is more flexible, but is also more difficult to imple-
ment from the programmer’s perspective. From a reversing standpoint, static
linking is easier to deal with because it openly exposes which functions are
called from which modules.
Headers
A PE file starts with the good old DOS header. This is a common backward-
compatible design that ensures that attempts to execute PE files on DOS sys-
tems will fail gracefully. In this case failing gracefully means that you’ll just get
the well-known “This program cannot be run in DOS mode” message. It goes
without saying that no PE executable will actually run on DOS—this message
is as far as they’ll go. In order to implement this message, each PE executable
essentially contains a little 16-bit DOS program that displays it.
The most important field in the DOS header (which is defined in the
IMAGE_DOS_HEADERstructure) is the e_lfanewmember, which points to the
real PE header. This is an extension to the DOS header—DOS never reads it.
The “new” header is essentially the real PE header, and is defined as follows.
typedef struct _IMAGE_NT_HEADERS{
DWORD Signature;
IMAGE_FILE_HEADER FileHeader;
IMAGE_OPTIONAL_HEADER32 OptionalHeader;
} IMAGE_NT_HEADERS32, *PIMAGE_NT_HEADERS32;This data structure references two data structures which contain the actual
PE header. They are:
typedef struct _IMAGE_FILE_HEADER{
WORD Machine;
WORD NumberOfSections;
DWORD TimeDateStamp;
DWORD PointerToSymbolTable;
DWORD NumberOfSymbols;
WORD SizeOfOptionalHeader;
WORD Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;typedef struct _IMAGE_OPTIONAL_HEADER {
// Standard fields.
WORD Magic;
BYTE MajorLinkerVersion;
BYTE MinorLinkerVersion;
DWORD SizeOfCode;Windows Fundamentals 97