Microsoft Portable Executable and Common Object File Format Specification

Microsoft Corporation
Revision 6.0 - February 1999

Note This document is provided to aid in the development of tools and applications for Microsoft Windows NT but is not guaranteed to be a complete specification in all respects. Microsoft reserves the right to alter this document without notice. Microsoft, MS, MS-DOS, and CodeView are registered trademarks, and Windows, Windows NT, Win32, Win32s, and Visual C++ are trademarks of Microsoft Corporation in the USA and other countries. Alpha AXP is a trademark of Digital Equipment Corporation. Intel is a registered trademark, and Intel386 is a trademark of Intel Corporation. MIPS is a registered trademark of MIPS Computer Systems, Inc. Unicode is a trademark of Unicode, Incorporated. UNIX is a registered trademark of UNIX Systems Laboratories. Other product and company names mentioned herein may be the trademarks of their respective owners. 1999 Microsoft Corporation. All rights reserved.

Contents 1. General Concepts 2. Overview 3. File Headers 3.1. MS-DOS Stub (Image Only) 3.2. Signature (Image Only) 3.3. COFF File Header (Object & Image) 3.4. Optional Header (Usually Image Only) 4. Section Table (Section Headers) 4.1. Section Flags 4.2. Grouped Sections (Object Only) 5. Other Contents of the File 5.1. Section Data 5.2. COFF Relocations (Object Only) 5.3. COFF Line Numbers 5.4. COFF Symbol Table 5.5. Auxiliary Symbol Records 5.6. COFF String Table 5.7. The Attribute Certificate Table (Image Only) 5.8 Delay-Load Import Tables (Image Only) 6. Special Sections 6.1. The .debug Section 6.2. The .drectve Section (Object Only) 6.3. The .edata Section (Image Only) 6.4. The .idata Section 6.5. The .pdata Section 6.6. The .reloc Section (Image Only) 6.7. The .tls Section 6.8. The .rsrc Section 7. Archive (Library) File Format 7.1. Archive File Signature 7.2. Archive Member Headers 7.3. First Linker Member 7.4. Second Linker Member 7.5. Longnames Member 8. Import Library Format 8.1. Import Header 8.2. Import Type 8.3. Import Name Type Appendix: Example Object File Appendix: Calculating Image Message Digests Fields Not To Include In Digests

4 5 7 7 7 7 10 16 17 19 20 20 20 28 29 34 38 39 39 41 43 45 46 49 51 52 54 57 61 62 62 63 64 65 65 66 66 67 67 72 73

1. General Concepts
This document specifies the structure of executable (image) files and object files under the Microsoft Windows NT operating system. These files are referred to as Portable Executable (PE) and Common Object File Format (COFF) files respectively. The name Portable Executable refers to the fact that the format is not architecture-specific. Certain concepts appear repeatedly throughout the specification and are described in the following table: Name Image file Description Executable file: either a .EXE file or a DLL. An image file can be thought of as a memory image. The term image file is usually used instead of executable file, because the latter sometimes is taken to mean only a .EXE file. A file given as input to the linker. The linker produces an image file, which in turn is used as input by the loader. The term object file does not necessarily imply any connection to object-oriented programming. Relative Virtual Address. In an image file, an RVA is always the address of an item once loaded into memory, with the base address of the image file subtracted from it. The RVA of an item will almost always differ from its position within the file on disk (File Pointer). In an object file, an RVA is less meaningful because memory locations are not assigned. In this case, an RVA would be an address within a section (see below), to which a relocation is later applied during linking. For simplicity, compilers should just set the first RVA in each section to zero. Virtual Address (VA) Same as RVA (see above), except that the base address of the image file is not subtracted. The address is called a Virtual Address because Windows NT creates a distinct virtual address space for each process, independent of physical memory. For almost all purposes, a virtual address should be considered just an address. A virtual address is not as predictable as an RVA, because the loader might not load the image at its preferred location. Location of an item within the file itself, before being processed by the linker (in the case of object files) or the loader (in the case of image files). In other words, this is a position within the file as stored on disk. Date/time stamps are used in a number of places in a PE/COFF file, and for different purposes. The format of each such stamp, however, is always the same: that used by the time functions in the C run-time library.

Object file

RVA

File pointer

Date/Time Stamp

Section

A section is the basic unit of code or data within a PE/COFF file. In an object file, for example, all code can be combined within a single section, or (depending on compiler behavior) each function can occupy its own section. With more sections, there is more file overhead, but the linker is able to link in code more selectively. A section is vaguely similar to a segment in Intel 8086 architecture. All the raw data in a section must be loaded contiguously. In addition, an image file can contain a number of sections, such as .tls or .reloc, that have special purposes. Attribute certificates are used to associate verifiable statements with an image. There are a number of different verifiable statements that can be associated with a file, but one of the most useful ones, and one that is easy to describe, is a statement by a software manufacturer indicating what the message digest of the image is expected to be. A message digest is similar to a checksum except that it is extremely difficult to forge, and, therefore it is very difficult to modify a file in such a way as to have the same message digest as the original file. The statement may be verified as being made by the manufacturer by use of public/private key cryptography schemes. This document does not go into details of attribute certificates other than to allow for their insertion into image files.

2. Overview
Figures 1 and 2 illustrate the Microsoft PE executable format and the Microsoft COFF objectmodule format.

Figure 1. Typical 32-Bit Portable .EXE File Layout

Figure 2. Typical 32-Bit COFF Object Module Layout

3. File Headers
The PE file header consists of an MS-DOS stub, the PE signature, the COFF File Header, and an Optional Header. A COFF object file header consists of a COFF File Header and an Optional Header. In both cases, the file headers are followed immediately by section headers.

3.1. MS-DOS Stub (Image Only)

The MS-DOS Stub is a valid application that runs under MS-DOS and is placed at the front of the .EXE image. The linker places a default stub here, which prints out the message This program cannot be run in DOS mode when the image is run in MS-DOS. The user can specify another stub by using the /STUB linker option. At location 0x3c, the stub has the file offset to the Portable Executable (PE) signature. This information enables Windows NT to properly execute the image file, even though it has a DOS Stub. This file offset is placed at location 0x3c during linking.

3.2. Signature (Image Only)

After the MS-DOS stub, at the file offset specified at offset 0x3c, there is a 4-byte signature identifying the file as a PE format image file; this format is used in Win32, Posix on Windows NT, and for some device drivers in Windows NT. Currently, this signature is PE\0\0 (the letters P and E followed by two null bytes).

3.3. COFF File Header (Object & Image)

At the beginning of an object file, or immediately after the signature of an image file, there is a standard COFF header of the following format. Note that the Windows NT loader limits the Number of Sections to 96. Offset 0 Size 2 Field Machine Description Number identifying type of target machine. See Section 3.3.1, Machine Types, for more information. Number of sections; indicates size of the Section Table, which immediately follows the headers. Time and date the file was created. File offset of the COFF symbol table or 0 if none is present. Number of entries in the symbol table. This data can be used in locating the string table, which immediately follows the symbol table. Size of the optional header, which is required for executable files but not for object files. An object file should have a value of 0 here. The format is described in the section Optional Header.

NumberOfSections

4 8 12

4 4 4

TimeDateStamp PointerToSymbolTable NumberOfSymbols

16

SizeOfOptionalHeader

18

Characteristics

Flags indicating attributes of the file. See Section 3.3.2, Characteristics, for specific flag values.

3.3.1. Machine Types

The Machine field has one of the following values, defined below, which specify its machine (CPU) type. An image file can be run only on the specified machine, or a system emulating it. Constant
IMAGE_FILE_MACHINE_UNKNOWN

Value 0x0 0x184 0x1c0 0x284 0x14c 0x200 0x268 0x266 0x366 0x466 0x1f0 0x162 0x166 0x168 0x1a2 0x1a6 0x1c2

Description Contents assumed to be applicable to any machine type. Alpha AXP.

IMAGE_FILE_MACHINE_ALPHA IMAGE_FILE_MACHINE_ARM IMAGE_FILE_MACHINE_ALPHA64 IMAGE_FILE_MACHINE_I386 IMAGE_FILE_MACHINE_IA64 IMAGE_FILE_MACHINE_M68K IMAGE_FILE_MACHINE_MIPS16 IMAGE_FILE_MACHINE_MIPSFPU IMAGE_FILE_MACHINE_MIPSFPU16 IMAGE_FILE_MACHINE_POWERPC IMAGE_FILE_MACHINE_R3000 IMAGE_FILE_MACHINE_R4000 IMAGE_FILE_MACHINE_R10000 IMAGE_FILE_MACHINE_SH3 IMAGE_FILE_MACHINE_SH4 IMAGE_FILE_MACHINE_THUMB

Alpha AXP 64-bit. Intel 386 or later, and compatible processors. Intel IA64 Motorola 68000 series.

MIPS with FPU MIPS16 with FPU Power PC, little endian.

MIPS little endian.

Hitachi SH3 Hitachi SH4

3.3.2. Characteristics
The Characteristics field contains flags that indicate attributes of the object or image file. The following flags are currently defined: Flag
IMAGE_FILE_RELOCS_STRIPPED

Value 0x0001

Description Image only, Windows CE, Windows NT and above. Indicates that the file does not contain base relocations and must therefore be loaded at its preferred base address. If the base address is not available, the loader reports an error. Operating systems running on top of MS-DOS (Win32s) are generally not able to use the preferred base address and so cannot run these images. However, beginning with version 4.0, Windows will use an applications preferred base address. The default behavior of the linker is to strip base relocations from EXEs. Image only. Indicates that the image file is valid and can be run. If this flag is not set, it generally indicates a linker error. COFF line numbers have been removed. COFF symbol table entries for local symbols have been removed. Aggressively trim working set. App can handle > 2gb addresses. Use of this flag is reserved for future use. Little endian: LSB precedes MSB in memory. Machine based on 32-bit-word architecture. Debugging information removed from image file. If image is on removable media, copy and run from swap file. The image file is a system file, not a user program.

IMAGE_FILE_EXECUTABLE_IMAGE

0x0002

IMAGE_FILE_LINE_NUMS_STRIPPED

0x0004 0x0008 0x0010 0x0020 0x0040 0x0080 0x0100 0x0200 0x0400 0x1000

IMAGE_FILE_LOCAL_SYMS_STRIPPED

IMAGE_FILE_AGGRESSIVE_WS_TRIM IMAGE_FILE_LARGE_ADDRESS_AWARE IMAGE_FILE_16BIT_MACHINE

IMAGE_FILE_BYTES_REVERSED_LO

IMAGE_FILE_32BIT_MACHINE

IMAGE_FILE_DEBUG_STRIPPED

IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP

IMAGE_FILE_SYSTEM

IMAGE_FILE_DLL

0x2000

The image file is a dynamic-link library (DLL). Such files are considered executable files for almost all purposes, although they cannot be directly run. File should be run only on a UP machine. Big endian: MSB precedes LSB in memory.

IMAGE_FILE_UP_SYSTEM_ONLY

0x4000 0x8000

IMAGE_FILE_BYTES_REVERSED_HI

3.4. Optional Header (Usually Image Only)

Every image file has an Optional Header that provides information to the loader. This header is also referred to the PE Header. This header is optional in the sense that some files (specifically, object files) do not have it. For image files, this header is required. An object file may have an optional header, but generally this header has no function in an object file except to increase size. Note that the size of the optional header is not fixed. The Optional Header Size in the COFF Header (see Section 3.3 COFF File Header (Object & Image)) must be used in conjunction with the Optional Headers Number of Data Directories field to accurately calculate the size of the header. In addition, it is important to validate the Optional Headers Magic number for format compatibility. The Optional Headers Magic number determines whether an image is a PE32 or PE32+ executable: Magic Number 0x10b 0x20b PE Format PE32 PE32+

PE32+ images allow for a 64-bit address space while limiting the image size to 4 Gigabytes. Other PE32+ modifications are addressed in their respective sections. The Optional Header itself has three major parts: Offset
(PE32/PE32+)

Size
(PE32/PE32+)

Header part Standard fields Windows specific fields Data directories

Description These are defined for all implementations of COFF, including UNIX. These include additional fields to support specific features of Windows (for example, subsystem). These fields are address/size pairs for special tables, found in the image file and used by the operating system (for example, Import Table and Export Table).

0 28/24

28/24 68 / 88

96/112

Variable

3.4.1. Optional Header Standard Fields (Image Only)

The first eight fields of the Optional Header are standard fields, defined for every implementation of COFF. These fields contain general information useful for loading and running an executable file, and are unchanged for the PE32+ format. Offset 0 Size 2 Field Magic Description Unsigned integer identifying the state of the image file. The most common number is 0413 octal (0x10B), identifying it as a normal executable file. 0407 (0x107) identifies a ROM image. Linker major version number. Linker minor version number. Size of the code (text) section, or the sum of all code sections if there are multiple sections. Size of the initialized data section, or the sum of all such sections if there are multiple data sections. Size of the uninitialized data section (BSS), or the sum of all such sections if there are multiple BSS sections. Address of entry point, relative to image base, when executable file is loaded into memory. For program images, this is the starting address. For device drivers, this is the address of the initialization function. An entry point is optional for DLLs. When none is present this field should be 0. Address, relative to image base, of beginning of code section, when loaded into memory.

2 3 4

1 1 4

MajorLinkerVersion MinorLinkerVersion SizeOfCode

SizeOfInitializedData

12

SizeOfUninitializedData

16

AddressOfEntryPoint

20

BaseOfCode

PE32 contains this additional field, absent in PE32+, following BaseOfCode: 24 4 BaseOfData Address, relative to image base, of beginning of data section, when loaded into memory.

3.4.2. Optional Header Windows NT-Specific Fields (Image Only)

The next twenty-one fields are an extension to the COFF Optional Header format and contain additional information needed by the linker and loader in Windows NT. Offset
(PE32/PE32+)

Size
(PE32/PE32+)

Field ImageBase

Description Preferred address of first byte of image when loaded into memory; must be a multiple of 64K. The default for DLLs is 0x10000000. The default for Windows CE EXEs is 0x00010000. The default for Windows NT, Windows 95, and Windows 98 is 0x00400000. Alignment (in bytes) of sections when loaded into memory. Must greater or equal to File Alignment. Default is the page size for the architecture. Alignment factor (in bytes) used to align the raw data of sections in the image file. The value should be a power of 2 between 512 and 64K inclusive. The default is 512. If the SectionAlignment is less than the architectures page size than this must match the SectionAlignment. Major version number of required OS. Minor version number of required OS. Major version number of image. Minor version number of image. Major version number of subsystem. Minor version number of subsystem. dd Size, in bytes, of image, including all headers; must be a multiple of Section Alignment. Combined size of MS-DOS stub, PE Header, and section headers rounded up to a multiple of FileAlignment.

28 / 24

4/8

32 / 32

SectionAlignment

36 / 36

FileAlignment

40 / 40 42 / 42 44 / 44 46 / 46 48 / 48 50 / 50 52 / 52 56 / 56

2 2 2 2 2 2 4 4

MajorOperatingSystem Version MinorOperatingSystem Version MajorImageVersion MinorImageVersion MajorSubsystemVersion MinorSubsystemVersion Reserved SizeOfImage

60 / 60

SizeOfHeaders

64 / 64

CheckSum

Image file checksum. The algorithm for computing is incorporated into IMAGHELP.DLL. The following are checked for validation at load time: all drivers, any DLL loaded at boot time, and any DLL that ends up in the server. Subsystem required to run this image. See Windows NT Subsystem below for more information. See DLL Characteristics below for more information. Size of stack to reserve. Only the Stack Commit Size is committed; the rest is made available one page at a time, until reserve size is reached. Size of stack to commit. Size of local heap space to reserve. Only the Heap Commit Size is committed; the rest is made available one page at a time, until reserve size is reached. Size of local heap space to commit. Obsolete. Number of data-dictionary entries in the remainder of the Optional Header. Each describes a location and size.

68 / 68

Subsystem

70 / 70 72 / 72

2 4/8

DLL Characteristics SizeOfStackReserve

76 / 80 80 / 88

4/8 4/8

SizeOfStackCommit SizeOfHeapReserve

84 / 96 88 / 104 92 / 108

4/8 4 4

SizeOfHeapCommit LoaderFlags NumberOfRvaAndSizes

Windows NT Subsystem
The following values are defined for the Subsystem field of the Optional Header. They determine what, if any, Windows NT subsystem is required to run the image. Constant
IMAGE_SUBSYSTEM_UNKNOWN IMAGE_SUBSYSTEM_NATIVE

Value 0 1 2 3 7 9 10 11

Description Unknown subsystem. Used for device drivers and native Windows NT processes. Image runs in the Windows graphical user interface (GUI) subsystem. Image runs in the Windows character subsystem. Image runs in the Posix character subsystem. Image runs in on Windows CE. Image is an EFI application. Image is an EFI driver that provides boot services. Image is an EFI driver that provides runtime services.

IMAGE_SUBSYSTEM_WINDOWS_GUI

IMAGE_SUBSYSTEM_WINDOWS_CUI

IMAGE_SUBSYSTEM_POSIX_CUI

IMAGE_SUBSYSTEM_WINDOWS_CE_GUI IMAGE_SUBSYSTEM_EFI_APPLICATION IMAGE_SUBSYSTEM_EFI_BOOT_SERVICE_ DRIVER IMAGE_SUBSYSTEM_EFI_RUNTIME_DRIVER

12

DLL Characteristics
The following values are defined for the DLLCharacteristics field of the Optional Header. Constant Value 0x0001 0x0002 0x0004 0x0008
IMAGE_DLLCHARACTERISTICS_NO_BIND IMAGE_DLLCHARACTERISTICS_WDM_DRIVER IMAGE_DLLCHARACTERISTICS_TERMINAL_SERVER_ AWARE

Description Reserved Reserved Reserved Reserved Do not bind image Driver is a WDM Driver Image is Terminal Server aware

0x0800 0x2000 0x8000

3.4.3. Optional Header Data Directories (Image Only)

Each data directory gives the address and size of a table or string used by Windows NT. These are all loaded into memory so that they can be used by the system at run time. A data directory is an eight-byte field that has the following declaration:
typedef struct _IMAGE_DATA_DIRECTORY { DWORD RVA; DWORD Size; } IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;

The first field, RVA, is the relative virtual address of the table. The RVA is the address of the table, when loaded, relative to the base address of the image. The second field gives the size in bytes. The data directories, which form the last part of the Optional Header, are listed below. Note that the number of directories is not fixed. The NumberOfRvaAndSizes field in the optional header should be checked before looking for a specific directory. Do not assume that the RVAs given in this table point to the beginning of a section or that the sections containing specific tables have specific names. Offset
(PE/PE32+)

Size 8 8 8 8 8 8 8 8 8

Field Export Table Import Table Resource Table Exception Table Certificate Table Base Relocation Table Debug Architecture Global Ptr

Description Export Table address and size. Import Table address and size Resource Table address and size. Exception Table address and size. Attribute Certificate Table address and size. Base Relocation Table address and size. Debug data starting address and size. Architecture-specific data address and size. Relative virtual address of the value to be stored in the global pointer register. Size member of this structure must be set to 0. Thread Local Storage (TLS) Table address and size. Load Configuration Table address and size. Bound Import Table address and size. Import Address Table address and size. Address and size of the Delay Import Descriptor. COM+ Runtime Header address and size

96/112 104/120 112/128 120/136 128/144 136/152 144/160 152/168 160/176

168/184 176/192 184/200 192/208 200/216 208/224 216/232

8 8 8 8 8 8 8

TLS Table Load Config Table Bound Import IAT Delay Import Descriptor COM+ Runtime Header Reserved

The Certificate Table entry points to a table of attribute certificates. These certificates are not loaded into memory as part of the image. As such, the first field of this entry, which is normally an RVA, is a File Pointer instead.

4. Section Table (Section Headers)

Each row of the Section Table, in effect, is a section header. This table immediately follows the optional header, if any. This positioning is required because the file header does not contain a direct pointer to the section table; the location of the section table is determined by calculating the location of the first byte after the headers. Make sure to use the size of the optional header as specified in the file header. The number of entries in the Section Table is given by the NumberOfSections field in the file header. Entries in the Section Table are numbered starting from one. The code and data memory section entries are in the order chosen by the linker. In an image file, the virtual addresses for sections must be assigned by the linker such that they are in ascending order and adjacent, and they must be a multiple of the Section Align value in the optional header. Each section header (Section Table entry) has the following format, for a total of 40 bytes per entry: Offset 0 Size 8 Field Name Description An 8-byte, null-padded ASCII string. There is no terminating null if the string is exactly eight characters long. For longer names, this field contains a slash (/) followed by ASCII representation of a decimal number: this number is an offset into the string table. Executable images do not use a string table and do not support section names longer than eight characters. Long names in object files will be truncated if emitted to an executable file. Total size of the section when loaded into memory. If this value is greater than Size of Raw Data, the section is zero-padded. This field is valid only for executable images and should be set to 0 for object files. For executable images this is the address of the first byte of the section, when loaded into memory, relative to the image base. For object files, this field is the address of the first byte before relocation is applied; for simplicity, compilers should set this to zero. Otherwise, it is an arbitrary value that is subtracted from offsets during relocation.

VirtualSize

12

VirtualAddress

16

SizeOfRawData

Size of the section (object file) or size of the initialized data on disk (image files). For executable image, this must be a multiple of FileAlignment from the optional header. If this is less than VirtualSize the remainder of the section is zero filled. Because this field is rounded while the VirtualSize field is not it is possible for this to be greater than VirtualSize as well. When a section contains only uninitialized data, this field should be 0. File pointer to sections first page within the COFF file. For executable images, this must be a multiple of FileAlignment from the optional header. For object files, the value should be aligned on a fourbyte boundary for best performance. When a section contains only uninitialized data, this field should be 0. File pointer to beginning of relocation entries for the section. Set to 0 for executable images or if there are no relocations. File pointer to beginning of line-number entries for the section. Set to 0 if there are no COFF line numbers. Number of relocation entries for the section. Set to 0 for executable images. Number of line-number entries for the section. Flags describing sections characteristics. See Section 4.1, Section Flags, for more information.

20

PointerToRawData

24

PointerToRelocati ons PointerToLinenum bers NumberOfRelocati ons NumberOfLinenu mbers Characteristics

28

32 34 36

2 2 4

4.1. Section Flags

The Section Flags field indicates characteristics of the section. Flag
IMAGE_SCN_TYPE_REG IMAGE_SCN_TYPE_DSECT IMAGE_SCN_TYPE_NOLOAD IMAGE_SCN_TYPE_GROUP IMAGE_SCN_TYPE_NO_PAD

Value 0x00000000 0x00000001 0x00000002 0x00000004 0x00000008

Description Reserved for future use. Reserved for future use. Reserved for future use. Reserved for future use. Section should not be padded to next boundary. This is obsolete and replaced by IMAGE_SCN_ALIGN_1BYTES. This is valid for object files only.

IMAGE_SCN_TYPE_COPY IMAGE_SCN_CNT_CODE IMAGE_SCN_CNT_INITIALIZED_DATA IMAGE_SCN_CNT_UNINITIALIZED_DATA IMAGE_SCN_LNK_OTHER IMAGE_SCN_LNK_INFO

0x00000010 0x00000020 0x00000040 0x00000080 0x00000100 0x00000200

Reserved for future use. Section contains executable code. Section contains initialized data. Section contains uninitialized data. Reserved for future use. Section contains comments or other information. The .drectve section has this type. This is valid for object files only. Reserved for future use. Section will not become part of the image. This is valid for object files only. Section contains COMDAT data. See Section 5.5.6, COMDAT Sections, for more information. This is valid for object files only. Reserved for future use. Reserved for future use. Reserved for future use. Reserved for future use. Reserved for future use. Align data on a 1-byte boundary. This is valid for object files only. Align data on a 2-byte boundary. This is valid for object files only. Align data on a 4-byte boundary. This is valid for object files only. Align data on a 8-byte boundary. This is valid for object files only. Align data on a 16-byte boundary. This is valid for object files only. Align data on a 32-byte boundary. This is valid for object files only. Align data on a 64-byte boundary. This is valid for object files only. Align data on a 128-byte boundary. This is valid for object files only.

IMAGE_SCN_TYPE_OVER IMAGE_SCN_LNK_REMOVE

0x00000400 0x00000800

IMAGE_SCN_LNK_COMDAT

0x00001000

IMAGE_SCN_MEM_FARDATA IMAGE_SCN_MEM_PURGEABLE IMAGE_SCN_MEM_16BIT IMAGE_SCN_MEM_LOCKED IMAGE_SCN_MEM_PRELOAD IMAGE_SCN_ALIGN_1BYTES

0x00008000 0x00020000 0x00020000 0x00040000 0x00080000 0x00100000 0x00200000 0x00300000 0x00400000 0x00500000 0x00600000 0x00700000 0x00800000

IMAGE_SCN_ALIGN_2BYTES

IMAGE_SCN_ALIGN_4BYTES

IMAGE_SCN_ALIGN_8BYTES

IMAGE_SCN_ALIGN_16BYTES

IMAGE_SCN_ALIGN_32BYTES

IMAGE_SCN_ALIGN_64BYTES

IMAGE_SCN_ALIGN_128BYTES

IMAGE_SCN_ALIGN_256BYTES

0x00900000 0x00A00000 0x00B00000 0x00C00000 0x00D00000 0x00E00000 0x01000000 0x02000000 0x04000000 0x08000000 0x10000000 0x20000000 0x40000000 0x80000000

Align data on a 256-byte boundary. This is valid for object files only. Align data on a 512-byte boundary. This is valid for object files only. Align data on a 1024-byte boundary. This is valid for object files only. Align data on a 2048-byte boundary. This is valid for object files only. Align data on a 4096-byte boundary. This is valid for object files only. Align data on a 8192-byte boundary. This is valid for object files only. Section contains extended relocations. Section can be discarded as needed. Section cannot be cached. Section is not pageable. Section can be shared in memory. Section can be executed as code. Section can be read. Section can be written to.

IMAGE_SCN_ALIGN_512BYTES

IMAGE_SCN_ALIGN_1024BYTES

IMAGE_SCN_ALIGN_2048BYTES

IMAGE_SCN_ALIGN_4096BYTES

IMAGE_SCN_ALIGN_8192BYTES

IMAGE_SCN_LNK_NRELOC_OVFL

IMAGE_SCN_MEM_DISCARDABLE IMAGE_SCN_MEM_NOT_CACHED IMAGE_SCN_MEM_NOT_PAGED IMAGE_SCN_MEM_SHARED IMAGE_SCN_MEM_EXECUTE IMAGE_SCN_MEM_READ IMAGE_SCN_MEM_WRITE

IMAGE_SCN_LNK_NRELOC_OVFL indicates that the count of relocations for the section exceeds the 16 bits reserved for it in section header. If the bit is set and the NumberOfRelocations field in the section header is 0xffff, the actual relocation count is stored in the 32-bit VirtualAddress field of the first relocation.

4.2. Grouped Sections (Object Only)

The $ character (dollar sign) has a special interpretation in section names in object files. When determining the image section that will contain the contents of an object section, the linker discards the $ and all characters following it. Thus, an object section named .text$X will actually contribute to the .text section in the image. However, the characters following the $ determine the ordering of the contributions to the image section. All contributions with the same object-section name will be allocated contiguously in the image, and the blocks of contributions will be sorted in lexical order by object-section name. Therefore, everything in object files with section name .text$X will end up together, after the .text$W contributions and before the .text$Y contributions. The section name in an image file will never contain a $ character.

5. Other Contents of the File

The data structures described so far, up to and including the optional header, are all located at a fixed offset from the beginning of the file (or from the PE header if the file is an image containing an MS-DOS stub). The remainder of a COFF object or image file contains blocks of data that are not necessarily at any specific file offset. Instead the locations are defined by pointers in the Optional Header or a section header. An exception is for images with a Section Alignment value (see the Optional Header description) of less than the page size of the architecture (4K for Intel x86 and for MIPS; 8K for Alpha). In this case there are constraints on the file offset of the section data, as described in the next section. Another exception is that attribute certificate and debug information must be placed at the very end of an image file (with the attribute certificate table immediately preceding the debug section), because the loader does not map these into memory. The rule on attribute certificate and debug information does not apply to object files, however.

5.1. Section Data

Initialized data for a section consists of simple blocks of bytes. However, for sections containing all zeros, the section data need not be included. The data for each section is located at the file offset given by the PointerToRawData field in the section header, and the size of this data in the file is indicated by the SizeOfRawData field. If the SizeOfRawData is less than the VirtualSize, the remainder is padded with zeros. In an image file, the section data must be aligned on a boundary as specified by the FileAlignment field in the optional header. Section data must appear in order of the RVA values for the corresponding sections (as do the individual section headers in the Section Table). There are additional restrictions on image files for which the Section Align value in the Optional Header is less than the page size of the architecture. For such files, the location of section data in the file must match its location in memory when the image is loaded, so that the physical offset for section data is the same as the RVA.

5.2. COFF Relocations (Object Only)

Object files contain COFF relocations, which specify how the section data should be modified when placed in the image file and subsequently loaded into memory. Image files do not contain COFF relocations, because all symbols referenced have already been assigned addresses in a flat address space. An image contains relocation information in the form of base relocations in the .reloc section (unless the image has the IMAGE_FILE_RELOCS_STRIPPED attribute). See Section 6.5 for more information.

For each section in an object file, there is an array of fixed-length records that are the sections COFF relocations. The position and length of the array are specified in the section header. Each element of the array has the following format: Offset 0 Size 4 Field VirtualAddress Description Address of the item to which relocation is applied: this is the offset from the beginning of the section, plus the value of the sections RVA/Offset field (see Section 4, Section Table.). For example, if the first byte of the section has an address of 0x10, the third byte has an address of 0x12. A zero-based index into the symbol table. This symbol gives the address to be used for the relocation. If the specified symbol has section storage class, then the symbols address is the address with the first section of the same name. A value indicating what kind of relocation should be performed. Valid relocation types depend on machine type. See Section 5.2.1, Type Indicators.

SymbolTableInd ex

Type

If the symbol referred to (by the SymbolTableIndex field) has storage class IMAGE_SYM_CLASS_SECTION, the symbols address is the beginning of the section. The section is usually in the same file, except when the object file is part of an archive (library). In that case, the section may be found in any other object file in the archive that has the same archive-member name as the current object file. (The relationship with the archive-member name is used in the linking of import tables, i.e. the .idata section.)

5.2.1. Type Indicators

The Type field of the relocation record indicates what kind of relocation should be performed. Different relocation types are defined for each type of machine.

Intel 386
The following relocation type indicators are defined for Intel386 and compatible processors: Constant
IMAGE_REL_I386_ABSOLUTE IMAGE_REL_I386_DIR16 IMAGE_REL_I386_REL16 IMAGE_REL_I386_DIR32 IMAGE_REL_I386_DIR32NB IMAGE_REL_I386_SEG12 IMAGE_REL_I386_SECTION

Value 0x0000 0x0001 0x0002 0x0006 0x0007 0x0009 0x000A

Description This relocation is ignored. Not supported. Not supported. The targets 32-bit virtual address. The targets 32-bit relative virtual address. Not supported. The 16-bit-section index of the section containing the target. This is used to support debugging information.

IMAGE_REL_I386_SECREL

0x000B

The 32-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. The 32-bit relative displacement to the target. This supports the x86 relative branch and call instructions.

IMAGE_REL_I386_REL32

0x0014

MIPS Processors
The following relocation type indicators are defined for MIPS processors: Constant
IMAGE_REL_MIPS_ABSOLUTE IMAGE_REL_MIPS_REFHALF

Value 0x0000 0x0001 0x0002 0x0003 0x0004

Description This relocation is ignored. The high 16 bits of the targets 32-bit virtual address. The targets 32-bit virtual address. The low 26 bits of the targets virtual address. This supports the MIPS J and JAL instructions. The high 16 bits of the targets 32-bit virtual address. Used for the first instruction in a twoinstruction sequence that loads a full address. This relocation must be immediately followed by a PAIR relocations whose SymbolTableIndex contains a signed 16-bit displacement which is added to the upper 16 bits taken from the location being relocated. The low 16 bits of the targets virtual address. 16-bit signed displacement of the target relative to the Global Pointer (GP) register. Same as IMAGE_REL_MIPS_GPREL. The 16-bit section index of the section containing the target. This is used to support debugging information. The 32-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. The low 16 bits of the 32-bit offset of the target from the beginning of its section.

IMAGE_REL_MIPS_REFWORD IMAGE_REL_MIPS_JMPADDR

IMAGE_REL_MIPS_REFHI

IMAGE_REL_MIPS_REFLO IMAGE_REL_MIPS_GPREL

0x0005 0x0006 0x0007 0x000A

IMAGE_REL_MIPS_LITERAL IMAGE_REL_MIPS_SECTION

IMAGE_REL_MIPS_SECREL

0x000B

IMAGE_REL_MIPS_SECRELLO

0x000C

IMAGE_REL_MIPS_SECRELHI

0x000D

The high 16 bits of the 32-bit offset of the target from the beginning of its section. A PAIR relocation must immediately follow this on. The SymbolTableIndex of the PAIR relocation contains a signed 16-bit displacement, which is added to the upper 16 bits taken from the location being relocated. The low 26 bits of the targets virtual address. This supports the MIPS16 JAL instruction. The targets 32-bit relative virtual address. This relocation is only valid when it immediately follows a REFHI or SECRELHI relocation. Its SymbolTableIndex contains a displacement and not an index into the symbol table.

IMAGE_REL_MIPS_JMPADDR16

0x0010 0x0022 0x0025

IMAGE_REL_MIPS_REFWORDNB IMAGE_REL_MIPS_PAIR

Alpha Processors
The following relocation Type indicators are defined for Alpha processors: Constant
IMAGE_REL_ALPHA_ABSOLUTE IMAGE_REL_ALPHA_REFLONG

Value 0x0000 0x0001

Description This relocation is ignored. The targets 32-bit virtual address. This fixup is illegal in a PE32+ image unless the image has been sandboxed by clearing the IMAGE_FILE_LARGE_ADDRESS_AWARE bit in the File Header. The targets 64-bit virtual address. 32-bit signed displacement of the target relative to the Global Pointer (GP) register. 16-bit signed displacement of the target relative to the Global Pointer (GP) register. Reserved for future use. Reserved for future use. The 21-bit relative displacement to the target. This supports the Alpha relative branch instructions. 14-bit hints to the processor for the target of an Alpha jump instruction.

IMAGE_REL_ALPHA_REFQUAD IMAGE_REL_ALPHA_GPREL32

0x0002 0x0003 0x0004 0x0005 0x0006 0x0007

IMAGE_REL_ALPHA_LITERAL

IMAGE_REL_ALPHA_LITUSE IMAGE_REL_ALPHA_GPDISP IMAGE_REL_ALPHA_BRADDR

IMAGE_REL_ALPHA_HINT

0x0008

IMAGE_REL_ALPHA_INLINE_REFL ONG

0x0009

The targets 32-bit virtual address split into high and low 16-bit parts. Either an ABSOLUTE or MATCH relocation must immediately follow this relocation. The high 16 bits of the target address are stored in the location identified by the INLINE_REFLONG relocation. The low 16 bits are stored four bytes later if the following relocation is of type ABSOLUTE or at a signed displacement given in the SymbolTableIndex if the following relocation is of type MATCH. The high 16 bits of the targets 32-bit virtual address. Used for the first instruction in a twoinstruction sequence that loads a full address. This relocation must be immediately followed by a PAIR relocations whose SymbolTableIndex contains a signed 16-bit displacement which is added to the upper 16 bits taken from the location being relocated. The low 16 bits of the targets virtual address. This relocation is only valid when it immediately follows a REFHI , REFQ3, REFQ2, or SECRELHI relocation. Its SymbolTableIndex contains a displacement and not an index into the symbol table. This relocation is only valid when it immediately follows INLINE_REFLONG relocation. Its SymbolTableIndex contains the displacement in bytes of the location for the matching low address and not an index into the symbol table. The 16-bit section index of the section containing the target. This is used to support debugging information. The 32-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. The targets 32-bit relative virtual address. The low 16 bits of the 32-bit offset of the target from the beginning of its section.

IMAGE_REL_ALPHA_REFHI

0x000A

IMAGE_REL_ALPHA_REFLO IMAGE_REL_ALPHA_PAIR

0x000B 0x000C

IMAGE_REL_ALPHA_MATCH

0x000D

IMAGE_REL_ALPHA_SECTION

0x000E

IMAGE_REL_ALPHA_SECREL

0x000F

IMAGE_REL_ALPHA_REFLONGNB IMAGE_REL_ALPHA_SECRELLO

0x0010 0x0011

IMAGE_REL_ALPHA_SECRELHI

0x0012

The high 16 bits of the 32-bit offset of the target from the beginning of its section. A PAIR relocation must immediately follow this on. The SymbolTableIndex of the PAIR relocation contains a signed 16-bit displacement which is added to the upper 16 bits taken from the location being relocated. The low 16 bits of the high 32 bits of the targets 64-bit virtual address. This relocation must be immediately followed by a PAIR relocations whose SymbolTableIndex contains a signed 32bit displacement which is added to the 16 bits taken from the location being relocated. The 16 bits in the relocated location are shifted left by 32 before this addition. The high 16 bits of the low 32 bits of the targets 64-bit virtual address. This relocation must be immediately followed by a PAIR relocations whose SymbolTableIndex contains a signed 16bit displacement which is added to the upper 16 bits taken from the location being relocated. The low 16 bits of the targets 64-bit virtual address. The low 16 bits of the 32-bit signed displacement of the target relative to the Global Pointer (GP) register. The high 16 bits of the 32-bit signed displacement of the target relative to the Global Pointer (GP) register.

IMAGE_REL_ALPHA_REFQ3

0x0013

IMAGE_REL_ALPHA_REFQ2

0x0014

IMAGE_REL_ALPHA_REFQ1

0x0015 0x0016

IMAGE_REL_ALPHA_GPRELLO

IMAGE_REL_ALPHA_GPRELHI

0x0017

IBM PowerPC Processors

The following relocation Type indicators are defined for PowerPC processors: Constant
IMAGE_REL_PPC_ABSOLUTE IMAGE_REL_PPC_ADDR64 IMAGE_REL_PPC_ADDR32 IMAGE_REL_PPC_ADDR24

Value 0x0000 0x0001 0x0002 0x0003

Description This relocation is ignored. The targets 64-bit virtual address. The targets 32-bit virtual address. The low 24 bits of the targets virtual address. This is only valid when the target symbol is absolute and can be sign extended to its original value. The low 16 bits of the targets virtual address.

IMAGE_REL_PPC_ADDR16

0x0004

IMAGE_REL_PPC_ADDR14

0x0005

The low 14 bits of the targets virtual address. This is only valid when the target symbol is absolute and can be sign extended to its original value. A 24-bit PC-relative offset to the symbols location. A 14-bit PC-relative offset to the symbols location. The targets 32-bit relative virtual address. The 32-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. The 16-bit section index of the section containing the target. This is used to support debugging information. The 16-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. The high 16 bits of the targets 32-bit virtual address. Used for the first instruction in a two-instruction sequence that loads a full address. This relocation must be immediately followed by a PAIR relocations whose SymbolTableIndex contains a signed 16-bit displacement which is added to the upper 16 bits taken from the location being relocated. The low 16 bits of the targets virtual address. This relocation is only valid when it immediately follows a REFHI or SECRELHI relocation. Its SymbolTableIndex contains a displacement and not an index into the symbol table. The low 16 bits of the 32-bit offset of the target from the beginning of its section. The high 16 bits of the 32-bit offset of the target from the beginning of its section. A PAIR relocation must immediately follow this on. The SymbolTableIndex of the PAIR relocation contains a signed 16-bit displacement which is added to the upper 16 bits taken from the location being relocated. 16-bit signed displacement of the target relative to the Global Pointer (GP) register.

IMAGE_REL_PPC_REL24 IMAGE_REL_PPC_REL14 IMAGE_REL_PPC_ADDR32NB IMAGE_REL_PPC_SECREL

0x0006 0x0007 0x000A 0x000B

IMAGE_REL_PPC_SECTION

0x000C

IMAGE_REL_PPC_SECREL16

0x000F

IMAGE_REL_PPC_REFHI

0x0010

IMAGE_REL_PPC_REFLO IMAGE_REL_PPC_PAIR

0x0011 0x0012

IMAGE_REL_PPC_SECRELLO

0x0013 0x0014

IMAGE_REL_PPC_SECRELHI

IMAGE_REL_PPC_GPREL

0x0015

Hitachi SuperH Processors

The following relocation type indicators are defined for SH3 and SH4 processors: Constant
IMAGE_REL_SH3_ABSOLUTE IMAGE_REL_SH3_DIRECT16

Value 0x0000 0x0001 0x0002 0x0003 0x0004

Description This relocation is ignored. Reference to the 16-bit location that contains the virtual address of the target symbol. The targets 32-bit virtual address. Reference to the 8-bit location that contains the virtual address of the target symbol. Reference to the 8-bit instruction that contains the effective 16-bit virtual address of the target symbol. Reference to the 8-bit instruction that contains the effective 32-bit virtual address of the target symbol. Reference to the 8-bit location whose low 4 bits contain the virtual address of the target symbol. Reference to the 8-bit instruction whose low 4 bits contain the effective 16-bit virtual address of the target symbol. Reference to the 8-bit instruction whose low 4 bits contain the effective 32-bit virtual address of the target symbol. Reference to the 8-bit instruction which contains the effective 16-bit relative offset of the target symbol. Reference to the 8-bit instruction which contains the effective 32-bit relative offset of the target symbol. Reference to the 16-bit instruction whose low 12 bits contain the effective 16-bit relative offset of the target symbol. Reference to a 32-bit location that is the virtual address of the symbols section. Reference to the 32-bit location that is the size of the symbols section. The 16-bit section index of the section containing the target. This is used to support debugging information.

IMAGE_REL_SH3_DIRECT32 IMAGE_REL_SH3_DIRECT8

IMAGE_REL_SH3_DIRECT8_WORD

IMAGE_REL_SH3_DIRECT8_LONG

0x0005

IMAGE_REL_SH3_DIRECT4

0x0006

IMAGE_REL_SH3_DIRECT4_WORD

0x0007

IMAGE_REL_SH3_DIRECT4_LONG

0x0008

IMAGE_REL_SH3_PCREL8_WORD

0x0009

IMAGE_REL_SH3_PCREL8_LONG

0x000A

IMAGE_REL_SH3_PCREL12_WORD

0x000B

IMAGE_REL_SH3_STARTOF_SECTION

0x000C 0x000D 0x000E

IMAGE_REL_SH3_SIZEOF_SECTION

IMAGE_REL_SH3_SECTION

IMAGE_REL_SH3_SECREL

0x000F

The 32-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage. The targets 32-bit relative virtual address.

IMAGE_REL_SH3_DIRECT32_NB

0x0010

ARM Processors
The following relocation Type indicators are defined for ARM processors: Constant
IMAGE_REL_ARM_ABSOLUTE IMAGE_REL_ARM_ADDR32 IMAGE_REL_ARM_ADDR32NB IMAGE_REL_ARM_BRANCH24 IMAGE_REL_ARM_BRANCH11

Value 0x0000 0x0001 0x0002 0x0003 0x0004 0x000E

Description This relocation is ignored. The targets 32-bit virtual address. The targets 32-bit relative virtual address. The 24-bit relative displacement to the target. Reference to a subroutine call, consisting of two 16-bit instructions with 11-bit offsets. The 16-bit section index of the section containing the target. This is used to support debugging information. The 32-bit offset of the target from the beginning of its section. This is used to support debugging information as well as static thread local storage.

IMAGE_REL_ARM_SECTION

IMAGE_REL_ARM_SECREL

0x000F

5.3. COFF Line Numbers

COFF line numbers indicate the relationship between code and line-numbers in source files. The Microsoft format for COFF line numbers is similar to standard COFF, but it has been extended to allow a single section to relate to line numbers in multiple source files. COFF line numbers consist of an array of fixed-length records. The location (file offset) and size of the array are specified in the section header. Each line-number record is of the following format: Offset 0 Size 4 Field Type (*) Description Union of two fields: Symbol Table Index and RVA. Whether Symbol Table Index or RVA is used depends on the value of Linenumber. When nonzero, this field specifies a one-based line number. When zero, the Type field is interpreted as a Symbol Table Index for a function.

Linenumber

The Type field is a union of two four-byte fields, Symbol Table Index, and RVA: Offset 0 Size 4 Field SymbolTableIndex Description Used when Linenumber is 0: index to symbol table entry for a function. This format is used to indicate the function that a group of line-number records refer to. Used when Linenumber is non-zero: relative virtual address of the executable code that corresponds to the source line indicated. In an object file, this contains the virtual address within the section.

VirtualAddress

A line-number record, then, can either set the Linenumber field to 0 and point to a function definition in the Symbol Table, or else it can work as a standard line-number entry by giving a positive integer (line number) and the corresponding address in the object code. A group of line-number entries always begins with the first format: the index of a function symbol. If this is the first line-number record in the section, then it is also the COMDAT symbol name for the function if the sections COMDAT flag is set. (See Section 5.5.6, COMDAT Sections.) The functions auxiliary record in the Symbol Table has a Pointer to Linenumbers field that points to this same line-number record. A record identifying a function is followed by any number of line-number entries that give actual line-number information (Linenumber greater than zero). These entries are one-based, relative to the beginning of the function, and represent every source line in the function except for the first one. For example, the first line-number record for the following example would specify the ReverseSign function (Symbol Table Index of ReverseSign, Linenumber set to 0). Then records with Linenumber values of 1, 2, and 3 would follow, corresponding to source lines as shown:
// some code precedes ReverseSign function int ReverseSign(int i) 1: { 2: return -1 * i; 3: }

5.4. COFF Symbol Table

The Symbol Table described in this section is inherited from the traditional COFF format. It is distinct from CodeView information. A file may contain both a COFF Symbol Table and CodeView debug information, and the two are kept separate. Some Microsoft tools use the Symbol Table for limited but important purposes, such as communicating COMDAT information to the linker. Section names and file names, as well as code and data symbols, are listed in the Symbol Table. The location of the Symbol Table is indicated in the COFF Header.

The Symbol Table is an array of records, each 18 bytes long. Each record is either a standard or auxiliary symbol-table record. A standard record defines a symbol or name, and has the following format: Offset 0 Size 8 Field Name (*) Description Name of the symbol, represented by union of three structures. An array of eight bytes is used if the name is not more than eight bytes long. See Section 5.4.1, Symbol Name Representation, for more information. Value associated with the symbol. The interpretation of this field depends on Section Number and Storage Class. A typical meaning is the relocatable address. Signed integer identifying the section, using a one-based index into the Section Table. Some values have special meaning defined in Section Number Values. A number representing type. Microsoft tools set this field to 0x20 (function) or 0x0 (not a function). See Section 5.4.3, Type Representation, for more information. Enumerated value representing storage class. See Section 5.4.4, Storage Class, for more information. Number of auxiliary symbol table entries that follow this record.

Value

12

SectionNumber

14

Type

16

StorageClass

17

NumberOfAuxSymbols

Zero or more auxiliary symbol-table records immediately follow each standard symbol-table record. However, typically not more than one auxiliary symbol-table record follows a standard symbol-table record (except for .file records with long file names). Each auxiliary record is the same size as a standard symbol-table record (18 bytes), but rather than define a new symbol, the auxiliary record gives additional information on the last symbol defined. The choice of which of several formats to use depends on the Storage Class field. Currently defined formats for auxiliary symbol table records are shown in Auxiliary Symbol Records. Tools that read COFF symbol tables must ignore auxiliary symbol records whose interpretation is unknown. This allows the symbol table format to be extended to add new auxiliary records, without breaking existing tools.

5.4.1. Symbol Name Representation

The Name field in a symbol table consists of eight bytes that contain the name itself, if not too long, or else give an offset into the String Table. To determine whether the name itself or an offset is given, test the first four bytes for equality to zero. Offset 0 Size 8 Field Short Name Description An array of eight bytes. This array is padded with nulls on the right if the name is less than eight bytes long. Set to all zeros if the name is longer than eight bytes. Offset into the String Table.

0 4

4 4

Zeroes Offset

5.4.2. Section Number Values

Normally, the Section Value field in a symbol table entry is a one-based index into the Section Table. However, this field is a signed integer and may take negative values. The following values, less than one, have special meanings: Constant
IMAGE_SYM_UNDEFINED

Value 0

Description Symbol record is not yet assigned a section. If the value is 0 this indicates a references to an external symbol defined elsewhere. If the value is non-zero this is a common symbol with a size specified by the value. The symbol has an absolute (non-relocatable) value and is not an address. The symbol provides general type or debugging information but does not correspond to a section. Microsoft tools use this setting along with .file records (storage class FILE).

IMAGE_SYM_ABSOLUTE

-1 -2

IMAGE_SYM_DEBUG

5.4.3. Type Representation

The Type field of a symbol table entry contains two bytes, each byte representing type information. The least-significant byte represents simple (base) data type, and the mostsignificant byte represents complex type, if any: MSB Complex type: none, pointer, function, array. LSB Base type: integer, floating-point, etc.

The following values are defined for base type, although Microsoft tools generally do not use this field, setting the least-significant byte to 0. Instead, CodeView information is used to indicate types. However, the possible COFF values are listed here for completeness. Constant
IMAGE_SYM_TYPE_NULL

Value 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Description No type information or unknown base type. Microsoft tools use this setting. No valid type; used with void pointers and functions. Character (signed byte). Two-byte signed integer. Natural integer type (normally four bytes in Windows NT). Four-byte signed integer. Four-byte floating-point number. Eight-byte floating-point number. Structure. Union. Enumerated type. Member of enumeration (a specific value). Byte; unsigned one-byte integer. Word; unsigned two-byte integer. Unsigned integer of natural size (normally, four bytes). Unsigned four-byte integer.

IMAGE_SYM_TYPE_VOID IMAGE_SYM_TYPE_CHAR IMAGE_SYM_TYPE_SHORT IMAGE_SYM_TYPE_INT

IMAGE_SYM_TYPE_LONG IMAGE_SYM_TYPE_FLOAT IMAGE_SYM_TYPE_DOUBLE IMAGE_SYM_TYPE_STRUCT IMAGE_SYM_TYPE_UNION IMAGE_SYM_TYPE_ENUM IMAGE_SYM_TYPE_MOE IMAGE_SYM_TYPE_BYTE IMAGE_SYM_TYPE_WORD IMAGE_SYM_TYPE_UINT

IMAGE_SYM_TYPE_DWORD

The most significant byte specifies whether the symbol is a pointer to, function returning, or array of the base type specified in the least significant byte. Microsoft tools use this field only to indicate whether or not the symbol is a function, so that the only two resulting values are 0x0 and 0x20 for the Type field. However, other tools can use this field to communicate more information. It is very important to specify the function attribute correctly. This information is required for incremental linking to work correctly. For some architectures the information may be required for other purposes. Constant
IMAGE_SYM_DTYPE_NULL

Value 0 1 2

Description No derived type; the symbol is a simple scalar variable. Pointer to base type. Function returning base type.

IMAGE_SYM_DTYPE_POINTER IMAGE_SYM_DTYPE_FUNCTION

IMAGE_SYM_DTYPE_ARRAY

Array of base type.

5.4.4. Storage Class

The Storage Class field of the Symbol Table indicates what kind of definition a symbol represents. The following table shows possible values. Note that the Storage Class field is an unsigned one-byte integer. The special value -1 should therefore be taken to mean its unsigned equivalent, 0xFF. Although traditional COFF format makes use of many storage-class values, Microsoft tools rely on CodeView format for most symbolic information and generally use only four storage-class values: EXTERNAL (2), STATIC (3), FUNCTION (101), and STATIC (103). Except in the second column heading below, Value should be taken to mean the Value field of the symbol record (whose interpretation depends on the number found as the storage class). Constant
IMAGE_SYM_CLASS_END_OF_FUNCTION

Value -1 (0xFF) 0 1 2

Description / Interpretation of Value Field Special symbol representing end of function, for debugging purposes. No storage class assigned. Automatic (stack) variable. The Value field specifies stack frame offset. Used by Microsoft tools for external symbols. The Value field indicates the size if the section number is IMAGE_SYM_UNDEFINED (0). If the section number is not 0, then the Value field specifies the offset within the section. The Value field specifies the offset of the symbol within the section. If the Value is 0, then the symbol represents a section name. Register variable. The Value field specifies register number. Symbol is defined externally. Code label defined within the module. The Value field specifies the offset of the symbol within the section. Reference to a code label not defined. Structure member. The Value field specifies nth member. Formal argument (parameter)of a function. The Value field specifies nth argument. Structure tag-name entry.

IMAGE_SYM_CLASS_NULL IMAGE_SYM_CLASS_AUTOMATIC

IMAGE_SYM_CLASS_EXTERNAL

IMAGE_SYM_CLASS_STATIC

IMAGE_SYM_CLASS_REGISTER

4 5 6

IMAGE_SYM_CLASS_EXTERNAL_DEF IMAGE_SYM_CLASS_LABEL

IMAGE_SYM_CLASS_UNDEFINED_LABEL IMAGE_SYM_CLASS_MEMBER_OF_STRUCT

7 8 9 10

IMAGE_SYM_CLASS_ARGUMENT

IMAGE_SYM_CLASS_STRUCT_TAG

IMAGE_SYM_CLASS_MEMBER_OF_UNION

11 12 13 14 15 16 17 18 100

Union member. The Value field specifies nth member. Union tag-name entry. Typedef entry. Static data declaration. Enumerated type tagname entry. Member of enumeration. Value specifies nth member. Register parameter. Bit-field reference. Value specifies nth bit in the bit field. A .bb (beginning of block) or .eb (end of block) record. Value is the relocatable address of the code location. Used by Microsoft tools for symbol records that define the extent of a function: begin function (named .bf), end function (.ef), and lines in function (.lf). For .lf records, Value gives the number of source lines in the function. For .ef records, Value gives the size of function code. End of structure entry. Used by Microsoft tools, as well as traditional COFF format, for the source-file symbol record. The symbol is followed by auxiliary records that name the file. Definition of a section (Microsoft tools use STATIC storage class instead). Weak external. See Section 5.5.3, Auxiliary Format 3: Weak Externals, for more information.

IMAGE_SYM_CLASS_UNION_TAG IMAGE_SYM_CLASS_TYPE_DEFINITION IMAGE_SYM_CLASS_UNDEFINED_STATIC IMAGE_SYM_CLASS_ENUM_TAG IMAGE_SYM_CLASS_MEMBER_OF_ENUM

IMAGE_SYM_CLASS_REGISTER_PARAM IMAGE_SYM_CLASS_BIT_FIELD

IMAGE_SYM_CLASS_BLOCK

IMAGE_SYM_CLASS_FUNCTION

101

IMAGE_SYM_CLASS_END_OF_STRUCT IMAGE_SYM_CLASS_FILE

102 103

IMAGE_SYM_CLASS_SECTION

104 105

IMAGE_SYM_CLASS_WEAK_EXTERNAL

5.5. Auxiliary Symbol Records

Auxiliary Symbol Table records always follow and apply to some standard Symbol Table record. An auxiliary record can have any format that the tools are designed to recognize, but 18 bytes must be allocated for them so that Symbol Table is maintained as an array of regular size. Currently, Microsoft tools recognize auxiliary formats for the following kinds of records: function definitions, function begin and end symbols (.bf and .ef), weak externals, filenames, and section definitions.

The traditional COFF design also includes auxiliary-record formats for arrays and structures. Microsoft tools do not use these, and instead place that symbolic information in CodeView format in the debug sections.

5.5.1. Auxiliary Format 1: Function Definitions

A symbol table record marks the beginning of a function definition if all of the following are true: it has storage class EXTERNAL (2), a Type value indicating it is a function (0x20), and a section number greater than zero. Note that a symbol table record that has a section number of UNDEFINED (0) does not define the function and does not have an auxiliary record. Functiondefinition symbol records are followed by an auxiliary record with the format described below. Offset 0 4 Size 4 4 Field TagIndex TotalSize Description Symbol-table index of the corresponding .bf (begin function) symbol record. Size of the executable code for the function itself. If the function is in its own section, the Size of Raw Data in the section header will be greater or equal to this field, depending on alignment considerations. File offset of the first COFF line-number entry for the function, or zero if none exists. See Section 5.3, COFF Line Numbers, for more information. Symbol-table index of the record for the next function. If the function is the last in the symbol table, this field is set to zero.

PointerToLinenumber

12

PointerToNextFunction

16

Unused.

5.5.2. Auxiliary Format 2: .bf and .ef Symbols

For each function definition in the Symbol Table, there are three contiguous items that describe the beginning, ending, and number of lines. Each of these symbols has storage class FUNCTION (101): 1 2 3 A symbol record named .bf (begin function). The Value field is unused. A symbol record named .lf (lines in function). The Value field gives the number of lines in the function. A symbol record named .ef (end of function). The Value field has the same number as the Total Size field in the function-definition symbol record.

The .bf and .ef symbol records (but not .lf records) are followed by an auxiliary record with the following format:

Offset 0 4

Size 4 2

Field Unused. Linenumber

Description

Actual ordinal line number (1, 2, 3, etc.) within source file, corresponding to the .bf or .ef record.

6 12

6 4

Unused. PointerToNextFunction (.bf only) Symbol-table index of the next .bf symbol record. If the function is the last in the symbol table, this field is set to zero. Not used for .ef records.

16

Unused.

5.5.3. Auxiliary Format 3: Weak Externals

Weak externals are a mechanism for object files allowing flexibility at link time. A module can contain an unresolved external symbol (sym1), but it can also include an auxiliary record indicating that if sym1 is not present at link time, another external symbol (sym2) is used to resolve references instead. If a definition of sym1 is linked, then an external reference to the symbol is resolved normally. If a definition of sym1 is not linked, then all references to the weak external for sym1 refer to sym2 instead. The external symbol, sym2, must always be linked; typically it is defined in the module containing the weak reference to sym1. Weak externals are represented by a Symbol Table record with EXTERNAL storage class, UNDEF section number, and a value of 0. The weak-external symbol record is followed by an auxiliary record with the following format: Offset 0 4 Size 4 4 Field TagIndex Characteristics Description Symbol-table index of sym2, the symbol to be linked if sym1 is not found. A value of IMAGE_WEAK_EXTERN_SEARCH_NOLIBRAR Y indicates that no library search for sym1 should be performed.

A value of IMAGE_WEAK_EXTERN_SEARCH_LIBRARY indicates that a library search for sym1 should be performed.

A value of IMAGE_WEAK_EXTERN_SEARCH_ALIAS indicates that sym1 is an alias for sym2.

10

Unused.

Note that the Characteristics field is not defined in WINNT.H; instead, the Total Size field is used.

5.5.4. Auxiliary Format 4: Files

This format follows a symbol-table record with storage class FILE (103). The symbol name itself should be .file, and the auxiliary record that follows it gives the name of a source-code file. Offset 0 Size 18 Field File Name Description ASCII string giving the name of the source file; padded with nulls if less than maximum length.

5.5.5. Auxiliary Format 5: Section Definitions

This format follows a symbol-table record that defines a section: such a record has a symbol name that is the name of a section (such as .text or .drectve) and has storage class STATIC (3). The auxiliary record provides information on the section referred to. Thus it duplicates some of the information in the section header. Offset 0 4 6 8 Size 4 2 2 4 Field Length NumberOfRelocations NumberOfLinenumbers Check Sum Description Size of section data; same as Size of Raw Data in the section header. Number of relocation entries for the section. Number of line-number entries for the section. Checksum for communal data. Applicable if the IMAGE_SCN_LNK_COMDAT flag is set in the section header. See COMDAT Sections below, for more information. One-based index into the Section Table for the associated section; used when the COMDAT Selection setting is 5. COMDAT selection number. Applicable if the section is a COMDAT section.

12

Number

14 15

1 3

Selection Unused.

5.5.6. COMDAT Sections (Object Only)

The Selection field of the Section Definition auxiliary format is applicable if the section is a COMDAT section: a section that can be defined by more than one object file. (The flag IMAGE_SCN_LNK_COMDAT is set in the Section Flags field of the section header.) The Selection field determines the way that the linker resolves the multiple definitions of COMDAT sections. The first symbol having the section value of the COMDAT section must be the section symbol. This symbol has the name of the section, Value field equal to 0, the section number of the

COMDAT section in question, Type field equal to IMAGE_SYM_TYPE_NULL, Class field equal to IMAGE_SYM_CLASS_STATIC, and one auxiliary record. The second symbol is called the COMDAT symbol and is used by the linker in conjunction with the Selection field. Values for the Selection field are shown below. Constant
IMAGE_COMDAT_SELECT_NODUPLICATES

Value 1 2

Description The linker issues a multiply defined symbol error if this symbol is already defined. Any section defining the same COMDAT symbol may be linked; the rest are removed. The linker chooses an arbitrary section among the definitions for this symbol. A multiply defined symbol error is issued if all definitions dont have the same size. The linker chooses an arbitrary section among the definitions for this symbol. A multiply defined symbol error is issued if all definitions dont match exactly. The section is linked if a certain other COMDAT section is linked. This other section is indicated by the Number field of the auxiliary symbol record for the section definition. Use of this setting is useful for definitions that have components in multiple sections (for example, code in one and data in another), but where all must be linked or discarded as a set. The linker chooses the largest from the definitions for this symbol. If multiple definitions have this size the choice between them is arbitrary.

IMAGE_COMDAT_SELECT_ANY

IMAGE_COMDAT_SELECT_SAME_SIZE

IMAGE_COMDAT_SELECT_EXACT_MATCH

IMAGE_COMDAT_SELECT_ASSOCIATIVE

IMAGE_COMDAT_SELECT_LARGEST

5.6. COFF String Table

Immediately following the COFF symbol table is the COFF string table. The position of this table is found by taking the symbol table address in the COFF header, and adding the number of symbols multiplied by the size of a symbol. At the beginning of the COFF string table are 4 bytes containing the total size (in bytes) of the rest of the string table. This size includes the size field itself, so that the value in this location would be 4 if no strings were present. Following the size are null-terminated strings pointed to by symbols in the COFF symbol table.

5.7. The Attribute Certificate Table (Image Only)

Attribute Certificates may be associated with an image by adding an Attribute Certificate Table. There are a number of different types of Attribute Certificates. The meaning and use of each certificate type is not covered in this document. For this information see the Microsoft Distributed System Architecture, Attribute Certificate Architecture Specification. An Attribute Certificate Table is added at the end of the image, with only a .debug section following (if a .debug section is present). The Attribute Certificate Table contains one or more fixed length table entries which can be found via the Certificate Table field of the Optional Header Data Directories list (offset 128). Each entry of this table identifies the beginning location and length of a corresponding certificate. There is one Certificate Table entry for each certificate stored in this section. The number of entries in the certificate table can be calculated by dividing the size of the certificate table (found in offset 132) by the size of an entry in the certificate table (8). Note that the size of the certificate table includes only the table entries, not the actual certificates which the table entries, in turn, point to. The format of each table entry is: Offset 0 Size 4 Field Certificate Data Description File pointer to the certificate data. This will always point to an address that is octaword aligned (i.e., is a multiple of 8 bytes and so the low-order 3 bits are zero). Unsigned integer identifying the size (in bytes) of the certificate.

Size of Certificate

Notice that certificates always start on an octaword boundary. If a certificate is not an even number of octawords long, it is zero padded to the next octaword boundary. However, the length of the certificate does not include this padding and so any certificate navigation software must be sure to round up to the next octaword to locate another certificate.

5.7.1. Certificate Data

This is the binary data representing an Attribute Certificate. The format and meaning of each certificate is defined in Attribute Certificate Architecture Specification. The certificate starting location and length is specified by an entry in the Certificate Table. Each certificate is represented by a single Certificate Table entry.

5.8 Delay-Load Import Tables (Image Only)

These tables were added to the image in order to support a uniform mechanism for applications to delay the loading of a DLL until the first call into that DLL. The layout of the tables matches that of the traditional import tables (see Section 6.4. The .idata Section for details), so only a few details will be discussed here.

5.8.1. The Delay-Load Directory Table

The Delay-Load Directory Table is the counterpart to the Import Directory Table, and can be retrieved via the Delay Import Descriptor entry in the Optional Header Data Directories list (offset 200). The Table is arranged as follows: Offset 0 4 Size 4 4 Field Attributes Name Description Must be zero. Relative virtual address of the name of the DLL to be loaded. The name resides in the read-only data section of the image. Relative virtual address of the module handle (in the data section of the image) of the DLL to be delay-loaded. Used for storage by the routine supplied to manage delay-loading. Relative virtual address of the delay-load import address table. See below for further details. Relative virtual address of the delay-load name table, which contains the names of the imports that may need to be loaded. Matches the layout of the Import Name Table, Section 6.4.3. Hint/Name Table. Relative virtual address of the bound delayload address table, if it exists. Relative virtual address of the unload delay-load address table, if it exists. This is an exact copy of the Delay Import Address Table. In the event that the caller unloads the DLL, this table should be copied back over the Delay IAT such that subsequent calls to the DLL continue to use the thunking mechanism correctly. Time stamp of DLL to which this image has been bound.

Module Handle

12

Delay Import Address Table Delay Import Name Table

16

20 24

4 4

Bound Delay Import Table Unload Delay Import Table

28

Time Stamp

The tables referenced in this data structure are organized and sorted just as their counterparts are for traditional imports. See Section 6.4. The idata Section for details.

5.8.2. Attributes
As yet, there are no attribute flags defined. This field is currently set to zero by the linker in the image. This field can be used to extend the record by indicating the presence of new fields or for indicating behaviors to the delay and/or unload helper functions.

5.8.3. Name
The name of the DLL to be delay loaded resides in the read-only data section of the image and is referenced via the szName field.

5.8.4. Module handle

The handle of the DLL to be delay loaded is located in the data section of the image and pointed to via the phmod field. The supplied delay load helper uses this location to store the handle to the loaded DLL.

5.8.5. Delay Import Address Table (IAT)

The delay IAT is referenced by the delay import descriptor via the pIAT field. This is the working copy of the entry point function pointers that resides in the data section of the image and initially refer to the delay load thunks. The delay load helper is responsible for updating these pointers with the real entry points so that the thunks are no longer in the calling loop. The function pointers are access via the expression pINT->u1.Function.

5.8.6. Delay Import Name Table (INT)

The delay INT has the names of the imports that may need to be loaded. They are ordered in the same fashion as the function pointers in the IAT. They consist of the same structures as the standard INT and are accessed via the expression pINT->u1.AddressOfData->Name[0].

5.8.7. Delay Bound Import Address Table (BIAT) and Time Stamp
The delay BIAT is an optional table of IMAGE_THUNK_DATA items that is used along with the timestamp field by a post process binding phase.

5.8.8. Delay Unload Import Address Table (UIAT)

The delay UIAT is an optional table of IMAGE_THUNK_DATA items that is used by the unload code to handle an explicit unload request. It is initialized data in the read-only section that is an exact copy of the original IAT that referred the code to the delay load thunks. On the unload request, the library can be freed, the *phmod cleared, and the UIAT written over the IAT to restore everything to its pre-load state.

6. Special Sections
Typical COFF sections contain code or data that linkers and Win32 loaders process without special knowledge of the sections contents. The contents are relevant only to the application being linked or executed. However, some COFF sections have special meanings when found in object files and/or image files. Tools and loaders recognize these sections because they have special flags set in the section header, or because they are pointed to from special locations in the image optional header, or because the section name is magic: that is, the name indicates a special function of the section. (Even where the section name is not magic, the name is dictated by convention, so we will refer to a name.)

The reserved sections and their attributes are described in the table below, followed by detailed descriptions for a subset of them. Section Name .arch Content Alpha architecture information Characteristics IMAGE_SCN_MEM_READ | IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_ALIGN_8BYTES | IMAGE_SCN_MEM_DISCARDABLE IMAGE_SCN_CNT_UNINITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE IMAGE_SCN_CNT_CODE | IMAGE_SCN_MEM_EXECUTE | IIMAGE_SCN_MEM_READ IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ

.bss

Uninitialized data

.data

Initialized data

.edata .idata

Export tables Import tables

.pdata .rdata .reloc

Exception information Read-only initialized data Image relocations

.rsrc

Resource directory Executable code

.text

.tls

Thread-local storage Exception information

.xdata

Some of the sections listed here are marked (object only) or (image only) to indicate that their special semantics are relevant only for object files or image files, respectively. A section that says (image only) may still appear in an object file as a way of getting into the image file, but the section has no special meaning to the linker, only to the image file loader.

6.1. The .debug Section

The .debug section is used in object files to contain compiler-generated debug information, and in image files to contain the total debug information generated. This section describes the packaging of debug information in object and image files. The actual format of CodeView debug information is not described here. See the document CV4 Symbolic Debug Information Specification. The next section describes the format of the debug directory, which can be anywhere in the image. Subsequent sections describe the groups in object files that contain debug information. The default for the linker is that debug information is not mapped into the address space of the image. A .debug section exists only when debug information is mapped in the address space.

6.1.1. Debug Directory (Image Only)

Image files contain an optional debug directory indicating what form of debug information is present and where it is. This directory consists of an array of debug directory entries whose location and sizes are indicated in the image optional header. The debug directory may be in a discardable .debug section (if one exists) or it may be included in any other section in the image file, or not in a section at all. Each debug directory entry identifies the location and size of a block of debug information. The RVA specified may be 0 if the debug information is not covered by a section header (i.e., it resides in the image file and is not mapped into the run-time address space). If it is mapped, the RVA is its address. Here is the format of a debug directory entry: Offset 0 4 8 10 12 Size 4 4 2 2 4 Field Characteristics TimeDateStamp MajorVersion MinorVersion Type Description A reserved field intended to be used for flags, set to zero for now. Time and date the debug data was created. Major version number of the debug data format. Minor version number of the debug data format. Format of debugging information: this field enables support of multiple debuggers. See Section 6.1.2, Debug Type, for more information. Size of the debug data (not including the debug directory itself). Address of the debug data when loaded, relative to the image base. File pointer to the debug data.

16 20 24

4 4 4

SizeOfData AddressOfRawData PointerToRawData

6.1.2. Debug Type

The following values are defined for the Debug Type field of the debug directory: Constant
IMAGE_DEBUG_TYPE_UNKNOWN IMAGE_DEBUG_TYPE_COFF

Value 0 1

Description Unknown value, ignored by all tools. COFF debug information (line numbers, symbol table, and string table). This type of debug information is also pointed to by fields in the file headers. CodeView debug information. The format of the data block is described by the CV4 specification. Frame Pointer Omission (FPO) information. This information tells the debugger how to interpret non-standard stack frames, which use the EBP register for a purpose other than as a frame pointer.

IMAGE_DEBUG_TYPE_CODEVIEW

IMAGE_DEBUG_TYPE_FPO

IMAGE_DEBUG_TYPE_MISC IMAGE_DEBUG_TYPE_EXCEPTION IMAGE_DEBUG_TYPE_FIXUP IMAGE_DEBUG_TYPE_OMAP_TO_SRC IMAGE_DEBUG_TYPE_OMAP_FROM_SRC IMAGE_DEBUG_TYPE_BORLAND

4 5 6 7 8 9

If Debug Type is set to IMAGE_DEBUG_TYPE_FPO, the debug raw data is an array in which each member describes the stack frame of a function. Not every function in the image file need have FPO information defined for it, even though debug type is FPO. Those functions that do not have FPO information are assumed to have normal stack frames. The format for FPO information is defined as follows:
#define FRAME_FPO #define FRAME_TRAP #define FRAME_TSS 0 1 2 // // // // 8; 3; 1; 1; 1; 2; // // // // // // offset 1st # bytes in # bytes in # bytes in byte of function code function locals/4 params/4

typedef struct _FPO_DATA { DWORD ulOffStart; DWORD cbProcSize; DWORD cdwLocals; WORD cdwParams; WORD WORD WORD WORD WORD WORD } FPO_DATA; cbProlog cbRegs fHasSEH fUseBP reserved cbFrame : : : : : :

# bytes in prolog # regs saved TRUE if SEH in func TRUE if EBP has been allocated reserved for future use frame type

6.1.3. .debug$F (Object Only)

Object files can contain .debug$F sections whose contents are one or more FPO_DATA records (Frame Pointer Omission information). See IMAGE_DEBUG_TYPE_FPO in table above. The linker recognizes these .debug$F records. If debug information is being generated, the linker sorts the FPO_DATA records by procedure RVA, and generates a debug directory entry for them. The compiler should not generate FPO records for procedures that have a standard frame format.

6.1.4. .debug$S (Object Only)

This section contains CV4 symbolic information: a stream of CV4 symbol records as described in the CV4 spec.

6.1.5. .debug$T (Object Only)

This section contains CV4 type information: a stream of CV4 type records as described in the CV4 spec.

6.1.6. Linker Support for Microsoft CodeView Debug Information

To support CodeView debug information, the linker: 1 2 3 4 5 6 Generates the header and NB05 signature. Packages the header with .debug$S and .debug$T sections from object files and synthetic (linker-generated) CV4 information, and creates a debug directory entry. Generates the subsection directory containing a pointer to each known subsection, including subsections that are linker-generated. Generates the sstModules subsection, which specifies the address and size of each modules contribution(s) to the image address space. Generates the sstSegMap subsection, which specifies the address and size of each section in the image. Generates the sstPublicSym subsection, which contains the name and address of all externally defined symbols. (A symbol may be represented both by .debug$S information and by an sstPublicSym entry.)

6.2. The .drectve Section (Object Only)

A section is a directive section if it has the IMAGE_SCN_LNK_INFO flag set in the section header. By convention, such a section also has the name .drectve. The linker removes a .drectve section after processing the information, so the section does not appear in the image file being linked. Note that a section marked with IMAGE_SCN_LNK_INFO that is not named .drectve is ignored and discarded by the linker. A .drectve section consists of a string of ASCII text. This string is a series of linker options (each option containing hyphen, option name, and any appropriate attribute) separated by spaces. The .drectve section must not have relocations or line numbers.

In a .drectve section, if the hyphen preceding an option is followed by a question mark (for example, -?export), and the option is not recognized as a valid directive, the linker must ignore it. This allows compilers and linkers to add new directives while maintaining compatibility with existing linkers, as long as the new directives are not required for the correct linking of the application. For example, if the directive enables a link-time optimization, it is acceptable if some linkers cannot recognize it.

6.3. The .edata Section (Image Only)

The export data section, named .edata, contains information about symbols that other images can access through dynamic linking. Exports are generally found in DLLs, but DLLs can import symbols as well. An overview of the general structure of the export section is described below. The tables described are generally contiguous in the file and present in the order shown (though this is not strictly required). Only the Directory Table and Address Table are necessary for exporting symbols as ordinals. (An ordinal is an export accessed directly as an Export Address Table index.) The Name Pointer Table, Ordinal Table, and Export Name Table all exist to support use of export names. Table Name Export Directory Table Export Address Table Description A table with just one row (unlike the debug directory). This table indicates the locations and sizes of the other export tables. An array of RVAs of exported symbols. These are the actual addresses of the exported functions and data within the executable code and data sections. Other image files can import a symbol by using an index to this table (an ordinal) or, optionally, by using the public name that corresponds to the ordinal if one is defined. Array of pointers to the public export names, sorted in ascending order. Array of the ordinals that correspond to members of the Name Pointer Table. The correspondence is by position; therefore, the Name Pointer Table and the Ordinal Table must have the same number of members. Each ordinal is an index into the Export Address Table. A series of null-terminated ASCII strings. Members of the Name Pointer Table point into this area. These names are the public names through which the symbols are imported and exported; they do not necessarily have to be the same as the private names used within the image file.

Name Pointer Table Ordinal Table

Export Name Table

When another image file imports a symbol by name, the Name Pointer Table is searched for a matching string. If one is found, the associated ordinal is then determined by looking at the corresponding member in the Ordinal Table (that is, the member of the Ordinal Table with the same index as the string pointer found in the Name Pointer Table). The resulting ordinal is an index into the Export Address Table, which gives the actual location of the desired symbol. Every export symbol can be accessed by an ordinal.

Direct use of an ordinal is therefore more efficient, because it avoids the need to search the Name Pointer Table for a matching string. However, use of an export name is more mnemonic and does not require the user to know the table index for the symbol.

6.3.1. Export Directory Table

The export information begins with the Export Directory Table, which describes the remainder of the export information. The Export Directory Table contains address information that is used to resolve fix-up references to the entry points within this image. Offset 0 4 8 10 12 16 Size 4 4 2 2 4 4 Field Export Flags Time/Date Stamp Major Version Minor Version Name RVA Ordinal Base Description A reserved field, set to zero for now. Time and date the export data was created. Major version number. The major/minor version number can be set by the user. Minor version number. Address of the ASCII string containing the name of the DLL. Relative to image base. Starting ordinal number for exports in this image. This field specifies the starting ordinal number for the Export Address Table. Usually set to 1. Number of entries in the Export Address Table. Number of entries in the Name Pointer Table (also the number of entries in the Ordinal Table). Address of the Export Address Table, relative to the image base. Address of the Export Name Pointer Table, relative to the image base. The table size is given by Number of Name Pointers. Address of the Ordinal Table, relative to the image base.

20 24

4 4

Address Table Entries Number of Name Pointers Export Address Table RVA Name Pointer RVA

28 32

4 4

36

Ordinal Table RVA

6.3.2. Export Address Table

The Export Address Table contains the address of exported entry points and exported data and absolutes. An ordinal number is used to index the Export Address Table, after subtracting the value of the Ordinal Base field to get a true, zero-based index. (Thus, if the Ordinal Base is set to 1, a common value, an ordinal of 6 is the same as a zero-based index of 5.) Each entry in the Export Address Table is a field that uses one of two formats, as shown in the following table. If the address specified is not within the export section (as defined by the address

and length indicated in the Optional Header), the field is an Export RVA: an actual address in code or data. Otherwise, the field is a Forwarder RVA, which names a symbol in another DLL. Offset 0 Size 4 Field Export RVA Description Address of the exported symbol when loaded into memory, relative to the image base. For example, the address of an exported function. Pointer to a null-terminated ASCII string in the export section, giving the DLL name and the name of the export (for example, MYDLL.expfunc) or the DLL name and an export (for example, MYDLL.#27).

Forwarder RVA

A Forwarder RVA exports a definition from some other image, making it appear as if it were being exported by the current image. Thus the symbol is simultaneously imported and exported. For example, in KERNEL32.DLL in Windows NT, the export named HeapAlloc is forwarded to the string NTDLL.RtlAllocateHeap. This allows applications to use the Windows NT-specific module NTDLL.DLL without actually containing import references to it. The applications import table references only KERNEL32.DLL. Therefore, the application is not specific to Windows NT and can run on any Win32 system.

6.3.3. Export Name Pointer Table

The Export Name Pointer Table is an array of addresses (RVAs) into the Export Name Table. The pointers are 32 bits each and are relative to the Image Base. The pointers are ordered lexically to allow binary searches. An export name is defined only if the Export Name Pointer Table contains a pointer to it.

6.3.4. Export Ordinal Table

The Export Ordinal Table is an array of 16-bit indexes into the Export Address Table. The ordinals are biased by the Ordinal Base field of the Export Directory Table. In other words, the Ordinal Base must be subtracted from the ordinals to obtain true indexes into the Export Address Table. The Export Name Pointer Table and the Export Ordinal Table form two parallel arrays, separated to allow natural field alignment. These two tables, in effect, operate as one table, in which the Export Name Pointer column points to a public (exported) name, and the Export Ordinal column gives the corresponding ordinal for that public name. A member of the Export Name Pointer Table and a member of the Export Ordinal Table are associated by having the same position (index) in their respective arrays. Thus, when the Export Name Pointer Table is searched and a matching string is found at position i, the algorithm for finding the symbols address is:
i = Search_ExportNamePointerTable (ExportName); ordinal = ExportOrdinalTable [i]; SymbolRVA = ExportAddressTable [ordinal - OrdinalBase];

6.3.5. Export Name Table

The Export Name Table contains the actual string data pointed to by the Export Name Pointer Table. The strings in this table are public names that can be used by other images to import the symbols; these public export names are not necessarily the same as the (private) symbol names that the symbols have in their own image file and source code, although they can be. Every exported symbol has an ordinal value, which is just the index into the Export Address Table (plus the Ordinal Base value). Use of export names, however, is optional. Some, all, or none of the exported symbols can have export names. For those exported symbols that do have export names, corresponding entries in the Export Name Pointer Table and Export Ordinal Table work together to associate each name with an ordinal. The structure of the Export Name Table is a series of ASCII strings, of variable length, each null terminated.

6.4. The .idata Section

All image files that import symbols, including virtually all .EXE files, have an .idata section. A typical file layout for the import information follows: Directory Table

Null Directory Entry

DLL1 Import Lookup Table

Null

DLL2 Import Lookup Table

Null

DLL3 Import Lookup Table

Null

Hint-Name Table

Figure 3. Typical Import Section Layout

6.4.1. Import Directory Table

The import information begins with the Import Directory Table, which describes the remainder of the import information. The Import Directory Table contains address information that is used to resolve fix-up references to the entry points within a DLL image. The Import Directory Table consists of an array of Import Directory Entries, one entry for each DLL the image references. The last directory entry is empty (filled with null values), which indicates the end of the directory table. Each Import Directory entry has the following format: Offset 0 Size 4 Field Import Lookup Table RVA (Characteristics) Description Relative virtual address of the Import Lookup Table; this table contains a name or ordinal for each import. (The name Characteristics is used in WINNT.H but is no longer descriptive of this field.) Set to zero until bound; then this field is set to the time/data stamp of the DLL. Index of first forwarder reference. Address of ASCII string containing the DLL name. This address is relative to the image base. Relative virtual address of the Import Address Table: this table is identical in contents to the Import Lookup Table until the image is bound.

4 8 12

4 4 4

Time/Date Stamp Fowarder Chain Name RVA

16

Import Address Table RVA (Thunk Table)

6.4.2. Import Lookup Table

An Import Lookup Table is an array of 32-bit numbers for PE32, 64-bit for PE32+. Each entry uses the bit-field format described below, in which bit 31 (63) is the most significant bit. The collection of these entries describes all imports from the image to a given DLL. The last entry is set to zero (NULL) to indicate end of the table. Bit(s) 31 / 63 Size 1 Bit Field Ordinal/Name Flag Description If bit is set, import by ordinal. Otherwise, import by name. Bit is masked as 0x80000000 for PE32, 0x8000000000000000 for PE32+. Ordinal/Name Flag is 1: import by ordinal. This field is a 31-bit (63-bit) ordinal number. Ordinal/Name Flag is 0: import by name. This field is a 31-bit (63-bit) address of a Hint/Name Table entry, relative to image base.

30 0 / 62 0 30 0 / 62 0

31 / 63

Ordinal Number

31 / 63

Hint/Name Table RVA

In a PE32 image, the lower 31 bits can be masked as 0x7FFFFFFF. In either case, the resulting number is a 32-bit integer or pointer in which the high bit is always zero (zero extension to 32 bits). Similarly for a PE32+ image, the lower 63 bits can be masked as 0x7FFFFFFFFFFFFFFF.

6.4.3. Hint/Name Table

One Hint/Name Table suffices for the entire import section. Each entry in the Hint/Name Table has the following format: Offset 0 Size 2 Field Hint Description Index into the Export Name Pointer Table. A match is attempted first with this value. If it fails, a binary search is performed on the DLLs Export Name Pointer Table. ASCII string containing name to import. This is the string that must be matched to the public name in the DLL. This string is case sensitive and terminated by a null byte. A trailing zero pad byte appears after the trailing null byte, if necessary, to align the next entry on an even boundary.

variable

Name

0 or 1

Pad

6.4.4. Import Address Table

The structure and content of the Import Address Table are identical to that of the Import Lookup Table, until the file is bound. During binding, the entries in the Import Address Table are overwritten with the 32-bit (or 64-bit for PE32+) addresses of the symbols being imported: these addresses are the actual memory addresses of the symbols themselves (although technically, they are still called virtual addresses). The processing of binding is typically performed by the loader.

6.5. The .pdata Section

The .pdata section contains an array of function table entries used for exception handling and is pointed to by the exception table entry in the image data directory. The entries must be sorted according to the function addresses (the first field in each structure) before being emitted into the final image. The target platform determines which of the three variations described below is used. For 32-bit MIPS and Alpha images the following structure is used: Offset 0 4 8 12 Size 4 4 4 4 Field Begin Address End Address Exception Handler Handler Data Description Virtual address of the corresponding function. Virtual address of the end of the function. Pointer to the exception handler to be executed. Pointer to additional information to be passed to the handler.

16

Prolog End Address

Virtual address of the end of the functions prolog.

For the ARM, PowerPC, SH3 and SH4 WindowsCE platforms, this function table entry format is used: Offset 0 4 4 4 4 Size 4 8 bits 22 bits 1 bit 1 bit Field Begin Address Prolog Length Function Length 32-bit Flag Exception Flag Description Virtual address of the corresponding function. Number of instructions in the functions prolog. Number of instructions in the function. Set if the function is comprised of 32-bit instructions, cleared for a 16-bit function. Set if an exception handler exists for the function.

Finally, for ALPHA64 the pdata entry format is as follows: Offset 0 8 16 24 32 Size 8 8 8 8 8 Field Begin Address End Address Exception Handler Handler Data Prolog End Address Description Virtual address of the corresponding function. Virtual address of the end of the function. Pointer to the exception handler to be executed. Pointer to additional information to be passed to the handler. Virtual address of the end of the functions prolog.

6.6. The .reloc Section (Image Only)

The Fix-Up Table contains entries for all fixups in the image. The Total Fix-Up Data Size in the Optional Header is the number of bytes in the fixup table. The fixup table is broken into blocks of fixups. Each block represents the fixups for a 4K page. Each block must start on a 32-bit boundary. Fixups that are resolved by the linker do not need to be processed by the loader, unless the load image cant be loaded at the Image Base specified in the PE Header.

6.6.1. Fixup Block

Each fixup block starts with the following structure: Offset 0 Size 4 Field Page RVA Description The image base plus the page RVA is added to each offset to create the virtual address of where the fixup needs to be applied. Total number of bytes in the fixup block, including the Page RVA and Block Size fields, as well as the Type/Offset fields that follow.

Block Size

The Block Size field is then followed by any number of Type/Offset entries. Each entry is a word (2 bytes) and has the following structure: Offset 0 Size 4 bits Field Type Description Stored in high 4 bits of word. Value indicating which type of fixup is to be applied. These fixups are described in Fixup Types. Stored in remaining 12 bits of word. Offset from starting address specified in the Page RVA field for the block. This offset specifies where the fixup is to be applied.

12 bits

Offset

To apply a fixup, a delta is calculated as the difference between the preferred base address, and the base where the image is actually loaded. If the image is loaded at its preferred base, the delta would be zero, and thus the fixups would not have to be applied.

6.6.2. Fixup Types

Constant
IMAGE_REL_BASED_ABSOLUTE

Value 0 1

Description The fixup is skipped. This type can be used to pad a block. The fixup adds the high 16 bits of the delta to the 16-bit field at Offset. The 16-bit field represents the high value of a 32-bit word. The fixup adds the low 16 bits of the delta to the 16-bit field at Offset. The 16-bit field represents the low half of a 32-bit word. The fixup applies the delta to the 32-bit field at Offset.

IMAGE_REL_BASED_HIGH

IMAGE_REL_BASED_LOW

IMAGE_REL_BASED_HIGHLOW

IMAGE_REL_BASED_HIGHADJ

The fixup adds the high 16 bits of the delta to the 16-bit field at Offset. The 16-bit field represents the high value of a 32-bit word. The low 16 bits of the 32-bit value are stored in the 16-bit word that follows this base relocation. This means that this base relocation occupies two slots. Fixup applies to a MIPS jump instruction. Reserved for future use Reserved for future use Fixup applies to a MIPS16 jump instruction. This fixup applies the delta to the 64-bit field at Offset The fixup adds the high 16 bits of the delta to the 16-bit field at Offset. The 16-bit field represents the high value of a 48-bit word. The low 32 bits of the 48-bit value are stored in the 32-bit word that follows this base relocation. This means that this base relocation occupies three slots.

IMAGE_REL_BASED_MIPS_JMPADDR IMAGE_REL_BASED_SECTION IMAGE_REL_BASED_REL32 IMAGE_REL_BASED_MIPS_JMPADDR16 IMAGE_REL_BASED_DIR64

5 6 7 9 10 11

IMAGE_REL_BASED_HIGH3ADJ

6.7. The .tls Section

The .tls section provides direct PE/COFF support for static Thread Local Storage (TLS). TLS is a special storage class supported by Windows NT, in which a data object is not an automatic (stack) variable, yet it is local to each individual thread that runs the code. Thus, each thread can maintain a different value for a variable declared using TLS. Note that any amount of TLS data can be supported by using the API calls TlsAlloc, TlsFree, TlsSetValue, and TlsGetValue. The PE/COFF implementation is an alternative approach to using the API, and it has the advantage of being simpler from the high-level-language programmers point of view. This implementation enables TLS data to be defined and initialized in a manner similar to ordinary static variables in a program. For example, in Microsoft Visual C++, a static TLS variable can be defined as follows, without using the Windows API:
__declspec (thread) int tlsFlag = 1;

To support this programming construct, the PE/COFF .tls section specifies the following information: initialization data, callback routines for per-thread initialization and termination, and the TLS index explained in the following discussion. Note Statically declared TLS data objects can be used only in statically loaded image files. This fact makes it unreliable to use static TLS data in a DLL unless you know that the DLL, or anything statically linked with it, will never be loaded dynamically with the LoadLibrary API function. Executable code accesses a static TLS data object through the following steps:

1. At link time, the linker sets the Address of Index field of the TLS Directory. This field points to a location where the program will expect to receive the TLS index. The Microsoft run-time library facilitates this process by defining a memory image of the TLS Directory and giving it the special name __tls_used (Intel x86 platforms) or _tls_used (other platforms). The linker looks for this memory image and uses the data there to create the TLS Directory. Other compilers that support TLS and work with the Microsoft linker must use this same technique. 2. When a thread is created, the loader communicates the address of the threads TLS array by placing the address of the Thread Environment Block (TEB) in the FS register. A pointer to the TLS array is at the offset of 0x2C from the beginning of TEB. This behavior is Intel x86 specific. 3. The loader assigns the value of the TLS index to the place indicated by the Address of Index field. 4. The executable code retrieves the TLS index and also the location of the TLS array.

5. The code uses the TLS index and the TLS array location (multiplying the index by four and using it as an offset to the array) to get the address of the TLS data area for the given program and module. Each thread has its own TLS data area, but this is transparent to the program, which doesnt need to know how data is allocated for individual threads. 6. An individual TLS data object is accessed as some fixed offset into the TLS data area.

The TLS array is an array of addresses that the system maintains for each thread. Each address in this array gives the location of TLS data for a given module (.EXE or DLL) within the program. The TLS index indicates which member of the array to use. (The index is a number, meaningful only to the system that identifies the module).

6.7.1. The TLS Directory

The TLS Directory has the following format: Offset
(PE32/PE32+)

Size
(PE32/PE32 +)

Field

Description

4/8

Raw Data Start VA (Virtual Address)

Starting address of the TLS template. The template is a block of data used to initialize TLS data. The system copies all this data each time a thread is created, so it must not be corrupted. Note that this address is not an RVA; it is an address for which there should be a base relocation in the .reloc section. Address of the last byte of the TLS, except for the zero fill. As with the Raw Data Start VA, this is a virtual address, not an RVA.

4/8

4/8

Raw Data End VA

8/16

4/8

Address of Index

Location to receive the TLS index, which the loader assigns. This location is in an ordinary data section, so it can be given a symbolic name accessible to the program. Pointer to an array of TLS callback functions. The array is null-terminated, so if there is no callback function supported, this field points to four bytes set to zero. The prototype for these functions is given below, in TLS Callback Functions. The size in bytes of the template, beyond the initialized data delimited by Raw Data Start VA and Raw Data End VA. The total template size should be the same as the total size of TLS data in the image file. The zero fill is the amount of data that comes after the initialized nonzero data. Reserved for possible future use by TLS flags.

12/24

4/8

Address of Callbacks

16/32

Size of Zero Fill

20/36

Characteristics

6.7.2. TLS Callback Functions

The program can provide one or more TLS callback functions (though Microsoft compilers do not currently use this feature) to support additional initialization and termination for TLS data objects. A typical reason to use such a callback function would be to call constructors and destructors for objects. Although there is typically no more than one callback function, a callback is implemented as an array to make it possible to add additional callback functions if desired. If there is more than one callback function, each function is called in the order its address appears in the array. A null pointer terminates the array. It is perfectly valid to have an empty list (no callback supported), in which case the callback array has exactly one membera null pointer. The prototype for a callback function (pointed to by a pointer of type PIMAGE_TLS_CALLBACK) has the same parameters as a DLL entry-point function:
typedef VOID (NTAPI *PIMAGE_TLS_CALLBACK) ( PVOID DllHandle, DWORD Reason, PVOID Reserved );

The Reserved parameter should be left set to 0. The Reason parameter can take the following values: Setting
DLL_PROCESS_ATTACH DLL_THREAD_ATTACH

Value 1 2 3 0

Description New process has started, including the first thread. New thread has been created (this notification sent for all but the first thread). Thread is about to be terminated (this notification sent for all but the first thread). Process is about to terminate, including the original thread.

DLL_THREAD_DETACH

DLL_PROCESS_DETACH

6.8. The .rsrc Section

Resources are indexed by a multiple level binary-sorted tree structure. The general design can incorporate 2**31 levels. By convention, however, Windows NT uses three levels: 1 2 3 Type Name Language

A series of Resource Directory Tables relate all the levels in the following way: each directory table is followed by a series of directory entries, which give the name or ID for that level (Type, Name, or Language level) and an address of either a data description or another directory table. If a data description is pointed to, then the data is a leaf in the tree. If another directory table is pointed to, then that table lists directory entries at the next level down. A leafs Type, Name, and Language IDs are determined by the path taken, through directory tables, to reach the leaf. The first table determines Type ID, the second table (pointed to by the directory entry in the first table) determines Name ID, and the third table determines Language ID. The general structure of the .rsrc section is: Data Resource Directory Tables (and Resource Directory Entries) Description A series of tables, one for each group of nodes in the tree. All top-level (Type) nodes are listed in the first table. Entries in this table point to second-level tables. Each second-level tree has the same Type identifier but different Name identifiers. Third-level trees have the same Type and Name identifiers but different Language identifiers. Each individual table is immediately followed by directory entries, in which each entry has: 1) a name or numeric identifier, and 2) a pointer to a data description or a table at the next lower level.

Resource Directory Strings Resource Data Description

Two-byte-aligned Unicode strings, which serve as string data pointed to by directory entries. An array of records, pointed to by tables, which describe the actual size and location of the resource data. These records are the leaves in the resource-description tree. Raw data of the resource section. The size and location information in the Resource Data Descriptions delimit the individual regions of resource data.

Resource Data

6.8.1. Resource Directory Table

Each Resource Directory Table has the following format. This data structure should be considered the heading of a table, because the table actually consists of directory entries (see next section) as well as this structure: Offset 0 4 8 10 12 Size 4 4 2 2 2 Field Characteristics Time/Date Stamp Major Version Minor Version Number of Name Entries Description Resource flags, reserved for future use; currently set to zero. Time the resource data was created by the resource compiler. Major version number, set by the user. Minor version number. Number of directory entries, immediately following the table, that use strings to identify Type, Name, or Language (depending on the level of the table). Number of directory entries, immediately following the Name entries, that use numeric identifiers for Type, Name, or Language.

14

Number of ID Entries

6.8.2. Resource Directory Entries

The directory entries make up the rows of a table. Each Resource Directory Entry has the following format. Note that whether the entry is a Name or ID entry is indicated by the Resource Directory Table, which indicates how many Name and ID entries follow it (remember that all the Name entries precede all the ID entries for the table). All entries for the table are sorted in ascending order: the Name entries by case-insensitive string, and the ID entries by numeric value. Offset 0 Size 4 Field Name RVA Description Address of string that gives the Type, Name, or Language identifier, depending on level of table.

0 4 4

4 4 4

Integer ID Data Entry RVA Subdirectory RVA

32-bit integer that identifies Type, Name, or Language. High bit 0. Address of a Resource Data Entry (a leaf). High bit 1. Lower 31 bits are the address of another Resource Directory Table (the next level down).

6.8.3. Resource Directory String

The Resource Directory String area consists of Unicode strings, which are word aligned. These strings are stored together after the last Resource Directory Entry and before the first Resource Data Entry. This minimizes the impact of these variable length strings on the alignment of the fixed-size directory entries. Each Resource Directory String has the following format: Offset 0 2 Size 2 Variable Field Length Unicode String Description Size of string, not including length field itself. Variable-length Unicode string data, word aligned.

6.8.4. Resource Data Entry

Each Resource Data Entry describes an actual unit of raw data in the Resource Data area, and has the following format: Offset 0 4 8 Size 4 4 4 Field Data RVA Size Codepage Description Address of a unit of resource data in the Resource Data area. Size, in bytes, of the resource data pointed to by the Data RVA field. Code page used to decode code point values within the resource data. Typically, the code page would be the Unicode code page.

12

Reserved (must be set to 0)

6.8.5. Resource Example

The resource example shows the PE/COFF representation of the following resource data:
TypeId# 1 1 1 1 2 2 2 2 9 9 NameId# 1 1 2 3 1 2 3 4 1 9 Language ID 0 1 0 0 0 0 0 0 0 0 Resource Data 00010001 10010001 00010002 00010003 00020001 00020002 00020003 00020004 00090001 00090009

9 9

9 9

1 2

10090009 20090009

When this data is encoded, a dump of the PE/COFF Resource Directory results in the following output:
Offset Data 0000: 00000000 00000000 00000000 00030000 (3 entries in this directory) 0010: 00000001 80000028 (TypeId #1, Subdirectory at offset 0x28) 0018: 00000002 80000050 (TypeId #2, Subdirectory at offset 0x50) 0020: 00000009 80000080 (TypeId #9, Subdirectory at offset 0x80) 0028: 00000000 00000000 00000000 00030000 (3 entries in this directory) 0038: 00000001 800000A0 (NameId #1, Subdirectory at offset 0xA0) 0040: 00000002 00000108 (NameId #2, data desc at offset 0x108) 0048: 00000003 00000118 (NameId #3, data desc at offset 0x118) 0050: 00000000 00000000 00000000 00040000 (4 entries in this directory) 0060: 00000001 00000128 (NameId #1, data desc at offset 0x128) 0068: 00000002 00000138 (NameId #2, data desc at offset 0x138) 0070: 00000003 00000148 (NameId #3, data desc at offset 0x148) 0078: 00000004 00000158 (NameId #4, data desc at offset 0x158) 0080: 00000000 00000000 00000000 00020000 (2 entries in this directory) 0090: 00000001 00000168 (NameId #1, data desc at offset 0x168) 0098: 00000009 800000C0 (NameId #9, Subdirectory at offset 0xC0) 00A0: 00000000 00000000 00000000 00020000 (2 entries in this directory) 00B0: 00000000 000000E8 (Language ID 0, data desc at offset 0xE8 00B8: 00000001 000000F8 (Language ID 1, data desc at offset 0xF8 00C0: 00000000 00000000 00000000 00030000 (3 entries in this directory) 00D0: 00000001 00000178 (Language ID 0, data desc at offset 0x178 00D8: 00000001 00000188 (Language ID 1, data desc at offset 0x188 00E0: 00000001 00000198 (Language ID 2, data desc at offset 0x198 00E8: 000001A8 (At offset 0x1A8, for TypeId #1, NameId #1, Language id #0 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 00F8: 000001AC (At offset 0x1AC, for TypeId #1, NameId #1, Language id #1 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0108: 000001B0 (At offset 0x1B0, for TypeId #1, NameId #2, 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0118: 000001B4 (At offset 0x1B4, for TypeId #1, NameId #3, 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0128: 000001B8 (At offset 0x1B8, for TypeId #2, NameId #1, 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0138: 000001BC (At offset 0x1BC, for TypeId #2, NameId #2, 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0148: 000001C0 (At offset 0x1C0, for TypeId #2, NameId #3, 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0158: 000001C4 (At offset 0x1C4, for TypeId #2, NameId #4, 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0168: 000001C8 (At offset 0x1C8, for TypeId #9, NameId #1, 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0178: 000001CC (At offset 0x1CC, for TypeId #9, NameId #9, Language id #0 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0188: 000001D0 (At offset 0x1D0, for TypeId #9, NameId #9,

Language id #1 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved) 0198: 000001D4 (At offset 0x1D4, for TypeId #9, NameId #9, Language id #2 00000004 (4 bytes of data) 00000000 (codepage) 00000000 (reserved)

The raw data for the resources follows:

01A8: 01AC: 01B0: 01B4: 01B8: 01BC: 01C0: 01C4: 01C8: 01CC: 01D0: 01D4: 00010001 10010001 00010002 00010003 00020001 00020002 00020003 00020004 00090001 00090009 10090009 20090009

7. Archive (Library) File Format

The COFF archive format provides a standard mechanism for storing collections of object files. These collections are frequently referred to as libraries in programming documentation. The first eight bytes of an archive consist of the file signature. The rest of the archive consists of a series of archive members, as follows: 1 The first and second members are linker members. Each has of these members has its own format as described in Section 8.3. Typically, a linker places information into these archive members. The linker members contain the directory of the archive. The third member is the longnames member. This member consists of a series of nullterminated ASCII strings, in which each string is the name of another archive member. The rest of the archive consists of standard (object-file) members. Each of these members contains the contents of one object file in its entirety.

2 3

An archive member header precedes each member. The following illustration shows the general structure of an archive: Signature :!<arch>\n

Header 1 Linker Member

st

Header 2nd Linker Member

Header

Longnames Member

Header Contents of OBJ File 1 (COFF format)

Header Contents of OBJ File 2 (COFF format)

. Header Contents of OBJ File N (COFF format)

Figure 4. Archive File Structure

7.1. Archive File Signature

The archive file signature identifies the file type. Any utility (for example, a linker) expecting an archive file as input can check the file type by reading this signature. The signature consists of the following ASCII characters, in which each character below is represented literally, except for the newline (\n) character:
S!<arch>\n

7.2. Archive Member Headers

Each member (linker, longnames, or object-file member) is preceded by a header. An archive member header has the following format, in which each field is an ASCII text string that is left justified and padded with spaces to the end of the field. There is no terminating null character in any of these fields. Each member header starts on the first even address after the end of the previous archive member. Offset 0 Size 16 Field Name Description Name of archive member, with a slash (/) appended to terminate the name. If the first character is a slash, the name has a special interpretation, as described below.

16

12

Date

Date and time the archive member was created: ASCII decimal representation of the number of seconds since 1/1/1970 UCT. ASCII decimal representation of the user ID. ASCII group representation of the group ID. ASCII octal representation of the members file mode. ASCII decimal representation of the total size of the archive member, not including the size of the header. The two bytes in the C string \n.

28 34 40 48

6 6 8 10

User ID Group ID Mode Size

58

End of Header

The Name field has one of the formats shown in the following table. As mentioned above, each of these strings is left justified and padded with trailing spaces within a field of 16 bytes: Contents of Name Field Name/ / // Description The field gives the name of the archive member directly. The archive member is one of the two linker members. Both of the linker members have this name. The archive member is the longname member, which consists of a series of null-terminated ASCII strings. The longnames member is the third archive member, and must always be present even if the contents are empty. The name of the archive member is located at offset n within the longnames member. The number n is the decimal representation of the offset. For example: \26 indicates that the name of the archive member is located 26 bytes beyond the beginning of longnames member contents.

7.3. First Linker Member

The name of the first linker member is \. The first linker member, which is included for backward compatibility, is not used by current linkers but its format must be correct. This linker member provides a directory of symbol names, as does the second linker member. For each symbol, the information indicates where to find the archive member that contains the symbol. The first linker member has the following format. This information appears after the header: Offset 0 Size 4 Field Number of Symbols Description Unsigned long containing the number of symbols indexed. This number is stored in bigendian format. Each object-file member typically defines one or more external symbols.

4*n

Offsets

Array of file offsets to archive member headers, in which n is equal to Number of Symbols. Each number in the array is an unsigned long stored in big-endian format. For each symbol named in the String Table, the corresponding element in the Offsets array gives the location of the archive member that contains the symbol. Series of null-terminated strings that name all the symbols in the directory. Each string begins immediately after the null character in the previous string. The number of strings must be equal to the value of the Number of Symbols fields.

String Table

The elements in the Offsets array must be arranged in ascending order. This fact implies that the symbols listed in the String Table must be arranged according to the order of archive members. For example, all the symbols in the first object-file member would have to be listed before the symbols in the second object file.

7.4. Second Linker Member

The second linker member has the name \ as does the first linker member. Although both the linker members provide a directory of symbols and archive members that contain them, the second linker member is used in preference to the first by all current linkers. The second linker member includes symbol names in lexical order, which enables faster searching by name. The first second member has the following format. This information appears after the header: Offset 0 4 Size 4 4*m Field Number of Members Offsets Description Unsigned long containing the number of archive members. Array of file offsets to archive member headers, arranged in ascending order. Each offset is an unsigned long. The number m is equal to the value of the Number of Members field. Unsigned long containing the number of symbols indexed. Each object-file member typically defines one or more external symbols.

Number of Symbols

2*n

Indices

Array of 1-based indices (unsigned short) which map symbol names to archive member offsets. The number n is equal to Number of Symbols. For each symbol named in the String Table, the corresponding element in the Indices array gives an index into the Offsets array. The Offsets array, in turn, gives the location of the archive member that contains the symbol. Series of null-terminated strings that name all the symbols in the directory. Each string begins immediately after the null byte in the previous string. The number of strings must be equal to the value of the Number of Symbols fields. This table lists all the symbol names in ascending lexical order.

String Table

7.5. Longnames Member

The name of the longnames member is \\. The longnames member is a series of strings of archive member names. A name appears here only when there is insufficient room in the Name field (16 bytes). The longnames member can be empty, though its header must appear. The strings are null-terminated. Each string begins immediately after the null byte in the previous string.

8. Import Library Format

Traditional import libraries, i.e., libraries that describe the exports from one image for use by another, typically follow the layout described in 7. Archive (Library) File Format. The primary difference is that import library members contain pseudo-object files instead of real ones, where each member includes the section contributions needed to build the Import Tables described in Section 6.4 The .idata Section. The linker generates this archive while building the exporting application. The section contributions for an import can be inferred from a small set of information. The linker can either generate the complete, verbose information into the import library for each member at the time of the librarys creation, or it can write only the canonical information to the library and let the application that later uses it generate the necessary data on-the-fly. In an import library with the long format, a single member contains the following information: Archive member header File header Section headers Data corresponding to each of the section headers COFF symbol table Strings In contrast a short import library is written as follows:

Archive member header Import header Null-terminated import name string Null-terminated DLL name string This is sufficient information to accurately reconstruct the entire contents of the member at the time of its use.

8.1. Import Header

The import header contains the following fields and offsets: Offset 0 Size 2 Field Sig1 Description Must be IMAGE_FILE_MACHINE_UNKNOWN. See Section 3.3.1, Machine Types, for more information. Must be 0xFFFF.

2 4 6

2 2 2

Sig2 Version Machine

Number identifying type of target machine. See Section 3.3.1, Machine Types, for more information. Time and date the file was created. Size of the strings following the header. Either the ordinal or the hint for the import, determined by the value in the Name Type field. The import type. See Section 8.2 Import Type for specific values and descriptions. The Import Name Type. See Section 8.3. Import Name Type for specific values and descriptions. Reserved. Must be zero.

8 12 16

4 4 2

Time-Date Stamp Size Of Data Ordinal/Hint

18

2 bits 3 bits

Type Name Type

11 bits

Reserved

This structure is followed by two null-terminated strings describing the imported symbols name, and the DLL from which it came.

8.2. Import Type

The following values are defined for the Type field in the Import Header: Constant
IMPORT_CODE IMPORT_DATA

Value 0 1

Description The import is executable code. The import is data.

IMPORT_CONST

The import was specified as CONST in the .def file.

These values are used to determine which section contributions must be generated by the tool using the library if it must access that data.

8.3. Import Name Type

The null-terminated import symbol name immediately follows its associated Import Header. The following values are defined for the Name Type field in the Import Header, indicating how the name is to be used to generate the correct symbols representing the import: Constant
IMPORT_ORDINAL

Value 0

Description The import is by ordinal. This indicates that the value in the Ordinal/Hint field of the Import Header is the imports ordinal. If this constant is not specified, then the Ordinal/Hint field should always be interpreted as the imports hint. The import name is identical to the public symbol name. The import name is the public symbol name, but skipping the leading ?, @, or optionally _. The import name is the public symbol name, but skipping the leading ?, @, or optionally _, and truncating at the first @.

IMPORT_NAME

1 2 3

IMPORT_NAME_NOPREFIX

IMPORT_NAME_UNDECORATE

Appendix: Example Object File

This section describes the PE/COFF object file produced by compiling the file HELLO2.C, which contains the following small C program:
main() { foo(); } foo() { }

The commands used to compile HELLO.C (with debug information) and generate this example were the following (the -Gy option to the compiler is used, which causes each procedure to be generated as a separate COMDAT section):
cl -c -Zi -Gy hello2.c link -dump -all hello2.obj >hello2.dmp

Here is the resulting file HELLO2.DMP: (The reader is encouraged to experiment with various other examples, in order to clarify the concepts described in this specification.)
Dump of file hello2.obj File Type: COFF OBJECT FILE HEADER VALUES

14C 7 3436E157 2A0 1E 0 0

machine (i386) number of sections time date stamp Sat Oct 04 17:37:43 1997 file pointer to symbol table number of symbols size of optional header characteristics

SECTION HEADER #1 .drectve name 0 physical address 0 virtual address 26 size of raw data 12C file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 100A00 flags Info Remove 1 byte align RAW DATA #1 00000000 2D 64 65 66 61 75 6C 74 | 6C 69 62 3A 4C 49 42 43 -default|lib:LIBC 00000010 20 2D 64 65 66 61 75 6C | 74 6C 69 62 3A 4F 4C 44 -defaul|tlib:OLD 00000020 4E 41 4D 45 53 20 NAMES Linker Directives -----------------defaultlib:LIBC -defaultlib:OLDNAMES SECTION HEADER #2 .debug$S name 0 physical address 0 virtual address 5C size of raw data 152 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 42100048 flags No Pad Initialized Data Discardable 1 byte align Read Only RAW DATA #2 00000000 02 00000010 6C 00000020 4D 00000030 2D 00000040 69 00000050 65 00 6F 69 62 7A 72 00 32 63 69 69 73 00 2E 72 74 6E 69 11 6F 6F 20 67 6F 00 62 73 43 20 6E 09 6A 6F 2F 43 20 00 43 66 43 6F 31 | | | | | | 00 00 74 2B 6D 31 00 01 20 2B 70 2E 00 00 28 20 69 30 00 05 52 4F 6C 30 0A 00 29 70 65 68 00 20 74 72 65 00 33 69 20 6C 3C 32 6D 56 ........|.....hel lo2.objC|.......< Microsof|t (R) 32 -bit C/C|++ Optim izing Co|mpiler V ersion 1|1.00

SECTION HEADER #3 .text name 0 physical address 0 virtual address A size of raw data 1AE file pointer to raw data 1B8 file pointer to relocation table 1C2 file pointer to line numbers 1 number of relocations 3 number of line numbers 60501020 flags Code Communal; sym= _main 16 byte align Execute Read RAW DATA #3

00000000

55 8B EC E8 00 00 00 00 | 5D C3 Symbol Index -------13

U....|]. Symbol Name -----_foo

RELOCATIONS #3 Offset -------00000004 Type ---------------REL32 Applied To ----------------00000000

LINENUMBERS #3 Symbol index: 8 Base line number: Symbol name = _main 00000003( 3) 00000008( 4) SECTION HEADER #4 .debug$S name 0 physical address 0 virtual address 30 size of raw data 1D4 file pointer to raw data 204 file pointer to relocation table 0 file pointer to line numbers 2 number of relocations 0 number of line numbers 42101048 flags No Pad Initialized Data Communal (no symbol) Discardable 1 byte align Read Only RAW DATA #4 00000000 2A 00 0B 10 00 00 00 00 | 00 00 00 00 00 00 00 00 *.......|........ 00000010 0A 00 00 00 03 00 00 00 | 08 00 00 00 01 10 00 00 ........|........ 00000020 00 00 00 00 00 00 01 04 | 6D 61 69 6E 02 00 06 00 ........|main.... RELOCATIONS #4 Offset -------00000020 00000024 Type ---------------SECREL SECTION Applied To ----------------00000000 0000 Symbol Index -------8 8 Symbol Name -----_main _main 2

SECTION HEADER #5 .text name 0 physical address 0 virtual address 5 size of raw data 218 file pointer to raw data 0 file pointer to relocation table 21D file pointer to line numbers 0 number of relocations 2 number of line numbers 60501020 flags Code Communal; sym= _foo 16 byte align Execute Read RAW DATA #5 00000000 55 8B EC 5D C3 LINENUMBERS #5 Symbol index: Symbol name = _foo 00000003( 8) 13 Base line number: 7 U].

SECTION HEADER #6 .debug$S name 0 physical address 0 virtual address 2F size of raw data 229 file pointer to raw data

258 0 2 0 42101048

file pointer to relocation table file pointer to line numbers number of relocations number of line numbers flags No Pad Initialized Data Communal (no symbol) Discardable 1 byte align Read Only

RAW DATA #6 00000000 29 00 0B 10 00 00 00 00 | 00 00 00 00 00 00 00 00 ).......|........ 00000010 05 00 00 00 03 00 00 00 | 03 00 00 00 01 10 00 00 ........|........ 00000020 00 00 00 00 00 00 01 03 | 66 6F 6F 02 00 06 00 ........|foo.... RELOCATIONS #6 Offset -------00000020 00000024 Type ---------------SECREL SECTION Applied To ----------------00000000 0000 Symbol Index -------13 13 Symbol Name -----_foo _foo

SECTION HEADER #7 .debug$T name 0 physical address 0 virtual address 34 size of raw data 26C file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 42100048 flags No Pad Initialized Data Discardable 1 byte align Read Only RAW DATA #7 00000000 02 00000010 22 00000020 35 00000030 70 00 65 30 64 00 3A 5C 62 00 2E 00 16 00 | 33 E1 36 34 01 00 00 00 ........|364.... 5C 62 62 74 5C | 74 6F 6F 6C 73 5C 76 63 "e:\bbt\|tools\vc 62 69 6E 5C 78 | 38 36 5C 76 63 35 30 2E 50\bin\x|86\vc50. F1 pdb.

COFF SYMBOL TABLE 000 00000000 DEBUG notype Filename | .file hello2.c 002 00000000 SECT1 notype Static | .drectve Section length 26, #relocs 0, #linenums 0, checksum 0 004 00000000 SECT2 notype Static | .debug$S Section length 5C, #relocs 0, #linenums 0, checksum 0 006 00000000 SECT3 notype Static | .text Section length A, #relocs 1, #linenums 3, checksum 0, selection (pick no duplicates) 008 00000000 SECT3 notype () External | _main tag index 0000000A size 0000000A lines 000001C2 next function 00000013 00A 00000000 SECT3 notype BeginFunction | .bf line# 0002 end 00000015 00C 00000003 SECT3 notype .bf or.ef | .lf 00D 0000000A SECT3 notype EndFunction | .ef line# 0004 00F 00000000 SECT4 notype Static | .debug$S Section length 30, #relocs 2, #linenums 0, checksum 0, selection (pick associative Section 3) 011 00000000 SECT5 notype Static | .text Section length 5, #relocs 0, #linenums 2, checksum 0, selection (pick no duplicates) 013 00000000 SECT5 notype () External | _foo tag index 00000015 size 00000005 lines 0000021D next function 00000000 015 00000000 SECT5 notype BeginFunction | .bf line# 0007 end 00000000 017 00000002 SECT5 notype .bf or.ef | .lf

5 1

018 00000005 SECT5 notype EndFunction | .ef line# 0008 01A 00000000 SECT6 notype Static | .debug$S Section length 2F, #relocs 2, #linenums 0, checksum (pick associative Section 5) 01C 00000000 SECT7 notype Static | .debug$T Section length 34, #relocs 0, #linenums 0, checksum String Table Size = 0x0 bytes Summary BB 34 26 F .debug$S .debug$T .drectve .text

0, selection 0

Here is a hexadecimal dump of HELLO2.OBJ:

hello2.obj: 00000000 4c 00000010 00 00000020 00 00000030 00 00000040 75 00000050 52 00000060 48 00000070 00 00000080 c2 00000090 75 000000a0 d4 000000b0 48 000000c0 00 000000d0 1d 000000e0 75 000000f0 29 00000100 48 00000110 00 00000120 00 00000130 61 00000140 66 00000150 53 00000160 65 00000170 00 00000180 33 00000190 69 000001a0 20 000001b0 ec 000001c0 14 000001d0 00 000001e0 00 000001f0 01 00000200 02 00000210 00 00000220 00 00000230 00 00000240 00 00000250 03 00000260 0b 00000270 2e 00000280 62 00000290 69 000002a0 2e 000002b0 67 000002c0 00 000002d0 01 000002e0 00 000002f0 00 00000300 00 00000310 74 00000320 00 00000330 5f 00000340 02 00000350 00 01 00 00 00 67 01 00 00 01 67 01 10 00 02 67 02 10 00 00 75 61 20 6c 3c 32 6d 56 e8 00 00 00 10 00 00 00 00 03 66 00 00 62 6e 66 01 00 00 00 00 00 00 00 6d 01 00 07 00 00 00 24 00 10 00 00 24 00 10 00 00 24 00 10 00 00 6c 75 02 6c 4d 2d 69 65 00 08 02 00 00 06 08 00 00 00 6f 24 16 74 5c 69 68 00 00 00 00 00 00 01 61 0a 00 00 00 00 00 53 00 42 00 00 53 00 42 00 00 53 00 42 00 00 74 6c 00 6f 69 62 7a 72 00 00 00 00 00 00 00 03 00 00 6f 00 00 5c 78 6c 65 00 00 00 00 00 00 00 69 00 00 57 2e 26 00 00 00 2e 0a 01 00 04 2e 05 00 00 58 2e 34 00 6c 74 00 32 63 69 69 73 00 00 2a 0a 00 20 00 00 00 00 02 00 33 74 38 65 6c 2e 03 00 02 00 00 03 6e 00 2e e1 64 00 00 00 00 74 00 00 00 02 74 00 00 00 02 64 00 00 69 6c 00 2e 72 74 6e 69 00 00 00 00 00 00 00 00 00 01 00 00 e1 6f 36 00 6c 64 01 00 00 00 00 00 00 00 62 36 72 00 00 00 00 65 00 03 00 00 65 00 02 00 00 65 00 00 62 69 11 6f 6f 20 67 6f 5d 00 0b 00 00 00 0a 00 00 10 06 13 36 6f 5c 00 6f 72 26 00 00 00 00 00 00 0a 66 34 65 00 00 00 00 78 00 00 00 00 78 00 00 00 00 62 00 00 3a 62 00 62 73 43 20 6e c3 00 10 00 00 00 00 01 00 00 00 00 34 6c 76 00 32 65 00 00 00 00 00 00 00 00 00 a0 63 2c 00 00 00 74 ae 20 00 00 74 18 20 00 00 75 6c 48 4c 3a 09 6a 6f 2f 43 20 04 03 00 03 00 08 55 00 00 00 20 00 01 73 63 00 2e 63 00 2e 03 00 03 00 00 00 00 02 74 01 0a 00 00 00 01 10 00 00 00 02 10 00 00 67 02 00 49 4f 00 43 66 43 6f 31 00 00 00 00 00 00 8b 29 05 00 00 00 00 5c 35 00 63 74 00 64 01 00 00 00 00 00 00 00 76 00 10 00 00 00 00 50 00 00 00 00 50 00 00 24 00 10 42 4c 00 00 74 2b 6d 31 00 00 00 00 01 00 ec 00 00 00 00 0a 00 76 30 00 00 76 00 65 5c 00 00 00 00 c2 00 00 65 00 00 00 00 00 00 60 00 00 00 00 60 00 00 54 00 42 43 44 00 01 20 2b 70 2e 00 00 00 00 04 00 5d 0b 00 00 00 00 00 63 2e 00 00 65 00 62 00 00 00 00 00 01 00 1e 00 00 2e 5c 00 00 b8 2e 30 02 00 00 2e 2f 02 00 00 2d 20 4e 00 00 28 20 69 30 13 01 00 08 6d 0b c3 10 00 00 13 02 22 35 70 fe 00 00 00 75 00 2e 03 01 03 00 00 00 00 00 64 00 00 00 01 64 00 00 00 00 64 00 00 00 00 64 2d 41 00 05 52 4f 6c 30 00 00 00 00 61 00 13 00 03 00 00 00 65 30 64 ff 00 00 00 67 00 74 01 00 00 00 00 00 00 00 65 00 00 00 00 65 00 00 00 00 65 00 00 00 00 65 64 4d 0a 00 29 70 65 55 00 08 00 00 69 24 00 00 00 00 00 00 3a 5c 62 00 00 00 00 24 00 65 0a 00 20 13 00 00 00 00 62 00 00 00 00 62 00 00 00 00 62 00 00 00 00 66 65 45 68 00 20 74 72 8b 00 00 00 00 6e 00 00 00 00 01 00 00 5c 62 f1 00 00 00 00 53 00 78 00 00 00 00 00 L...W.64........ .....drectve.... ....&...,....... .............deb ug$S........\... R............... H..B.text....... ................ ........ .P`.deb ug$S........0... ................ H..B.text....... ................ ........ .P`.deb ug$S......../... )...X........... H..B.debug$T.... ....4...l....... ........H..B-def aultlib:LIBC -de faultlib:OLDNAME S .............h ello2.objC...... .<Microsoft (R) 32-bit C/C++ Opt imizing Compiler Version 11.00U. ......]......... ................ ....*........... ................ ............main .... .........$. ........U..].... .........)...... ................ ................ .foo.... ....... ..$............. ....3.64...."e:\ bbt\tools\vc50\b in\x86\vc50.pdb. .file........... g.hello2.c...... .....drectve.... ......&......... .........debug$S ..........\..... .............tex t............... ................ _main......... . ................ .....bf.........

00000360 00000370 00000380 00000390 000003a0 000003b0 000003c0 000003d0 000003e0 000003f0 00000400 00000410 00000420 00000430 00000440 00000450 00000460 00000470 00000480 00000490 000004a0 000004b0

03 00 03 00 04 65 30 00 00 00 00 1d 00 07 66 2e 65 00 06 00 00 00

00 00 00 00 00 62 00 00 00 00 00 02 00 00 00 65 01 00 00 00 00 00

00 15 00 0a 00 75 00 2e 03 01 05 00 00 00 00 66 00 00 00 05 00 00

00 00 00 00 00 67 00 74 01 00 00 00 00 00 00 00 00 00 00 00 00 00

65 00 03 00 00 24 02 65 05 00 20 00 00 00 00 00 00 2e 03 05 07 00

01 00 00 00 00 53 00 78 00 00 00 00 00 00 00 00 00 64 01 00 00 00

00 00 00 03 00 00 00 74 00 5f 02 00 05 00 02 00 08 65 2f 00 00 00

00 00 00 00 00 00 00 00 00 66 01 00 00 00 00 00 00 62 00 00 00 00

00 2e 65 00 00 00 00 00 00 6f 15 00 00 00 00 05 00 75 00 2e 03 00

00 6c 00 00 00 00 00 00 00 6f 00 00 00 00 00 00 00 67 00 64 01 00

02 66 2e 65 00 04 00 00 02 00 00 2e 65 00 05 00 00 24 02 65 34 00

00 00 65 01 00 00 00 00 00 00 00 62 01 00 00 00 00 53 00 62 00 00

00 00 66 00 00 00 03 00 00 00 05 66 00 00 00 05 00 00 00 75 00 04

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 67 00 00

00 00 00 00 2e 03 05 05 00 00 00 00 00 2e 65 00 00 00 00 24 00 00

00 00 00 00 64 01 00 00 00 00 00 00 00 6c 00 00 00 00 00 54 00 00

....e........... .........lf..... ........e..ef... ..........e..... ...............d ebug$S.......... 0............... ...text......... ................ ......_foo...... .... ........... ...........bf... ..........e..... ...............l f.............e. .ef............. e............... .....debug$S.... ....../......... .........debug$T ..........4..... ................

Appendix: Calculating Image Message Digests

Several Attribute Certificates are expected to be used to verify the integrity of the images. That is, they will be used to ensure that a particular image file, or part of that image file, has not been altered in any way from its original form. To accomplish this task, these certificates will typically include something called a Message Digest. Message digests are similar to a file checksum in that they produce a small value that relates to the integrity of a file. A checksum is produced by a simple algorithm and its use is primarily to detect memory failures. That is, it is used to detect whether or not a block of memory on disk has gone bad and the values stored there have become corrupted. A message digest is similar to a checksum in that it will also detect file corruption. However, unlike most checksum algorithms, a message digest also has the property that it is very difficult to modify a file such that it will have the same message digest as its original (unmodified) form. That is, a checksum is intended to detect simple memory failures leading to corruption, but a message digest may be used to detect intentional, and even crafty modifications to a file, such as those introduced by viruses, hackers, or Trojan Horse programs. It is not desirable to include all image file data in the calculation of a message digest. In some cases it simply presents undesirable characteristics (like the file is no longer localizable without regenerating certificates) and in other cases it is simply impossible. For example, it is not possible to include all information within an image file in a message digest, then insert a certificate containing that message digest in the file, and later be able to generate an identical message digest by including all image file data in the calculation again (since the file now contains a certificate that wasnt originally there). This specification does not attempt to architect what each Attribute Certificate may be used for, or which fields or sections of an image file must be included in a message digest. However, this section does identify which fields you may not want to or may not include in a message digest. In addition to knowing which fields are and are not included in the calculation of a message digest, it is important to know the order in which the contents of the image are presented to the digest algorithm. This section specifies that order.

Fields Not To Include In Digests

There are some parts of an image that you may not want to include in any message digest. This section identifies those parts, and describes why you might not want to include them in a message digest. 1. Information related to Attribute Certificates - It is not possible to include a certificate in the calculation of a message digest that resides within the certificate. Since certificates can be added to or removed from an image without effecting the overall integrity of the image this is not a problem. Therefore, it is best to leave all attribute certificates out of the image even if there are certificates already in the image at the time you are calculating your message digest. There is no guarantee those certificates will still be there later, or that other certificates wont have been added. To exclude attribute certificate information from the message digest calculation, you must exclude the following information from that calculation: The Certificate Table field of the Optional Header Data Directories. The Certificate Table and corresponding certificates pointed to by the Certificate Table field listed immediately above.

2. Debug information - Debug information may generally be considered advisory (to debuggers) and does not effect the actual integrity of the executable program. It is quite literally possible to remove debug information from an image after a product has been delivered and not effect the functionality of the program. This is, in fact, a disk saving measure that is sometimes utilized. If you do not want to include debug information in your message digest, then you should not include the following information in your message digest calculation: The Debug entry of the Data Directory in with optional header. The .debug section

3. File Checksum field of the Windows NT-Specific Fields of the Optional Header - This checksum includes the entire file (including any attribute certificates included in the file) and will, in all likelihood, be different after inserting your certificate than when you were originally calculating a message digest to include in your certificate. 4. Unused, or obsolete fields - There are several fields that are either unused or obsolete. The value of these fields is undefined and may change after you calculate your message digest. These fields include: Reserved field of the Optional Header Windows NT-Specific Fields (offset 52). The DLL Flags field of the Optional Header Windows NT-Specific Fields. This field is obsolete. Loader Flags field of the Optional Header Windows NT-Specific Fields. This field is obsolete. Reserved entries of the Data Directory in the object header.

5. Resources (makes localization easier) - depending upon the specifics of your Attribute Certificate, it may be desirable or undesirable to include resources in the message digest. If you want to allow localization without the generation of new certificates, then you do not want to include resources in your message digest. If the values of the resources are critical to your application, then you probably do want them included in your message digest, and you will accept the overhead of generating a certificate for each localized copy of the image. If you

do not want to include resources in your message digest, then you should not include the following information in the message digest calculation: Resource Table entry of the Optional Header Data Directory. The .rsrc section.