Formato PE – Documentação oficial Microsoft, livremente traduzido

 

Esta especificação descreve a estrutura de arquivos executáveis (imagem) e arquivos de objeto na família de sistemas operacionais Windows. Esses arquivos são chamados de arquivos Portable Executable (PE) e Common Object File Format (COFF), respectivamente.

 

Observação

Este documento é fornecido para ajudar no desenvolvimento de ferramentas e aplicativos para Windows, mas não é garantido que seja uma especificação completa em todos os aspectos. A Microsoft se reserva o direito de alterar este documento sem aviso prévio. Veja em: https://docs.microsoft.com/pt-br/windows/win32/debug/pe-format, acesso em 23/04/2020.

 

Esta revisão da Especificação de formato de arquivo executável portátil e de objeto comum da Microsoft substitui todas as revisões anteriores desta especificação.

 

 

Conceitos Gerais

Este documento especifica a estrutura dos arquivos executáveis (imagem) e dos objetos da família de sistemas operacionais Microsoft Windows. Esses arquivos são chamados de arquivos Portable Executable (PE) e Common Object File Format (COFF), respectivamente. O nome “Executável portátil” refere-se ao fato de que o formato não é específico da arquitetura.

 

Certos conceitos que aparecem ao longo desta especificação são descritos na tabela a seguir:

TABELA 1

Name

Description

attribute certificate

A certificate that is used to associate verifiable statements with an image. A number of different verifiable statements can be associated with a file; one of the most useful ones is a statement by a software manufacturer that indicates 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. Therefore, it is very difficult to modify a file to have the same message digest as the original file. The statement can be verified as being made by the manufacturer by using public or private key cryptography schemes. This document describes details about attribute certificates other than to allow for their insertion into image files.

date/time stamp

A stamp that is used for different purposes in several places in a PE or COFF file. In most cases, the format of each stamp is the same as that used by the time functions in the C run-time library. For exceptions, see the descripton of IMAGE_DEBUG_TYPE_REPRO in Debug Type. If the stamp value is 0 or 0xFFFFFFFF, it does not represent a real or meaningful date/time stamp.

file pointer

The 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.

linker

A reference to the linker that is provided with Microsoft Visual Studio.

object file

A file that is 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.

reserved, must be 0

A description of a field that indicates that the value of the field must be zero for generators and consumers must ignore the field.

RVA

Relative virtual address. In an image file, the address of an item after it is loaded into memory, with the base address of the image file subtracted from it. The RVA of an item almost always differs 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 (described later in this table), to which a relocation is later applied during linking. For simplicity, a compiler should just set the first RVA in each section to zero.

section

The basic unit of code or data within a PE or COFF file. For example, all code in an object file 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 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 , which have special purposes.

VA

virtual address. Same as RVA, except that the base address of the image file is not subtracted. The address is called a “VA” because Windows creates a distinct VA space for each process, independent of physical memory. For almost all purposes, a VA should be considered just an address. A VA is not as predictable as an RVA because the loader might not load the image at its preferred location.

 

 

 

visão global

A lista a seguir descreve o formato executável do Microsoft PE, com a base do cabeçalho da imagem na parte superior. A seção do cabeçalho EXE compatível do MS-DOS 2.0 até a seção não utilizada imediatamente antes do cabeçalho do PE é a seção do MS-DOS 2.0 e é usada apenas para compatibilidade com o MS-DOS.

 

  • MS-DOS 2.0 Compatible EXE Header
  • unused
  • OEM Identifier

OEM Information

Offset to PE Header

  • MS-DOS 2.0 Stub Program and Relocation Table
  • unused
  • PE Header (aligned on 8-byte boundary)
  • Section Headers
  • Image Pages:

import info

export info

base relocations

resource info

 

A lista a seguir descreve o formato de módulo de objeto do Microsoft COFF:

  • Microsoft COFF Header
  • Section Headers
  • Raw Data:

code

data

debug info

relocations

 

Cabeçalhos de arquivo

O cabeçalho do arquivo PE consiste em um stub do Microsoft MS-DOS, a assinatura PE, o cabeçalho do arquivo COFF e um cabeçalho opcional. Um cabeçalho de arquivo de objeto COFF consiste em um cabeçalho de arquivo COFF e um cabeçalho opcional. Nos dois casos, os cabeçalhos dos arquivos são seguidos imediatamente pelos cabeçalhos das seções.

 

Stub do MS-DOS (somente imagem)

O stub do MS-DOS é um aplicativo válido executado no MS-DOS. É colocado na frente da imagem EXE. O vinculador coloca um stub padrão aqui, que imprime a mensagem “Este programa não pode ser executado no modo DOS” quando a imagem é executada no MS-DOS. O usuário pode especificar um stub diferente usando a opção do vinculador / STUB.

No local 0x3c, o stub tem o deslocamento do arquivo para a assinatura do PE. Essas informações permitem que o Windows execute corretamente o arquivo de imagem, mesmo que ele tenha um stub do MS-DOS. Esse deslocamento de arquivo é colocado no local 0x3c durante a vinculação.

 

Assinatura (apenas imagem)

Após o stub do MS-DOS, no deslocamento do arquivo especificado no deslocamento 0x3c, é uma assinatura de 4 bytes que identifica o arquivo como um arquivo de imagem no formato PE. Essa assinatura é “PE\ 0\0” (as letras “P” e “E” seguidas por dois bytes nulos).

 

Cabeçalho do arquivo COFF (objeto e imagem)

No início de um arquivo de objeto, ou imediatamente após a assinatura de um arquivo de imagem, existe um cabeçalho de arquivo COFF padrão no seguinte formato. Observe que o carregador do Windows limita o número de seções a 96.

 

TABELA 2

TABELA 2

Offset

Size

Field

Description

0

2

Machine

The number that identifies the type of target machine. For more information, see Machine Types.

2

2

NumberOfSections

The number of sections. This indicates the size of the section table, which immediately follows the headers.

4

4

TimeDateStamp

The low 32 bits of the number of seconds since 00:00 January 1, 1970 (a C run-time time_t value), that indicates when the file was created.

8

4

PointerToSymbolTable

The file offset of the COFF symbol table, or zero if no COFF symbol table is present. This value should be zero for an image because COFF debugging information is deprecated.

12

4

NumberOfSymbols

The number of entries in the symbol table. This data can be used to locate the string table, which immediately follows the symbol table. This value should be zero for an image because COFF debugging information is deprecated.

16

2

SizeOfOptionalHeader

The size of the optional header, which is required for executable files but not for object files. This value should be zero for an object file. For a description of the header format, see Optional Header (Image Only).

18

2

Characteristics

The flags that indicate the attributes of the file. For specific flag values, see Characteristics.

 

 

Tipos de máquinas

O campo Máquina possui um dos seguintes valores que especifica seu tipo de CPU. Um arquivo de imagem pode ser executado apenas na máquina especificada ou em um sistema que emula a máquina especificada.

 

TABELA 3

Constant

Value

Description

IMAGE_FILE_MACHINE_UNKNOWN

0x0

The contents of this field are assumed to be applicable to any machine type

IMAGE_FILE_MACHINE_AM33

0x1d3

Matsushita AM33

IMAGE_FILE_MACHINE_AMD64

0x8664

x64

IMAGE_FILE_MACHINE_ARM

0x1c0

ARM little endian

IMAGE_FILE_MACHINE_ARM64

0xaa64

ARM64 little endian

IMAGE_FILE_MACHINE_ARMNT

0x1c4

ARM Thumb-2 little endian

IMAGE_FILE_MACHINE_EBC

0xebc

EFI byte code

IMAGE_FILE_MACHINE_I386

0x14c

Intel 386 or later processors and compatible processors

IMAGE_FILE_MACHINE_IA64

0x200

Intel Itanium processor family

IMAGE_FILE_MACHINE_M32R

0x9041

Mitsubishi M32R little endian

IMAGE_FILE_MACHINE_MIPS16

0x266

MIPS16

IMAGE_FILE_MACHINE_MIPSFPU

0x366

MIPS with FPU

IMAGE_FILE_MACHINE_MIPSFPU16

0x466

MIPS16 with FPU

IMAGE_FILE_MACHINE_POWERPC

0x1f0

Power PC little endian

IMAGE_FILE_MACHINE_POWERPCFP

0x1f1

Power PC with floating point support

IMAGE_FILE_MACHINE_R4000

0x166

MIPS little endian

IMAGE_FILE_MACHINE_RISCV32

0x5032

RISC-V 32-bit address space

IMAGE_FILE_MACHINE_RISCV64

0x5064

RISC-V 64-bit address space

IMAGE_FILE_MACHINE_RISCV128

0x5128

RISC-V 128-bit address space

IMAGE_FILE_MACHINE_SH3

0x1a2

Hitachi SH3

IMAGE_FILE_MACHINE_SH3DSP

0x1a3

Hitachi SH3 DSP

IMAGE_FILE_MACHINE_SH4

0x1a6

Hitachi SH4

IMAGE_FILE_MACHINE_SH5

0x1a8

Hitachi SH5

IMAGE_FILE_MACHINE_THUMB

0x1c2

Thumb

IMAGE_FILE_MACHINE_WCEMIPSV2

0x169

MIPS little-endian WCE v2

 

 

Características

O campo Características contém sinalizadores que indicam atributos do objeto ou arquivo de imagem. Os seguintes sinalizadores estão atualmente definidos:

TABELA 4

Flag

Value

Description

IMAGE_FILE_RELOCS_STRIPPED

0x0001

Image only, Windows CE, and Microsoft Windows NT and later. This 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. The default behavior of the linker is to strip base relocations from executable (EXE) files.

IMAGE_FILE_EXECUTABLE_IMAGE

0x0002

Image only. This indicates that the image file is valid and can be run. If this flag is not set, it indicates a linker error.

IMAGE_FILE_LINE_NUMS_STRIPPED

0x0004

COFF line numbers have been removed. This flag is deprecated and should be zero.

IMAGE_FILE_LOCAL_SYMS_STRIPPED

0x0008

COFF symbol table entries for local symbols have been removed. This flag is deprecated and should be zero.

IMAGE_FILE_AGGRESSIVE_WS_TRIM

0x0010

Obsolete. Aggressively trim working set. This flag is deprecated for Windows 2000 and later and must be zero.

IMAGE_FILE_LARGE_ADDRESS_ AWARE

0x0020

Application can handle > 2-GB addresses.

0x0040

This flag is reserved for future use.

IMAGE_FILE_BYTES_REVERSED_LO

0x0080

Little endian: the least significant bit (LSB) precedes the most significant bit (MSB) in memory. This flag is deprecated and should be zero.

IMAGE_FILE_32BIT_MACHINE

0x0100

Machine is based on a 32-bit-word architecture.

IMAGE_FILE_DEBUG_STRIPPED

0x0200

Debugging information is removed from the image file.

IMAGE_FILE_REMOVABLE_RUN_ FROM_SWAP

0x0400

If the image is on removable media, fully load it and copy it to the swap file.

IMAGE_FILE_NET_RUN_FROM_SWAP

0x0800

If the image is on network media, fully load it and copy it to the swap file.

IMAGE_FILE_SYSTEM

0x1000

The image file is a system file, not a user program.

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.

IMAGE_FILE_UP_SYSTEM_ONLY

0x4000

The file should be run only on a uniprocessor machine.

IMAGE_FILE_BYTES_REVERSED_HI

0x8000

Big endian: the MSB precedes the LSB in memory. This flag is deprecated and should be zero.

 

 

Cabeçalho opcional (apenas imagem)

Todo arquivo de imagem possui um cabeçalho opcional que fornece informações ao carregador. Esse cabeçalho é opcional no sentido de que alguns arquivos (especificamente, arquivos de objetos) não o possuem. Para arquivos de imagem, esse cabeçalho é necessário. Um arquivo de objeto pode ter um cabeçalho opcional, mas geralmente esse cabeçalho não tem função em um arquivo de objeto, exceto para aumentar seu tamanho.

Observe que o tamanho do cabeçalho opcional não é fixo. O campo SizeOfOptionalHeader no cabeçalho COFF deve ser usado para validar que uma análise no arquivo para um diretório de dados específico não ultrapasse SizeOfOptionalHeader. Para obter mais informações, consulte Cabeçalho do arquivo COFF (Objeto e imagem).

O campo NumberOfRvaAndSizes do cabeçalho opcional também deve ser usado para garantir que nenhum probe para uma entrada específica do diretório de dados ultrapasse o cabeçalho opcional. Além disso, é importante validar o número mágico do cabeçalho opcional para compatibilidade de formato.

O número mágico do cabeçalho opcional determina se uma imagem é um executável PE32 ou PE32 +.

TABELA 5

Magic number

PE format

0x10b

PE32

0x20b

PE32+

 

As imagens PE32 + permitem um espaço de endereço de 64 bits, limitando o tamanho da imagem a 2 gigabytes. Outras modificações do PE32 + são abordadas em suas respectivas seções.

O cabeçalho opcional em si possui três partes principais.

TABELA 6

Offset (PE32/PE32+)

Size (PE32/PE32+)

Header part

Description

0

28/24

Standard fields

Fields that are defined for all implementations of COFF, including UNIX.

28/24

68/88

Windows-specific fields

Additional fields to support specific features of Windows (for example, subsystems).

96/112

Variable

Data directories

Address/size pairs for special tables that are found in the image file and are used by the operating system (for example, the import table and the export table).

 

 

Campos padrão do cabeçalho opcional (apenas imagem)

Os oito primeiros campos do cabeçalho opcional são campos padrão definidos para cada implementação do COFF. Esses campos contêm informações gerais úteis para carregar e executar um arquivo executável. Eles não são alterados para o formato PE32 +.

TABELA 7

Offset

Size

Field

Description

0

2

Magic

The unsigned integer that identifies the state of the image file. The most common number is 0x10B, which identifies it as a normal executable file. 0x107 identifies it as a ROM image, and 0x20B identifies it as a PE32+ executable.

2

1

MajorLinkerVersion

The linker major version number.

3

1

MinorLinkerVersion

The linker minor version number.

4

4

SizeOfCode

The size of the code (text) section, or the sum of all code sections if there are multiple sections.

8

4

SizeOfInitializedData

The size of the initialized data section, or the sum of all such sections if there are multiple data sections.

12

4

SizeOfUninitializedData

The size of the uninitialized data section (BSS), or the sum of all such sections if there are multiple BSS sections.

16

4

AddressOfEntryPoint

The address of the entry point relative to the image base when the 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 no entry point is present, this field must be zero.

20

4

BaseOfCode

The address that is relative to the image base of the beginning-of-code section when it is loaded into memory.

 

O PE32 contém esse campo adicional, ausente no PE32 +, após BaseOfCode.

TABELA 8

Offset

Size

Field

Description

24

4

BaseOfData

The address that is relative to the image base of the beginning-of-data section when it is loaded into memory.

 

Campos específicos do Windows do cabeçalho opcional (apenas imagem)

Os próximos 21 campos são uma extensão do formato de cabeçalho opcional COFF. Eles contêm informações adicionais exigidas pelo vinculador e carregador no Windows.

TABELA 9

Offset (PE32/ PE32+)

Size (PE32/ PE32+)

Field

Description

28/24

4/8

ImageBase

The preferred address of the first byte of image when loaded into memory; must be a multiple of 64 K. The default for DLLs is 0x10000000. The default for Windows CE EXEs is 0x00010000. The default for Windows NT, Windows 2000, Windows XP, Windows 95, Windows 98, and Windows Me is 0x00400000.

32/32

4

SectionAlignment

The alignment (in bytes) of sections when they are loaded into memory. It must be greater than or equal to FileAlignment. The default is the page size for the architecture.

36/36

4

FileAlignment

The alignment factor (in bytes) that is used to align the raw data of sections in the image file. The value should be a power of 2 between 512 and 64 K, inclusive. The default is 512. If the SectionAlignment is less than the architecture’s page size, then FileAlignment must match SectionAlignment.

40/40

2

MajorOperatingSystemVersion

The major version number of the required operating system.

42/42

2

MinorOperatingSystemVersion

The minor version number of the required operating system.

44/44

2

MajorImageVersion

The major version number of the image.

46/46

2

MinorImageVersion

The minor version number of the image.

48/48

2

MajorSubsystemVersion

The major version number of the subsystem.

50/50

2

MinorSubsystemVersion

The minor version number of the subsystem.

52/52

4

Win32VersionValue

Reserved, must be zero.

56/56

4

SizeOfImage

The size (in bytes) of the image, including all headers, as the image is loaded in memory. It must be a multiple of SectionAlignment.

60/60

4

SizeOfHeaders

The combined size of an MS-DOS stub, PE header, and section headers rounded up to a multiple of FileAlignment.

64/64

4

CheckSum

The image file checksum. The algorithm for computing the checksum 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 is loaded into a critical Windows process.

68/68

2

Subsystem

The subsystem that is required to run this image. For more information, see Windows Subsystem.

70/70

2

DllCharacteristics

For more information, see DLL Characteristics later in this specification.

72/72

4/8

SizeOfStackReserve

The size of the stack to reserve. Only SizeOfStackCommit is committed; the rest is made available one page at a time until the reserve size is reached.

76/80

4/8

SizeOfStackCommit

The size of the stack to commit.

80/88

4/8

SizeOfHeapReserve

The size of the local heap space to reserve. Only SizeOfHeapCommit is committed; the rest is made available one page at a time until the reserve size is reached.

84/96

4/8

SizeOfHeapCommit

The size of the local heap space to commit.

88/104

4

LoaderFlags

Reserved, must be zero.

92/108

4

NumberOfRvaAndSizes

The number of data-directory entries in the remainder of the optional header. Each describes a location and size.

 

 

Subsistema Windows

Os seguintes valores definidos para o campo Subsistema do cabeçalho opcional determinam qual subsistema Windows (se houver) é necessário para executar a imagem.

TABELA 10

Constant

Value

Description

IMAGE_SUBSYSTEM_UNKNOWN

0

An unknown subsystem

IMAGE_SUBSYSTEM_NATIVE

1

Device drivers and native Windows processes

IMAGE_SUBSYSTEM_WINDOWS_GUI

2

The Windows graphical user interface (GUI) subsystem

IMAGE_SUBSYSTEM_WINDOWS_CUI

3

The Windows character subsystem

IMAGE_SUBSYSTEM_OS2_CUI

5

The OS/2 character subsystem

IMAGE_SUBSYSTEM_POSIX_CUI

7

The Posix character subsystem

IMAGE_SUBSYSTEM_NATIVE_WINDOWS

8

Native Win9x driver

IMAGE_SUBSYSTEM_WINDOWS_CE_GUI

9

Windows CE

IMAGE_SUBSYSTEM_EFI_APPLICATION

10

An Extensible Firmware Interface (EFI) application

IMAGE_SUBSYSTEM_EFI_BOOT_ SERVICE_DRIVER

11

An EFI driver with boot services

IMAGE_SUBSYSTEM_EFI_RUNTIME_ DRIVER

12

An EFI driver with run-time services

IMAGE_SUBSYSTEM_EFI_ROM

13

An EFI ROM image

IMAGE_SUBSYSTEM_XBOX

14

XBOX

IMAGE_SUBSYSTEM_WINDOWS_BOOT_APPLICATION

16

Windows boot application.

 

Características da DLL

Os seguintes valores são definidos para o campo DllCharacteristics do cabeçalho opcional.

TABELA 11

Constant

Value

Description

0x0001

Reserved, must be zero.

0x0002

Reserved, must be zero.

0x0004

Reserved, must be zero.

0x0008

Reserved, must be zero.

IMAGE_DLLCHARACTERISTICS_HIGH_ENTROPY_VA

0x0020

Image can handle a high entropy 64-bit virtual address space.

IMAGE_DLLCHARACTERISTICS_
DYNAMIC_BASE

0x0040

DLL can be relocated at load time.

IMAGE_DLLCHARACTERISTICS_
FORCE_INTEGRITY

0x0080

Code Integrity checks are enforced.

IMAGE_DLLCHARACTERISTICS_
NX_COMPAT

0x0100

Image is NX compatible.

IMAGE_DLLCHARACTERISTICS_ NO_ISOLATION

0x0200

Isolation aware, but do not isolate the image.

IMAGE_DLLCHARACTERISTICS_ NO_SEH

0x0400

Does not use structured exception (SE) handling. No SE handler may be called in this image.

IMAGE_DLLCHARACTERISTICS_ NO_BIND

0x0800

Do not bind the image.

IMAGE_DLLCHARACTERISTICS_APPCONTAINER

0x1000

Image must execute in an AppContainer.

IMAGE_DLLCHARACTERISTICS_ WDM_DRIVER

0x2000

A WDM driver.

IMAGE_DLLCHARACTERISTICS_GUARD_CF

0x4000

Image supports Control Flow Guard.

IMAGE_DLLCHARACTERISTICS_ TERMINAL_SERVER_AWARE

0x8000

Terminal Server aware.

 

 

Diretórios de dados de cabeçalho opcionais (apenas imagem)

Cada diretório de dados fornece o endereço e o tamanho de uma tabela ou string que o Windows usa. Essas entradas do diretório de dados são todas carregadas na memória para que o sistema possa usá-las em tempo de execução. Um diretório de dados é um campo de 8 bytes que possui a seguinte declaração:

 

C++

typedef struct _IMAGE_DATA_DIRECTORY {

    DWORD   VirtualAddress;

    DWORD   Size;

} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;

 

O primeiro campo, VirtualAddress, é realmente o RVA da tabela. O RVA é o endereço da tabela em relação ao endereço base da imagem quando a tabela é carregada. O segundo campo fornece o tamanho em bytes. Os diretórios de dados, que formam a última parte do cabeçalho opcional, estão listados na tabela a seguir.

Observe que o número de diretórios não é fixo. Antes de procurar um diretório específico, verifique o campo NumberOfRvaAndSizes no cabeçalho opcional.

Além disso, não assuma que os RVAs nesta tabela apontem para o início de uma seção ou que as seções que contêm tabelas específicas tenham nomes específicos.

TABELA 12

Offset (PE/PE32+)

Size

Field

Description

96/112

8

Export Table

The export table address and size. For more information see .edata Section (Image Only).

104/120

8

Import Table

The import table address and size. For more information, see The .idata Section.

112/128

8

Resource Table

The resource table address and size. For more information, see The .rsrc Section.

120/136

8

Exception Table

The exception table address and size. For more information, see The .pdata Section.

128/144

8

Certificate Table

The attribute certificate table address and size. For more information, see The Attribute Certificate Table (Image Only).

136/152

8

Base Relocation Table

The base relocation table address and size. For more information, see The .reloc Section (Image Only).

144/160

8

Debug

The debug data starting address and size. For more information, see The .debug Section.

152/168

8

Architecture

Reserved, must be 0

160/176

8

Global Ptr

The RVA of the value to be stored in the global pointer register. The size member of this structure must be set to zero.

168/184

8

TLS Table

The thread local storage (TLS) table address and size. For more information, The .tls Section.

176/192

8

Load Config Table

The load configuration table address and size. For more information, The Load Configuration Structure (Image Only).

184/200

8

Bound Import

The bound import table address and size.

192/208

8

IAT

The import address table address and size. For more information, see Import Address Table.

200/216

8

Delay Import Descriptor

The delay import descriptor address and size. For more information, see Delay-Load Import Tables (Image Only).

208/224

8

CLR Runtime Header

The CLR runtime header address and size. For more information, see The .cormeta Section (Object Only).

216/232

8

Reserved, must be zero

 

A entrada da tabela de certificados aponta para uma tabela de certificados de atributo. Esses certificados não são carregados na memória como parte da imagem. Dessa forma, o primeiro campo dessa entrada, que normalmente é um RVA, é um ponteiro de arquivo.

 

Tabela de seção (cabeçalhos de seção)

Cada linha da tabela de seções é, com efeito, um cabeçalho de seção. Esta tabela segue imediatamente o cabeçalho opcional, se houver. Esse posicionamento é necessário porque o cabeçalho do arquivo não contém um ponteiro direto para a tabela de seção. Em vez disso, a localização da tabela de seção é determinada calculando a localização do primeiro byte após os cabeçalhos. Certifique-se de usar o tamanho do cabeçalho opcional, conforme especificado no cabeçalho do arquivo.

O número de entradas na tabela de seções é fornecido pelo campo NumberOfSections no cabeçalho do arquivo. As entradas na tabela de seções são numeradas a partir de um (1). As entradas da seção de código e memória de dados estão na ordem escolhida pelo vinculador.

Em um arquivo de imagem, os VAs das seções devem ser atribuídos pelo vinculador para que estejam em ordem crescente e adjacentes e devem ser um múltiplo do valor SectionAlignment no cabeçalho opcional.

Cada cabeçalho da seção (entrada da tabela de seção) possui o seguinte formato, para um total de 40 bytes por entrada.

TABELA 13

Offset

Size

Field

Description

0

8

Name

An 8-byte, null-padded UTF-8 encoded string. If the string is exactly 8 characters long, there is no terminating null. For longer names, this field contains a slash (/) that is followed by an ASCII representation of a decimal number that is an offset into the string table. Executable images do not use a string table and do not support section names longer than 8 characters. Long names in object files are truncated if they are emitted to an executable file.

8

4

VirtualSize

The total size of the section when loaded into memory. If this value is greater than SizeOfRawData, the section is zero-padded. This field is valid only for executable images and should be set to zero for object files.

12

4

VirtualAddress

For executable images, the address of the first byte of the section relative to the image base when the section is loaded into memory. 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.

16

4

SizeOfRawData

The size of the section (for object files) or the size of the initialized data on disk (for image files). For executable images, 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 the SizeOfRawData field is rounded but the VirtualSize field is not, it is possible for SizeOfRawData to be greater than VirtualSize as well. When a section contains only uninitialized data, this field should be zero.

20

4

PointerToRawData

The file pointer to the first page of the section 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 4-byte boundary for best performance. When a section contains only uninitialized data, this field should be zero.

24

4

PointerToRelocations

The file pointer to the beginning of relocation entries for the section. This is set to zero for executable images or if there are no relocations.

28

4

PointerToLinenumbers

The file pointer to the beginning of line-number entries for the section. This is set to zero if there are no COFF line numbers. This value should be zero for an image because COFF debugging information is deprecated.

32

2

NumberOfRelocations

The number of relocation entries for the section. This is set to zero for executable images.

34

2

NumberOfLinenumbers

The number of line-number entries for the section. This value should be zero for an image because COFF debugging information is deprecated.

36

4

Characteristics

The flags that describe the characteristics of the section. For more information, see Section Flags.

 

Sinalizadores de seção

Os sinalizadores de seção no campo Características do cabeçalho da seção indicam características da seção.

TABELA 14

Flag

Value

Description

0x00000000

Reserved for future use.

0x00000001

Reserved for future use.

0x00000002

Reserved for future use.

0x00000004

Reserved for future use.

IMAGE_SCN_TYPE_NO_PAD

0x00000008

The section should not be padded to the next boundary. This flag is obsolete and is replaced by IMAGE_SCN_ALIGN_1BYTES. This is valid only for object files.

0x00000010

Reserved for future use.

IMAGE_SCN_CNT_CODE

0x00000020

The section contains executable code.

IMAGE_SCN_CNT_INITIALIZED_DATA

0x00000040

The section contains initialized data.

IMAGE_SCN_CNT_UNINITIALIZED_ DATA

0x00000080

The section contains uninitialized data.

IMAGE_SCN_LNK_OTHER

0x00000100

Reserved for future use.

IMAGE_SCN_LNK_INFO

0x00000200

The section contains comments or other information. The .drectve section has this type. This is valid for object files only.

0x00000400

Reserved for future use.

IMAGE_SCN_LNK_REMOVE

0x00000800

The section will not become part of the image. This is valid only for object files.

IMAGE_SCN_LNK_COMDAT

0x00001000

The section contains COMDAT data. For more information, see COMDAT Sections (Object Only). This is valid only for object files.

IMAGE_SCN_GPREL

0x00008000

The section contains data referenced through the global pointer (GP).

IMAGE_SCN_MEM_PURGEABLE

0x00020000

Reserved for future use.

IMAGE_SCN_MEM_16BIT

0x00020000

Reserved for future use.

IMAGE_SCN_MEM_LOCKED

0x00040000

Reserved for future use.

IMAGE_SCN_MEM_PRELOAD

0x00080000

Reserved for future use.

IMAGE_SCN_ALIGN_1BYTES

0x00100000

Align data on a 1-byte boundary. Valid only for object files.

IMAGE_SCN_ALIGN_2BYTES

0x00200000

Align data on a 2-byte boundary. Valid only for object files.

IMAGE_SCN_ALIGN_4BYTES

0x00300000

Align data on a 4-byte boundary. Valid only for object files.

IMAGE_SCN_ALIGN_8BYTES

0x00400000

Align data on an 8-byte boundary. Valid only for object files.

IMAGE_SCN_ALIGN_16BYTES

0x00500000

Align data on a 16-byte boundary. Valid only for object files.

IMAGE_SCN_ALIGN_32BYTES

0x00600000

Align data on a 32-byte boundary. Valid only for object files.

IMAGE_SCN_ALIGN_64BYTES

0x00700000

Align data on a 64-byte boundary. Valid only for object files.

IMAGE_SCN_ALIGN_128BYTES

0x00800000

Align data on a 128-byte boundary. Valid only for object files.

IMAGE_SCN_ALIGN_256BYTES

0x00900000

Align data on a 256-byte boundary. Valid only for object files.

IMAGE_SCN_ALIGN_512BYTES

0x00A00000

Align data on a 512-byte boundary. Valid only for object files.

IMAGE_SCN_ALIGN_1024BYTES

0x00B00000

Align data on a 1024-byte boundary. Valid only for object files.

IMAGE_SCN_ALIGN_2048BYTES

0x00C00000

Align data on a 2048-byte boundary. Valid only for object files.

IMAGE_SCN_ALIGN_4096BYTES

0x00D00000

Align data on a 4096-byte boundary. Valid only for object files.

IMAGE_SCN_ALIGN_8192BYTES

0x00E00000

Align data on an 8192-byte boundary. Valid only for object files.

IMAGE_SCN_LNK_NRELOC_OVFL

0x01000000

The section contains extended relocations.

IMAGE_SCN_MEM_DISCARDABLE

0x02000000

The section can be discarded as needed.

IMAGE_SCN_MEM_NOT_CACHED

0x04000000

The section cannot be cached.

IMAGE_SCN_MEM_NOT_PAGED

0x08000000

The section is not pageable.

IMAGE_SCN_MEM_SHARED

0x10000000

The section can be shared in memory.

IMAGE_SCN_MEM_EXECUTE

0x20000000

The section can be executed as code.

IMAGE_SCN_MEM_READ

0x40000000

The section can be read.

IMAGE_SCN_MEM_WRITE

0x80000000

The section can be written to.

 

IMAGE_SCN_LNK_NRELOC_OVFL indica que a contagem de realocações para a seção excede os 16 bits reservados para ela no cabeçalho da seção. Se o bit estiver definido e o campo NumberOfRelocations no cabeçalho da seção for 0xffff, a contagem real de realocação será armazenada no campo Endereço Virtual de 32 bits da primeira realocação. É um erro se IMAGE_SCN_LNK_NRELOC_OVFL estiver definido e houver menos de 0xffff realocações na seção.

 

Seções agrupadas (apenas objeto)

O “$”? O caractere (cifrão) possui uma interpretação especial nos nomes das seções nos arquivos de objetos.

Ao determinar a seção de imagem que conterá o conteúdo de uma seção de objeto, o vinculador descarta o “$”? e todos os personagens que seguem. Assim, uma seção de objeto chamada. O texto $ X realmente contribui para a seção .text da imagem.

No entanto, os caracteres após o “$”? determine a ordem das contribuições para a seção de imagem. Todas as contribuições com o mesmo nome da seção do objeto são alocadas contiguamente na imagem e os blocos de contribuições são classificados em ordem lexical pelo nome da seção do objeto. Portanto, tudo nos arquivos de objeto com o nome da seção .text$X termina juntos, após as contribuições .text$W e antes das contribuições .text$Y.

O nome da seção em um arquivo de imagem nunca contém um “$”? personagem.

 

Outros conteúdos do arquivo

As estruturas de dados que foram descritas até agora, incluindo o cabeçalho opcional, estão todas localizadas em um deslocamento fixo desde o início do arquivo (ou do cabeçalho PE, se o arquivo for uma imagem que contenha um stub do MS-DOS) .

O restante de um objeto COFF ou arquivo de imagem contém blocos de dados que não estão necessariamente em nenhum deslocamento de arquivo específico. Em vez disso, os locais são definidos por ponteiros no cabeçalho opcional ou no cabeçalho da seção.

Uma exceção é para imagens com um valor SectionAlignment menor que o tamanho da página da arquitetura (4 K para Intel x86 e MIPS e 8 K para Itanium). Para obter uma descrição do SectionAlignment, consulte Cabeçalho opcional (apenas imagem) . Nesse caso, há restrições no deslocamento do arquivo dos dados da seção, conforme descrito na seção 5.1, “Dados da seção”. Outra exceção é que as informações de certificado e depuração de atributos devem ser colocadas no final de um arquivo de imagem, com a tabela de certificados de atributos imediatamente anterior à seção de depuração, porque o carregador não as mapeia na memória. A regra sobre certificado de atributo e informações de depuração, no entanto, não se aplica a arquivos de objetos.

 

Dados da seção (Section Data)

Os dados inicializados para uma seção consistem em blocos simples de bytes. No entanto, para seções que contêm todos os zeros, os dados da seção não precisam ser incluídos.

Os dados para cada seção estão localizados no deslocamento do arquivo fornecido pelo campo PointerToRawData no cabeçalho da seção. O tamanho desses dados no arquivo é indicado pelo campo SizeOfRawData. Se SizeOfRawData for menor que VirtualSize, o restante será preenchido com zeros.

Em um arquivo de imagem, os dados da seção devem ser alinhados em um limite, conforme especificado pelo campo FileAlignment no cabeçalho opcional. Os dados da seção devem aparecer na ordem dos valores de RVA para as seções correspondentes (assim como os cabeçalhos de seção individuais na tabela de seções).

Existem restrições adicionais nos arquivos de imagem se o valor SectionAlignment no cabeçalho opcional for menor que o tamanho da página da arquitetura. Para esses arquivos, o local dos dados da seção no arquivo deve corresponder ao local na memória quando a imagem é carregada, para que o deslocamento físico dos dados da seção seja o mesmo que o RVA.

 

Realocações COFF (apenas objeto)

Os arquivos de objetos contêm realocações COFF, que especificam como os dados da seção devem ser modificados quando colocados no arquivo de imagem e subsequentemente carregados na memória.

Os arquivos de imagem não contêm realocações COFF, porque todos os símbolos referenciados já foram atribuídos a endereços em um espaço de endereço simples. Uma imagem contém informações de realocação na forma de realocações básicas na seção .reloc (a menos que a imagem tenha o atributo IMAGE_FILE_RELOCS_STRIPPED). Para obter mais informações, consulte a seção .reloc (apenas imagem) .

Para cada seção em um arquivo de objeto, uma matriz de registros de comprimento fixo mantém as realocações COFF da seção. A posição e o comprimento da matriz são especificados no cabeçalho da seção. Cada elemento da matriz tem o seguinte formato.

TABELA 15

Offset

Size

Field

Description

0

4

VirtualAddress

The address of the item to which relocation is applied. This is the offset from the beginning of the section, plus the value of the section’s RVA/Offset field. See Section Table (Section Headers). For example, if the first byte of the section has an address of 0x10, the third byte has an address of 0x12.

4

4

SymbolTableIndex

A zero-based index into the symbol table. This symbol gives the address that is to be used for the relocation. If the specified symbol has section storage class, then the symbol’s address is the address with the first section of the same name.

8

2

Type

A value that indicates the kind of relocation that should be performed. Valid relocation types depend on machine type. See Type Indicators.

 

Se o símbolo referido pelo campo SymbolTableIndex tiver a classe de armazenamento IMAGE_SYM_CLASS_SECTION, o endereço do símbolo será o início da seção. A seção geralmente está no mesmo arquivo, exceto quando o arquivo de objeto faz parte de um archive (biblioteca). Nesse caso, a seção pode ser encontrada em qualquer outro arquivo de objeto no arquivo que tenha o mesmo nome de membro do arquivo que o arquivo de objeto atual. (O relacionamento com o nome do membro do arquivo morto é usado no vínculo de tabelas de importação, ou seja, na seção .idata.)

 

Indicadores de tipo

O campo Tipo do registro de realocação indica que tipo de realocação deve ser executada. Diferentes tipos de realocação são definidos para cada tipo de máquina.

 

Processadores x64

Os seguintes indicadores de tipo de realocação são definidos para x64 e processadores compatíveis.

TABELA 16

Constant

Value

Description

IMAGE_REL_AMD64_ABSOLUTE

0x0000

The relocation is ignored.

IMAGE_REL_AMD64_ADDR64

0x0001

The 64-bit VA of the relocation target.

IMAGE_REL_AMD64_ADDR32

0x0002

The 32-bit VA of the relocation target.

IMAGE_REL_AMD64_ADDR32NB

0x0003

The 32-bit address without an image base (RVA).

IMAGE_REL_AMD64_REL32

0x0004

The 32-bit relative address from the byte following the relocation.

IMAGE_REL_AMD64_REL32_1

0x0005

The 32-bit address relative to byte distance 1 from the relocation.

IMAGE_REL_AMD64_REL32_2

0x0006

The 32-bit address relative to byte distance 2 from the relocation.

IMAGE_REL_AMD64_REL32_3

0x0007

The 32-bit address relative to byte distance 3 from the relocation.

IMAGE_REL_AMD64_REL32_4

0x0008

The 32-bit address relative to byte distance 4 from the relocation.

IMAGE_REL_AMD64_REL32_5

0x0009

The 32-bit address relative to byte distance 5 from the relocation.

IMAGE_REL_AMD64_SECTION

0x000A

The 16-bit section index of the section that contains the target. This is used to support debugging information.

IMAGE_REL_AMD64_SECREL

0x000B

The 32-bit offset of the target from the beginning of its section. This is used to support debugging information and static thread local storage.

IMAGE_REL_AMD64_SECREL7

0x000C

A 7-bit unsigned offset from the base of the section that contains the target.

IMAGE_REL_AMD64_TOKEN

0x000D

CLR tokens.

IMAGE_REL_AMD64_SREL32

0x000E

A 32-bit signed span-dependent value emitted into the object.

IMAGE_REL_AMD64_PAIR

0x000F

A pair that must immediately follow every span-dependent value.

IMAGE_REL_AMD64_SSPAN32

0x0010

A 32-bit signed span-dependent value that is applied at link time.

 

 

Processadores ARM

Os seguintes indicadores de tipo de realocação são definidos para processadores ARM.

TABELA 17

Constant

Value

Description

IMAGE_REL_ARM_ABSOLUTE

0x0000

The relocation is ignored.

IMAGE_REL_ARM_ADDR32

0x0001

The 32-bit VA of the target.

IMAGE_REL_ARM_ADDR32NB

0x0002

The 32-bit RVA of the target.

IMAGE_REL_ARM_BRANCH24

0x0003

The 24-bit relative displacement to the target.

IMAGE_REL_ARM_BRANCH11

0x0004

The reference to a subroutine call. The reference consists of two 16-bit instructions with 11-bit offsets.

IMAGE_REL_ARM_REL32

0x000A

The 32-bit relative address from the byte following the relocation.

IMAGE_REL_ARM_SECTION

0x000E

The 16-bit section index of the section that contains the target. This is used to support debugging information.

IMAGE_REL_ARM_SECREL

0x000F

The 32-bit offset of the target from the beginning of its section. This is used to support debugging information and static thread local storage.

IMAGE_REL_ARM_MOV32

0x0010

The 32-bit VA of the target. This relocation is applied using a MOVW instruction for the low 16 bits followed by a MOVT for the high 16 bits.

IMAGE_REL_THUMB_MOV32

0x0011

The 32-bit VA of the target. This relocation is applied using a MOVW instruction for the low 16 bits followed by a MOVT for the high 16 bits.

IMAGE_REL_THUMB_BRANCH20

0x0012

The instruction is fixed up with the 21-bit relative displacement to the 2-byte aligned target. The least significant bit of the displacement is always zero and is not stored. This relocation corresponds to a Thumb-2 32-bit conditional B instruction.

Unused

0x0013

IMAGE_REL_THUMB_BRANCH24

0x0014

The instruction is fixed up with the 25-bit relative displacement to the 2-byte aligned target. The least significant bit of the displacement is zero and is not stored.This relocation corresponds to a Thumb-2 B instruction.

IMAGE_REL_THUMB_BLX23

0x0015

The instruction is fixed up with the 25-bit relative displacement to the 4-byte aligned target. The low 2 bits of the displacement are zero and are not stored.
This relocation corresponds to a Thumb-2 BLX instruction.

IMAGE_REL_ARM_PAIR

0x0016

The relocation is valid only when it immediately follows a ARM_REFHI or THUMB_REFHI. Its SymbolTableIndex contains a displacement and not an index into the symbol table.

 

Processadores ARM64

Os seguintes indicadores de tipo de realocação são definidos para processadores ARM64.

TABELA 18

Constant

Value

Description

IMAGE_REL_ARM64_ABSOLUTE

0x0000

The relocation is ignored.

IMAGE_REL_ARM64_ADDR32

0x0001

The 32-bit VA of the target.

IMAGE_REL_ARM64_ADDR32NB

0x0002

The 32-bit RVA of the target.

IMAGE_REL_ARM64_BRANCH26

0x0003

The 26-bit relative displacement to the target, for B and BL instructions.

IMAGE_REL_ARM64_PAGEBASE_REL21

0x0004

The page base of the target, for ADRP instruction.

IMAGE_REL_ARM64_REL21

0x0005

The 12-bit relative displacement to the target, for instruction ADR

IMAGE_REL_ARM64_PAGEOFFSET_12A

0x0006

The 12-bit page offset of the target, for instructions ADD/ADDS (immediate) with zero shift.

IMAGE_REL_ARM64_PAGEOFFSET_12L

0x0007

The 12-bit page offset of the target, for instruction LDR (indexed, unsigned immediate).

IMAGE_REL_ARM64_SECREL

0x0008

The 32-bit offset of the target from the beginning of its section. This is used to support debugging information and static thread local storage.

IMAGE_REL_ARM64_SECREL_LOW12A

0x0009

Bit 0:11 of section offset of the target, for instructions ADD/ADDS (immediate) with zero shift.

IMAGE_REL_ARM64_SECREL_HIGH12A

0x000A

Bit 12:23 of section offset of the target, for instructions ADD/ADDS (immediate) with zero shift.

IMAGE_REL_ARM64_SECREL_LOW12L

0x000B

Bit 0:11 of section offset of the target, for instruction LDR (indexed, unsigned immediate).

IMAGE_REL_ARM64_TOKEN

0x000C

CLR token.

IMAGE_REL_ARM64_SECTION

0x000D

The 16-bit section index of the section that contains the target. This is used to support debugging information.

IMAGE_REL_ARM64_ADDR64

0x000E

The 64-bit VA of the relocation target.

IMAGE_REL_ARM64_BRANCH19

0x000F

The 19-bit offset to the relocation target, for conditional B instruction.

IMAGE_REL_ARM64_BRANCH14

0x0010

The 14-bit offset to the relocation target, for instructions TBZ and TBNZ.

IMAGE_REL_ARM64_REL32

0x0011

The 32-bit relative address from the byte following the relocation.

 

Processadores Hitachi SuperH

Os seguintes indicadores de tipo de realocação são definidos para os processadores SH3 e SH4. As realocações específicas para SH5 são anotadas como SHM (SH Media).

TABELA 19

Constant

Value

Description

IMAGE_REL_SH3_ABSOLUTE

0x0000

The relocation is ignored.

IMAGE_REL_SH3_DIRECT16

0x0001

A reference to the 16-bit location that contains the VA of the target symbol.

IMAGE_REL_SH3_DIRECT32

0x0002

The 32-bit VA of the target symbol.

IMAGE_REL_SH3_DIRECT8

0x0003

A reference to the 8-bit location that contains the VA of the target symbol.

IMAGE_REL_SH3_DIRECT8_WORD

0x0004

A reference to the 8-bit instruction that contains the effective 16-bit VA of the target symbol.

IMAGE_REL_SH3_DIRECT8_LONG

0x0005

A reference to the 8-bit instruction that contains the effective 32-bit VA of the target symbol.

IMAGE_REL_SH3_DIRECT4

0x0006

A reference to the 8-bit location whose low 4 bits contain the VA of the target symbol.

IMAGE_REL_SH3_DIRECT4_WORD

0x0007

A reference to the 8-bit instruction whose low 4 bits contain the effective 16-bit VA of the target symbol.

IMAGE_REL_SH3_DIRECT4_LONG

0x0008

A reference to the 8-bit instruction whose low 4 bits contain the effective 32-bit VA of the target symbol.

IMAGE_REL_SH3_PCREL8_WORD

0x0009

A reference to the 8-bit instruction that contains the effective 16-bit relative offset of the target symbol.

IMAGE_REL_SH3_PCREL8_LONG

0x000A

A reference to the 8-bit instruction that contains the effective 32-bit relative offset of the target symbol.

IMAGE_REL_SH3_PCREL12_WORD

0x000B

A reference to the 16-bit instruction whose low 12 bits contain the effective 16-bit relative offset of the target symbol.

IMAGE_REL_SH3_STARTOF_SECTION

0x000C

A reference to a 32-bit location that is the VA of the section that contains the target symbol.

IMAGE_REL_SH3_SIZEOF_SECTION

0x000D

A reference to the 32-bit location that is the size of the section that contains the target symbol.

IMAGE_REL_SH3_SECTION

0x000E

The 16-bit section index of the section that contains the target. This is used to support debugging information.

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 and static thread local storage.

IMAGE_REL_SH3_DIRECT32_NB

0x0010

The 32-bit RVA of the target symbol.

IMAGE_REL_SH3_GPREL4_LONG

0x0011

GP relative.

IMAGE_REL_SH3_TOKEN

0x0012

CLR token.

IMAGE_REL_SHM_PCRELPT

0x0013

The offset from the current instruction in longwords. If the NOMODE bit is not set, insert the inverse of the low bit at bit 32 to select PTA or PTB.

IMAGE_REL_SHM_REFLO

0x0014

The low 16 bits of the 32-bit address.

IMAGE_REL_SHM_REFHALF

0x0015

The high 16 bits of the 32-bit address.

IMAGE_REL_SHM_RELLO

0x0016

The low 16 bits of the relative address.

IMAGE_REL_SHM_RELHALF

0x0017

The high 16 bits of the relative address.

IMAGE_REL_SHM_PAIR

0x0018

The relocation is valid only when it immediately follows a REFHALF, RELHALF, or RELLO relocation. The SymbolTableIndex field of the relocation contains a displacement and not an index into the symbol table.

IMAGE_REL_SHM_NOMODE

0x8000

The relocation ignores section mode.

 

Processadores IBM PowerPC

Os seguintes indicadores de tipo de realocação são definidos para processadores PowerPC.

TABELA 20

Constant

Value

Description

IMAGE_REL_PPC_ABSOLUTE

0x0000

The relocation is ignored.

IMAGE_REL_PPC_ADDR64

0x0001

The 64-bit VA of the target.

IMAGE_REL_PPC_ADDR32

0x0002

The 32-bit VA of the target.

IMAGE_REL_PPC_ADDR24

0x0003

The low 24 bits of the VA of the target. This is valid only when the target symbol is absolute and can be sign-extended to its original value.

IMAGE_REL_PPC_ADDR16

0x0004

The low 16 bits of the target’s VA.

IMAGE_REL_PPC_ADDR14

0x0005

The low 14 bits of the target’s VA. This is valid only when the target symbol is absolute and can be sign-extended to its original value.

IMAGE_REL_PPC_REL24

0x0006

A 24-bit PC-relative offset to the symbol’s location.

IMAGE_REL_PPC_REL14

0x0007

A 14-bit PC-relative offset to the symbol’s location.

IMAGE_REL_PPC_ADDR32NB

0x000A

The 32-bit RVA of the target.

IMAGE_REL_PPC_SECREL

0x000B

The 32-bit offset of the target from the beginning of its section. This is used to support debugging information and static thread local storage.

IMAGE_REL_PPC_SECTION

0x000C

The 16-bit section index of the section that contains the target. This is used to support debugging information.

IMAGE_REL_PPC_SECREL16

0x000F

The 16-bit offset of the target from the beginning of its section. This is used to support debugging information and static thread local storage.

IMAGE_REL_PPC_REFHI

0x0010

The high 16 bits of the target’s 32-bit VA. This is used for the first instruction in a two-instruction sequence that loads a full address. This relocation must be immediately followed by a PAIR relocation whose SymbolTableIndex contains a signed 16-bit displacement that is added to the upper 16 bits that was taken from the location that is being relocated.

IMAGE_REL_PPC_REFLO

0x0011

The low 16 bits of the target’s VA.

IMAGE_REL_PPC_PAIR

0x0012

A relocation that is valid only when it immediately follows a REFHI or SECRELHI relocation. Its SymbolTableIndex contains a displacement and not an index into the symbol table.

IMAGE_REL_PPC_SECRELLO

0x0013

The low 16 bits of the 32-bit offset of the target from the beginning of its section.

IMAGE_REL_PPC_GPREL

0x0015

The 16-bit signed displacement of the target relative to the GP register.

IMAGE_REL_PPC_TOKEN

0x0016

The CLR token.

 

Processadores Intel 386

Os seguintes indicadores de tipo de realocação estão definidos para Intel 386 e processadores compatíveis.

TABELA 21

Constant

Value

Description

IMAGE_REL_I386_ABSOLUTE

0x0000

The relocation is ignored.

IMAGE_REL_I386_DIR16

0x0001

Not supported.

IMAGE_REL_I386_REL16

0x0002

Not supported.

IMAGE_REL_I386_DIR32

0x0006

The target’s 32-bit VA.

IMAGE_REL_I386_DIR32NB

0x0007

The target’s 32-bit RVA.

IMAGE_REL_I386_SEG12

0x0009

Not supported.

IMAGE_REL_I386_SECTION

0x000A

The 16-bit section index of the section that contains 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 and static thread local storage.

IMAGE_REL_I386_TOKEN

0x000C

The CLR token.

IMAGE_REL_I386_SECREL7

0x000D

A 7-bit offset from the base of the section that contains the target.

IMAGE_REL_I386_REL32

0x0014

The 32-bit relative displacement to the target. This supports the x86 relative branch and call instructions.

 

Família de processadores Intel Itanium (IPF)

Os seguintes indicadores de tipo de realocação são definidos para a família de processadores Intel Itanium e processadores compatíveis. Observe que as realocações nas instruções usam o número do deslocamento e do slot do pacote configurável para o deslocamento da realocação.

TABELA 22

Constant

Value

Description

IMAGE_REL_IA64_ABSOLUTE

0x0000

The relocation is ignored.

IMAGE_REL_IA64_IMM14

0x0001

The instruction relocation can be followed by an ADDEND relocation whose value is added to the target address before it is inserted into the specified slot in the IMM14 bundle. The relocation target must be absolute or the image must be fixed.

IMAGE_REL_IA64_IMM22

0x0002

The instruction relocation can be followed by an ADDEND relocation whose value is added to the target address before it is inserted into the specified slot in the IMM22 bundle. The relocation target must be absolute or the image must be fixed.

IMAGE_REL_IA64_IMM64

0x0003

The slot number of this relocation must be one (1). The relocation can be followed by an ADDEND relocation whose value is added to the target address before it is stored in all three slots of the IMM64 bundle.

IMAGE_REL_IA64_DIR32

0x0004

The target’s 32-bit VA. This is supported only for /LARGEADDRESSAWARE:NO images.

IMAGE_REL_IA64_DIR64

0x0005

The target’s 64-bit VA.

IMAGE_REL_IA64_PCREL21B

0x0006

The instruction is fixed up with the 25-bit relative displacement to the 16-bit aligned target. The low 4 bits of the displacement are zero and are not stored.

IMAGE_REL_IA64_PCREL21M

0x0007

The instruction is fixed up with the 25-bit relative displacement to the 16-bit aligned target. The low 4 bits of the displacement, which are zero, are not stored.

IMAGE_REL_IA64_PCREL21F

0x0008

The LSBs of this relocation’s offset must contain the slot number whereas the rest is the bundle address. The bundle is fixed up with the 25-bit relative displacement to the 16-bit aligned target. The low 4 bits of the displacement are zero and are not stored.

IMAGE_REL_IA64_GPREL22

0x0009

The instruction relocation can be followed by an ADDEND relocation whose value is added to the target address and then a 22-bit GP-relative offset that is calculated and applied to the GPREL22 bundle.

IMAGE_REL_IA64_LTOFF22

0x000A

The instruction is fixed up with the 22-bit GP-relative offset to the target symbol’s literal table entry. The linker creates this literal table entry based on this relocation and the ADDEND relocation that might follow.

IMAGE_REL_IA64_SECTION

0x000B

The 16-bit section index of the section contains the target. This is used to support debugging information.

IMAGE_REL_IA64_SECREL22

0x000C

The instruction is fixed up with the 22-bit offset of the target from the beginning of its section. This relocation can be followed immediately by an ADDEND relocation, whose Value field contains the 32-bit unsigned offset of the target from the beginning of the section.

IMAGE_REL_IA64_SECREL64I

0x000D

The slot number for this relocation must be one (1). The instruction is fixed up with the 64-bit offset of the target from the beginning of its section. This relocation can be followed immediately by an ADDEND relocation whose Value field contains the 32-bit unsigned offset of the target from the beginning of the section.

IMAGE_REL_IA64_SECREL32

0x000E

The address of data to be fixed up with the 32-bit offset of the target from the beginning of its section.

IMAGE_REL_IA64_DIR32NB

0x0010

The target’s 32-bit RVA.

IMAGE_REL_IA64_SREL14

0x0011

This is applied to a signed 14-bit immediate that contains the difference between two relocatable targets. This is a declarative field for the linker that indicates that the compiler has already emitted this value.

IMAGE_REL_IA64_SREL22

0x0012

This is applied to a signed 22-bit immediate that contains the difference between two relocatable targets. This is a declarative field for the linker that indicates that the compiler has already emitted this value.

IMAGE_REL_IA64_SREL32

0x0013

This is applied to a signed 32-bit immediate that contains the difference between two relocatable values. This is a declarative field for the linker that indicates that the compiler has already emitted this value.

IMAGE_REL_IA64_UREL32

0x0014

This is applied to an unsigned 32-bit immediate that contains the difference between two relocatable values. This is a declarative field for the linker that indicates that the compiler has already emitted this value.

IMAGE_REL_IA64_PCREL60X

0x0015

A 60-bit PC-relative fixup that always stays as a BRL instruction of an MLX bundle.

IMAGE_REL_IA64_PCREL60B

0x0016

A 60-bit PC-relative fixup. If the target displacement fits in a signed 25-bit field, convert the entire bundle to an MBB bundle with NOP.B in slot 1 and a 25-bit BR instruction (with the 4 lowest bits all zero and dropped) in slot 2.

IMAGE_REL_IA64_PCREL60F

0x0017

A 60-bit PC-relative fixup. If the target displacement fits in a signed 25-bit field, convert the entire bundle to an MFB bundle with NOP.F in slot 1 and a 25-bit (4 lowest bits all zero and dropped) BR instruction in slot 2.

IMAGE_REL_IA64_PCREL60I

0x0018

A 60-bit PC-relative fixup. If the target displacement fits in a signed 25-bit field, convert the entire bundle to an MIB bundle with NOP.I in slot 1 and a 25-bit (4 lowest bits all zero and dropped) BR instruction in slot 2.

IMAGE_REL_IA64_PCREL60M

0x0019

A 60-bit PC-relative fixup. If the target displacement fits in a signed 25-bit field, convert the entire bundle to an MMB bundle with NOP.M in slot 1 and a 25-bit (4 lowest bits all zero and dropped) BR instruction in slot 2.

IMAGE_REL_IA64_IMMGPREL64

0x001a

A 64-bit GP-relative fixup.

IMAGE_REL_IA64_TOKEN

0x001b

A CLR token.

IMAGE_REL_IA64_GPREL32

0x001c

A 32-bit GP-relative fixup.

IMAGE_REL_IA64_ADDEND

0x001F

The relocation is valid only when it immediately follows one of the following relocations: IMM14, IMM22, IMM64, GPREL22, LTOFF22, LTOFF64, SECREL22, SECREL64I, or SECREL32. Its value contains the addend to apply to instructions within a bundle, not for data.

 

 

Processadores MIPS

Os seguintes indicadores de tipo de realocação são definidos para processadores MIPS.

TABELA 23

Constant

Value

Description

IMAGE_REL_MIPS_ABSOLUTE

0x0000

The relocation is ignored.

IMAGE_REL_MIPS_REFHALF

0x0001

The high 16 bits of the target’s 32-bit VA.

IMAGE_REL_MIPS_REFWORD

0x0002

The target’s 32-bit VA.

IMAGE_REL_MIPS_JMPADDR

0x0003

The low 26 bits of the target’s VA. This supports the MIPS J and JAL instructions.

IMAGE_REL_MIPS_REFHI

0x0004

The high 16 bits of the target’s 32-bit VA. This is used for the first instruction in a two-instruction sequence that loads a full address. This relocation must be immediately followed by a PAIR relocation whose SymbolTableIndex contains a signed 16-bit displacement that is added to the upper 16 bits that are taken from the location that is being relocated.

IMAGE_REL_MIPS_REFLO

0x0005

The low 16 bits of the target’s VA.

IMAGE_REL_MIPS_GPREL

0x0006

A 16-bit signed displacement of the target relative to the GP register.

IMAGE_REL_MIPS_LITERAL

0x0007

The same as IMAGE_REL_MIPS_GPREL.

IMAGE_REL_MIPS_SECTION

0x000A

The 16-bit section index of the section contains the target. This is used to support debugging information.

IMAGE_REL_MIPS_SECREL

0x000B

The 32-bit offset of the target from the beginning of its section. This is used to support debugging information and static thread local storage.

IMAGE_REL_MIPS_SECRELLO

0x000C

The low 16 bits of the 32-bit offset of the target from the beginning of its section.

IMAGE_REL_MIPS_SECRELHI

0x000D

The high 16 bits of the 32-bit offset of the target from the beginning of its section. An IMAGE_REL_MIPS_PAIR relocation must immediately follow this one. The SymbolTableIndex of the PAIR relocation contains a signed 16-bit displacement that is added to the upper 16 bits that are taken from the location that is being relocated.

IMAGE_REL_MIPS_JMPADDR16

0x0010

The low 26 bits of the target’s VA. This supports the MIPS16 JAL instruction.

IMAGE_REL_MIPS_REFWORDNB

0x0022

The target’s 32-bit RVA.

IMAGE_REL_MIPS_PAIR

0x0025

The relocation is valid only when it immediately follows a REFHI or SECRELHI relocation. Its SymbolTableIndex contains a displacement and not an index into the symbol table.

 

 

Mitsubishi M32R

Os seguintes indicadores de tipo de realocação são definidos para os processadores Mitsubishi M32R.

TABELA 24

Constant

Value

Description

IMAGE_REL_M32R_ABSOLUTE

0x0000

The relocation is ignored.

IMAGE_REL_M32R_ADDR32

0x0001

The target’s 32-bit VA.

IMAGE_REL_M32R_ADDR32NB

0x0002

The target’s 32-bit RVA.

IMAGE_REL_M32R_ADDR24

0x0003

The target’s 24-bit VA.

IMAGE_REL_M32R_GPREL16

0x0004

The target’s 16-bit offset from the GP register.

IMAGE_REL_M32R_PCREL24

0x0005

The target’s 24-bit offset from the program counter (PC), shifted left by 2 bits and sign-extended

IMAGE_REL_M32R_PCREL16

0x0006

The target’s 16-bit offset from the PC, shifted left by 2 bits and sign-extended

IMAGE_REL_M32R_PCREL8

0x0007

The target’s 8-bit offset from the PC, shifted left by 2 bits and sign-extended

IMAGE_REL_M32R_REFHALF

0x0008

The 16 MSBs of the target VA.

IMAGE_REL_M32R_REFHI

0x0009

The 16 MSBs of the target VA, adjusted for LSB sign extension. This is used for the first instruction in a two-instruction sequence that loads a full 32-bit address. This relocation must be immediately followed by a PAIR relocation whose SymbolTableIndex contains a signed 16-bit displacement that is added to the upper 16 bits that are taken from the location that is being relocated.

IMAGE_REL_M32R_REFLO

0x000A

The 16 LSBs of the target VA.

IMAGE_REL_M32R_PAIR

0x000B

The relocation must follow the REFHI relocation. Its SymbolTableIndex contains a displacement and not an index into the symbol table.

IMAGE_REL_M32R_SECTION

0x000C

The 16-bit section index of the section that contains the target. This is used to support debugging information.

IMAGE_REL_M32R_SECREL

0x000D

The 32-bit offset of the target from the beginning of its section. This is used to support debugging information and static thread local storage.

IMAGE_REL_M32R_TOKEN

0x000E

The CLR token.

 

 

Números de linha COFF (descontinuado)

Os números das linhas COFF não são mais produzidos e, no futuro, não serão consumidos.

Os números de linha COFF indicam a relação entre código e números de linha nos arquivos de origem. O formato da Microsoft para números de linha COFF é semelhante ao COFF padrão, mas foi estendido para permitir que uma única seção se relacione com números de linha em vários arquivos de origem.

Os números de linha COFF consistem em uma matriz de registros de comprimento fixo. A localização (deslocamento do arquivo) e o tamanho da matriz são especificados no cabeçalho da seção. Cada registro de número de linha tem o seguinte formato.

TABELA 25

Offset

Size

Field

Description

0

4

Type (*)

This is a union of two fields: SymbolTableIndex and VirtualAddress. Whether SymbolTableIndex or RVA is used depends on the value of Linenumber.

4

2

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.

 

O campo Tipo é uma união de dois campos de 4 bytes: SymbolTableIndex e VirtualAddress.

TABELA 26

Offset

Size

Field

Description

0

4

SymbolTableIndex

Used when Linenumber is zero: index to symbol table entry for a function. This format is used to indicate the function to which a group of line-number records refers.

0

4

VirtualAddress

Used when Linenumber is non-zero: the RVA of the executable code that corresponds to the source line indicated. In an object file, this contains the VA within the section.

 

Um registro de número de linha pode definir o campo Linenumber como zero e apontar para uma definição de função na tabela de símbolos ou pode funcionar como uma entrada de número de linha padrão, fornecendo um número inteiro positivo (número de linha) e o endereço correspondente no objeto código.

Um grupo de entradas de número de linha sempre começa com o primeiro formato: o índice de um símbolo de função. Se este for o primeiro registro de número de linha na seção, também será o nome do símbolo COMDAT para a função se o sinalizador COMDAT da seção estiver definido. Consulte Seções COMDAT (apenas objeto). O registro auxiliar da função na tabela de símbolos possui um ponteiro para o campo Linenumber que aponta para esse mesmo registro de número de linha.

Um registro que identifica uma função é seguido por qualquer número de entradas de número de linha que forneça informações reais sobre o número de linha (ou seja, entradas com número de linha maior que zero). Essas entradas são baseadas em uma, relativas ao início da função e representam todas as linhas de origem na função, exceto a primeira linha.

Por exemplo, o primeiro registro de número de linha do exemplo a seguir especificaria a função ReverseSign (SymbolTableIndex de ReverseSign e Linenumber definido como zero). Em seguida, os registros com valores de Linenumber de 1, 2 e 3 seguiriam, correspondendo às linhas de origem, como mostrado:

 

C++

// some code precedes ReverseSign function

int ReverseSign(int i)

1: {

2:  return -1 * i;

3: }

 

Tabela de símbolos COFF

A tabela de símbolos nesta seção é herdada do formato COFF tradicional. É diferente das informações de depuração do Microsoft Visual C ++. Um arquivo pode conter uma tabela de símbolos COFF e informações de depuração do Visual C ++, e os dois são mantidos separados. Algumas ferramentas da Microsoft usam a tabela de símbolos para fins limitados, mas importantes, como a comunicação de informações COMDAT ao vinculador. Os nomes das seções e os arquivos, assim como os símbolos de código e dados, estão listados na tabela de símbolos.

A localização da tabela de símbolos é indicada no cabeçalho COFF.

A tabela de símbolos é uma matriz de registros, cada um com 18 bytes de comprimento. Cada registro é um registro padrão ou auxiliar da tabela de símbolos. Um registro padrão define um símbolo ou nome e tem o seguinte formato.

TABELA 27

Offset

Size

Field

Description

0

8

Name (*)

The name of the symbol, represented by a union of three structures. An array of 8 bytes is used if the name is not more than 8 bytes long. For more information, see Symbol Name Representation.

8

4

Value

The value that is associated with the symbol. The interpretation of this field depends on SectionNumber and StorageClass. A typical meaning is the relocatable address.

12

2

SectionNumber

The signed integer that identifies the section, using a one-based index into the section table. Some values have special meaning, as defined in section 5.4.2, “Section Number Values.”

14

2

Type

A number that represents type. Microsoft tools set this field to 0x20 (function) or 0x0 (not a function). For more information, see Type Representation.

16

1

StorageClass

An enumerated value that represents storage class. For more information, see Storage Class.

17

1

NumberOfAuxSymbols

The number of auxiliary symbol table entries that follow this record.

 

 

Zero ou mais registros auxiliares da tabela de símbolos seguem imediatamente cada registro padrão da tabela de símbolos. No entanto, normalmente não mais de um registro auxiliar da tabela de símbolos segue um registro padrão da tabela de símbolos (exceto para registros .file com nomes longos de arquivos). Cada registro auxiliar tem o mesmo tamanho de um registro de tabela de símbolos padrão (18 bytes), mas, em vez de definir um novo símbolo, o registro auxiliar fornece informações adicionais sobre o último símbolo definido. A escolha de qual dos vários formatos usar depende do campo StorageClass. Os formatos atualmente definidos para registros auxiliares da tabela de símbolos são mostrados na seção 5.5, “Registros auxiliares de símbolos”.

As ferramentas que lêem tabelas de símbolos COFF devem ignorar registros auxiliares de símbolos cuja interpretação é desconhecida. Isso permite que o formato da tabela de símbolos seja estendido para adicionar novos registros auxiliares, sem quebrar as ferramentas existentes.

 

Símbolo Nome Representação

O campo ShortName em uma tabela de símbolos consiste em 8 bytes que contêm o próprio nome, se não tiver mais de 8 bytes, ou o campo ShortName fornecerá um deslocamento na tabela de cadeias. Para determinar se o próprio nome ou um deslocamento é fornecido, teste os 4 primeiros bytes para que a igualdade seja zero.

Por convenção, os nomes são tratados como cadeias codificadas em UTF-8 com terminação zero.

TABELA 28

Offset

Size

Field

Description

0

8

ShortName

An array of 8 bytes. This array is padded with nulls on the right if the name is less than 8 bytes long.

0

4

Zeroes

A field that is set to all zeros if the name is longer than 8 bytes.

4

4

Offset

An offset into the string table.

 

Valores do número da seção

Normalmente, o campo Valor da seção em uma entrada da tabela de símbolos é um índice com base em uma tabela de seção. No entanto, esse campo é um número inteiro assinado e pode assumir valores negativos. Os seguintes valores, menos de um, têm significados especiais.

TABELA 29

Constant

Value

Description

IMAGE_SYM_UNDEFINED

0

The symbol record is not yet assigned a section. A value of zero indicates that a reference to an external symbol is defined elsewhere. A value of non-zero is a common symbol with a size that is specified by the value.

IMAGE_SYM_ABSOLUTE

-1

The symbol has an absolute (non-relocatable) value and is not an address.

IMAGE_SYM_DEBUG

-2

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).

 

Representação de tipo

O campo Tipo de uma entrada da tabela de símbolos contém 2 bytes, em que cada byte representa informações de tipo. O LSB representa o tipo de dados simples (base) e o MSB representa o tipo complexo, se houver:

TABELA 30

MSB

LSB

Complex type: none, pointer, function, array.

Base type: integer, floating-point, and so on.

 

Os seguintes valores são definidos para o tipo base, embora as ferramentas da Microsoft geralmente não usem esse campo e definam o LSB como 0. Em vez disso, as informações de depuração do Visual C ++ são usadas para indicar tipos. No entanto, os possíveis valores COFF estão listados aqui para fins de integridade.

TABELA 31

Constant

Value

Description

IMAGE_SYM_TYPE_NULL

0

No type information or unknown base type. Microsoft tools use this setting

IMAGE_SYM_TYPE_VOID

1

No valid type; used with void pointers and functions

IMAGE_SYM_TYPE_CHAR

2

A character (signed byte)

IMAGE_SYM_TYPE_SHORT

3

A 2-byte signed integer

IMAGE_SYM_TYPE_INT

4

A natural integer type (normally 4 bytes in Windows)

IMAGE_SYM_TYPE_LONG

5

A 4-byte signed integer

IMAGE_SYM_TYPE_FLOAT

6

A 4-byte floating-point number

IMAGE_SYM_TYPE_DOUBLE

7

An 8-byte floating-point number

IMAGE_SYM_TYPE_STRUCT

8

A structure

IMAGE_SYM_TYPE_UNION

9

A union

IMAGE_SYM_TYPE_ENUM

10

An enumerated type

IMAGE_SYM_TYPE_MOE

11

A member of enumeration (a specific value)

IMAGE_SYM_TYPE_BYTE

12

A byte; unsigned 1-byte integer

IMAGE_SYM_TYPE_WORD

13

A word; unsigned 2-byte integer

IMAGE_SYM_TYPE_UINT

14

An unsigned integer of natural size (normally, 4 bytes)

IMAGE_SYM_TYPE_DWORD

15

An unsigned 4-byte integer

 

O byte mais significativo especifica se o símbolo é um ponteiro para, função retornando ou matriz do tipo base especificado no LSB. As ferramentas da Microsoft usam esse campo apenas para indicar se o símbolo é uma função, para que os únicos dois valores resultantes sejam 0x0 e 0x20 para o campo Tipo. No entanto, outras ferramentas podem usar esse campo para comunicar mais informações.

É muito importante especificar o atributo da função corretamente. Essas informações são necessárias para que o link incremental funcione corretamente. Para algumas arquiteturas, as informações podem ser necessárias para outros fins.

TABELA 32

Constant

Value

Description

IMAGE_SYM_DTYPE_NULL

0

No derived type; the symbol is a simple scalar variable.

IMAGE_SYM_DTYPE_POINTER

1

The symbol is a pointer to base type.

IMAGE_SYM_DTYPE_FUNCTION

2

The symbol is a function that returns a base type.

IMAGE_SYM_DTYPE_ARRAY

3

The symbol is an array of base type.

 

Classe de armazenamento

O campo StorageClass da tabela de símbolos indica que tipo de definição um símbolo representa. A tabela a seguir mostra os valores possíveis. Observe que o campo StorageClass é um número inteiro de 1 byte não assinado. O valor especial -1 deve, portanto, ser entendido como seu equivalente não assinado, 0xFF.

Embora o formato COFF tradicional use muitos valores de classe de armazenamento, as ferramentas da Microsoft contam com o formato de depuração do Visual C ++ para a maioria das informações simbólicas e geralmente usam apenas quatro valores de classe de armazenamento: EXTERNAL (2), STATIC (3), FUNCTION (101) e ESTÁTICO (103). Exceto no cabeçalho da segunda coluna abaixo, “Valor” deve ser entendido como o campo Valor do registro de símbolo (cuja interpretação depende do número encontrado como a classe de armazenamento).

TABELA 33

Constant

Value

Description/interpretation of the Value field

IMAGE_SYM_CLASS_END_OF_FUNCTION

-1 (0xFF)

A special symbol that represents the end of function, for debugging purposes.

IMAGE_SYM_CLASS_NULL

0

No assigned storage class.

IMAGE_SYM_CLASS_AUTOMATIC

1

The automatic (stack) variable. The Value field specifies the stack frame offset.

IMAGE_SYM_CLASS_EXTERNAL

2

A value that Microsoft tools use for external symbols. The Value field indicates the size if the section number is IMAGE_SYM_UNDEFINED (0). If the section number is not zero, then the Value field specifies the offset within the section.

IMAGE_SYM_CLASS_STATIC

3

The offset of the symbol within the section. If the Value field is zero, then the symbol represents a section name.

IMAGE_SYM_CLASS_REGISTER

4

A register variable. The Value field specifies the register number.

IMAGE_SYM_CLASS_EXTERNAL_DEF

5

A symbol that is defined externally.

IMAGE_SYM_CLASS_LABEL

6

A code label that is defined within the module. The Value field specifies the offset of the symbol within the section.

IMAGE_SYM_CLASS_UNDEFINED_LABEL

7

A reference to a code label that is not defined.

IMAGE_SYM_CLASS_MEMBER_OF_STRUCT

8

The structure member. The Value field specifies the n th member.

IMAGE_SYM_CLASS_ARGUMENT

9

A formal argument (parameter) of a function. The Value field specifies the n th argument.

IMAGE_SYM_CLASS_STRUCT_TAG

10

The structure tag-name entry.

IMAGE_SYM_CLASS_MEMBER_OF_UNION

11

A union member. The Value field specifies the n th member.

IMAGE_SYM_CLASS_UNION_TAG

12

The Union tag-name entry.

IMAGE_SYM_CLASS_TYPE_DEFINITION

13

A Typedef entry.

IMAGE_SYM_CLASS_UNDEFINED_STATIC

14

A static data declaration.

IMAGE_SYM_CLASS_ENUM_TAG

15

An enumerated type tagname entry.

IMAGE_SYM_CLASS_MEMBER_OF_ENUM

16

A member of an enumeration. The Value field specifies the n th member.

IMAGE_SYM_CLASS_REGISTER_PARAM

17

A register parameter.

IMAGE_SYM_CLASS_BIT_FIELD

18

A bit-field reference. The Value field specifies the n th bit in the bit field.

IMAGE_SYM_CLASS_BLOCK

100

A .bb (beginning of block) or .eb (end of block) record. The Value field is the relocatable address of the code location.

IMAGE_SYM_CLASS_FUNCTION

101

A value that Microsoft tools use for symbol records that define the extent of a function: begin function (.bf ), end function ( .ef ), and lines in function ( .lf ). For .lf records, the Value field gives the number of source lines in the function. For .ef records, the Value field gives the size of the function code.

IMAGE_SYM_CLASS_END_OF_STRUCT

102

An end-of-structure entry.

IMAGE_SYM_CLASS_FILE

103

A value that Microsoft tools, as well as traditional COFF format, use for the source-file symbol record. The symbol is followed by auxiliary records that name the file.

IMAGE_SYM_CLASS_SECTION

104

A definition of a section (Microsoft tools use STATIC storage class instead).

IMAGE_SYM_CLASS_WEAK_EXTERNAL

105

A weak external. For more information, see Auxiliary Format 3: Weak Externals.

IMAGE_SYM_CLASS_CLR_TOKEN

107

A CLR token symbol. The name is an ASCII string that consists of the hexadecimal value of the token. For more information, see CLR Token Definition (Object Only).

 

Registros auxiliares de símbolos

Os registros auxiliares da tabela de símbolos sempre seguem e se aplicam a algum registro padrão da tabela de símbolos. Um registro auxiliar pode ter qualquer formato que as ferramentas possam reconhecer, mas 18 bytes devem ser alocados para eles, para que a tabela de símbolos seja mantida como uma matriz de tamanho regular. Atualmente, as ferramentas da Microsoft reconhecem formatos auxiliares para os seguintes tipos de registros: definições de funções, símbolos de início e término da função (.bf e .ef), externos fracos, nomes de arquivos e definições de seção.

O design tradicional do COFF também inclui formatos de registros auxiliares para matrizes e estruturas. As ferramentas da Microsoft não as usam, mas, em vez disso, coloque essas informações simbólicas no formato de depuração do Visual C ++ nas seções de depuração.

 

Formato auxiliar 1: Definições de funções

Um registro da tabela de símbolos marca o início de uma definição de função se tiver todo o seguinte: uma classe de armazenamento EXTERNO (2), um valor de Tipo que indica que é uma função (0x20) e um número de seção maior que zero. Observe que um registro da tabela de símbolos que possui um número de seção UNDEFINED (0) não define a função e não possui um registro auxiliar. Os registros de símbolos de definição de função são seguidos por um registro auxiliar no formato descrito abaixo:

TABELA 34

Offset

Size

Field

Description

0

4

TagIndex

The symbol-table index of the corresponding .bf (begin function) symbol record.

4

4

TotalSize

The size of the executable code for the function itself. If the function is in its own section, the SizeOfRawData in the section header is greater or equal to this field, depending on alignment considerations.

8

4

PointerToLinenumber

The file offset of the first COFF line-number entry for the function, or zero if none exists. For more information, see COFF Line Numbers (Deprecated).

12

4

PointerToNextFunction

The 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.

16

2

Unused

 

Formato auxiliar 2: símbolos .bf e .ef

Para cada definição de função na tabela de símbolos, três itens descrevem o início, o final e o número de linhas. Cada um desses símbolos possui a classe de armazenamento FUNCTION (101):

Um registro de símbolo chamado .bf (função de início). O campo Valor não é utilizado.

Um registro de símbolo chamado .lf (linhas na função). O campo Valor fornece o número de linhas na função.

Um registro de símbolo chamado .ef (fim da função). O campo Valor tem o mesmo número que o campo Tamanho total no registro do símbolo de definição de função.

Os registros de símbolo .bf e .ef (mas não os registros .lf) são seguidos por um registro auxiliar com o seguinte formato:

TABELA 35

Offset

Size

Field

Description

0

4

Unused

4

2

Linenumber

The actual ordinal line number (1, 2, 3, and so on) within the source file, corresponding to the .bf or .ef record.

6

6

Unused

12

4

PointerToNextFunction ( .bf only)

The 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. It is not used for .ef records.

16

2

Unused

 

 

Formato Auxiliar 3: Externos Fracos

“Externos fracos” são um mecanismo para arquivos de objetos que permite flexibilidade no tempo do link. Um módulo pode conter um símbolo externo não resolvido (sym1), mas também pode incluir um registro auxiliar que indica que, se sym1 não estiver presente no momento do link, outro símbolo externo (sym2) será usado para resolver as referências.

Se uma definição de sym1 estiver vinculada, uma referência externa ao símbolo será resolvida normalmente. Se uma definição de sym1 não estiver vinculada, todas as referências ao externo fraco para sym1 se referirão a sym2. O símbolo externo, sym2, deve sempre estar vinculado; normalmente, é definido no módulo que contém a referência fraca para sym1.

Externos fracos são representados por um registro da tabela de símbolos com classe de armazenamento EXTERNO, número da seção UNDEF e valor zero. O registro de símbolo externo fraco é seguido por um registro auxiliar com o seguinte formato:

TABELA 36

Offset

Size

Field

Description

0

4

TagIndex

The symbol-table index of sym2, the symbol to be linked if sym1 is not found.

4

4

Characteristics

A value of IMAGE_WEAK_EXTERN_SEARCH_NOLIBRARY 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.

8

10

Unused

 

Observe que o campo de características não está definido no WINNT.H; em vez disso, o campo Tamanho total é usado.

 

Formato Auxiliar 4: Arquivos

Este formato segue um registro da tabela de símbolos com a classe de armazenamento FILE (103). O nome do símbolo em si deve ser .file e o registro auxiliar a seguir fornece o nome de um arquivo de código-fonte.

TABELA 37

Offset

Size

Field

Description

0

18

File Name

An ANSI string that gives the name of the source file. This is padded with nulls if it is less than the maximum length.

 

Formato auxiliar 5: Definições da seção

Esse formato segue um registro da tabela de símbolos que define uma seção. Esse registro possui um nome de símbolo que é o nome de uma seção (como .text ou .drectve) e possui a classe de armazenamento STATIC (3). O registro auxiliar fornece informações sobre a seção a que se refere. Portanto, ele duplica algumas das informações no cabeçalho da seção.

TABELA 38

Offset

Size

Field

Description

0

4

Length

The size of section data; the same as SizeOfRawData in the section header.

4

2

NumberOfRelocations

The number of relocation entries for the section.

6

2

NumberOfLinenumbers

The number of line-number entries for the section.

8

4

CheckSum

The checksum for communal data. It is applicable if the IMAGE_SCN_LNK_COMDAT flag is set in the section header. For more information, see COMDAT Sections (Object Only).

12

2

Number

One-based index into the section table for the associated section. This is used when the COMDAT selection setting is 5.

14

1

Selection

The COMDAT selection number. This is applicable if the section is a COMDAT section.

15

3

Unused

 

 

Seções COMDAT (apenas objeto)

O campo Seleção do formato auxiliar de definição de seção é aplicável se a seção for uma seção COMDAT. Uma seção COMDAT é uma seção que pode ser definida por mais de um arquivo de objeto. (O sinalizador IMAGE_SCN_LNK_COMDAT é definido no campo Sinalizadores de Seção do cabeçalho da seção.) O campo Seleção determina a maneira pela qual o vinculador resolve as várias definições de seções COMDAT.

O primeiro símbolo que possui o valor da seção COMDAT deve ser o símbolo da seção. Este símbolo possui o nome da seção, o campo Valor igual a zero, o número da seção COMDAT em questão, o campo Tipo igual a IMAGE_SYM_TYPE_NULL, o campo Classe igual a IMAGE_SYM_CLASS_STATIC e um registro auxiliar. O segundo símbolo é chamado “o símbolo COMDAT” e é usado pelo vinculador em conjunto com o campo Seleção.

Os valores para o campo Seleção são mostrados abaixo.

TABELA 39

Constant

Value

Description

IMAGE_COMDAT_SELECT_NODUPLICATES

1

If this symbol is already defined, the linker issues a “multiply defined symbol” error.

IMAGE_COMDAT_SELECT_ANY

2

Any section that defines the same COMDAT symbol can be linked; the rest are removed.

IMAGE_COMDAT_SELECT_SAME_SIZE

3

The linker chooses an arbitrary section among the definitions for this symbol. If all definitions are not the same size, a “multiply defined symbol” error is issued.

IMAGE_COMDAT_SELECT_EXACT_MATCH

4

The linker chooses an arbitrary section among the definitions for this symbol. If all definitions do not match exactly, a “multiply defined symbol” error is issued.

IMAGE_COMDAT_SELECT_ASSOCIATIVE

5

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. 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 other section this section is associated with must be a COMDAT section, which can be another associative COMDAT section. An associative COMDAT section’s section association chain can’t form a loop. The section association chain must eventually come to a COMDAT section that doesn’t have IMAGE_COMDAT_SELECT_ASSOCIATIVE set.

IMAGE_COMDAT_SELECT_LARGEST

6

The linker chooses the largest definition from among all of the definitions for this symbol. If multiple definitions have this size, the choice between them is arbitrary.

 

Definição de token CLR (somente objeto)

Este símbolo auxiliar geralmente segue o IMAGE_SYM_CLASS_CLR_TOKEN. É usado para associar um token ao namespace da tabela de símbolos COFF.

TABELA 40

Offset

Size

Field

Description

0

1

bAuxType

Must be IMAGE_AUX_SYMBOL_TYPE_TOKEN_DEF (1).

1

1

bReserved

Reserved, must be zero.

2

4

SymbolTableIndex

The symbol index of the COFF symbol to which this CLR token definition refers.

6

12

Reserved, must be zero.

 

Tabela de String COFF

Imediatamente após a tabela de símbolos COFF está a tabela de cadeias COFF. A posição desta tabela é encontrada pegando o endereço da tabela de símbolos no cabeçalho COFF e adicionando o número de símbolos multiplicado pelo tamanho de um símbolo.

No início da tabela de strings COFF, existem 4 bytes que contêm o tamanho total (em bytes) do restante da tabela de strings. Esse tamanho inclui o próprio campo de tamanho, para que o valor nesse local seja 4 se não houver cadeias.

A seguir ao tamanho estão as sequências terminadas em nulo que são apontadas por símbolos na tabela de símbolos COFF.

 

A tabela de certificado de atributo (apenas imagem)

Os certificados de atributo podem ser associados a uma imagem adicionando uma tabela de certificado de atributo. A tabela de certificado de atributo é composta por um conjunto de entradas de certificado de atributo alinhadas com quatro palavras contíguas. O preenchimento zero é inserido entre o final original do arquivo e o início da tabela de certificados de atributos para atingir esse alinhamento. Cada entrada de certificado de atributo contém os seguintes campos.

TABELA 41

Offset

Size

Field

Description

0

4

dwLength

Specifies the length of the attribute certificate entry.

4

2

wRevision

Contains the certificate version number. For details, see the following text.

6

2

wCertificateType

Specifies the type of content in bCertificate. For details, see the following text.

8

See the following

bCertificate

Contains a certificate, such as an Authenticode signature. For details, see the following text.

 

O valor do endereço virtual da entrada Tabela de Certificados no Diretório de Dados de Cabeçalho Opcional é um deslocamento de arquivo para a primeira entrada de certificado de atributo. As entradas subsequentes são acessadas avançando os bytes dwLength da entrada, arredondados para um múltiplo de 8 bytes, desde o início da entrada atual do certificado de atributo. Isso continua até que a soma dos valores arredondados de dwLength seja igual ao valor de tamanho da entrada da tabela de certificados no diretório de dados de cabeçalho opcional. Se a soma dos valores arredondados dwLength não for igual ao valor Tamanho, a tabela de certificados de atributo ou o campo Tamanho estarão corrompidos.

Por exemplo, se a Entrada da tabela de certificados do Diretório de dados de cabeçalho opcional contiver:

C++

virtual address = 0x5000

size = 0x1000

 

O primeiro certificado inicia no deslocamento 0x5000 desde o início do arquivo no disco. Para avançar por todas as entradas de certificado de atributo:

  1. Adicione o valor dwLength do primeiro certificado de atributo ao deslocamento inicial.
  2. Arredonde o valor da etapa 1 até o múltiplo de 8 bytes mais próximo para encontrar o deslocamento da segunda entrada do certificado de atributo.
  3. Adicione o valor de deslocamento da etapa 2 ao valor dwLength da segunda entrada de certificado de atributo e arredondar para o múltiplo de 8 bytes mais próximo para determinar o deslocamento da terceira entrada de certificado de atributo.
  4. Repita a etapa 3 para cada certificado sucessivo até que o deslocamento calculado seja igual a 0x6000 (início de 0x5000 + tamanho total de 0x1000), o que indica que você percorreu a tabela inteira.

Como alternativa, você pode enumerar as entradas do certificado chamando a função Win32 ImageEnumerateCertificates em um loop. Para um link para a página de referência da função, consulte Referências.

As entradas da tabela de certificado de atributo podem conter qualquer tipo de certificado, desde que a entrada tenha o valor dwLength correto, um valor exclusivo de wRevision e um valor exclusivo de wCertificateType. O tipo mais comum de entrada da tabela de certificados é uma estrutura WIN_CERTIFICATE, documentada em Wintrust.he discutida no restante desta seção.

 

As opções para o membro WIN_CERTIFICATE wRevision incluem (mas não estão limitadas a) o seguinte.

TABELA 42

Value

Name

Notes

0x0100

WIN_CERT_REVISION_1_0

Version 1, legacy version of the Win_Certificate structure. It is supported only for purposes of verifying legacy Authenticode signatures

0x0200

WIN_CERT_REVISION_2_0

Version 2 is the current version of the Win_Certificate structure.

 

As opções para o membro WIN_CERTIFICATE wCertificateType incluem (mas não estão limitadas a) os itens na tabela a seguir. Observe que alguns valores não são suportados no momento.

TABELA 43

Value

Name

Notes

0x0001

WIN_CERT_TYPE_X509

bCertificate contains an X.509 Certificate
Not Supported

0x0002

WIN_CERT_TYPE_PKCS_SIGNED_DATA

bCertificate contains a PKCS#7 SignedData structure

0x0003

WIN_CERT_TYPE_RESERVED_1

Reserved

0x0004

WIN_CERT_TYPE_TS_STACK_SIGNED

Terminal Server Protocol Stack Certificate signing
Not Supported

 

O membro bCertificate da estrutura WIN_CERTIFICATE contém uma matriz de bytes de comprimento variável com o tipo de conteúdo especificado por wCertificateType. O tipo suportado pelo Authenticode é WIN_CERT_TYPE_PKCS_SIGNED_DATA, uma estrutura PKCS # 7 SignedData. Para obter detalhes sobre o formato de assinatura digital Authenticode, consulte Formato de assinatura executável portátil do Windows Authenticode.

Se o conteúdo do bCertificate não terminar em um limite de quatro palavras, a entrada do certificado de atributo será preenchida com zeros, do final de bCertificate ao próximo limite de quatro palavras.

O valor dwLength é o comprimento da estrutura WIN_CERTIFICATE finalizada e é calculado como:

dwLength = offsetof(WIN_CERTIFICATE, bCertificate) + (size of the variable-length binary array contained within bCertificate)

Esse comprimento deve incluir o tamanho de qualquer preenchimento usado para satisfazer o requisito de que cada estrutura WIN_CERTIFICATE esteja alinhada com quatro palavras-chave:

dwLength += (8 – (dwLength & 7)) & 7;

O tamanho da tabela de certificados – especificado na entrada da tabela de certificados nos diretórios de dados de cabeçalho opcionais (apenas imagem) – inclui o preenchimento.

Para obter mais informações sobre o uso da API ImageHlp para enumerar, adicionar e remover certificados dos arquivos PE, consulte Funções do ImageHlp.

 

Dados do certificado

Conforme declarado na seção anterior, os certificados na tabela de certificados de atributos podem conter qualquer tipo de certificado. Certificados que garantem a integridade de um arquivo PE podem incluir um hash de imagem PE.

Um hash de imagem PE (ou hash de arquivo) é semelhante a uma soma de verificação de arquivo, pois o algoritmo de hash produz um resumo da mensagem relacionado à integridade de um arquivo. No entanto, uma soma de verificação é produzida por um algoritmo simples e é usada principalmente para detectar se um bloco de memória no disco está com defeito e se os valores armazenados nele foram corrompidos. Um hash de arquivo é semelhante a uma soma de verificação, pois também detecta a corrupção do arquivo. No entanto, diferentemente da maioria dos algoritmos de soma de verificação, é muito difícil modificar um arquivo sem alterar o hash do arquivo de seu valor original não modificado. Assim, um hash de arquivo pode ser usado para detectar modificações intencionais e até sutis em um arquivo, como as introduzidas por vírus, hackers ou programas de cavalos de Tróia.

Quando incluído em um certificado, o resumo da imagem deve excluir determinados campos da imagem PE, como a entrada Soma de verificação e Tabela de certificados nos Diretórios opcionais de dados do cabeçalho. Isso ocorre porque o ato de adicionar um certificado altera esses campos e faria com que um valor de hash diferente fosse calculado.

A função Win32 ImageGetDigestStream fornece um fluxo de dados de um arquivo PE de destino com o qual funções de hash. Esse fluxo de dados permanece consistente quando os certificados são adicionados ou removidos de um arquivo PE. Com base nos parâmetros passados para o ImageGetDigestStream , outros dados da imagem do PE podem ser omitidos da computação de hash. Para um link para a página de referência da função, consulte Referências.

 

Tabelas de importação com atraso de carregamento (apenas imagem)

Essas tabelas foram adicionadas à imagem para oferecer suporte a um mecanismo uniforme para os aplicativos atrasarem o carregamento de uma DLL até a primeira chamada nessa DLL. O layout das tabelas corresponde ao das tabelas de importação tradicionais descritas na seção 6.4, a seção .idata . “Apenas alguns detalhes são discutidos aqui.

 

A tabela de diretório de carregamento em atraso

A tabela de diretórios delay-load é a contrapartida da tabela de diretórios de importação. Ele pode ser recuperado através da entrada Delay Import Descriptor na lista de diretórios de dados do cabeçalho opcional (deslocamento 200). A tabela está organizada da seguinte forma:

TABELA 44

Offset

Size

Field

Description

0

4

Attributes

Must be zero.

4

4

Name

The RVA of the name of the DLL to be loaded. The name resides in the read-only data section of the image.

8

4

Module Handle

The RVA of the module handle (in the data section of the image) of the DLL to be delay-loaded. It is used for storage by the routine that is supplied to manage delay-loading.

12

4

Delay Import Address Table

The RVA of the delay-load import address table. For more information, see Delay Import Address Table (IAT).

16

4

Delay Import Name Table

The RVA of the delay-load name table, which contains the names of the imports that might need to be loaded. This matches the layout of the import name table. For more information, see Hint/Name Table.

20

4

Bound Delay Import Table

The RVA of the bound delay-load address table, if it exists.

24

4

Unload Delay Import Table

The RVA of the unload delay-load address table, if it exists. This is an exact copy of the delay import address table. If the caller unloads the DLL, this table should be copied back over the delay import address table so that subsequent calls to the DLL continue to use the thunking mechanism correctly.

28

4

Time Stamp

The timestamp of the DLL to which this image has been bound.

 

As tabelas referenciadas nessa estrutura de dados são organizadas e classificadas da mesma forma que suas contrapartes para importações tradicionais. Para detalhes, consulte A seção .idata.

 

Atributos

Até o momento, nenhum sinalizador de atributo está definido. O vinculador define esse campo como zero na imagem. Este campo pode ser usado para estender o registro, indicando a presença de novos campos, ou pode ser usado para indicar comportamentos nas funções auxiliares de atraso ou descarregamento.

 

Nome

O nome da DLL a ser carregada com atraso reside na seção de dados somente leitura da imagem. É referenciado através do campo szName.

 

Alça do módulo

O identificador da DLL a ser carregada com atraso está na seção de dados da imagem. O campo phmod aponta para o identificador. O auxiliar de atraso de carregamento fornecido usa esse local para armazenar o identificador na DLL carregada.

 

Atraso na tabela de endereços de importação

A tabela de endereços de importação de atraso (IAT) é referenciada pelo descritor de importação de atraso por meio do campo pIAT. O auxiliar de carregamento de atraso atualiza esses ponteiros com os pontos de entrada reais, para que os thunks não estejam mais no loop de chamada. Os ponteiros de função são acessados usando a expressão pINT->u1.Function.

 

Atraso na tabela de nomes de importação

A tabela de nome de importação de atraso (INT) contém os nomes das importações que podem exigir carregamento. Eles são ordenados da mesma maneira que os ponteiros de função no IAT. Eles consistem das mesmas estruturas como a INT padrão e são acedidos utilizando a expressão pINT->u1.AddressOfData->Name[0].

 

Tabela de endereços de importação com limite de atraso e registro de data e hora

A tabela de endereços de importação com limite de atraso (BIAT) é uma tabela opcional de itens IMAGE_THUNK_DATA que é usada junto com o campo de registro de data e hora da tabela de diretórios de atraso de carregamento por uma fase de ligação pós-processo.

 

Atraso na tabela de endereços de importação de descarregamento

A tabela de endereço de importação de atraso de descarregamento (UIAT) é uma tabela opcional de itens IMAGE_THUNK_DATA que o código de descarregamento usa para manipular uma solicitação de descarregamento explícita. Consiste em dados inicializados na seção somente leitura, que é uma cópia exata do IAT original que referiu o código aos thunks de atraso de carregamento. Na solicitação de descarregamento, a biblioteca pode ser liberada, o *phmod limpo e o UIAT gravado no IAT para restaurar tudo ao seu estado de pré-carregamento.

 

Seções Especiais

As seções COFF típicas contêm código ou dados que os vinculadores e os carregadores do Microsoft Win32 processam sem conhecimento especial do conteúdo da seção. O conteúdo é relevante apenas para o aplicativo que está sendo vinculado ou executado.

No entanto, algumas seções do COFF têm significados especiais quando encontradas em arquivos de objetos ou arquivos de imagem. As ferramentas e os carregadores reconhecem essas seções porque possuem sinalizadores especiais definidos no cabeçalho da seção, porque locais especiais no cabeçalho opcional da imagem apontam para eles ou porque o próprio nome da seção indica uma função especial da seção. (Mesmo que o nome da seção em si não indique uma função especial da seção, o nome da seção é ditado por convenção, portanto os autores desta especificação podem se referir a um nome de seção em todos os casos.)

As seções reservadas e seus atributos são descritos na tabela abaixo, seguidas de descrições detalhadas para os tipos de seção que persistem em executáveis e os tipos de seção que contêm metadados para extensões.

TABELA 45

Section Name

Content

Characteristics

.bss

Uninitialized data (free format)

IMAGE_SCN_CNT_UNINITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE

.cormeta

CLR metadata that indicates that the object file contains managed code

IMAGE_SCN_LNK_INFO

.data

Initialized data (free format)

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE

.debug$F

Generated FPO debug information (object only, x86 architecture only, and now obsolete)

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE

.debug$P

Precompiled debug types (object only)

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE

.debug$S

Debug symbols (object only)

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE

.debug$T

Debug types (object only)

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE

.drective

Linker options

IMAGE_SCN_LNK_INFO

.edata

Export tables

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ

.idata

Import tables

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE

.idlsym

Includes registered SEH (image only) to support IDL attributes. For information, see “IDL Attributes” in References at the end of this topic.

IMAGE_SCN_LNK_INFO

.pdata

Exception information

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ

.rdata

Read-only initialized data

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ

.reloc

Image relocations

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_DISCARDABLE

.rsrc

Resource directory

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ

.sbss

GP-relative uninitialized data (free format)

IMAGE_SCN_CNT_UNINITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE | IMAGE _SCN_GPREL The IMAGE_SCN_GPREL flag should be set for IA64 architectures only; this flag is not valid for other architectures. The IMAGE_SCN_GPREL flag is for object files only; when this section type appears in an image file, the IMAGE_SCN_GPREL flag must not be set.

.sdata

GP-relative initialized data (free format)

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE | IMAGE _SCN_GPREL The IMAGE_SCN_GPREL flag should be set for IA64 architectures only; this flag is not valid for other architectures. The IMAGE_SCN_GPREL flag is for object files only; when this section type appears in an image file, the IMAGE_SCN_GPREL flag must not be set.

.srdata

GP-relative read-only data (free format)

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE _SCN_GPREL The IMAGE_SCN_GPREL flag should be set for IA64 architectures only; this flag is not valid for other architectures. The IMAGE_SCN_GPREL flag is for object files only; when this section type appears in an image file, the IMAGE_SCN_GPREL flag must not be set.

.sxdata

Registered exception handler data (free format and x86/object only)

IMAGE_SCN_LNK_INFO Contains the symbol index of each of the exception handlers being referred to by the code in that object file. The symbol can be for an UNDEF symbol or one that is defined in that module.

.text

Executable code (free format)

IMAGE_SCN_CNT_CODE | IMAGE_SCN_MEM_EXECUTE | IIMAGE_SCN_MEM_READ

.tls

Thread-local storage (object only)

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE

.tls$

Thread-local storage (object only)

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE

.vsdata

GP-relative initialized data (free format and for ARM, SH4, and Thumb architectures only)

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ | IMAGE_SCN_MEM_WRITE

.xdata

Exception information (free format)

IMAGE_SCN_CNT_INITIALIZED_DATA | IMAGE_SCN_MEM_READ

 

Algumas das seções listadas aqui estão marcadas como “apenas objeto” ou “apenas imagem” para indicar que sua semântica especial é relevante apenas para arquivos de objeto ou de imagem, respectivamente. Uma seção marcada como “apenas imagem” ainda pode aparecer em um arquivo de objeto como uma maneira de entrar no arquivo de imagem, mas a seção não tem significado especial para o vinculador, apenas para o carregador de arquivo de imagem.

 

A seção .debug

A seção .debug é usada em arquivos de objeto para conter informações de depuração geradas pelo compilador e em arquivos de imagem para conter todas as informações de depuração geradas. Esta seção descreve o empacotamento de informações de depuração nos arquivos de objeto e imagem.

A próxima seção descreve o formato do diretório de depuração, que pode estar em qualquer lugar da imagem. As seções subsequentes descrevem os “grupos” nos arquivos de objetos que contêm informações de depuração.

O padrão para o vinculador é que as informações de depuração não sejam mapeadas no espaço de endereço da imagem. Uma seção .debug existe apenas quando as informações de depuração são mapeadas no espaço de endereço.

 

Diretório de depuração (somente imagem)

Os arquivos de imagem contêm um diretório de depuração opcional que indica qual forma de informação de depuração está presente e onde está. Este diretório consiste em uma matriz de entradas do diretório de depuração cuja localização e tamanho são indicados no cabeçalho opcional da imagem.

O diretório de depuração pode estar em uma seção .debug descartável (se houver), ou pode ser incluído em qualquer outra seção no arquivo de imagem ou não estar em nenhuma seção.

Cada entrada do diretório de depuração identifica o local e o tamanho de um bloco de informações de depuração. O RVA especificado pode ser zero se as informações de depuração não estiverem cobertas por um cabeçalho de seção (ou seja, residem no arquivo de imagem e não são mapeadas no espaço de endereço em tempo de execução). Se estiver mapeado, o RVA é o seu endereço.

Uma entrada do diretório de depuração tem o seguinte formato:

TABELA 46

Offset

Size

Field

Description

0

4

Characteristics

Reserved, must be zero.

4

4

TimeDateStamp

The time and date that the debug data was created.

8

2

MajorVersion

The major version number of the debug data format.

10

2

MinorVersion

The minor version number of the debug data format.

12

4

Type

The format of debugging information. This field enables support of multiple debuggers. For more information, see Debug Type.

16

4

SizeOfData

The size of the debug data (not including the debug directory itself).

20

4

AddressOfRawData

The address of the debug data when loaded, relative to the image base.

24

4

PointerToRawData

The file pointer to the debug data.

 

 

Tipo de depuração

Os seguintes valores são definidos para o campo Tipo da entrada do diretório de depuração:

TABELA 47

Constant

Value

Description

IMAGE_DEBUG_TYPE_UNKNOWN

0

An unknown value that is ignored by all tools.

IMAGE_DEBUG_TYPE_COFF

1

The 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.

IMAGE_DEBUG_TYPE_CODEVIEW

2

The Visual C++ debug information.

IMAGE_DEBUG_TYPE_FPO

3

The frame pointer omission (FPO) information. This information tells the debugger how to interpret nonstandard stack frames, which use the EBP register for a purpose other than as a frame pointer.

IMAGE_DEBUG_TYPE_MISC

4

The location of DBG file.

IMAGE_DEBUG_TYPE_EXCEPTION

5

A copy of .pdata section.

IMAGE_DEBUG_TYPE_FIXUP

6

Reserved.

IMAGE_DEBUG_TYPE_OMAP_TO_SRC

7

The mapping from an RVA in image to an RVA in source image.

IMAGE_DEBUG_TYPE_OMAP_FROM_SRC

8

The mapping from an RVA in source image to an RVA in image.

IMAGE_DEBUG_TYPE_BORLAND

9

Reserved for Borland.

IMAGE_DEBUG_TYPE_RESERVED10

10

Reserved.

IMAGE_DEBUG_TYPE_CLSID

11

Reserved.

IMAGE_DEBUG_TYPE_REPRO

16

PE determinism or reproducibility.

IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS

20

Extended DLL characteristics bits.

 

Se o campo Tipo estiver definido como IMAGE_DEBUG_TYPE_FPO, os dados brutos de depuração serão uma matriz na qual cada membro descreve o quadro de pilha de uma função. Nem todas as funções no arquivo de imagem devem ter informações de FPO definidas para ele, mesmo que o tipo de depuração seja FPO. Supõe-se que as funções que não possuem informações de FPO tenham quadros de pilha normais. O formato das informações do FPO é o seguinte:

 

C++

#define FRAME_FPO   0              

#define FRAME_TRAP  1

#define FRAME_TSS   2

 

typedef struct _FPO_DATA {

    DWORD       ulOffStart;            // offset 1st byte of function code

    DWORD       cbProcSize;            // # bytes in function

    DWORD       cdwLocals;             // # bytes in locals/4

    WORD        cdwParams;             // # bytes in params/4

    WORD        cbProlog : 8;          // # bytes in prolog

    WORD        cbRegs   : 3;          // # regs saved

    WORD        fHasSEH  : 1;          // TRUE if SEH in func

    WORD        fUseBP   : 1;          // TRUE if EBP has been allocated

    WORD        reserved : 1;          // reserved for future use

    WORD        cbFrame  : 2;          // frame type

} FPO_DATA;

 

A presença de uma entrada do tipo IMAGE_DEBUG_TYPE_REPRO indica que o arquivo PE foi criado de maneira a obter determinismo ou reprodutibilidade. Se a entrada não for alterada, é garantido que o arquivo PE de saída seja idêntico bit a bit, independentemente de quando ou onde o PE for produzido. Vários campos de data / hora no arquivo PE são preenchidos com parte ou todos os bits de um valor de hash calculado que usa o conteúdo do arquivo PE como entrada e, portanto, não representam mais a data e a hora reais em que um arquivo PE ou dados específicos relacionados dentro o PE é produzido. Os dados brutos dessa entrada de depuração podem estar vazios ou podem conter um valor de hash calculado precedido por um valor de quatro bytes que representa o comprimento do valor de hash.

Se o campo Tipo estiver definido como IMAGE_DEBUG_TYPE_EX_DLLCHARACTERISTICS, os dados brutos de depuração conterão bits de características DLL estendidos, além daqueles que podem ser definidos no cabeçalho opcional da imagem. Consulte Características da DLL na seção Campos específicos do Windows do cabeçalho opcional (apenas imagem).

 

Características estendidas da DLL

Os seguintes valores são definidos para os bits de características estendidas da DLL.

TABELA 48

Constant

Value

Description

IMAGE_DLLCHARACTERISTICS_EX_CET_COMPAT

0x0001

Image is CET compatible.

 

.debug$F (somente objeto)

Os dados nesta seção foram substituídos no Visual C ++ versão 7.0 e posterior por um conjunto mais extenso de dados emitidos em uma subseção .debug$S.

Os arquivos de objeto podem conter seções .debug$F  cujo conteúdo é um ou mais registros FPO_DATA (informações de omissão do ponteiro de quadro). Consulte “IMAGE_DEBUG_TYPE_FPO” em Tipo de depuração .

O vinculador reconhece esses registros .debug$F . Se as informações de depuração estiverem sendo geradas, o vinculador classificará os registros FPO_DATA pelo procedimento RVA e gerará uma entrada no diretório de depuração para eles.

O compilador não deve gerar registros FPO para procedimentos que tenham um formato de quadro padrão.

.debug$S (somente objeto)

Esta seção contém informações de depuração do Visual C ++ (informações simbólicas).

.debug$P (somente objeto)

Esta seção contém informações de depuração do Visual C ++ (informações pré-compiladas). Esses são tipos compartilhados entre todos os objetos que foram compilados usando o cabeçalho pré-compilado que foi gerado com esse objeto.

.debug$T (somente objeto)

Esta seção contém informações de depuração do Visual C ++ (informações de tipo).

 

Suporte do vinculador para informações de depuração da Microsoft

Para oferecer suporte a informações de depuração, o vinculador:

  • Reúne todos os dados de depuração relevantes do .debug$Fdebug$S.debug$P, e seções .debug$T.
  • Processa esses dados junto com as informações de depuração geradas pelo vinculador no arquivo PDB e cria uma entrada no diretório de depuração para fazer referência a ele.

 

A seção .drectve (somente objeto)

Uma seção é uma seção de diretiva se tiver o sinalizador IMAGE_SCN_LNK_INFO definido no cabeçalho da seção e tiver o nome da seção .drectve. O vinculador remove uma seção .drectve após o processamento das informações, para que a seção não apareça no arquivo de imagem que está sendo vinculado.

Uma seção .drectve consiste em uma sequência de texto que pode ser codificada como ANSI ou UTF-8. Se o marcador de ordem de bytes UTF-8 (BOM, um prefixo de três bytes que consiste em 0xEF, 0xBB e 0xBF) não estiver presente, a cadeia de diretiva será interpretada como ANSI. A cadeia de diretiva é uma série de opções de vinculador que são separadas por espaços. Cada opção contém um hífen, o nome da opção e qualquer atributo apropriado. Se uma opção contiver espaços, ela deverá estar entre aspas. A seção .drectve não deve ter realocações ou números de linha.

 

A seção .edata (somente imagem)

A seção de dados de exportação, denominada .edata, contém informações sobre símbolos que outras imagens podem acessar por meio de vínculo dinâmico. Os símbolos exportados geralmente são encontrados nas DLLs, mas as DLLs também podem importar símbolos.

Uma visão geral da estrutura geral da seção de exportação é descrita abaixo. As tabelas descritas são geralmente contíguas no arquivo na ordem mostrada (embora isso não seja necessário). Somente a tabela de diretório de exportação e a tabela de endereço de exportação são necessárias para exportar símbolos como ordinais. (Um ordinal é uma exportação que é acessada diretamente pelo índice da tabela de endereços de exportação.) A tabela do ponteiro de nomes, a tabela ordinal e a tabela de nomes de exportação existem para oferecer suporte ao uso de nomes de exportação.

TABELA 49

Table Name

Description

Export directory table

A table with just one row (unlike the debug directory). This table indicates the locations and sizes of the other export tables.

Export address table

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 a public name is defined.

Name pointer table

An array of pointers to the public export names, sorted in ascending order.

Ordinal table

An 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.

Export name 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 are not necessarily the same as the private names that are used within the image file.

 

Quando outro arquivo de imagem importa um símbolo por nome, o carregador Win32 pesquisa na tabela de ponteiros de nomes uma sequência correspondente. Se uma sequência correspondente for encontrada, o ordinal associado será identificado procurando o membro correspondente na tabela ordinal (ou seja, o membro da tabela ordinal com o mesmo índice que o ponteiro da sequência encontrado na tabela de nomes). O ordinal resultante é um índice na tabela de endereços de exportação, que fornece a localização real do símbolo desejado. Cada símbolo de exportação pode ser acessado por um ordinal.

Quando outro arquivo de imagem importa um símbolo por ordinal, é desnecessário pesquisar na tabela de ponteiros de nomes por uma sequência correspondente. O uso direto de um ordinal é, portanto, mais eficiente. No entanto, um nome de exportação é mais fácil de lembrar e não requer que o usuário conheça o índice da tabela para o símbolo.

 

Tabela de Diretório de Exportação

As informações do símbolo de exportação começam com a tabela do diretório de exportação, que descreve o restante das informações do símbolo de exportação. A tabela do diretório de exportação contém informações de endereço usadas para resolver importações para os pontos de entrada nesta imagem.

TABELA 50

Offset

Size

Field

Description

0

4

Export Flags

Reserved, must be 0.

4

4

Time/Date Stamp

The time and date that the export data was created.

8

2

Major Version

The major version number. The major and minor version numbers can be set by the user.

10

2

Minor Version

The minor version number.

12

4

Name RVA

The address of the ASCII string that contains the name of the DLL. This address is relative to the image base.

16

4

Ordinal Base

The starting ordinal number for exports in this image. This field specifies the starting ordinal number for the export address table. It is usually set to 1.

20

4

Address Table Entries

The number of entries in the export address table.

24

4

Number of Name Pointers

The number of entries in the name pointer table. This is also the number of entries in the ordinal table.

28

4

Export Address Table RVA

The address of the export address table, relative to the image base.

32

4

Name Pointer RVA

The address of the export name pointer table, relative to the image base. The table size is given by the Number of Name Pointers field.

36

4

Ordinal Table RVA

The address of the ordinal table, relative to the image base.

 

Tabela de endereços de exportação

A tabela de endereços de exportação contém o endereço dos pontos de entrada exportados, dados e absolutos exportados. Um número ordinal é usado como um índice na tabela de endereços de exportação.

Cada entrada na tabela de endereços de exportação é um campo que usa um dos dois formatos na tabela a seguir. Se o endereço especificado não estiver na seção de exportação (conforme definido pelo endereço e comprimento indicados no cabeçalho opcional), o campo será um RVA de exportação, que é um endereço real no código ou nos dados. Caso contrário, o campo é um encaminhador RVA, que nomeia um símbolo em outra DLL.

TABELA 51

Offset

Size

Field

Description

0

4

Export RVA

The address of the exported symbol when loaded into memory, relative to the image base. For example, the address of an exported function.

0

4

Forwarder RVA

The pointer to a null-terminated ASCII string in the export section. This string must be within the range that is given by the export table data directory entry. See Optional Header Data Directories (Image Only). This string gives the DLL name and the name of the export (for example, “MYDLL.expfunc”) or the DLL name and the ordinal number of the export (for example, “MYDLL.#27”).

 

Um encaminhador RVA exporta uma definição de alguma outra imagem, fazendo parecer como se estivesse sendo exportada pela imagem atual. Assim, o símbolo é simultaneamente importado e exportado.

Por exemplo, no Kernel32.dll no Windows XP, a exportação denominada “HeapAlloc” é encaminhada para a cadeia “NTDLL.RtlAllocateHeap“. Isso permite que os aplicativos usem o módulo específico do Windows XP Ntdll.dll sem realmente conter referências de importação. A tabela de importação do aplicativo refere-se apenas ao Kernel32.dll. Portanto, o aplicativo não é específico para o Windows XP e pode ser executado em qualquer sistema Win32.

 

Tabela de ponteiro de nome de exportação

A tabela do ponteiro do nome da exportação é uma matriz de endereços (RVAs) na tabela de nomes da exportação. Os ponteiros têm 32 bits cada e são relativos à base da imagem. Os ponteiros são ordenados lexicamente para permitir pesquisas binárias.

Um nome de exportação é definido apenas se a tabela de ponteiros de nome de exportação contiver um ponteiro para ela.

 

Tabela Ordinal de Exportação

A tabela ordinal de exportação é uma matriz de índices imparciais de 16 bits na tabela de endereços de exportação. Ordinais são influenciados pelo campo Base Ordinal da tabela do diretório de exportação. Em outras palavras, a base ordinal deve ser subtraída dos ordinais para obter índices verdadeiros na tabela de endereços de exportação.

 

A tabela do ponteiro do nome da exportação e a tabela ordinal da exportação formam duas matrizes paralelas que são separadas para permitir o alinhamento do campo natural. Essas duas tabelas, com efeito, funcionam como uma tabela, na qual a coluna Exportar Ponteiro de Nome aponta para um nome público (exportado) e a coluna Exportar Ordinal fornece o ordinal correspondente para esse nome público. Um membro da tabela de ponteiro de nome de exportação e um membro da tabela ordinal de exportação são associados por terem a mesma posição (índice) em suas respectivas matrizes.

 

Assim, quando a tabela do ponteiro do nome da exportação é pesquisada e uma string correspondente é encontrada na posição i, o algoritmo para encontrar o RVA do símbolo e o ordinal polarizado é:

C++

i = Search_ExportNamePointerTable (name);

ordinal = ExportOrdinalTable [i];

 

rva = ExportAddressTable [ordinal];

biased_ordinal = ordinal + OrdinalBase;

 

Ao procurar um símbolo por ordinal (tendencioso), o algoritmo para encontrar o RVA e o nome do símbolo é:

C++

ordinal = biased_ordinal – OrdinalBase;

i = Search_ExportOrdinalTable (ordinal);

 

rva = ExportAddressTable [ordinal];

name = ExportNameTable [i];

 

Tabela de nomes de exportação

A tabela de nomes de exportação contém os dados reais da cadeia que foram apontados pela tabela de ponteiros de nomes de exportação. As cadeias nesta tabela são nomes públicos que outras imagens podem usar para importar os símbolos. Esses nomes de exportação pública não são necessariamente os mesmos que os nomes de símbolos privados que os símbolos possuem em seu próprio arquivo de imagem e código-fonte, embora possam ser.

Todo símbolo exportado possui um valor ordinal, que é apenas o índice da tabela de endereços de exportação. O uso de nomes de exportação, no entanto, é opcional. Alguns, todos ou nenhum dos símbolos exportados podem ter nomes de exportação. Para símbolos exportados que possuem nomes de exportação, as entradas correspondentes na tabela de ponteiros de nomes de exportação e na tabela ordinal de exportação trabalham juntas para associar cada nome a um ordinal.

A estrutura da tabela de nomes de exportação é uma série de cadeias ASCII terminadas em nulo de comprimento variável.

 

A seção .idata

Todos os arquivos de imagem que importam símbolos, incluindo praticamente todos os arquivos executáveis (EXE), possuem uma seção .idata. Um layout de arquivo típico para as informações de importação é apresentado a seguir:

  • Directory Table

Null Directory Entry

  • DLL1 Import Lookup Table

Null

  • DLL2 Import Lookup Table

Null

  • DLL3 Import Lookup Table

Null

  • Hint-Name Table

 

Tabela de diretório de importação

As informações de importação começam com a tabela do diretório de importação, que descreve o restante das informações de importação. A tabela do diretório de importação contém informações de endereço usadas para resolver as referências de correção dos pontos de entrada em uma imagem DLL. A tabela do diretório de importação consiste em uma matriz de entradas do diretório de importação, uma entrada para cada DLL à qual a imagem se refere. A última entrada do diretório está vazia (preenchida com valores nulos), o que indica o final da tabela de diretórios.

Cada entrada do diretório de importação possui o seguinte formato:

TABELA 52

Offset

Size

Field

Description

0

4

Import Lookup Table RVA (Characteristics)

The RVA of the import lookup table. This table contains a name or ordinal for each import. (The name “Characteristics” is used in Winnt.h, but no longer describes this field.)

4

4

Time/Date Stamp

The stamp that is set to zero until the image is bound. After the image is bound, this field is set to the time/data stamp of the DLL.

8

4

Forwarder Chain

The index of the first forwarder reference.

12

4

Name RVA

The address of an ASCII string that contains the name of the DLL. This address is relative to the image base.

16

4

Import Address Table RVA (Thunk Table)

The RVA of the import address table. The contents of this table are identical to the contents of the import lookup table until the image is bound.

 

 

Tabela de pesquisa de importação

Uma tabela de pesquisa de importação é uma matriz de números de 32 bits para o PE32 ou uma matriz de números de 64 bits para o PE32+. Cada entrada usa o formato de campo de bits descrito na tabela a seguir. Nesse formato, o bit 31 é o bit mais significativo para o PE32 e o bit 63 é o bit mais significativo para o PE32+. A coleção dessas entradas descreve todas as importações de uma determinada DLL. A última entrada é definida como zero (NULL) para indicar o final da tabela.

TABELA 53

Bit(s)

Size

Bit field

Description

31/63

1

Ordinal/Name Flag

If this bit is set, import by ordinal. Otherwise, import by name. Bit is masked as 0x80000000 for PE32, 0x8000000000000000 for PE32+.

15-0

16

Ordinal Number

A 16-bit ordinal number. This field is used only if the Ordinal/Name Flag bit field is 1 (import by ordinal). Bits 30-15 or 62-15 must be 0.

30-0

31

Hint/Name Table RVA

A 31-bit RVA of a hint/name table entry. This field is used only if the Ordinal/Name Flag bit field is 0 (import by name). For PE32+ bits 62-31 must be zero.

 

Tabela de Nomes (Hint/Name Table)

Uma tabela de dica/nome é suficiente para toda a seção de importação. Cada entrada na tabela dica/nome tem o seguinte formato:

TABELA 54

Offset

Size

Field

Description

0

2

Hint

An 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 DLL’s export name pointer table.

2

variable

Name

An ASCII string that contains the 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.

*

0 or 1

Pad

A trailing zero-pad byte that appears after the trailing null byte, if necessary, to align the next entry on an even boundary.

 

Tabela de endereços de importação

A estrutura e o conteúdo da tabela de endereços de importação são idênticos aos da tabela de pesquisa de importação, até o arquivo ser vinculado. Durante a ligação, as entradas na tabela de endereços de importação são substituídas pelos endereços de 32 bits (para PE32) ou de 64 bits (para PE32 +) dos símbolos que estão sendo importados. Esses endereços são os endereços de memória reais dos símbolos, embora tecnicamente ainda sejam chamados de “endereços virtuais”. O carregador normalmente processa a ligação.

 

A seção .pdata

A seção .pdata contém uma matriz de entradas da tabela de funções que são usadas para manipulação de exceções. É apontado pela entrada da tabela de exceção no diretório de dados da imagem. As entradas devem ser classificadas de acordo com os endereços das funções (o primeiro campo de cada estrutura) antes de serem emitidas na imagem final. A plataforma de destino determina qual das três variações de formato de entrada da tabela de funções descritas abaixo é usada.

Para imagens MIPS de 32 bits, as entradas da tabela de funções têm o seguinte formato:

TABELA 55

Offset

Size

Field

Description

0

4

Begin Address

The VA of the corresponding function.

4

4

End Address

The VA of the end of the function.

8

4

Exception Handler

The pointer to the exception handler to be executed.

12

4

Handler Data

The pointer to additional information to be passed to the handler.

16

4

Prolog End Address

The VA of the end of the function’s prolog.

 

Para as plataformas Windows CEM, PowerPC, SH3 e SH4 Windows CE, as entradas da tabela de funções têm o seguinte formato:

TABELA 56

Offset

Size

Field

Description

0

4

Begin Address

The VA of the corresponding function.

4

8 bits

Prolog Length

The number of instructions in the function’s prolog.

4

22 bits

Function Length

The number of instructions in the function.

4

1 bit

32-bit Flag

If set, the function consists of 32-bit instructions. If clear, the function consists of 16-bit instructions.

4

1 bit

Exception Flag

If set, an exception handler exists for the function. Otherwise, no exception handler exists.

 

Para plataformas x64 e Itanium, as entradas da tabela de funções têm o seguinte formato:

TABELA 57

Offset

Size

Field

Description

0

4

Begin Address

The RVA of the corresponding function.

4

4

End Address

The RVA of the end of the function.

8

4

Unwind Information

The RVA of the unwind information.

 

A seção .reloc (apenas imagem)

A tabela de realocação base contém entradas para todas as realocações base na imagem. O campo Tabela de realocação base nos diretórios de dados de cabeçalho opcionais fornece o número de bytes na tabela de realocação base. Para obter mais informações, consulte Diretórios de dados de cabeçalho opcionais (apenas imagem). A tabela de realocação básica é dividida em blocos. Cada bloco representa as realocações básicas para uma página 4K. Cada bloco deve iniciar em um limite de 32 bits.

O carregador não é necessário para processar as realocações de base que são resolvidas pelo vinculador, a menos que a imagem de carregamento não possa ser carregada na base de imagem especificada no cabeçalho do PE.

 

Bloco de realocação base

Cada bloco de realocação básico começa com a seguinte estrutura:

TABELA 58

Offset

Size

Field

Description

0

4

Page RVA

The image base plus the page RVA is added to each offset to create the VA where the base relocation must be applied.

4

4

Block Size

The total number of bytes in the base relocation block, including the Page RVA and Block Size fields and the Type/Offset fields that follow.

 

O campo Tamanho do bloco é seguido por qualquer número de entradas de campo Tipo ou Deslocamento. Cada entrada é uma PALAVRA (2 bytes) e possui a seguinte estrutura:

TABELA 59

Offset

Size

Field

Description

0

4 bits

Type

Stored in the high 4 bits of the WORD, a value that indicates the type of base relocation to be applied. For more information, see Base Relocation Types.

0

12 bits

Offset

Stored in the remaining 12 bits of the WORD, an offset from the starting address that was specified in the Page RVA field for the block. This offset specifies where the base relocation is to be applied.

 

Para aplicar uma realocação de base, a diferença é calculada entre o endereço base preferido e a base onde a imagem é realmente carregada. Se a imagem é carregada na sua base preferida, a diferença é zero e, portanto, as realocações da base não precisam ser aplicadas.

 

Tipos de realocação base

TABELA 60

Constant

Value

Description

IMAGE_REL_BASED_ABSOLUTE

0

The base relocation is skipped. This type can be used to pad a block.

IMAGE_REL_BASED_HIGH

1

The base relocation adds the high 16 bits of the difference to the 16-bit field at offset. The 16-bit field represents the high value of a 32-bit word.

IMAGE_REL_BASED_LOW

2

The base relocation adds the low 16 bits of the difference to the 16-bit field at offset. The 16-bit field represents the low half of a 32-bit word.

IMAGE_REL_BASED_HIGHLOW

3

The base relocation applies all 32 bits of the difference to the 32-bit field at offset.

IMAGE_REL_BASED_HIGHADJ

4

The base relocation adds the high 16 bits of the difference 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.

IMAGE_REL_BASED_MIPS_JMPADDR

5

The relocation interpretation is dependent on the machine type.
When the machine type is MIPS, the base relocation applies to a MIPS jump instruction.

IMAGE_REL_BASED_ARM_MOV32

5

This relocation is meaningful only when the machine type is ARM or Thumb. The base relocation applies the 32-bit address of a symbol across a consecutive MOVW/MOVT instruction pair.

IMAGE_REL_BASED_RISCV_HIGH20

5

This relocation is only meaningful when the machine type is RISC-V. The base relocation applies to the high 20 bits of a 32-bit absolute address.

6

Reserved, must be zero.

IMAGE_REL_BASED_THUMB_MOV32

7

This relocation is meaningful only when the machine type is Thumb. The base relocation applies the 32-bit address of a symbol to a consecutive MOVW/MOVT instruction pair.

IMAGE_REL_BASED_RISCV_LOW12I

7

This relocation is only meaningful when the machine type is RISC-V. The base relocation applies to the low 12 bits of a 32-bit absolute address formed in RISC-V I-type instruction format.

IMAGE_REL_BASED_RISCV_LOW12S

8

This relocation is only meaningful when the machine type is RISC-V. The base relocation applies to the low 12 bits of a 32-bit absolute address formed in RISC-V S-type instruction format.

IMAGE_REL_BASED_MIPS_JMPADDR16

9

The relocation is only meaningful when the machine type is MIPS. The base relocation applies to a MIPS16 jump instruction.

IMAGE_REL_BASED_DIR64

10

The base relocation applies the difference to the 64-bit field at offset.

 

A seção .tls

A seção .tls fornece suporte direto de PE e COFF para armazenamento local de encadeamento estático (TLS). O TLS é uma classe de armazenamento especial suportada pelo Windows na qual um objeto de dados não é uma variável automática (pilha), mas é local para cada encadeamento individual que executa o código. Assim, cada encadeamento pode manter um valor diferente para uma variável declarada usando TLS.

 

Observe que qualquer quantidade de dados TLS pode ser suportada usando a API chama TlsAlloc, TlsFree, TlsSetValue e TlsGetValue. A implementação do PE ou COFF é uma abordagem alternativa ao uso da API e tem a vantagem de ser mais simples do ponto de vista do programador de linguagem de alto nível. Essa implementação permite que os dados TLS sejam definidos e inicializados de maneira semelhante às variáveis estáticas comuns em um programa. Por exemplo, no Visual C ++, uma variável TLS estática pode ser definida da seguinte maneira, sem usar a API do Windows:

__declspec (thread) int tlsFlag = 1;

Para oferecer suporte a essa construção de programação, a seção .tls do PE e COFF especifica as seguintes informações: dados de inicialização, rotinas de retorno de chamada para inicialização e finalização por thread e o índice TLS, explicado na discussão a seguir.

Observação

Os objetos de dados TLS declarados estaticamente podem ser usados apenas em arquivos de imagem carregados estaticamente. Esse fato torna não confiável o uso de dados estáticos de TLS em uma DLL, a menos que você saiba que a DLL ou qualquer coisa vinculada estaticamente a ela nunca será carregada dinamicamente com a função API LoadLibrary.

 

O código executável acessa um objeto de dados TLS estático através das seguintes etapas:

  1. No momento do link, o vinculador define o campo Endereço do Índice do diretório TLS. Este campo aponta para um local em que o programa espera receber o índice TLS.
  2. A biblioteca de tempo de execução da Microsoft facilita esse processo, definindo uma imagem de memória do diretório TLS e fornecendo o nome especial “__tls_used” (plataformas Intel x86) ou “_tls_used” (outras plataformas). O vinculador procura essa imagem de memória e usa os dados para criar o diretório TLS. Outros compiladores que oferecem suporte ao TLS e funcionam com o vinculador da Microsoft devem usar essa mesma técnica.
  3. Quando um encadeamento é criado, o carregador comunica o endereço da matriz TLS do encadeamento colocando o endereço do bloco de ambiente de encadeamento (TEB) no registrador FS. Um ponteiro para a matriz TLS está no deslocamento de 0x2C desde o início do TEB. Esse comportamento é específico da Intel x86.
  4. O carregador atribui o valor do índice TLS ao local indicado pelo campo Endereço do Índice.
  5. O código executável recupera o índice TLS e também o local da matriz TLS.
  6. O código usa o índice TLS e a localização da matriz TLS (multiplicando o índice por 4 e usando-o como um deslocamento para a matriz) para obter o endereço da área de dados TLS para o programa e módulo em questão. Cada encadeamento possui sua própria área de dados TLS, mas isso é transparente para o programa, que não precisa saber como os dados são alocados para encadeamentos individuais.
  7. Um objeto de dados TLS individual é acessado como algum deslocamento fixo na área de dados TLS.

 

A matriz TLS é uma matriz de endereços que o sistema mantém para cada encadeamento. Cada endereço nessa matriz fornece a localização dos dados TLS para um determinado módulo (EXE ou DLL) dentro do programa. O índice TLS indica qual membro da matriz usar. O índice é um número (significativo apenas para o sistema) que identifica o módulo.

 

O diretório TLS

O diretório TLS possui o seguinte formato:

TABELA 61

Offset (PE32/ PE32+)

Size (PE32/ PE32+)

Field

Description

0

4/8

Raw Data Start VA

The starting address of the TLS template. The template is a block of data that is used to initialize TLS data. The system copies all of 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.

4/8

4/8

Raw Data End VA

The address of the last byte of the TLS, except for the zero fill. As with the Raw Data Start VA field, this is a VA, not an RVA.

8/16

4/8

Address of Index

The 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 that is accessible to the program.

12/24

4/8

Address of Callbacks

The pointer to an array of TLS callback functions. The array is null-terminated, so if no callback function is supported, this field points to 4 bytes set to zero. For information about the prototype for these functions, see TLS Callback Functions.

16/32

4

Size of Zero Fill

The size in bytes of the template, beyond the initialized data delimited by the Raw Data Start VA and Raw Data End VA fields. 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.

20/36

4

Characteristics

The four bits [23:20] describe alignment info. Possible values are those defined as IMAGE_SCN_ALIGN_*, which are also used to describe alignment of section in object files. The other 28 bits are reserved for future use.

 

Funções de retorno de chamada TLS

O programa pode fornecer uma ou mais funções de retorno de chamada TLS para suportar inicialização e finalização adicionais para objetos de dados TLS. Um uso típico para uma função de retorno de chamada seria chamar construtores e destruidores de objetos.

Embora normalmente não haja mais de uma função de retorno de chamada, um retorno de chamada é implementado como uma matriz para possibilitar a adição de funções adicionais de retorno de chamada, se desejado. Se houver mais de uma função de retorno de chamada, cada função é chamada na ordem em que seu endereço aparece na matriz. Um ponteiro nulo termina a matriz. É perfeitamente válido ter uma lista vazia (sem suporte para retorno de chamada); nesse caso, a matriz de retorno de chamada possui exatamente um membro – um ponteiro nulo.

O protótipo para uma função de retorno de chamada (apontado por um ponteiro do tipo PIMAGE_TLS_CALLBACK) possui os mesmos parâmetros que uma função de ponto de entrada da DLL:

C++

typedef VOID

(NTAPI *PIMAGE_TLS_CALLBACK) (

    PVOID DllHandle,

    DWORD Reason,

    PVOID Reserved

    );

 

O parâmetro Reserved deve ser definido como zero. O parâmetro Reason pode assumir os seguintes valores:

TABELA 62

Setting

Value

Description

DLL_PROCESS_ATTACH

1

A new process has started, including the first thread.

DLL_THREAD_ATTACH

2

A new thread has been created. This notification sent for all but the first thread.

DLL_THREAD_DETACH

3

A thread is about to be terminated. This notification sent for all but the first thread.

DLL_PROCESS_DETACH

0

A process is about to terminate, including the original thread.

 

A estrutura de configuração de carregamento (apenas imagem)

A estrutura de configuração de carregamento (IMAGE_LOAD_CONFIG_DIRECTORY) era usada anteriormente em casos muito limitados no próprio sistema operacional Windows NT para descrever vários recursos muito difíceis ou grandes demais para serem descritos no cabeçalho do arquivo ou no cabeçalho opcional da imagem. As versões atuais do vinculador da Microsoft e do Windows XP e versões posteriores do Windows usam uma nova versão dessa estrutura para sistemas baseados em x86 de 32 bits que incluem a tecnologia SEH reservada. Isso fornece uma lista de manipuladores de exceção estruturados seguros que o sistema operacional usa durante o envio de exceções. Se o endereço do manipulador residir no intervalo VA de uma imagem e estiver marcado como reservado para reconhecimento de SEH (ou seja, IMAGE_DLLCHARACTERISTICS_NO_SEH estará desmarcado no campo DllCharacteristics do cabeçalho opcional, conforme descrito anteriormente), o manipulador deve estar na lista de manipuladores seguros conhecidos para essa imagem. Caso contrário, o sistema operacional encerra o aplicativo. Isso ajuda a impedir a exploração “sequestro do manipulador de exceções x86” que foi usada no passado para controlar o sistema operacional.

O vinculador da Microsoft fornece automaticamente uma estrutura de configuração de carregamento padrão para incluir os dados SEH reservados. Se o código do usuário já fornecer uma estrutura de configuração de carregamento, ele deverá incluir os novos campos SEH reservados. Caso contrário, o vinculador não pode incluir os dados SEH reservados e a imagem não é marcada como contendo SEH reservado.

 

Carregar diretório de configuração

A entrada do diretório de dados para uma estrutura de configuração de carga SEH pré-reservada deve especificar um tamanho específico da estrutura de configuração de carga, porque o carregador do sistema operacional sempre espera que esse seja um determinado valor. Nesse sentido, o tamanho é realmente apenas uma verificação de versão. Para compatibilidade com o Windows XP e versões anteriores do Windows, o tamanho deve ser 64 para imagens x86.

 

Carregar layout de configuração

A estrutura de configuração de carregamento possui o seguinte layout para arquivos PE de 32 e 64 bits:

TABELA 63

Offset

Size

Field

Description

0

4

Characteristics

Flags that indicate attributes of the file, currently unused.

4

4

TimeDateStamp

Date and time stamp value. The value is represented in the number of seconds that have elapsed since midnight (00:00:00), January 1, 1970, Universal Coordinated Time, according to the system clock. The time stamp can be printed by using the C runtime (CRT) time function.

8

2

MajorVersion

Major version number.

10

2

MinorVersion

Minor version number.

12

4

GlobalFlagsClear

The global loader flags to clear for this process as the loader starts the process.

16

4

GlobalFlagsSet

The global loader flags to set for this process as the loader starts the process.

20

4

CriticalSectionDefaultTimeout

The default timeout value to use for this process’s critical sections that are abandoned.

24

4/8

DeCommitFreeBlockThreshold

Memory that must be freed before it is returned to the system, in bytes.

28/32

4/8

DeCommitTotalFreeThreshold

Total amount of free memory, in bytes.

32/40

4/8

LockPrefixTable

[x86 only] The VA of a list of addresses where the LOCK prefix is used so that they can be replaced with NOP on single processor machines.

36/48

4/8

MaximumAllocationSize

Maximum allocation size, in bytes.

40/56

4/8

VirtualMemoryThreshold

Maximum virtual memory size, in bytes.

44/64

4/8

ProcessAffinityMask

Setting this field to a non-zero value is equivalent to calling SetProcessAffinityMask with this value during process startup (.exe only)

48/72

4

ProcessHeapFlags

Process heap flags that correspond to the first argument of the HeapCreate function. These flags apply to the process heap that is created during process startup.

52/76

2

CSDVersion

The service pack version identifier.

54/78

2

Reserved

Must be zero.

56/80

4/8

EditList

Reserved for use by the system.

60/88

4/8

SecurityCookie

A pointer to a cookie that is used by Visual C++ or GS implementation.

64/96

4/8

SEHandlerTable

[x86 only] The VA of the sorted table of RVAs of each valid, unique SE handler in the image.

68/104

4/8

SEHandlerCount

[x86 only] The count of unique handlers in the table.

72/112

4/8

GuardCFCheckFunctionPointer

The VA where Control Flow Guard check-function pointer is stored.

76/120

4/8

GuardCFDispatchFunctionPointer

The VA where Control Flow Guard dispatch-function pointer is stored.

80/128

4/8

GuardCFFunctionTable

The VA of the sorted table of RVAs of each Control Flow Guard function in the image.

84/136

4/8

GuardCFFunctionCount

The count of unique RVAs in the above table.

88/144

4

GuardFlags

Control Flow Guard related flags.

92/148

12

CodeIntegrity

Code integrity information.

104/160

4/8

GuardAddressTakenIatEntryTable

The VA where Control Flow Guard address taken IAT table is stored.

108/168

4/8

GuardAddressTakenIatEntryCount

The count of unique RVAs in the above table.

112/176

4/8

GuardLongJumpTargetTable

The VA where Control Flow Guard long jump target table is stored.

116/184

4/8

GuardLongJumpTargetCount

The count of unique RVAs in the above table.

 

O campo GuardFlags contém uma combinação de um ou mais dos seguintes sinalizadores e subcampos:

  • O módulo executa verificações de integridade do fluxo de controle usando o suporte fornecido pelo sistema.

#define IMAGE_GUARD_CF_INSTRUMENTED 0x00000100

  • O módulo executa o fluxo de controle e escreve verificações de integridade.

#define IMAGE_GUARD_CFW_INSTRUMENTED 0x00000200

  • O módulo contém metadados válidos do destino do fluxo de controle.

#define IMAGE_GUARD_CF_FUNCTION_TABLE_PRESENT 0x00000400

  • O módulo não faz uso do cookie de segurança / GS.

#define IMAGE_GUARD_SECURITY_COOKIE_UNUSED 0x00000800

  • O módulo suporta IAT de atraso de carregamento somente leitura.

#define IMAGE_GUARD_PROTECT_DELAYLOAD_IAT 0x00001000

  • Atrase a tabela de importação de carregamento em sua própria seção .didat (sem mais nada) que pode ser protegida livremente.

#define IMAGE_GUARD_DELAYLOAD_IAT_IN_ITS_OWN_SECTION 0x00002000

  • O módulo contém informações de exportação suprimidas. Isso também infere que o endereço obtido da tabela IAT também está presente na configuração de carregamento.

#define IMAGE_GUARD_CF_EXPORT_SUPPRESSION_INFO_PRESENT 0x00004000

  • Módulo permite a supressão de exportações.

#define IMAGE_GUARD_CF_ENABLE_EXPORT_SUPPRESSION 0x00008000

  • O módulo contém informações sobre o destino longjmp.

#define IMAGE_GUARD_CF_LONGJUMP_TABLE_PRESENT 0x00010000

Máscara para o subcampo que contém o passo das entradas da tabela de funções do Control Flow Guard (ou seja, a contagem adicional de bytes por entrada da tabela).

#define IMAGE_GUARD_CF_FUNCTION_TABLE_SIZE_MASK 0xF0000000

Além disso, o cabeçalho winnt.h do Windows SDK define essa macro para a quantidade de bits que desloca para a direita o valor GuardFlags para justificar à direita o passo da tabela de funções Control Flow Guard:

#define IMAGE_GUARD_CF_FUNCTION_TABLE_SIZE_SHIFT 28

 

A seção .rsrc

Os recursos são indexados por uma estrutura de árvore classificada em binário de vários níveis. O design geral pode incorporar 2 ** 31 níveis. Por convenção, no entanto, o Windows usa três níveis:

Tipo Nome Idioma

Uma série de tabelas de diretórios de recursos relaciona todos os níveis da seguinte maneira: Cada tabela de diretórios é seguida por uma série de entradas de diretório que fornecem o nome ou identificador (ID) para esse nível (tipo, nome ou idioma) e um endereço de uma descrição de dados ou de outra tabela de diretório. Se o endereço apontar para uma descrição de dados, os dados serão uma folha na árvore. Se o endereço apontar para outra tabela de diretório, essa tabela listará as entradas de diretório no próximo nível abaixo.

As IDs de tipo, nome e idioma de uma folha são determinadas pelo caminho percorrido pelas tabelas de diretório para alcançá-la. A primeira tabela determina o ID do tipo, a segunda tabela (apontada pela entrada do diretório na primeira tabela) determina o ID do nome e a terceira tabela determina o ID do idioma.

A estrutura geral da seção .rsrc é:

TABELA 64

Data

Description

Resource Directory Tables (and Resource Directory Entries)

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 ID but different Name IDs. Third-level trees have the same Type and Name IDs but different Language IDs.
Each individual table is immediately followed by directory entries, in which each entry has a name or numeric identifier and a pointer to a data description or a table at the next lower level.

Resource Directory Strings

Two-byte-aligned Unicode strings, which serve as string data that is pointed to by directory entries.

Resource Data Description

An array of records, pointed to by tables, that describe the actual size and location of the resource data. These records are the leaves in the resource-description tree.

Resource Data

Raw data of the resource section. The size and location information in the Resource Data Descriptions field delimit the individual regions of resource data.

 

Tabela Diretório de Recursos

Cada tabela de diretório de recursos possui o seguinte formato. Essa estrutura de dados deve ser considerada o cabeçalho de uma tabela porque, na verdade, a tabela consiste em entradas de diretório (descritas na seção 6.9.2, “Entradas do diretório de recursos”) e nesta estrutura:

TABELA 65

Offset

Size

Field

Description

0

4

Characteristics

Resource flags. This field is reserved for future use. It is currently set to zero.

4

4

Time/Date Stamp

The time that the resource data was created by the resource compiler.

8

2

Major Version

The major version number, set by the user.

10

2

Minor Version

The minor version number, set by the user.

12

2

Number of Name Entries

The number of directory entries immediately following the table that use strings to identify Type, Name, or Language entries (depending on the level of the table).

14

2

Number of ID Entries

The number of directory entries immediately following the Name entries that use numeric IDs for Type, Name, or Language entries.

 

Entradas do diretório de recursos

As entradas do diretório compõem as linhas de uma tabela. Cada entrada do diretório de recursos possui o seguinte formato. Se a entrada é uma entrada de Nome ou ID é indicada pela tabela de diretório de recursos, que indica quantas entradas de Nome e ID a seguem (lembre-se de que todas as entradas de Nome precedem todas as entradas de ID da tabela). Todas as entradas da tabela são classificadas em ordem crescente: as entradas Nome por sequência que diferenciam maiúsculas de minúsculas e as entradas de ID por valor numérico. Os deslocamentos são relativos ao endereço no DataDirectory IMAGE_DIRECTORY_ENTRY_RESOURCE. Consulte Peering no interior do PE: um tour pelo formato de arquivo executável portátil Win32 para obter mais informações.

TABELA 66

Offset

Size

Field

Description

0

4

Name Offset

The offset of a string that gives the Type, Name, or Language ID entry, depending on level of table.

0

4

Integer ID

A 32-bit integer that identifies the Type, Name, or Language ID entry.

4

4

Data Entry Offset

High bit 0. Address of a Resource Data entry (a leaf).

4

4

Subdirectory Offset

High bit 1. The lower 31 bits are the address of another resource directory table (the next level down).

 

Sequência do Diretório de Recursos

A área de cadeia de caracteres do diretório de recursos consiste em cadeias de caracteres Unicode, alinhadas por palavras. Essas sequências de caracteres são armazenadas juntas após a última entrada do Diretório de Recursos e antes da primeira entrada de Dados de Recursos. Isso minimiza o impacto dessas cadeias de comprimento variável no alinhamento das entradas de diretório de tamanho fixo. Cada sequência de diretórios de recurso tem o seguinte formato:

TABELA 67

Offset

Size

Field

Description

0

2

Length

The size of the string, not including length field itself.

2

variable

Unicode String

The variable-length Unicode string data, word-aligned.

 

Entrada de dados do recurso

Cada entrada de Dados do recurso descreve uma unidade real de dados brutos na área Dados do recurso. Uma entrada de Dados do Recurso possui o seguinte formato:

TABELA 68

Offset

Size

Field

Description

0

4

Data RVA

The address of a unit of resource data in the Resource Data area.

4

4

Size

The size, in bytes, of the resource data that is pointed to by the Data RVA field.

8

4

Codepage

The code page that is used to decode code point values within the resource data. Typically, the code page would be the Unicode code page.

12

4

Reserved, must be 0.

 

A seção .cormeta (somente objeto)

Os metadados CLR são armazenados nesta seção. É usado para indicar que o arquivo de objeto contém código gerenciado. O formato dos metadados não está documentado, mas pode ser entregue às interfaces CLR para manipulação de metadados.

 

A seção .sxdata

Os manipuladores de exceção válidos de um objeto estão listados na seção .sxdata desse objeto. A seção está marcada como IMAGE_SCN_LNK_INFO. Ele contém o índice do símbolo COFF de cada manipulador válido, usando 4 bytes por índice.

 

Além disso, o compilador marca um objeto COFF como SEH registrado, emitindo o símbolo absoluto “@ feat.00” com o LSB do campo de valor definido como 1. Um objeto COFF sem manipuladores SEH registrados teria o “@ feat.00” símbolo, mas nenhuma seção .sxdata.

 

Formato de arquivo de arquivo (biblioteca)

O formato de arquivo COFF fornece um mecanismo padrão para armazenar coleções de arquivos de objetos. Essas coleções são comumente chamadas de bibliotecas na documentação de programação.

Os primeiros 8 bytes de um arquivo morto consistem na assinatura do arquivo. O restante do arquivo consiste em uma série de membros do arquivo, da seguinte maneira:

  • O primeiro e o segundo membros são “membros vinculados”. Cada um desses membros possui seu próprio formato, conforme descrito na seção Tipo de nome de importação. Normalmente, um vinculador coloca informações nesses membros do arquivo. Os membros do vinculador contêm o diretório do arquivo morto.
  • O terceiro membro é o membro “longnames“. Esse membro consiste em uma série de cadeias ASCII terminadas em nulo, nas quais cada cadeia é o nome de outro membro do arquivo morto.
  • O restante do arquivamento consiste em membros padrão (arquivo de objeto). Cada um desses membros contém o conteúdo de um arquivo de objeto na sua totalidade.

Um cabeçalho de membro do arquivo precede cada membro. A lista a seguir mostra a estrutura geral de um arquivo morto:

  • Signature :”!<arch>\n”
  • Header

1st Linker Member

  • Header

2nd Linker Member

  • Header

Longnames Member

  • Header

Contents of OBJ File 1 (COFF format)

  • Header

Contents of OBJ File 2 (COFF format)

 

Assinatura de arquivo morto

A assinatura do arquivo morto identifica o tipo de arquivo. Qualquer utilitário (por exemplo, um vinculador) que usa um arquivo morto como entrada pode verificar o tipo de arquivo lendo esta assinatura. A assinatura consiste nos seguintes caracteres ASCII, nos quais cada caractere abaixo é representado literalmente, exceto pelo caractere de nova linha (\ n):

!<arch>\n

 

Cabeçalhos de membros do arquivo

Cada membro (vinculador, nomes longos ou membro do arquivo de objeto) é precedido por um cabeçalho. Um cabeçalho de membro do arquivo tem o seguinte formato, no qual cada campo é uma sequência de texto ASCII que é justificada à esquerda e preenchida com espaços até o final do campo. Não há caractere nulo final em nenhum desses campos.

Cada cabeçalho de membro inicia no primeiro endereço par após o término do membro de arquivamento anterior.

TABELA 69

Offset

Size

Field

Description

0

16

Name

The name of the 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 in the following table.

16

12

Date

The date and time that the archive member was created: This is the ASCII decimal representation of the number of seconds since 1/1/1970 UCT.

28

6

User ID

An ASCII decimal representation of the user ID. This field does not contain a meaningful value on Windows platforms because Microsoft tools emit all blanks.

34

6

Group ID

An ASCII decimal representation of the group ID. This field does not contain a meaningful value on Windows platforms because Microsoft tools emit all blanks.

40

8

Mode

An ASCII octal representation of the member’s file mode. This is the ST_MODE value from the C run-time function _wstat.

48

10

Size

An ASCII decimal representation of the total size of the archive member, not including the size of the header.

58

2

End of Header

The two bytes in the C string “˜\n” (0x60 0x0A).

 

O campo Nome possui um dos formatos mostrados na tabela a seguir. Como mencionado anteriormente, cada uma dessas sequências é justificada e preenchida com espaços à direita em um campo de 16 bytes:

TABELA 70

Contents of Name field

Description

name/

The name of the archive member.

/

The archive member is one of the two linker members. Both of the linker members have this name.

//

The archive member is the longnames 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.

/n

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 the longnames member contents.

 

Primeiro membro vinculador

O nome do primeiro membro do vinculador é “\”. O primeiro membro do vinculador está incluído para compatibilidade com versões anteriores. Não é usado pelos vinculadores atuais, mas seu formato deve estar correto. Esse membro do vinculador fornece um diretório de nomes de símbolos, assim como o segundo membro do vinculador. Para cada símbolo, as informações indicam onde encontrar o membro do arquivo que contém o símbolo.

O primeiro membro do vinculador tem o seguinte formato. Esta informação aparece após o cabeçalho:

TABELA 71

Offset

Size

Field

Description

0

4

Number of Symbols

Unsigned long that contains the number of indexed symbols. This number is stored in big-endian format. Each object-file member typically defines one or more external symbols.

4

4 * n

Offsets

An array of file offsets to archive member headers, in which n is equal to the Number of Symbols field. Each number in the array is an unsigned long stored in big-endian format. For each symbol that is named in the string table, the corresponding element in the offsets array gives the location of the archive member that contains the symbol.

*

*

String Table

A 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 field.

 

Os elementos na matriz de deslocamentos devem ser organizados em ordem crescente. Esse fato implica que os símbolos na tabela de cadeias devem ser organizados de acordo com a ordem dos membros do arquivo. Por exemplo, todos os símbolos no primeiro membro do arquivo de objeto precisariam ser listados antes dos símbolos no segundo arquivo de objeto.

 

Segundo membro vinculador

O segundo membro do vinculador tem o nome “\”, assim como o primeiro membro do vinculador. Embora ambos os membros do vinculador forneçam um diretório de símbolos e membros de arquivamento que os contenham, o segundo membro do vinculador é usado preferencialmente ao primeiro por todos os vinculadores atuais. O segundo membro do vinculador inclui nomes de símbolos em ordem lexical, o que permite uma pesquisa mais rápida por nome.

O segundo membro tem o seguinte formato. Esta informação aparece após o cabeçalho:

TABELA 72

Offset

Size

Field

Description

0

4

Number of Members

An unsigned long that contains the number of archive members.

4

4 * m

Offsets

An 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.

*

4

Number of Symbols

An unsigned long that contains the number of symbols indexed. Each object-file member typically defines one or more external symbols.

*

2 * n

Indices

An array of 1-based indexes (unsigned short ) that map symbol names to archive member offsets. The number n is equal to the Number of Symbols field. For each symbol that is 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.

*

*

String Table

A series of null-terminated strings that name all of 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 field. This table lists all the symbol names in ascending lexical order.

 

Longnames Membro

O nome do membro de nomes longos é “\\”. O membro longnames é uma série de cadeias de nomes de membros do arquivo morto. Um nome aparece aqui apenas quando não há espaço suficiente no campo Nome (16 bytes). O membro de nomes longos pode estar vazio, embora o cabeçalho deva aparecer.

As cadeias são terminadas em nulo. Cada sequência começa imediatamente após o byte nulo na sequência anterior.

 

Importar formato da biblioteca

As bibliotecas de importação tradicionais, isto é, as bibliotecas que descrevem as exportações de uma imagem para serem usadas por outra, geralmente seguem o layout descrito na seção 7, Formato de arquivo archive (biblioteca). A principal diferença é que os membros da biblioteca de importação contêm arquivos de pseudo-objeto em vez de reais, nos quais cada membro inclui as contribuições de seção necessárias para criar as tabelas de importação descritas na seção 6.4, A seção .idata O vinculador gera esse archive ao criar o aplicativo de exportação.

As contribuições da seção para uma importação podem ser deduzidas a partir de um pequeno conjunto de informações. O vinculador pode gerar as informações completas e detalhadas na biblioteca de importação para cada membro no momento da criação da biblioteca ou gravar apenas as informações canônicas na biblioteca e permitir que o aplicativo que mais tarde as utilize gere os dados necessários em tempo real.

Em uma biblioteca de importação com o formato longo, um único membro contém as seguintes informações:

Cabeçalho do membro do arquivo morto Cabeçalho do arquivo Cabeçalhos da seção Dados que correspondem a cada um dos cabeçalhos da seção Tabela de símbolos COFF Sequências de caracteres

Por outro lado, uma pequena biblioteca de importação é escrita da seguinte maneira:

Cabeçalho do membro do arquivo morto Cabeçalho de importação Cadeia de caracteres de nome de importação com terminação nula Cadeia de nomes de DLL com terminação nula

São informações suficientes para reconstruir com precisão todo o conteúdo do membro no momento de seu uso.

 

Importar cabeçalho

O cabeçalho de importação contém os seguintes campos e compensações:

TABELA 73

Offset

Size

Field

Description

0

2

Sig1

Must be IMAGE_FILE_MACHINE_UNKNOWN. For more information, see Machine Types.

2

2

Sig2

Must be 0xFFFF.

4

2

Version

The structure version.

6

2

Machine

The number that identifies the type of target machine. For more information, see Machine Types.

8

4

Time-Date Stamp

The time and date that the file was created.

12

4

Size Of Data

The size of the strings that follow the header.

16

2

Ordinal/Hint

Either the ordinal or the hint for the import, determined by the value in the Name Type field.

18

2 bits

Type

The import type. For specific values and descriptions, see Import Type.

3 bits

Name Type

The import name type. For more information, see Import Name Type.

11 bits

Reserved

Reserved, must be 0.

 

Essa estrutura é seguida por duas sequências terminadas em nulo que descrevem o nome do símbolo importado e a DLL da qual ele veio.

 

Tipo de Importação

Os seguintes valores são definidos para o campo Tipo no cabeçalho de importação:

TABELA 74

Constant

Value

Description

IMPORT_CODE

0

Executable code.

IMPORT_DATA

1

Data.

IMPORT_CONST

2

Specified as CONST in the .def file.

Esses valores são usados para determinar quais contribuições da seção devem ser geradas pela ferramenta que usa a biblioteca se ela deve acessar esses dados.

 

Tipo de nome de importação

O nome do símbolo de importação com terminação nula segue imediatamente seu cabeçalho de importação associado. Os seguintes valores são definidos para o campo Tipo de nome no cabeçalho de importação. Eles indicam como o nome deve ser usado para gerar os símbolos corretos que representam a importação:

TABELA 75

Constant

Value

Description

IMPORT_ORDINAL

0

The import is by ordinal. This indicates that the value in the Ordinal/Hint field of the import header is the import’s ordinal. If this constant is not specified, then the Ordinal/Hint field should always be interpreted as the import’s hint.

IMPORT_NAME

1

The import name is identical to the public symbol name.

IMPORT_NAME_NOPREFIX

2

The import name is the public symbol name, but skipping the leading ?, @, or optionally _.

IMPORT_NAME_UNDECORATE

3

The import name is the public symbol name, but skipping the leading ?, @, or optionally _, and truncating at the first @.

 

Apêndice A: Calculando o hash de imagem do Authenticode PE

Espera-se que vários certificados de atributo sejam usados para verificar a integridade das imagens. No entanto, o mais comum é a assinatura Authenticode. Uma assinatura Authenticode pode ser usada para verificar se as seções relevantes de um arquivo de imagem PE não foram alteradas de forma alguma a partir da forma original do arquivo. Para realizar essa tarefa, as assinaturas Authenticode contêm algo chamado hash de imagem PE

 

A.1 O que é um hash de imagem do Authenticode PE?

O hash de imagem do Authenticode PE, ou abreviado de arquivo, é semelhante a uma soma de verificação de arquivos, pois produz um pequeno valor relacionado à integridade de um arquivo. Uma soma de verificação é produzida por um algoritmo simples e é usada principalmente para detectar falhas de memória. Ou seja, é usado para detectar se um bloco de memória no disco está com defeito e os valores armazenados no local foram corrompidos. Um hash de arquivo é semelhante a uma soma de verificação, pois também detecta a corrupção do arquivo. No entanto, diferentemente da maioria dos algoritmos de soma de verificação, é muito difícil modificar um arquivo para que ele tenha o mesmo hash de arquivo que sua forma original (não modificada). Ou seja, uma soma de verificação tem como objetivo detectar falhas simples de memória que levam à corrupção, mas um hash de arquivo pode ser usado para detectar modificações intencionais e até sutis em um arquivo, como as introduzidas por vírus, hackers,

Em uma assinatura Authenticode, o hash do arquivo é assinado digitalmente usando uma chave privada conhecida apenas pelo assinante do arquivo. Um consumidor de software pode verificar a integridade do arquivo calculando o valor do hash do arquivo e comparando-o com o valor do hash assinado contido na assinatura digital Authenticode. Se os hashes do arquivo não corresponderem, parte do arquivo coberto pelo hash da imagem PE foi modificado.

 

A.2 O que é coberto em um hash de imagem PE Authenticode?

Não é possível ou desejável incluir todos os dados do arquivo de imagem no cálculo do hash da imagem do PE. Às vezes, simplesmente apresenta características indesejáveis (por exemplo, informações de depuração não podem ser removidas de arquivos divulgados publicamente); às vezes é simplesmente impossível. Por exemplo, não é possível incluir todas as informações em um arquivo de imagem em uma assinatura Authenticode, depois inserir a assinatura Authenticode que contém esse hash da imagem PE na imagem PE e, posteriormente, conseguir gerar um hash de imagem PE idêntico, incluindo todos os dados do arquivo de imagem no cálculo novamente, porque o arquivo agora contém a assinatura Authenticode que não estava originalmente lá.

Este apêndice ilustra como um hash de imagem PE é calculado e quais partes da imagem PE podem ser modificadas sem invalidar a assinatura Authenticode.

Vale ressaltar que o hash da imagem PE para um arquivo específico pode ser incluído em um arquivo de catálogo separado sem incluir um certificado de atributo no arquivo hash. Isso é relevante, porque torna-se possível invalidar o hash da imagem PE em um arquivo de catálogo assinado pelo Authenticode, modificando uma imagem PE que realmente não contém uma assinatura Authenticode.

 

Processo para gerar o hash de imagem Authenticode PE

Todos os dados nas seções da imagem do PE especificados na tabela de seções são totalmente divididos em hash, exceto pelos seguintes intervalos de exclusão:

  • O campo CheckSum do arquivo dos campos específicos do Windows do cabeçalho opcional. Essa soma de verificação inclui o arquivo inteiro (incluindo quaisquer certificados de atributo no arquivo). Com toda a probabilidade, a soma de verificação será diferente do valor original após a inserção da assinatura Authenticode.
  • Informações relacionadas aos certificados de atributo. As áreas da imagem do PE relacionadas à assinatura do Authenticode não são incluídas no cálculo do hash da imagem do PE, porque as assinaturas do Authenticode podem ser adicionadas ou removidas de uma imagem sem afetar a integridade geral da imagem. Isso não é um problema, porque há cenários de usuário que dependem da nova assinatura de imagens do PE ou da adição de um carimbo de data / hora. O Authenticode exclui as seguintes informações do cálculo de hash:
  • O campo Tabela de Certificados dos diretórios de dados do cabeçalho opcionais.
  • A tabela de certificados e os certificados correspondentes apontados pelo campo Tabela de certificados listados imediatamente acima.

 

Para calcular o hash da imagem PE, o Authenticode ordena as seções especificadas na tabela de seções por intervalo de endereços e, em seguida, faz hash na sequência de bytes resultante, passando pelos intervalos de exclusão.

 

  • Informações passadas do final da última seção. A área após a última seção (definida pelo deslocamento mais alto) não é dividida em hash. Esta área geralmente contém informações de depuração. As informações de depuração geralmente podem ser consideradas consultivas para os depuradores; isso não afeta a integridade real do programa executável. É literalmente possível remover informações de depuração de uma imagem após a entrega do produto e não afetar a funcionalidade do programa. De fato, isso às vezes é feito como uma medida de economia de disco. Vale ressaltar que as informações de depuração contidas nas seções especificadas da Imagem PE não podem ser removidas sem invalidar a assinatura Authenticode.

 

Você pode usar as ferramentas makecert e signtool fornecidas no Windows Platform SDK para experimentar a criação e verificação de assinaturas Authenticode. Para mais informações, consulte Referência, abaixo.

 

Referências

Downloads e ferramentas para Windows (inclui o Windows SDK)

Criando, visualizando e gerenciando certificados

Passo a passo de assinatura de código no modo kernel (.doc)

SignTool

Formato de assinatura executável portátil do Windows Authenticode (.docx)

Funções do ImageHlp

 

Aprenda mais no curso CFID

Gostou do artigo? Conheça o curso Computação Forense e Investigação Digital.

Este curso tem como objetivo apresentar os conceitos da Computação Forense e métodos de Investigação Digital, sendo baseado no conteúdo apresentado nas certificações mais conhecidas do mercado.

Hospedagem de site

digitalocean, excelente custo benefício.

Clique abaixo e aproveite!