通过分析可执行文件及动态链接库的pe及ne格式可以解决：1.NE formatINF: Executable-File Header Format [P_WinSDK]3.00
WINDOWS
PSSONLY | Windows 3 Developers Notes softlib ENDUSERSummary:Note: This article is part of a set of seven articles, collectively
called the "Windows 3.00 Developer's Notes." More information about
the contents of the other articles, and procedures for ordering a
hard-copy set, can be found in the knowledge base article titled "INF:
The Windows 3.00 Developer's Notes" (Q65260).This article can be found in the Software/Data Library by searching on
the word EXEFMT or S12688. EXEFMT was archived using the PKware
file-compression utility.More Information:Microsoft defined the segmented executable file format for Windows
applications and dynamic-link libraries (DLLs). This file format is
also referred to as the New Executable Format. This new format is an
extension of the existing MS-DOS .EXE format (old-style format). The
purpose of the segmented executable format is to provide the
information needed to support the dynamic linking and segmentation
capabilities of the Windows environment.An executable file contains Microsoft Windows code and data, or
Windows code, data, and resources. Specific fields have been added to
the old-style .EXE format header to indicate the existence of the
segmented file format. The old-style header may contain a valid
executable program, called a stub program, that will be executed if
the program is run on MS-DOS (without Windows). This stub program
usually prints a message indicating that Microsoft Windows is required
to run the program. The segmented executable format extensions also
begin with a header that describes the contents and location of the
executable image in the file. The loader uses this header information
when it loads the executable segments in memory.
======================================================================
OLD-STYLE HEADER EXTENSIONS
======================================================================The old-style header contains information the loader expects for a DOS
executable file. It describes a stub program (WINSTUB) the loader can
place in memory when necessary, it points to the new-style header, and
it contains the stub programs relocation table.The following illustrates the distinct parts of the old-style
executable format: +-------------------------+
00h | Old-style header info |
+-------------------------+
20h | Reserved |
+-------------------------+
3Ch | Offset to segmented |
| .EXE header |
+-------------------------+
40h | Relocation table and |
| DOS stub program |
+-------------------------+
| Segmented .EXE Header |
| . |
| . |
| . |The word at offset 18h in the old-style .EXE header contains the
relative byte offset to the stub program's relocation table. If this
offset is 40h, then the double word at offset 3Ch is assumed to be the
relative byte offset from the beginning of the file to the beginning
of the segmented executable header. A new-format .EXE file is
identified if the segmented executable header contains a valid
signature. If the signature is not valid, the file is assumed to be an
old-style format .EXE file. The remainder of the old-style format
header will describe a DOS program, the stub. The stub may be any
valid program but will typically be a program that displays an error
message.======================================================================
SEGMENTED EXE FORMAT
======================================================================Because Windows executable files are often larger than one segment
(64K), additional information (that does not appear in the old-style
header) is required so that the loader can load each segment properly.
The segmented EXE format was developed to provide the loader with this
information.The segmented .EXE file has the following format: +-----------------+
00h | Old-style EXE |
| Header |
+-----------------+
20h | Reserved |
+-----------------+
3Ch | Offset to | ---+
| Segmented Header| |
+-----------------+ |
40h | Relocation Table| |
| & Stub Program | |
+-----------------+ |
| | |
+-----------------+ |
xxh | Segmented EXE | <--+
| Header |
+-----------------+
| Segment Table |
+-----------------+
| Resource Table |
+-----------------+
| Resident Name |
| Table |
+-----------------+
| Module Reference|
| Table |
+-----------------+
| Imported Names |
| Table |
+-----------------+
| Entry Table |
+-----------------+
| Non-Resident |
| Name Table |
+-----------------+
| Seg #1 Data |
| Seg #1 Info |
+-----------------+
.
.
.
+-----------------+
| Seg #n Data |
| Seg #n Info |
+-----------------+
The following sections describe each of the components that make up
the segmented EXE format. Each section contains a description of the
component and the fields in the structures that make up that
component.Note: All unused fields and flag bits are reserved for future use and
must contain 0 (zero) values.======================================================================
SEGMENTED EXE HEADER
======================================================================The segmented EXE header contains general information about the EXE
file and contains information on the location and size of the other
sections. The Windows loader copies this section, along with other
data, into the module table in the system data. The module table is
internal data used by the loader to manage the loaded executable
modules in the system and to support dynamic linking.The following describes the format of the segmented executable header.
For each field, the offset is given relative to the beginning of the
segmented header, the size of the field is defined, and a description
is given. Offset Size Description
------ ---- ----------- 00h DW Signature word.
"N" is low-order byte.
"E" is high-order byte. 02h DB Version number of the linker. 03h DB Revision number of the linker. 04h DW Entry Table file offset, relative to the beginning of
the segmented EXE header.
06h DW Number of bytes in the entry table. 08h DD 32-bit CRC of entire contents of file.
These words are taken as 00 during the calculation. 0Ch DW Flag word.
0000h = NOAUTODATA
0001h = SINGLEDATA (Shared automatic data segment)
0002h = MULTIPLEDATA (Instanced automatic data
segment)
2000h = Errors detected at link time, module will not
load.
8000h = Library module.
The SS:SP information is invalid, CS:IP points
to an initialization procedure that is called
with AX equal to the module handle. This
initialization procedure must perform a far
return to the caller, with AX not equal to
zero to indicate success, or AX equal to zero
to indicate failure to initialize. DS is set
to the library's data segment if the
SINGLEDATA flag is set. Otherwise, DS is set
to the caller's data segment. A program or DLL can only contain dynamic
links to executable files that have this
library module flag set. One program cannot
dynamic-link to another program. 0Eh DW Segment number of automatic data segment.
This value is set to zero if SINGLEDATA and
MULTIPLEDATA flag bits are clear, NOAUTODATA is
indicated in the flags word. A Segment number is an index into the module's segment
table. The first entry in the segment table is segment
number 1. 10h DW Initial size, in bytes, of dynamic heap added to the
data segment. This value is zero if no initial local
heap is allocated. 12h DW Initial size, in bytes, of stack added to the data
segment. This value is zero to indicate no initial
stack allocation, or when SS is not equal to DS. 14h DD Segment number:offset of CS:IP. 18h DD Segment number:offset of SS:SP.
If SS equals the automatic data segment and SP equals
zero, the stack pointer is set to the top of the
automatic data segment just below the additional heap
area. +--------------------------+
| additional dynamic heap |
+--------------------------+ <- SP
| additional stack |
+--------------------------+
| loaded auto data segment |
+--------------------------+ <- DS, SS 1Ch DW Number of entries in the Segment Table. 1Eh DW Number of entries in the Module Reference Table.
20h DW Number of bytes in the Non-Resident Name Table. 22h DW Segment Table file offset, relative to the beginning
of the segmented EXE header. 24h DW Resource Table file offset, relative to the beginning
of the segmented EXE header. 26h DW Resident Name Table file offset, relative to the
beginning of the segmented EXE header. 28h DW Module Reference Table file offset, relative to the
beginning of the segmented EXE header. 2Ah DW Imported Names Table file offset, relative to the
beginning of the segmented EXE header. 2Ch DD Non-Resident Name Table offset, relative to the
beginning of the file. 30h DW Number of movable entries in the Entry Table. 32h DW Logical sector alignment shift count, log(base 2) of
the segment sector size (default 9). 34h DW Number of resource entries. 36h DB Executable type, used by loader.
02h = WINDOWS 37h-3Fh DB Reserved, currently 0's.
======================================================================
SEGMENT TABLE
======================================================================The segment table contains an entry for each segment in the executable
file. The number of segment table entries are defined in the segmented
EXE header. The first entry in the segment table is segment number 1.
The following is the structure of a segment table entry. Size Description
---- ----------- DW Logical-sector offset (n byte) to the contents of the segment
data, relative to the beginning of the file. Zero means no
file data. DW Length of the segment in the file, in bytes. Zero means 64K. DW Flag word.
0007h = TYPE_MASK Segment-type field.
0000h = CODE Code-segment type.
0001h = DATA Data-segment type.
0010h = MOVEABLE Segment is not fixed.
0040h = PRELOAD Segment will be preloaded; read-only if
this is a data segment.
0100h = RELOCINFO Set if segment has relocation records.
F000h = DISCARD Discard priority. DW Minimum allocation size of the segment, in bytes. Total size
of the segment. Zero means 64K.
======================================================================
RESOURCE TABLE
======================================================================The resource table follows the segment table and contains entries for
each resource in the executable file. The resource table consists of
an alignment shift count, followed by a table of resource records. The
resource records define the type ID for a set of resources. Each
resource record contains a table of resource entries of the defined
type. The resource entry defines the resource ID or name ID for the
resource. It also defines the location and size of the resource. The
following describes the contents of each of these structures: Size Description
---- ----------- DW Alignment shift count for resource data. A table of resource type information blocks follows. The following
is the format of each type information block: DW Type ID. This is an integer type if the high-order bit is
set (8000h); otherwise, it is an offset to the type string,
the offset is relative to the beginning of the resource
table. A zero type ID s the end of the resource type
information blocks. DW Number of resources for this type. DD Reserved. A table of resources for this type follows. The following is
the format of each resource (8 bytes each): DW File offset to the contents of the resource data,
relative to beginning of file. The offset is in terms
of the alignment shift count value specified at
beginning of the resource table. DW Length of the resource in the file (in bytes). DW Flag word.
0010h = MOVEABLE Resource is not fixed.
0020h = PURE Resource can be shared.
0040h = PRELOAD Resource is preloaded. DW Resource ID. This is an integer type if the high-order
bit is set (8000h), otherwise it is the offset to the
resource string, the offset is relative to the
beginning of the resource table. DD Reserved. Resource type and name strings are stored at the end of the
resource table. Note that these strings are NOT null terminated and
are case sensitive. DB Length of the type or name string that follows. A zero value
indicates the end of the resource type and name string, also
the end of the resource table. DB ASCII text of the type or name string.
======================================================================
RESIDENT-NAME TABLE
======================================================================The resident-name table follows the resource table, and contains this
module's name string and resident exported procedure name strings. The
first string in this table is this module's name. These name strings
are case-sensitive and are not null-terminated. The following
describes the format of the name strings: Size Description
---- ----------- DB Length of the name string that follows. A zero value indicates
the end of the name table. DB ASCII text of the name string. DW Ordinal number (index into entry table). This value is ignored
for the module name.
======================================================================
MODULE-REFERENCE TABLE
======================================================================The module-reference table follows the resident-name table. Each entry
contains an offset for the module-name string within the imported-
names table; each entry is 2 bytes long. Size Description
---- ----------- DW Offset within Imported Names Table to referenced module name
string.
======================================================================
IMPORTED-NAME TABLE
======================================================================The imported-name table follows the module-reference table. This table
contains the names of modules and procedures that are imported by the
executable file. Each entry is composed of a 1-byte field that
contains the length of the string, followed by any number of
characters. The strings are not null-terminated and are case
sensitive. Size Description
---- ----------- DB Length of the name string that follows. DB ASCII text of the name string.
======================================================================
ENTRY TABLE
======================================================================The entry table follows the imported-name table. This table contains
bundles of entry-point definitions. Bundling is done to save space in
the entry table. The entry table is accessed by an ordinal value.
Ordinal number one is defined to index the first entry in the entry
table. To find an entry point, the bundles are scanned searching for a
specific entry point using an ordinal number. The ordinal number is
adjusted as each bundle is checked. When the bundle that contains the
entry point is found, the ordinal number is multiplied by the size of
the bundle's entries to index the proper entry.The linker forms bundles in the most dense manner it can, under the
restriction that it cannot reorder entry points to improve bundling.
The reason for this restriction is that other .EXE files may refer to
entry points within this bundle by their ordinal number. The following
describes the format of the entry table bundles. Size Description
---- ----------- DB Number of entries in this bundle. All records in one bundle
are either moveable or refer to the same fixed segment. A zero
value in this field indicates the end of the entry table. DB Segment indicator for this bundle. This defines the type of
entry table entry data within the bundle. There are three
types of entries that are defined. 000h = Unused entries. There is no entry data in an unused
bundle. The next bundle follows this field. This is
used by the linker to skip ordinal numbers. 001h-0FEh = Segment number for fixed segment entries. A fixed
segment entry is 3 bytes long and has the following
format. DB Flag word.
01h = Set if the entry is exported.
02h = Set if the entry uses a global (shared) data
segments.
The first assembly-language instruction in the
entry point prologue must be "MOV AX,data
segment number". This may be set only for
SINGLEDATA library modules. DW Offset within segment to entry point. 0FFH = Moveable segment entries. The entry data contains the
segment number for the entry points. A moveable segment
entry is 6 bytes long and has the following format. DB Flag word.
01h = Set if the entry is exported.
02h = Set if the entry uses a global (shared) data
segments. INT 3FH. DB Segment number. DW Offset within segment to entry point.
======================================================================
NONRESIDENT-NAME TABLE
======================================================================The nonresident-name table follows the entry table, and contains a
module description and nonresident exported procedure name strings.
The first string in this table is a module description. These name
strings are case-sensitive and are not null-terminated. The name
strings follow the same format as those defined in the resident name
table.
======================================================================
PER SEGMENT DATA
======================================================================The location and size of the per-segment data is defined in the
segment table entry for the segment. If the segment has relocation
fixups, as defined in the segment table entry flags, they directly
follow the segment data in the file. The relocation fixup information
is defined as follows:
Size Description
---- ----------- DW Number of relocation records that follow. A table of relocation records follows. The following is the format
of each relocation record. DB Source type.
0Fh = SOURCE_MASK
00h = LOBYTE
02h = SEGMENT
03h = FAR_ADDR (32-bit pointer)
05h = OFFSET (16-bit offset) DB Flags byte.
03h = TARGET_MASK
00h = INTERNALREF
01h = IMPORTORDINAL
02h = IMPORTNAME
03h = OSFIXUP
04h = ADDITIVE DW Offset within this segment of the source chain.
If the ADDITIVE flag is set, then target value is added to
the source contents, instead of replacing the source and
following the chain. The source chain is an 0FFFFh
terminated linked list within this segment of all
references to the target. The target value has four types that are defined in the flag
byte field. The following are the formats for each target
type: INTERNALREF DB Segment number for a fixed segment, or 0FFh for a
movable segment. DB 0 DW Offset into segment if fixed segment, or ordinal
number index into Entry Table if movable segment. IMPORTNAME DW Index into module reference table for the imported
module. DW Offset within Imported Names Table to procedure name
string. IMPORTORDINAL DW Index into module reference table for the imported
module.
DW Procedure ordinal number. OSFIXUP DW Operating system fixup type.
Floating-point fixups.
0001h = FIARQQ, FJARQQ
0002h = FISRQQ, FJSRQQ
0003h = FICRQQ, FJCRQQ
0004h = FIERQQ
0005h = FIDRQQ
0006h = FIWRQQ DW 0======================================================================Microsoft is a registered trade and Windows is a trade of
Microsoft Corporation.Additional reference words: 3.02 PE format
PORTABLE EXECUTABLE FORMAT Author: Micheal J. O'Leary
Preface
This document was edited and released by Microsoft Developer
Support. It describes the binary portable executable format for NT.
The information is provided at this point because we feel it will
make the work of application development easier. Unfortunately, the
information in this document may change before the final release of
Windows NT. Microsoft is NOT committing to stay with these formats
by releasing this document. Questions or follow-ups for any of the
information presented here should be posted to CompuServe MSWIN32
forum, section 6.
--Steve Firebaugh
Microsoft Developer Support
Contents 1. Overview 2. PE Header 3. Object Table 4. Image Pages 5. Exports
5.1 Export Directory Table
5.2 Export Address Table
5.3 Export Name Table Pointers
5.4 Export Ordinal Table
5.5 Export Name Table 6. Imports
6.1 Import Directory Table
6.2 Import Lookup Table
6.3 Hint-Name Table
6.4 Import Address Table 7. Thread Local Storage
7.1 Thread Local Storage Directory Table
7.2 Thread Local Storage CallBack Table 8. Resources
8.1 Resource Directory Table
8.2 Resource Example 9. Fixup Table
9.1 Fixup Block 10. Debug Information
10.1 Debug Directory1. Overview 谀哪哪哪哪哪哪哪哪目 <哪? <哪哪? Base of Image Header
? DOS 2 Compatible ? ?
? EXE Header ? ?
媚哪哪哪哪哪哪哪哪拇 ?
? unused ? ?
媚哪哪哪哪哪哪哪哪拇 ?
? OEM Identifier ? ?
? OEM Info ? ?
? ? ? DOS 2.0 Section
? Offset to ? ? (for DOS compatibility only)
? PE Header ? ?
媚哪哪哪哪哪哪哪哪拇 ?
? DOS 2.0 Stub ? ?
? Program & ? ?
? Reloc. Table ? ?
媚哪哪哪哪哪哪哪哪拇 <哪?
? unused ?
媚哪哪哪哪哪哪哪哪拇 <哪哪哪哪? Aligned on 8 byte boundary
? PE Header ?
媚哪哪哪哪哪哪哪哪拇
? Object Table ?
媚哪哪哪哪哪哪哪哪拇
? Image Pages ?
? import info ?
? export info ?
? fixup info ?
? resource info?
? debug info ?
滥哪哪哪哪哪哪哪哪馁
Figure 1. A typical 32-bit Portable EXE File Layout2. PE Header
谀哪哪哪哪哪哪哪哪哪哪哪哪哪履哪哪哪哪哪哪履哪哪哪哪哪哪?
? SIGNATURE BYTES ? CPU TYPE ? # OBJECTS ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪聊哪哪哪哪哪哪?
? TIME/DATE STAMP ? RESERVED ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪履哪哪哪哪哪哪?
? RESERVED ? NT HDR SIZE? FLAGS ?
媚哪哪哪哪哪哪履哪哪穆哪哪哪拍哪哪哪哪哪哪聊哪哪哪哪哪哪?
? RESERVED 矻MAJOR矻MINOR? RESERVED ?
媚哪哪哪哪哪哪聊哪哪牧哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? RESERVED ? RESERVED ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? ENTRYPOINT RVA ? RESERVED ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? RESERVED ? IMAGE BASE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? OBJECT ALIGN ? FILE ALIGN ?
媚哪哪哪哪哪哪履哪哪哪哪哪哪拍哪哪哪哪哪哪履哪哪哪哪哪哪?
? OS MAJOR ? OS MINOR 砋SER MAJOR 砋SER MINOR ?
媚哪哪哪哪哪哪拍哪哪哪哪哪哪拍哪哪哪哪哪哪聊哪哪哪哪哪哪?
? SUBSYS MAJOR? SUBSYS MINOR? RESERVED ?
媚哪哪哪哪哪哪聊哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? IMAGE SIZE ? HEADER SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪履哪哪哪哪哪哪?
? FILE CHECKSUM ? SUBSYSTEM ? DLL FLAGS ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪聊哪哪哪哪哪哪?
? STACK RESERVE SIZE ? STACK COMMIT SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? HEAP RESERVE SIZE ? HEAP COMMIT SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? RESERVED ? # INTERESTING RVA/SIZES ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? EXPORT TABLE RVA ? TOTAL EXPORT DATA SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? IMPORT TABLE RVA ? TOTAL IMPORT DATA SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? RESOURCE TABLE RVA ? TOTAL RESOURCE DATA SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? EXCEPTION TABLE RVA ? TOTAL EXCEPTION DATA SIZE?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? SECURITY TABLE RVA ? TOTAL SECURITY DATA SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? FIXUP TABLE RVA ? TOTAL FIXUP DATA SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? DEBUG TABLE RVA ? TOTAL DEBUG DIRECTORIES ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? IMAGE DESCRIPTION RVA ? TOTAL DESCRIPTION SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? MACHINE SPECIFIC RVA ? MACHINE SPECIFIC SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? THREAD LOCAL STORAGE RVA ? TOTAL TLS SIZE ?
滥哪哪哪哪哪哪哪哪哪哪哪哪哪聊哪哪哪哪哪哪哪哪哪哪哪哪哪?
Figure 2. PE HeaderNotes: o A VA is a virtual address that is already biased by the Image
Base found in the PE Header. A RVA is a virtual address that is
relative to the Image Base.
o An RVA in the PE Header which has a value of zero indicates the
field isn't used.
o Image pages are aligned and zero padded to a File Align
boundary. The bases of all other tables and structures must be
aligned on DWORD (4 byte) boundary. Thus, all VA's and RVA's
must be on a 32 bit boundary. All table and structure fields
must be aligned on their "natural" boundaries, with the possible
exception of the Debug Info.
SIGNATURE BYTES = DB * 4.
Current value is "PE/0/0". Thats PE followed by two zeros (nulls).CPU TYPE = DW CPU Type.
This field specifies the type of CPU compatibility required by this
image to run. The values are: o 0000h __unknown
o 014Ch __80386
o 014Dh __80486
o 014Eh __80586
o 0162h __MIPS Mark I (R2000, R3000)
o 0163h __MIPS Mark II (R6000)
o 0166h __MIPS Mark III (R4000)
# OBJECTS = DW Number of object entries.
This field specifies the number of entries in the Object Table.TIME/DATE STAMP = DD Used to store the time and date the file was
created or modified by the linker.NT HDR SIZE = DW This is the number of remaining bytes in the NT
header that follow the FLAGS field.FLAGS = DW Flag bits for the image.
The flag bits have the following definitons: o 0000h __Program image.
o 0002h __Image is executable.
If this bit isn't set, then it indicates that either errors
where detected at link time or that the image is being
incrementally linked and therefore can't be loaded.
o 0200h __Fixed.
Indicates that if the image can't be loaded at the Image Base,
then don't load it.
o 2000h __Library image.
LMAJOR/LMINOR = DB Linker major/minor version number.ENTRYPOINT RVA = DD Entrypoint relative virtual address.
The address is relative to the Image Base. The address is the
starting address for program images and the library initialization
and library termination address for library images.IMAGE BASE = DD The virtual base of the image.
This will be the virtual address of the first byte of the file (Dos
Header). This must be a multiple of 64K.OBJECT ALIGN = DD The alignment of the objects. This must be a power
of 2 between 512 and 256M inclusive. The default is 64K.FILE ALIGN = DD Alignment factor used to align image pages. The
alignment factor (in bytes) used to align the base of the image pages
and to determine the granularity of per-object trailing zero pad.
Larger alignment factors will cost more file space; smaller alignment
factors will impact demand load performance, perhaps significantly.
Of the two, wasting file space is preferable. This value should be a
power of 2 between 512 and 64K inclusive.OS MAJOR/MINOR = DW OS version number required to run this image.USER MAJOR/MINOR # = DW User major/minor version number.
This is useful for differentiating between revisions of
images/dynamic linked libraries. The values are specified at link
time by the user.SUBSYS MAJOR/MINOR # = DW Subsystem major/minor version number.IMAGE SIZE = DD The virtual size (in bytes) of the image.
This includes all headers. The total image size must be a multiple
of Object Align.HEADER SIZE = DD Total header size.
The combined size of the Dos Header, PE Header and Object Table.FILE CHECKSUM = DD Checksum for entire file. Set to 0 by the linker.SUBSYSTEM = DW NT Subsystem required to run this image.
The values are: o 0000h __Unknown
o 0001h __Native
o 0002h __Windows GUI
o 0003h __Windows Character
o 0005h __OS/2 Character
o 0007h __Posix Character
DLL FLAGS = DW Indicates special loader requirements.
This flag has the following bit values: o 0001h __Per-Process Library Initialization.
o 0002h __Per-Process Library Termination.
o 0004h __Per-Thread Library Initialization.
o 0008h __Per-Thread Library Termination.
All other bits are reserved for future use and should be set to zero.STACK RESERVE SIZE = DD Stack size needed for image.
The memory is reserved, but only the STACK COMMIT SIZE is committed.
The next page of the stack is a 'guarded page'. When the application
hits the guarded page, the guarded page becomes valid, and the next
page becomes the guarded page. This continues until the RESERVE SIZE
is reached.STACK COMMIT SIZE = DD Stack commit size.HEAP RESERVE SIZE = DD Size of local heap to reserve.HEAP COMMIT SIZE = DD Amount to commit in local heap.# INTERESTING VA/SIZES = DD Indicates the size of the VA/SIZE array
that follows.EXPORT TABLE RVA = DD Relative Virtual Address of the Export Table.
This address is relative to the Image Base.IMPORT TABLE RVA = DD Relative Virtual Address of the Import Table.
This address is relative to the Image Base.RESOURCE TABLE RVA = DD Relative Virtual Address of the Resource
Table. This address is relative to the Image Base.EXCEPTION TABLE RVA = DD Relative Virtual Address of the Exception
Table. This address is relative to the Image Base.SECURITY TABLE RVA = DD Relative Virtual Address of the Security
Table. This address is relative to the Image Base.FIXUP TABLE RVA = DD Relative Virtual Address of the Fixup Table.
This address is relative to the Image Base.DEBUG TABLE RVA = DD Relative Virtual Address of the Debug Table.
This address is relative to the Image Base.IMAGE DESCRIPTION RVA = DD Relative Virtual Address of the
description string specified in the module definiton file.MACHINE SPECIFIC RVA = DD Relative Virtual Address of a machine
specific value. This address is relative to the Image Base.TOTAL EXPORT DATA SIZE = DD Total size of the export data.TOTAL IMPORT DATA SIZE = DD Total size of the import data.TOTAL RESOURCE DATA SIZE = DD Total size of the resource data.TOTAL EXCEPTION DATA SIZE = DD Total size of the exception data.TOTAL SECURITY DATA SIZE = DD Total size of the security data.TOTAL FIXUP DATA SIZE = DD Total size of the fixup data.TOTAL DEBUG DIRECTORIES = DD Total number of debug directories.TOTAL DESCRIPTION SIZE = DD Total size of the description data.MACHINE SPECIFIC SIZE = DD A machine specific value.3. Object TableThe number of entries in the Object Table is given by the # Objects
field in the PE Header. Entries in the Object Table are numbered
starting from one. The object table immediately follows the PE
Header. The code and data memory object entries are in the order
chosen by the linker. The virtual addresses for objects must be
assigned by the linker such that they are in ascending order and
adjacent, and must be a multiple of Object Align in the PE header.Each Object Table entry has the following format: 谀哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? OBJECT NAME ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪履哪哪哪哪哪哪哪哪哪哪哪哪哪?
? VIRTUAL SIZE ? RVA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? PHYSICAL SIZE ? PHYSICAL OFFSET ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? RESERVED ? RESERVED ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? RESERVED ? OBJECT FLAGS ?
滥哪哪哪哪哪哪哪哪哪哪哪哪哪聊哪哪哪哪哪哪哪哪哪哪哪哪哪?
Figure 3. Object TableOBJECT NAME = DB * 8 Object name. This is an eight-byte null-padded
ASCII string representing the object name.VIRTUAL SIZE = DD Virtual memory size. The size of the object that
will be allocated when the object is loaded. Any difference between
PHYSICAL SIZE and VIRTUAL SIZE is zero filled.RVA = DD Relative Virtual Address. The virtual address the object is
currently relocated to, relative to the Image Base. Each Object's
virtual address space consumes a multiple of Object Align (power of 2
between 512 and 256M inclusive. Default is 64K), and immediately
follows the previous Object in the virtual address space (the virtual
address space for a image must be dense).PHYSICAL SIZE = DD Physical file size of initialized data. The size
of the initialized data in the file for the object. The physical
size must be a multiple of the File Align field in the PE Header, and
must be less than or equal to the Virtual Size.PHYSICAL OFFSET = DD Physical offset for object's first page. This
offset is relative to beginning of the EXE file, and is aligned on a
multiple of the File Align field in the PE Header. The offset is
used as a seek value.OBJECT FLAGS = DD Flag bits for the object. The object flag bits
have the following definitions: o 000000020h __Code object.
o 000000040h __Initialized data object.
o 000000080h __Uninitialized data object.
o 040000000h __Object must not be cached.
o 080000000h __Object is not pageable.
o 100000000h __Object is shared.
o 200000000h __Executable object.
o 400000000h __Readable object.
o 800000000h __Writeable object.
All other bits are reserved for future use and should be set to zero.4. Image PagesThe Image Pages section contains all initialized data for all
objects. The seek offset for the first page in each object is
specified in the object table and is aligned on a File Align
boundary. The objects are ordered by the RVA. Every object begins
on a multiple of Object Align.5. ExportsA typical file layout for the export information follows: 谀哪哪哪哪哪哪哪哪哪哪哪?
? DIRECTORY TABLE ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? ADDRESS TABLE ?
? ?
? ?
? ?
? ?
? ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NAME PTR TABLE ?
? ?
? ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? ORDINAL TABLE ?
? ?
? ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NAME STRINGS ?
? ?
? ?
滥哪哪哪哪哪哪哪哪哪哪哪?
Figure 4. Export File Layout5.1 Export Directory TableThe export information begins with the Export Directory Table which
describes the remainder of the export information. The Export
Directory Table contains address information that is used to resolve
fixup references to the entry points within this image. 谀哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? EXPORT FLAGS ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? TIME/DATE STAMP ?
媚哪哪哪哪哪哪哪哪履哪哪哪哪哪哪哪哪?
? MAJOR VERSION ? MINOR VERSION ?
媚哪哪哪哪哪哪哪哪聊哪哪哪哪哪哪哪哪?
? NAME RVA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? ORDINAL BASE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? # EAT ENTRIES ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? # NAME PTRS ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? ADDRESS TABLE RVA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? NAME PTR TABLE RVA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? ORDINAL TABLE RVA ?
滥哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
Figure 5. Export Directory Table EntryEXPORT FLAGS = DD Currently set to zero.TIME/DATE STAMP = DD Time/Date the export data was created.MAJOR/MINOR VERSION = DW A user settable major/minor version number.NAME RVA = DD Relative Virtual Address of the Dll asciiz Name.
This is the address relative to the Image Base.ORDINAL BASE = DD First valid exported ordinal.
This field specifies the starting ordinal number for the export
address table for this image. Normally set to 1.# EAT ENTRIES = DD Indicates number of entries in the Export Address
Table.# NAME PTRS = DD This indicates the number of entries in the Name Ptr
Table (and parallel Ordinal Table).ADDRESS TABLE RVA = DD Relative Virtual Address of the Export Address
Table.
This address is relative to the Image Base.NAME TABLE RVA = DD Relative Virtual Address of the Export Name Table
Pointers.
This address is relative to the beginning of the Image Base. This
table is an array of RVA's with # NAMES entries.ORDINAL TABLE RVA = DD Relative Virtual Address of Export Ordinals
Table Entry.
This address is relative to the beginning of the Image Base.5.2 Export Address TableThe Export Address Table contains the address of exported entrypoints
and exported data and absolutes. An ordinal number is used to index
the Export Address Table. The ORDINAL BASE must be subracted from the
ordinal number before indexing into this table.Export Address Table entry formats are described below: 谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? EXPORTED RVA ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
Figure 6. Export Address Table EntryEXPORTED RVA = DD Export address.
This field contains the relative virtual address of the exported
entry (relative to the Image Base).5.3 Export Name Table PointersThe export name table pointers array contains address into the Export
Name Table. The pointers are 32-bits each, and are relative to the
Image Base. The pointers are ordered lexically to allow binary
searches.5.4 Export Ordinal TableThe Export Name Table Pointers and the Export Ordinal Table form two
parallel arrays, separated to allow natural field alignment. The
export ordinal table array contains the Export Address Table ordinal
numbers associated with the named export referenced by corresponding
Export Name Table Pointers.The ordinals are 16-bits each, and already include the Ordinal Base
stored in the Export Directory Table.5.5 Export Name TableThe export name table contains optional ASCII names for exported
entries in the image. These tables are used with the array of Export
Name Table Pointers and the array of Export Ordinals to translate a
procedure name string into an ordinal number by searching for a
matching name string. The ordinal number is used to locate the entry
point information in the export address table.Import references by name require the Export Name Table Pointers
table to be binary searched to find the matching name, then the
corresponding Export Ordinal Table is known to contain the entry
point ordinal number. Import references by ordinal number provide
the fastest lookup since searching the name table is not required.Each name table entry has the following format: 谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? ASCII STRING ::: :::::::: '\0' ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
Figure 7. Export Name Table EntryASCII STRING = DB ASCII String.
The string is case sensitive and is terminated by a null byte.6. ImportsA typical file layout for the import information follows: 谀哪哪哪哪哪哪哪哪哪哪哪?
? DIRECTORY TABLE ?
? ?
? ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NULL DIR ENTRY ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? DLL1 LOOKUP TABLE ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NULL ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? DLL2 LOOKUP TABLE ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NULL ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? Dll3 LOOKUP TABLE ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NULL ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? HINT-NAME TABLE ?
? ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? DLL1 ADDRESS TABLE ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NULL ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? DLL2 ADDRESS TABLE ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NULL ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? DLL3 ADDRESS TABLE ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NULL ?
滥哪哪哪哪哪哪哪哪哪哪哪?
Figure 8. Import File Layout6.1 Import Directory TableThe import information begins with the Import Directory Table which
describes the remainder of the import information. The Import
Directory Table contains address information that is used to resolve
fixup references to the entry points within a DLL image. The import
directory table consists of an array of Import Directory Entries, one
entry for each DLL this image references. The last directory entry is
empty (NULL) which indicates the end of the directory table.An Import Directory Entry has the following format: 谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? IMPORT FLAGS ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? TIME/DATE STAMP ?
媚哪哪哪哪哪哪哪哪履哪哪哪哪哪哪哪哪?
? MAJOR VERSION ? MINOR VERSION ?
媚哪哪哪哪哪哪哪哪聊哪哪哪哪哪哪哪哪?
? NAME RVA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? IMPORT LOOKUP TABLE RVA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? IMPORT ADDRESS TABLE RVA ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
Figure 9. Import Directory EntryIMPORT FLAGS = DD Currently set to zero.TIME/DATE STAMP = DD Time/Date the import data was pre-snapped or
zero if not pre-snapped.MAJOR/MINOR VERSION = DW The major/minor version number of the dll
being referenced.NAME RVA = DD Relative Virtual Address of the Dll asciiz Name.
This is the address relative to the Image Base.IMPORT LOOKUP TABLE RVA = DD This field contains the address of the
start of the import lookup table for this image. The address is
relative to the beginning of the Image Base.IMPORT ADDRESS TABLE RVA = DD This field contains the address of the
start of the import addresses for this image. The address is
relative to the beginning of the Image Base.6.2 Import Lookup TableThe Import Lookup Table is an array of ordinal or hint/name RVA's for
each DLL. The last entry is empty (NULL) which indicates the end of
the table.The last element is empty. 3 0
1
谀夷哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
?0? ORDINAL#/HINT-NAME TABLE RVA ?
滥心哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
Figure 10. Import Address Table FormatORDINAL/HINT-NAME TABLE RVA = 31-bits (mask = 7fffffffh) Ordinal
Number or Name Table RVA.
If the import is by ordinal, this field contains a 31 bit ordinal
number. If the import is by name, this field contains a 31 bit
address relative to the Image Base to the Hint-Name Table.O = 1-bit (mask = 80000000h) Import by ordinal flag. o 00000000h __Import by name.
o 80000000h __Import by ordinal.
6.3 Hint-Name TableThe Hint-Name Table format follows: 谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? HINT ? ASCII STRING |||?
媚哪哪哪呐哪哪哪哪拍哪哪哪呐哪哪哪哪?
硘||||||||||||||||? '\0' PAD ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
The PAD field is optional.
Figure 11. Import Hint-Name TableHINT = DW Hint into Export Name Table Pointers.
The hint value is used to index the Export Name Table Pointers array,
allowing faster by-name imports. If the hint is incorrect, then a
binary search is performed on the Export Name Ptr Table.ASCII STRING = DB ASCII String.
The string is case sensitive and is terminated by a null byte.PAD = DB Zero pad byte.
A trailing zero pad byte appears after the trailing null byte if
necessary to align the next entry on an even boundary.The loader overwrites the import address table when loading the image
with the 32-bit address of the import.6.4 Import Address TableThe Import Address Table is an array of addresses of the imported
routines for each DLL. The last entry is empty (NULL) which indicates
the end of the table.7. Thread Local StorageThread local storage is a special contiguous block of data. Each
thread will gets its own block upon creation of the thread.The file layout for thread local storage follows:
谀哪哪哪哪哪哪哪哪哪哪哪?
? DIRECTORY TABLE ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? TLS DATA ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? INDEX VARIABLE ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? CALLBACK ADDRESSES ?
滥哪哪哪哪哪哪哪哪哪哪哪?Figure 12. Thread Local Storage Layout7.1 Thread Local Storage Directory TableThe Thread Local Storage Directory Table contains address information
that is used to describe the rest of TLS.The Thread Local Storage Directory Table has the following format: 谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? START DATA BLOCK VA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? END DATA BLOCK VA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? INDEX VA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? CALLBACK TABLE VA ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
Figure 13. Thread Local Storage Directory TableSTART DATA BLOCK VA = DD Virtual Address of the start of the thread
local storage data block.END DATA BLOCK VA = DD Virtual Address of the end of the thread local
storage data block.INDEX VA = DD Virtual Address of the index variable used to access
the thread local storage data block.CALLBACK TABLE VA = DD Virtual Address of the callback table.7.2 Thread Local Storage CallBack TableThe Thread Local Storage Callbacks is an array of Virtual Address of
functions to be called by the loader after thread creation and thread
termination. The last entry is empty (NULL) which indicates the end
of the table.The Thread Local Storage CallBack Table has the following format: 谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? FUNCTION1 VA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? FUNCTION2 VA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? NULL ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
Figure 14. Thread Local Storage CallBack Table8. ResourcesResources are indexed by a multiple level binary-sorted tree
structure. The overall design can incorporate 2**31 levels, however,
NT uses only three: the highest is TYPE, then NAME, then LANGUAGE.A typical file layout for the resource information follows:
谀哪哪哪哪哪哪哪哪哪哪哪?
? RESOURCE DIRECTORY ?
? ?
? ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? RESOURCE DATA ?
? ?
? ?
? ?
? ?
? ?
? ?
滥哪哪哪哪哪哪哪哪哪哪哪?
Figure 15. Resource File Layout
The Resource directory is made up of the following tables:8.1 Resource Directory Table
谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? RESOURCE FLAGS ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? TIME/DATE STAMP ?
媚哪哪哪哪哪哪哪哪履哪哪哪哪哪哪哪哪?
? MAJOR VERSION ? MINOR VERSION ?
媚哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪?
? # NAME ENTRY ? # ID ENTRY ?
媚哪哪哪哪哪哪哪哪聊哪哪哪哪哪哪哪哪?
? RESOURCE DIR ENTRIES ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?Figure 16. Resource Table Entry
RESOURCE FLAGS = DD Currently set to zero.TIME/DATE STAMP = DD Time/Date the resource data was created by the
resource compiler.MAJOR/MINOR VERSION = DW A user settable major/minor version number.# NAME ENTRY = DW The number of name entries.
This field contains the number of entries at the beginning of the
array of directory entries which have actual string names associated
with them.# ID ENTRY = DW The number of ID integer entries.
This field contains the number of 32-bit integer IDs as their names
in the array of directory entries.The resource directory is followed by a variable length array of
directory entries. # NAME ENTRY is the number of entries at the
beginning of the array that have actual names associated with each
entry. The entires are in ascending order, case insensitive strings.
# ID ENTRY identifies the number of entries that have 32-bit integer
IDs as their name. These entries are also sorted in ascending order.This structure allows fast lookup by either name or number, but for
any given resource entry only one form of lookup is supported, not
both. This is consistent with the syntax of the .RC file and the .RES
file.The array of directory entries have the following format:
3 0
1
谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? NAME RVA/INTEGER ID ?
媚夷哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
矱? DATA ENTRY RVA/SUBDIR RVA ?
滥心哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?Figure 17. Resource Directory Entry
INTERGER ID = DD ID.
This field contains a integer ID field to identify a resource.NAME RVA = DD Name RVA address.
This field contains a 31-bit address relative to the beginning of the
Image Base to a Resource Directory String Entry.E = 1-bit (mask 80000000h) Unescape bit.
This bit is zero for unescaped Resource Data Entries.DATA RVA = 31-bits (mask 7fffffffh) Data entry address.
This field contains a 31-bit address relative to the beginning of the
Image Base to a Resource Data Entry.E = 1-bit (mask 80000000h) Escape bit.
This bit is 1 for escaped Subdirectory Entry.DATA RVA = 31-bits (mask 7fffffffh) Directory entries.
This field contains a 31-bit address relative to the beginning of the
Image Base to Subdirectory Entry.Each resource directory string entry has the following format:
谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? LENGTH ? UNICODE STRING ?
媚哪哪哪呐哪哪哪哪拍哪哪哪呐哪哪哪哪?
? ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?Figure 18. Resource Directory String Entry
LENGTH = DW Length of string.UNICODE STRING = DW UNICODE String.All of these string objects are stored together after the last
resource directory entry and before the first resource data object.
This minimizes the impact of these variable length objects on the
alignment of the fixed size directory entry objects. The length needs
to be word aligned.Each Resource Data Entry has the following format: 谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? DATA RVA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? CODEPAGE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? RESERVED ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
Figure 19. Resource Data EntryDATA RVA = DD Address of Resource Data.
This field contains 32-bit virtaul address of the resource data
(relative to the Image Base).SIZE = DD Size of Resource Data.
This field contains the size of the resource data for this resource.CODEPAGE = DD Codepage.RESERVED = DD Reserved - must be zero.Each resource data entry describes a leaf node in the resource
directory tree. It contains an address which is relative to the
beginning of Image Base, a size field that gives the number of bytes
of data at that address, a CodePage that should be used when decoding
code point values within the resource data. Typically for new
applications the code page would be the unicode code page.8.2 Resource ExampleThe following is an example for an app. which wants to use the following data
as resources: TypeId# NameId# Language ID Resource Data
00000001 00000001 0 00010001
00000001 00000001 1 10010001
00000001 00000002 0 00010002
00000001 00000003 0 00010003
00000002 00000001 0 00020001
00000002 00000002 0 00020002
00000002 00000003 0 00020003
00000002 00000004 0 00020004
00000009 00000001 0 00090001
00000009 00000009 0 00090009
00000009 00000009 1 10090009
00000009 00000009 2 20090009Then the Resource Directory in the Portable format looks like:
Offset Data
0000: 00000000 00000000 00000000 00030000 (3 entries in this directory)
0010: 00000001 80000028 (TypeId #1, Subdirectory at offset 0x28)
0018: 00000002 80000050 (TypeId #2, Subdirectory at offset 0x50)
0020: 00000009 80000080 (TypeId #9, Subdirectory at offset 0x80)
0028: 00000000 00000000 00000000 00030000 (3 entries in this directory)
0038: 00000001 800000A0 (NameId #1, Subdirectory at offset 0xA0)
0040: 00000002 00000108 (NameId #2, data desc at offset 0x108)
0048: 00000003 00000118 (NameId #3, data desc at offset 0x118)
0050: 00000000 00000000 00000000 00040000 (4 entries in this directory)
0060: 00000001 00000128 (NameId #1, data desc at offset 0x128)
0068: 00000002 00000138 (NameId #2, data desc at offset 0x138)
0070: 00000003 00000148 (NameId #3, data desc at offset 0x148)
0078: 00000004 00000158 (NameId #4, data desc at offset 0x158)
0080: 00000000 00000000 00000000 00020000 (2 entries in this directory)
0090: 00000001 00000168 (NameId #1, data desc at offset 0x168)
0098: 00000009 800000C0 (NameId #9, Subdirectory at offset 0xC0)
00A0: 00000000 00000000 00000000 00020000 (2 entries in this directory)
00B0: 00000000 000000E8 (Language ID 0, data desc at offset 0xE8
00B8: 00000001 000000F8 (Language ID 1, data desc at offset 0xF8
00C0: 00000000 00000000 00000000 00030000 (3 entries in this directory)
00D0: 00000001 00000178 (Language ID 0, data desc at offset 0x178
00D8: 00000001 00000188 (Language ID 1, data desc at offset 0x188
00E0: 00000001 00000198 (Language ID 2, data desc at offset 0x19800E8: 000001A8 (At offset 0x1A8, for TypeId #1, NameId #1, Language id #0
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
00F8: 000001AC (At offset 0x1AC, for TypeId #1, NameId #1, Language id #1
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0108: 000001B0 (At offset 0x1B0, for TypeId #1, NameId #2,
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0118: 000001B4 (At offset 0x1B4, for TypeId #1, NameId #3,
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0128: 000001B8 (At offset 0x1B8, for TypeId #2, NameId #1,
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0138: 000001BC (At offset 0x1BC, for TypeId #2, NameId #2,
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0148: 000001C0 (At offset 0x1C0, for TypeId #2, NameId #3,
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0158: 000001C4 (At offset 0x1C4, for TypeId #2, NameId #4,
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0168: 000001C8 (At offset 0x1C8, for TypeId #9, NameId #1,
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0178: 000001CC (At offset 0x1CC, for TypeId #9, NameId #9, Language id #0
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0188: 000001D0 (At offset 0x1D0, for TypeId #9, NameId #9, Language id #1
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0198: 000001D4 (At offset 0x1D4, for TypeId #9, NameId #9, Language id #2
00000004 (4 bytes of data)
WINDOWS
PSSONLY | Windows 3 Developers Notes softlib ENDUSERSummary:Note: This article is part of a set of seven articles, collectively
called the "Windows 3.00 Developer's Notes." More information about
the contents of the other articles, and procedures for ordering a
hard-copy set, can be found in the knowledge base article titled "INF:
The Windows 3.00 Developer's Notes" (Q65260).This article can be found in the Software/Data Library by searching on
the word EXEFMT or S12688. EXEFMT was archived using the PKware
file-compression utility.More Information:Microsoft defined the segmented executable file format for Windows
applications and dynamic-link libraries (DLLs). This file format is
also referred to as the New Executable Format. This new format is an
extension of the existing MS-DOS .EXE format (old-style format). The
purpose of the segmented executable format is to provide the
information needed to support the dynamic linking and segmentation
capabilities of the Windows environment.An executable file contains Microsoft Windows code and data, or
Windows code, data, and resources. Specific fields have been added to
the old-style .EXE format header to indicate the existence of the
segmented file format. The old-style header may contain a valid
executable program, called a stub program, that will be executed if
the program is run on MS-DOS (without Windows). This stub program
usually prints a message indicating that Microsoft Windows is required
to run the program. The segmented executable format extensions also
begin with a header that describes the contents and location of the
executable image in the file. The loader uses this header information
when it loads the executable segments in memory.
======================================================================
OLD-STYLE HEADER EXTENSIONS
======================================================================The old-style header contains information the loader expects for a DOS
executable file. It describes a stub program (WINSTUB) the loader can
place in memory when necessary, it points to the new-style header, and
it contains the stub programs relocation table.The following illustrates the distinct parts of the old-style
executable format: +-------------------------+
00h | Old-style header info |
+-------------------------+
20h | Reserved |
+-------------------------+
3Ch | Offset to segmented |
| .EXE header |
+-------------------------+
40h | Relocation table and |
| DOS stub program |
+-------------------------+
| Segmented .EXE Header |
| . |
| . |
| . |The word at offset 18h in the old-style .EXE header contains the
relative byte offset to the stub program's relocation table. If this
offset is 40h, then the double word at offset 3Ch is assumed to be the
relative byte offset from the beginning of the file to the beginning
of the segmented executable header. A new-format .EXE file is
identified if the segmented executable header contains a valid
signature. If the signature is not valid, the file is assumed to be an
old-style format .EXE file. The remainder of the old-style format
header will describe a DOS program, the stub. The stub may be any
valid program but will typically be a program that displays an error
message.======================================================================
SEGMENTED EXE FORMAT
======================================================================Because Windows executable files are often larger than one segment
(64K), additional information (that does not appear in the old-style
header) is required so that the loader can load each segment properly.
The segmented EXE format was developed to provide the loader with this
information.The segmented .EXE file has the following format: +-----------------+
00h | Old-style EXE |
| Header |
+-----------------+
20h | Reserved |
+-----------------+
3Ch | Offset to | ---+
| Segmented Header| |
+-----------------+ |
40h | Relocation Table| |
| & Stub Program | |
+-----------------+ |
| | |
+-----------------+ |
xxh | Segmented EXE | <--+
| Header |
+-----------------+
| Segment Table |
+-----------------+
| Resource Table |
+-----------------+
| Resident Name |
| Table |
+-----------------+
| Module Reference|
| Table |
+-----------------+
| Imported Names |
| Table |
+-----------------+
| Entry Table |
+-----------------+
| Non-Resident |
| Name Table |
+-----------------+
| Seg #1 Data |
| Seg #1 Info |
+-----------------+
.
.
.
+-----------------+
| Seg #n Data |
| Seg #n Info |
+-----------------+
The following sections describe each of the components that make up
the segmented EXE format. Each section contains a description of the
component and the fields in the structures that make up that
component.Note: All unused fields and flag bits are reserved for future use and
must contain 0 (zero) values.======================================================================
SEGMENTED EXE HEADER
======================================================================The segmented EXE header contains general information about the EXE
file and contains information on the location and size of the other
sections. The Windows loader copies this section, along with other
data, into the module table in the system data. The module table is
internal data used by the loader to manage the loaded executable
modules in the system and to support dynamic linking.The following describes the format of the segmented executable header.
For each field, the offset is given relative to the beginning of the
segmented header, the size of the field is defined, and a description
is given. Offset Size Description
------ ---- ----------- 00h DW Signature word.
"N" is low-order byte.
"E" is high-order byte. 02h DB Version number of the linker. 03h DB Revision number of the linker. 04h DW Entry Table file offset, relative to the beginning of
the segmented EXE header.
06h DW Number of bytes in the entry table. 08h DD 32-bit CRC of entire contents of file.
These words are taken as 00 during the calculation. 0Ch DW Flag word.
0000h = NOAUTODATA
0001h = SINGLEDATA (Shared automatic data segment)
0002h = MULTIPLEDATA (Instanced automatic data
segment)
2000h = Errors detected at link time, module will not
load.
8000h = Library module.
The SS:SP information is invalid, CS:IP points
to an initialization procedure that is called
with AX equal to the module handle. This
initialization procedure must perform a far
return to the caller, with AX not equal to
zero to indicate success, or AX equal to zero
to indicate failure to initialize. DS is set
to the library's data segment if the
SINGLEDATA flag is set. Otherwise, DS is set
to the caller's data segment. A program or DLL can only contain dynamic
links to executable files that have this
library module flag set. One program cannot
dynamic-link to another program. 0Eh DW Segment number of automatic data segment.
This value is set to zero if SINGLEDATA and
MULTIPLEDATA flag bits are clear, NOAUTODATA is
indicated in the flags word. A Segment number is an index into the module's segment
table. The first entry in the segment table is segment
number 1. 10h DW Initial size, in bytes, of dynamic heap added to the
data segment. This value is zero if no initial local
heap is allocated. 12h DW Initial size, in bytes, of stack added to the data
segment. This value is zero to indicate no initial
stack allocation, or when SS is not equal to DS. 14h DD Segment number:offset of CS:IP. 18h DD Segment number:offset of SS:SP.
If SS equals the automatic data segment and SP equals
zero, the stack pointer is set to the top of the
automatic data segment just below the additional heap
area. +--------------------------+
| additional dynamic heap |
+--------------------------+ <- SP
| additional stack |
+--------------------------+
| loaded auto data segment |
+--------------------------+ <- DS, SS 1Ch DW Number of entries in the Segment Table. 1Eh DW Number of entries in the Module Reference Table.
20h DW Number of bytes in the Non-Resident Name Table. 22h DW Segment Table file offset, relative to the beginning
of the segmented EXE header. 24h DW Resource Table file offset, relative to the beginning
of the segmented EXE header. 26h DW Resident Name Table file offset, relative to the
beginning of the segmented EXE header. 28h DW Module Reference Table file offset, relative to the
beginning of the segmented EXE header. 2Ah DW Imported Names Table file offset, relative to the
beginning of the segmented EXE header. 2Ch DD Non-Resident Name Table offset, relative to the
beginning of the file. 30h DW Number of movable entries in the Entry Table. 32h DW Logical sector alignment shift count, log(base 2) of
the segment sector size (default 9). 34h DW Number of resource entries. 36h DB Executable type, used by loader.
02h = WINDOWS 37h-3Fh DB Reserved, currently 0's.
======================================================================
SEGMENT TABLE
======================================================================The segment table contains an entry for each segment in the executable
file. The number of segment table entries are defined in the segmented
EXE header. The first entry in the segment table is segment number 1.
The following is the structure of a segment table entry. Size Description
---- ----------- DW Logical-sector offset (n byte) to the contents of the segment
data, relative to the beginning of the file. Zero means no
file data. DW Length of the segment in the file, in bytes. Zero means 64K. DW Flag word.
0007h = TYPE_MASK Segment-type field.
0000h = CODE Code-segment type.
0001h = DATA Data-segment type.
0010h = MOVEABLE Segment is not fixed.
0040h = PRELOAD Segment will be preloaded; read-only if
this is a data segment.
0100h = RELOCINFO Set if segment has relocation records.
F000h = DISCARD Discard priority. DW Minimum allocation size of the segment, in bytes. Total size
of the segment. Zero means 64K.
======================================================================
RESOURCE TABLE
======================================================================The resource table follows the segment table and contains entries for
each resource in the executable file. The resource table consists of
an alignment shift count, followed by a table of resource records. The
resource records define the type ID for a set of resources. Each
resource record contains a table of resource entries of the defined
type. The resource entry defines the resource ID or name ID for the
resource. It also defines the location and size of the resource. The
following describes the contents of each of these structures: Size Description
---- ----------- DW Alignment shift count for resource data. A table of resource type information blocks follows. The following
is the format of each type information block: DW Type ID. This is an integer type if the high-order bit is
set (8000h); otherwise, it is an offset to the type string,
the offset is relative to the beginning of the resource
table. A zero type ID s the end of the resource type
information blocks. DW Number of resources for this type. DD Reserved. A table of resources for this type follows. The following is
the format of each resource (8 bytes each): DW File offset to the contents of the resource data,
relative to beginning of file. The offset is in terms
of the alignment shift count value specified at
beginning of the resource table. DW Length of the resource in the file (in bytes). DW Flag word.
0010h = MOVEABLE Resource is not fixed.
0020h = PURE Resource can be shared.
0040h = PRELOAD Resource is preloaded. DW Resource ID. This is an integer type if the high-order
bit is set (8000h), otherwise it is the offset to the
resource string, the offset is relative to the
beginning of the resource table. DD Reserved. Resource type and name strings are stored at the end of the
resource table. Note that these strings are NOT null terminated and
are case sensitive. DB Length of the type or name string that follows. A zero value
indicates the end of the resource type and name string, also
the end of the resource table. DB ASCII text of the type or name string.
======================================================================
RESIDENT-NAME TABLE
======================================================================The resident-name table follows the resource table, and contains this
module's name string and resident exported procedure name strings. The
first string in this table is this module's name. These name strings
are case-sensitive and are not null-terminated. The following
describes the format of the name strings: Size Description
---- ----------- DB Length of the name string that follows. A zero value indicates
the end of the name table. DB ASCII text of the name string. DW Ordinal number (index into entry table). This value is ignored
for the module name.
======================================================================
MODULE-REFERENCE TABLE
======================================================================The module-reference table follows the resident-name table. Each entry
contains an offset for the module-name string within the imported-
names table; each entry is 2 bytes long. Size Description
---- ----------- DW Offset within Imported Names Table to referenced module name
string.
======================================================================
IMPORTED-NAME TABLE
======================================================================The imported-name table follows the module-reference table. This table
contains the names of modules and procedures that are imported by the
executable file. Each entry is composed of a 1-byte field that
contains the length of the string, followed by any number of
characters. The strings are not null-terminated and are case
sensitive. Size Description
---- ----------- DB Length of the name string that follows. DB ASCII text of the name string.
======================================================================
ENTRY TABLE
======================================================================The entry table follows the imported-name table. This table contains
bundles of entry-point definitions. Bundling is done to save space in
the entry table. The entry table is accessed by an ordinal value.
Ordinal number one is defined to index the first entry in the entry
table. To find an entry point, the bundles are scanned searching for a
specific entry point using an ordinal number. The ordinal number is
adjusted as each bundle is checked. When the bundle that contains the
entry point is found, the ordinal number is multiplied by the size of
the bundle's entries to index the proper entry.The linker forms bundles in the most dense manner it can, under the
restriction that it cannot reorder entry points to improve bundling.
The reason for this restriction is that other .EXE files may refer to
entry points within this bundle by their ordinal number. The following
describes the format of the entry table bundles. Size Description
---- ----------- DB Number of entries in this bundle. All records in one bundle
are either moveable or refer to the same fixed segment. A zero
value in this field indicates the end of the entry table. DB Segment indicator for this bundle. This defines the type of
entry table entry data within the bundle. There are three
types of entries that are defined. 000h = Unused entries. There is no entry data in an unused
bundle. The next bundle follows this field. This is
used by the linker to skip ordinal numbers. 001h-0FEh = Segment number for fixed segment entries. A fixed
segment entry is 3 bytes long and has the following
format. DB Flag word.
01h = Set if the entry is exported.
02h = Set if the entry uses a global (shared) data
segments.
The first assembly-language instruction in the
entry point prologue must be "MOV AX,data
segment number". This may be set only for
SINGLEDATA library modules. DW Offset within segment to entry point. 0FFH = Moveable segment entries. The entry data contains the
segment number for the entry points. A moveable segment
entry is 6 bytes long and has the following format. DB Flag word.
01h = Set if the entry is exported.
02h = Set if the entry uses a global (shared) data
segments. INT 3FH. DB Segment number. DW Offset within segment to entry point.
======================================================================
NONRESIDENT-NAME TABLE
======================================================================The nonresident-name table follows the entry table, and contains a
module description and nonresident exported procedure name strings.
The first string in this table is a module description. These name
strings are case-sensitive and are not null-terminated. The name
strings follow the same format as those defined in the resident name
table.
======================================================================
PER SEGMENT DATA
======================================================================The location and size of the per-segment data is defined in the
segment table entry for the segment. If the segment has relocation
fixups, as defined in the segment table entry flags, they directly
follow the segment data in the file. The relocation fixup information
is defined as follows:
Size Description
---- ----------- DW Number of relocation records that follow. A table of relocation records follows. The following is the format
of each relocation record. DB Source type.
0Fh = SOURCE_MASK
00h = LOBYTE
02h = SEGMENT
03h = FAR_ADDR (32-bit pointer)
05h = OFFSET (16-bit offset) DB Flags byte.
03h = TARGET_MASK
00h = INTERNALREF
01h = IMPORTORDINAL
02h = IMPORTNAME
03h = OSFIXUP
04h = ADDITIVE DW Offset within this segment of the source chain.
If the ADDITIVE flag is set, then target value is added to
the source contents, instead of replacing the source and
following the chain. The source chain is an 0FFFFh
terminated linked list within this segment of all
references to the target. The target value has four types that are defined in the flag
byte field. The following are the formats for each target
type: INTERNALREF DB Segment number for a fixed segment, or 0FFh for a
movable segment. DB 0 DW Offset into segment if fixed segment, or ordinal
number index into Entry Table if movable segment. IMPORTNAME DW Index into module reference table for the imported
module. DW Offset within Imported Names Table to procedure name
string. IMPORTORDINAL DW Index into module reference table for the imported
module.
DW Procedure ordinal number. OSFIXUP DW Operating system fixup type.
Floating-point fixups.
0001h = FIARQQ, FJARQQ
0002h = FISRQQ, FJSRQQ
0003h = FICRQQ, FJCRQQ
0004h = FIERQQ
0005h = FIDRQQ
0006h = FIWRQQ DW 0======================================================================Microsoft is a registered trade and Windows is a trade of
Microsoft Corporation.Additional reference words: 3.02 PE format
PORTABLE EXECUTABLE FORMAT Author: Micheal J. O'Leary
Preface
This document was edited and released by Microsoft Developer
Support. It describes the binary portable executable format for NT.
The information is provided at this point because we feel it will
make the work of application development easier. Unfortunately, the
information in this document may change before the final release of
Windows NT. Microsoft is NOT committing to stay with these formats
by releasing this document. Questions or follow-ups for any of the
information presented here should be posted to CompuServe MSWIN32
forum, section 6.
--Steve Firebaugh
Microsoft Developer Support
Contents 1. Overview 2. PE Header 3. Object Table 4. Image Pages 5. Exports
5.1 Export Directory Table
5.2 Export Address Table
5.3 Export Name Table Pointers
5.4 Export Ordinal Table
5.5 Export Name Table 6. Imports
6.1 Import Directory Table
6.2 Import Lookup Table
6.3 Hint-Name Table
6.4 Import Address Table 7. Thread Local Storage
7.1 Thread Local Storage Directory Table
7.2 Thread Local Storage CallBack Table 8. Resources
8.1 Resource Directory Table
8.2 Resource Example 9. Fixup Table
9.1 Fixup Block 10. Debug Information
10.1 Debug Directory1. Overview 谀哪哪哪哪哪哪哪哪目 <哪? <哪哪? Base of Image Header
? DOS 2 Compatible ? ?
? EXE Header ? ?
媚哪哪哪哪哪哪哪哪拇 ?
? unused ? ?
媚哪哪哪哪哪哪哪哪拇 ?
? OEM Identifier ? ?
? OEM Info ? ?
? ? ? DOS 2.0 Section
? Offset to ? ? (for DOS compatibility only)
? PE Header ? ?
媚哪哪哪哪哪哪哪哪拇 ?
? DOS 2.0 Stub ? ?
? Program & ? ?
? Reloc. Table ? ?
媚哪哪哪哪哪哪哪哪拇 <哪?
? unused ?
媚哪哪哪哪哪哪哪哪拇 <哪哪哪哪? Aligned on 8 byte boundary
? PE Header ?
媚哪哪哪哪哪哪哪哪拇
? Object Table ?
媚哪哪哪哪哪哪哪哪拇
? Image Pages ?
? import info ?
? export info ?
? fixup info ?
? resource info?
? debug info ?
滥哪哪哪哪哪哪哪哪馁
Figure 1. A typical 32-bit Portable EXE File Layout2. PE Header
谀哪哪哪哪哪哪哪哪哪哪哪哪哪履哪哪哪哪哪哪履哪哪哪哪哪哪?
? SIGNATURE BYTES ? CPU TYPE ? # OBJECTS ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪聊哪哪哪哪哪哪?
? TIME/DATE STAMP ? RESERVED ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪履哪哪哪哪哪哪?
? RESERVED ? NT HDR SIZE? FLAGS ?
媚哪哪哪哪哪哪履哪哪穆哪哪哪拍哪哪哪哪哪哪聊哪哪哪哪哪哪?
? RESERVED 矻MAJOR矻MINOR? RESERVED ?
媚哪哪哪哪哪哪聊哪哪牧哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? RESERVED ? RESERVED ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? ENTRYPOINT RVA ? RESERVED ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? RESERVED ? IMAGE BASE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? OBJECT ALIGN ? FILE ALIGN ?
媚哪哪哪哪哪哪履哪哪哪哪哪哪拍哪哪哪哪哪哪履哪哪哪哪哪哪?
? OS MAJOR ? OS MINOR 砋SER MAJOR 砋SER MINOR ?
媚哪哪哪哪哪哪拍哪哪哪哪哪哪拍哪哪哪哪哪哪聊哪哪哪哪哪哪?
? SUBSYS MAJOR? SUBSYS MINOR? RESERVED ?
媚哪哪哪哪哪哪聊哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? IMAGE SIZE ? HEADER SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪履哪哪哪哪哪哪?
? FILE CHECKSUM ? SUBSYSTEM ? DLL FLAGS ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪聊哪哪哪哪哪哪?
? STACK RESERVE SIZE ? STACK COMMIT SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? HEAP RESERVE SIZE ? HEAP COMMIT SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? RESERVED ? # INTERESTING RVA/SIZES ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? EXPORT TABLE RVA ? TOTAL EXPORT DATA SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? IMPORT TABLE RVA ? TOTAL IMPORT DATA SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? RESOURCE TABLE RVA ? TOTAL RESOURCE DATA SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? EXCEPTION TABLE RVA ? TOTAL EXCEPTION DATA SIZE?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? SECURITY TABLE RVA ? TOTAL SECURITY DATA SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? FIXUP TABLE RVA ? TOTAL FIXUP DATA SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? DEBUG TABLE RVA ? TOTAL DEBUG DIRECTORIES ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? IMAGE DESCRIPTION RVA ? TOTAL DESCRIPTION SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? MACHINE SPECIFIC RVA ? MACHINE SPECIFIC SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? THREAD LOCAL STORAGE RVA ? TOTAL TLS SIZE ?
滥哪哪哪哪哪哪哪哪哪哪哪哪哪聊哪哪哪哪哪哪哪哪哪哪哪哪哪?
Figure 2. PE HeaderNotes: o A VA is a virtual address that is already biased by the Image
Base found in the PE Header. A RVA is a virtual address that is
relative to the Image Base.
o An RVA in the PE Header which has a value of zero indicates the
field isn't used.
o Image pages are aligned and zero padded to a File Align
boundary. The bases of all other tables and structures must be
aligned on DWORD (4 byte) boundary. Thus, all VA's and RVA's
must be on a 32 bit boundary. All table and structure fields
must be aligned on their "natural" boundaries, with the possible
exception of the Debug Info.
SIGNATURE BYTES = DB * 4.
Current value is "PE/0/0". Thats PE followed by two zeros (nulls).CPU TYPE = DW CPU Type.
This field specifies the type of CPU compatibility required by this
image to run. The values are: o 0000h __unknown
o 014Ch __80386
o 014Dh __80486
o 014Eh __80586
o 0162h __MIPS Mark I (R2000, R3000)
o 0163h __MIPS Mark II (R6000)
o 0166h __MIPS Mark III (R4000)
# OBJECTS = DW Number of object entries.
This field specifies the number of entries in the Object Table.TIME/DATE STAMP = DD Used to store the time and date the file was
created or modified by the linker.NT HDR SIZE = DW This is the number of remaining bytes in the NT
header that follow the FLAGS field.FLAGS = DW Flag bits for the image.
The flag bits have the following definitons: o 0000h __Program image.
o 0002h __Image is executable.
If this bit isn't set, then it indicates that either errors
where detected at link time or that the image is being
incrementally linked and therefore can't be loaded.
o 0200h __Fixed.
Indicates that if the image can't be loaded at the Image Base,
then don't load it.
o 2000h __Library image.
LMAJOR/LMINOR = DB Linker major/minor version number.ENTRYPOINT RVA = DD Entrypoint relative virtual address.
The address is relative to the Image Base. The address is the
starting address for program images and the library initialization
and library termination address for library images.IMAGE BASE = DD The virtual base of the image.
This will be the virtual address of the first byte of the file (Dos
Header). This must be a multiple of 64K.OBJECT ALIGN = DD The alignment of the objects. This must be a power
of 2 between 512 and 256M inclusive. The default is 64K.FILE ALIGN = DD Alignment factor used to align image pages. The
alignment factor (in bytes) used to align the base of the image pages
and to determine the granularity of per-object trailing zero pad.
Larger alignment factors will cost more file space; smaller alignment
factors will impact demand load performance, perhaps significantly.
Of the two, wasting file space is preferable. This value should be a
power of 2 between 512 and 64K inclusive.OS MAJOR/MINOR = DW OS version number required to run this image.USER MAJOR/MINOR # = DW User major/minor version number.
This is useful for differentiating between revisions of
images/dynamic linked libraries. The values are specified at link
time by the user.SUBSYS MAJOR/MINOR # = DW Subsystem major/minor version number.IMAGE SIZE = DD The virtual size (in bytes) of the image.
This includes all headers. The total image size must be a multiple
of Object Align.HEADER SIZE = DD Total header size.
The combined size of the Dos Header, PE Header and Object Table.FILE CHECKSUM = DD Checksum for entire file. Set to 0 by the linker.SUBSYSTEM = DW NT Subsystem required to run this image.
The values are: o 0000h __Unknown
o 0001h __Native
o 0002h __Windows GUI
o 0003h __Windows Character
o 0005h __OS/2 Character
o 0007h __Posix Character
DLL FLAGS = DW Indicates special loader requirements.
This flag has the following bit values: o 0001h __Per-Process Library Initialization.
o 0002h __Per-Process Library Termination.
o 0004h __Per-Thread Library Initialization.
o 0008h __Per-Thread Library Termination.
All other bits are reserved for future use and should be set to zero.STACK RESERVE SIZE = DD Stack size needed for image.
The memory is reserved, but only the STACK COMMIT SIZE is committed.
The next page of the stack is a 'guarded page'. When the application
hits the guarded page, the guarded page becomes valid, and the next
page becomes the guarded page. This continues until the RESERVE SIZE
is reached.STACK COMMIT SIZE = DD Stack commit size.HEAP RESERVE SIZE = DD Size of local heap to reserve.HEAP COMMIT SIZE = DD Amount to commit in local heap.# INTERESTING VA/SIZES = DD Indicates the size of the VA/SIZE array
that follows.EXPORT TABLE RVA = DD Relative Virtual Address of the Export Table.
This address is relative to the Image Base.IMPORT TABLE RVA = DD Relative Virtual Address of the Import Table.
This address is relative to the Image Base.RESOURCE TABLE RVA = DD Relative Virtual Address of the Resource
Table. This address is relative to the Image Base.EXCEPTION TABLE RVA = DD Relative Virtual Address of the Exception
Table. This address is relative to the Image Base.SECURITY TABLE RVA = DD Relative Virtual Address of the Security
Table. This address is relative to the Image Base.FIXUP TABLE RVA = DD Relative Virtual Address of the Fixup Table.
This address is relative to the Image Base.DEBUG TABLE RVA = DD Relative Virtual Address of the Debug Table.
This address is relative to the Image Base.IMAGE DESCRIPTION RVA = DD Relative Virtual Address of the
description string specified in the module definiton file.MACHINE SPECIFIC RVA = DD Relative Virtual Address of a machine
specific value. This address is relative to the Image Base.TOTAL EXPORT DATA SIZE = DD Total size of the export data.TOTAL IMPORT DATA SIZE = DD Total size of the import data.TOTAL RESOURCE DATA SIZE = DD Total size of the resource data.TOTAL EXCEPTION DATA SIZE = DD Total size of the exception data.TOTAL SECURITY DATA SIZE = DD Total size of the security data.TOTAL FIXUP DATA SIZE = DD Total size of the fixup data.TOTAL DEBUG DIRECTORIES = DD Total number of debug directories.TOTAL DESCRIPTION SIZE = DD Total size of the description data.MACHINE SPECIFIC SIZE = DD A machine specific value.3. Object TableThe number of entries in the Object Table is given by the # Objects
field in the PE Header. Entries in the Object Table are numbered
starting from one. The object table immediately follows the PE
Header. The code and data memory object entries are in the order
chosen by the linker. The virtual addresses for objects must be
assigned by the linker such that they are in ascending order and
adjacent, and must be a multiple of Object Align in the PE header.Each Object Table entry has the following format: 谀哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? OBJECT NAME ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪履哪哪哪哪哪哪哪哪哪哪哪哪哪?
? VIRTUAL SIZE ? RVA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? PHYSICAL SIZE ? PHYSICAL OFFSET ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? RESERVED ? RESERVED ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪哪哪哪哪哪?
? RESERVED ? OBJECT FLAGS ?
滥哪哪哪哪哪哪哪哪哪哪哪哪哪聊哪哪哪哪哪哪哪哪哪哪哪哪哪?
Figure 3. Object TableOBJECT NAME = DB * 8 Object name. This is an eight-byte null-padded
ASCII string representing the object name.VIRTUAL SIZE = DD Virtual memory size. The size of the object that
will be allocated when the object is loaded. Any difference between
PHYSICAL SIZE and VIRTUAL SIZE is zero filled.RVA = DD Relative Virtual Address. The virtual address the object is
currently relocated to, relative to the Image Base. Each Object's
virtual address space consumes a multiple of Object Align (power of 2
between 512 and 256M inclusive. Default is 64K), and immediately
follows the previous Object in the virtual address space (the virtual
address space for a image must be dense).PHYSICAL SIZE = DD Physical file size of initialized data. The size
of the initialized data in the file for the object. The physical
size must be a multiple of the File Align field in the PE Header, and
must be less than or equal to the Virtual Size.PHYSICAL OFFSET = DD Physical offset for object's first page. This
offset is relative to beginning of the EXE file, and is aligned on a
multiple of the File Align field in the PE Header. The offset is
used as a seek value.OBJECT FLAGS = DD Flag bits for the object. The object flag bits
have the following definitions: o 000000020h __Code object.
o 000000040h __Initialized data object.
o 000000080h __Uninitialized data object.
o 040000000h __Object must not be cached.
o 080000000h __Object is not pageable.
o 100000000h __Object is shared.
o 200000000h __Executable object.
o 400000000h __Readable object.
o 800000000h __Writeable object.
All other bits are reserved for future use and should be set to zero.4. Image PagesThe Image Pages section contains all initialized data for all
objects. The seek offset for the first page in each object is
specified in the object table and is aligned on a File Align
boundary. The objects are ordered by the RVA. Every object begins
on a multiple of Object Align.5. ExportsA typical file layout for the export information follows: 谀哪哪哪哪哪哪哪哪哪哪哪?
? DIRECTORY TABLE ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? ADDRESS TABLE ?
? ?
? ?
? ?
? ?
? ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NAME PTR TABLE ?
? ?
? ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? ORDINAL TABLE ?
? ?
? ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NAME STRINGS ?
? ?
? ?
滥哪哪哪哪哪哪哪哪哪哪哪?
Figure 4. Export File Layout5.1 Export Directory TableThe export information begins with the Export Directory Table which
describes the remainder of the export information. The Export
Directory Table contains address information that is used to resolve
fixup references to the entry points within this image. 谀哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? EXPORT FLAGS ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? TIME/DATE STAMP ?
媚哪哪哪哪哪哪哪哪履哪哪哪哪哪哪哪哪?
? MAJOR VERSION ? MINOR VERSION ?
媚哪哪哪哪哪哪哪哪聊哪哪哪哪哪哪哪哪?
? NAME RVA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? ORDINAL BASE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? # EAT ENTRIES ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? # NAME PTRS ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? ADDRESS TABLE RVA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? NAME PTR TABLE RVA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? ORDINAL TABLE RVA ?
滥哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
Figure 5. Export Directory Table EntryEXPORT FLAGS = DD Currently set to zero.TIME/DATE STAMP = DD Time/Date the export data was created.MAJOR/MINOR VERSION = DW A user settable major/minor version number.NAME RVA = DD Relative Virtual Address of the Dll asciiz Name.
This is the address relative to the Image Base.ORDINAL BASE = DD First valid exported ordinal.
This field specifies the starting ordinal number for the export
address table for this image. Normally set to 1.# EAT ENTRIES = DD Indicates number of entries in the Export Address
Table.# NAME PTRS = DD This indicates the number of entries in the Name Ptr
Table (and parallel Ordinal Table).ADDRESS TABLE RVA = DD Relative Virtual Address of the Export Address
Table.
This address is relative to the Image Base.NAME TABLE RVA = DD Relative Virtual Address of the Export Name Table
Pointers.
This address is relative to the beginning of the Image Base. This
table is an array of RVA's with # NAMES entries.ORDINAL TABLE RVA = DD Relative Virtual Address of Export Ordinals
Table Entry.
This address is relative to the beginning of the Image Base.5.2 Export Address TableThe Export Address Table contains the address of exported entrypoints
and exported data and absolutes. An ordinal number is used to index
the Export Address Table. The ORDINAL BASE must be subracted from the
ordinal number before indexing into this table.Export Address Table entry formats are described below: 谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? EXPORTED RVA ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
Figure 6. Export Address Table EntryEXPORTED RVA = DD Export address.
This field contains the relative virtual address of the exported
entry (relative to the Image Base).5.3 Export Name Table PointersThe export name table pointers array contains address into the Export
Name Table. The pointers are 32-bits each, and are relative to the
Image Base. The pointers are ordered lexically to allow binary
searches.5.4 Export Ordinal TableThe Export Name Table Pointers and the Export Ordinal Table form two
parallel arrays, separated to allow natural field alignment. The
export ordinal table array contains the Export Address Table ordinal
numbers associated with the named export referenced by corresponding
Export Name Table Pointers.The ordinals are 16-bits each, and already include the Ordinal Base
stored in the Export Directory Table.5.5 Export Name TableThe export name table contains optional ASCII names for exported
entries in the image. These tables are used with the array of Export
Name Table Pointers and the array of Export Ordinals to translate a
procedure name string into an ordinal number by searching for a
matching name string. The ordinal number is used to locate the entry
point information in the export address table.Import references by name require the Export Name Table Pointers
table to be binary searched to find the matching name, then the
corresponding Export Ordinal Table is known to contain the entry
point ordinal number. Import references by ordinal number provide
the fastest lookup since searching the name table is not required.Each name table entry has the following format: 谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? ASCII STRING ::: :::::::: '\0' ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
Figure 7. Export Name Table EntryASCII STRING = DB ASCII String.
The string is case sensitive and is terminated by a null byte.6. ImportsA typical file layout for the import information follows: 谀哪哪哪哪哪哪哪哪哪哪哪?
? DIRECTORY TABLE ?
? ?
? ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NULL DIR ENTRY ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? DLL1 LOOKUP TABLE ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NULL ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? DLL2 LOOKUP TABLE ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NULL ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? Dll3 LOOKUP TABLE ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NULL ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? HINT-NAME TABLE ?
? ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? DLL1 ADDRESS TABLE ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NULL ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? DLL2 ADDRESS TABLE ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NULL ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? DLL3 ADDRESS TABLE ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? NULL ?
滥哪哪哪哪哪哪哪哪哪哪哪?
Figure 8. Import File Layout6.1 Import Directory TableThe import information begins with the Import Directory Table which
describes the remainder of the import information. The Import
Directory Table contains address information that is used to resolve
fixup references to the entry points within a DLL image. The import
directory table consists of an array of Import Directory Entries, one
entry for each DLL this image references. The last directory entry is
empty (NULL) which indicates the end of the directory table.An Import Directory Entry has the following format: 谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? IMPORT FLAGS ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? TIME/DATE STAMP ?
媚哪哪哪哪哪哪哪哪履哪哪哪哪哪哪哪哪?
? MAJOR VERSION ? MINOR VERSION ?
媚哪哪哪哪哪哪哪哪聊哪哪哪哪哪哪哪哪?
? NAME RVA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? IMPORT LOOKUP TABLE RVA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? IMPORT ADDRESS TABLE RVA ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
Figure 9. Import Directory EntryIMPORT FLAGS = DD Currently set to zero.TIME/DATE STAMP = DD Time/Date the import data was pre-snapped or
zero if not pre-snapped.MAJOR/MINOR VERSION = DW The major/minor version number of the dll
being referenced.NAME RVA = DD Relative Virtual Address of the Dll asciiz Name.
This is the address relative to the Image Base.IMPORT LOOKUP TABLE RVA = DD This field contains the address of the
start of the import lookup table for this image. The address is
relative to the beginning of the Image Base.IMPORT ADDRESS TABLE RVA = DD This field contains the address of the
start of the import addresses for this image. The address is
relative to the beginning of the Image Base.6.2 Import Lookup TableThe Import Lookup Table is an array of ordinal or hint/name RVA's for
each DLL. The last entry is empty (NULL) which indicates the end of
the table.The last element is empty. 3 0
1
谀夷哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
?0? ORDINAL#/HINT-NAME TABLE RVA ?
滥心哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
Figure 10. Import Address Table FormatORDINAL/HINT-NAME TABLE RVA = 31-bits (mask = 7fffffffh) Ordinal
Number or Name Table RVA.
If the import is by ordinal, this field contains a 31 bit ordinal
number. If the import is by name, this field contains a 31 bit
address relative to the Image Base to the Hint-Name Table.O = 1-bit (mask = 80000000h) Import by ordinal flag. o 00000000h __Import by name.
o 80000000h __Import by ordinal.
6.3 Hint-Name TableThe Hint-Name Table format follows: 谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? HINT ? ASCII STRING |||?
媚哪哪哪呐哪哪哪哪拍哪哪哪呐哪哪哪哪?
硘||||||||||||||||? '\0' PAD ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
The PAD field is optional.
Figure 11. Import Hint-Name TableHINT = DW Hint into Export Name Table Pointers.
The hint value is used to index the Export Name Table Pointers array,
allowing faster by-name imports. If the hint is incorrect, then a
binary search is performed on the Export Name Ptr Table.ASCII STRING = DB ASCII String.
The string is case sensitive and is terminated by a null byte.PAD = DB Zero pad byte.
A trailing zero pad byte appears after the trailing null byte if
necessary to align the next entry on an even boundary.The loader overwrites the import address table when loading the image
with the 32-bit address of the import.6.4 Import Address TableThe Import Address Table is an array of addresses of the imported
routines for each DLL. The last entry is empty (NULL) which indicates
the end of the table.7. Thread Local StorageThread local storage is a special contiguous block of data. Each
thread will gets its own block upon creation of the thread.The file layout for thread local storage follows:
谀哪哪哪哪哪哪哪哪哪哪哪?
? DIRECTORY TABLE ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? TLS DATA ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? INDEX VARIABLE ?
滥哪哪哪哪哪哪哪哪哪哪哪?
谀哪哪哪哪哪哪哪哪哪哪哪?
? CALLBACK ADDRESSES ?
滥哪哪哪哪哪哪哪哪哪哪哪?Figure 12. Thread Local Storage Layout7.1 Thread Local Storage Directory TableThe Thread Local Storage Directory Table contains address information
that is used to describe the rest of TLS.The Thread Local Storage Directory Table has the following format: 谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? START DATA BLOCK VA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? END DATA BLOCK VA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? INDEX VA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? CALLBACK TABLE VA ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
Figure 13. Thread Local Storage Directory TableSTART DATA BLOCK VA = DD Virtual Address of the start of the thread
local storage data block.END DATA BLOCK VA = DD Virtual Address of the end of the thread local
storage data block.INDEX VA = DD Virtual Address of the index variable used to access
the thread local storage data block.CALLBACK TABLE VA = DD Virtual Address of the callback table.7.2 Thread Local Storage CallBack TableThe Thread Local Storage Callbacks is an array of Virtual Address of
functions to be called by the loader after thread creation and thread
termination. The last entry is empty (NULL) which indicates the end
of the table.The Thread Local Storage CallBack Table has the following format: 谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? FUNCTION1 VA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? FUNCTION2 VA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? NULL ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
Figure 14. Thread Local Storage CallBack Table8. ResourcesResources are indexed by a multiple level binary-sorted tree
structure. The overall design can incorporate 2**31 levels, however,
NT uses only three: the highest is TYPE, then NAME, then LANGUAGE.A typical file layout for the resource information follows:
谀哪哪哪哪哪哪哪哪哪哪哪?
? RESOURCE DIRECTORY ?
? ?
? ?
? ?
媚哪哪哪哪哪哪哪哪哪哪哪?
? RESOURCE DATA ?
? ?
? ?
? ?
? ?
? ?
? ?
滥哪哪哪哪哪哪哪哪哪哪哪?
Figure 15. Resource File Layout
The Resource directory is made up of the following tables:8.1 Resource Directory Table
谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? RESOURCE FLAGS ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? TIME/DATE STAMP ?
媚哪哪哪哪哪哪哪哪履哪哪哪哪哪哪哪哪?
? MAJOR VERSION ? MINOR VERSION ?
媚哪哪哪哪哪哪哪哪拍哪哪哪哪哪哪哪哪?
? # NAME ENTRY ? # ID ENTRY ?
媚哪哪哪哪哪哪哪哪聊哪哪哪哪哪哪哪哪?
? RESOURCE DIR ENTRIES ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?Figure 16. Resource Table Entry
RESOURCE FLAGS = DD Currently set to zero.TIME/DATE STAMP = DD Time/Date the resource data was created by the
resource compiler.MAJOR/MINOR VERSION = DW A user settable major/minor version number.# NAME ENTRY = DW The number of name entries.
This field contains the number of entries at the beginning of the
array of directory entries which have actual string names associated
with them.# ID ENTRY = DW The number of ID integer entries.
This field contains the number of 32-bit integer IDs as their names
in the array of directory entries.The resource directory is followed by a variable length array of
directory entries. # NAME ENTRY is the number of entries at the
beginning of the array that have actual names associated with each
entry. The entires are in ascending order, case insensitive strings.
# ID ENTRY identifies the number of entries that have 32-bit integer
IDs as their name. These entries are also sorted in ascending order.This structure allows fast lookup by either name or number, but for
any given resource entry only one form of lookup is supported, not
both. This is consistent with the syntax of the .RC file and the .RES
file.The array of directory entries have the following format:
3 0
1
谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? NAME RVA/INTEGER ID ?
媚夷哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
矱? DATA ENTRY RVA/SUBDIR RVA ?
滥心哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?Figure 17. Resource Directory Entry
INTERGER ID = DD ID.
This field contains a integer ID field to identify a resource.NAME RVA = DD Name RVA address.
This field contains a 31-bit address relative to the beginning of the
Image Base to a Resource Directory String Entry.E = 1-bit (mask 80000000h) Unescape bit.
This bit is zero for unescaped Resource Data Entries.DATA RVA = 31-bits (mask 7fffffffh) Data entry address.
This field contains a 31-bit address relative to the beginning of the
Image Base to a Resource Data Entry.E = 1-bit (mask 80000000h) Escape bit.
This bit is 1 for escaped Subdirectory Entry.DATA RVA = 31-bits (mask 7fffffffh) Directory entries.
This field contains a 31-bit address relative to the beginning of the
Image Base to Subdirectory Entry.Each resource directory string entry has the following format:
谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? LENGTH ? UNICODE STRING ?
媚哪哪哪呐哪哪哪哪拍哪哪哪呐哪哪哪哪?
? ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?Figure 18. Resource Directory String Entry
LENGTH = DW Length of string.UNICODE STRING = DW UNICODE String.All of these string objects are stored together after the last
resource directory entry and before the first resource data object.
This minimizes the impact of these variable length objects on the
alignment of the fixed size directory entry objects. The length needs
to be word aligned.Each Resource Data Entry has the following format: 谀哪哪哪穆哪哪哪哪履哪哪哪穆哪哪哪哪?
? DATA RVA ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? SIZE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? CODEPAGE ?
媚哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪哪?
? RESERVED ?
滥哪哪哪牧哪哪哪哪聊哪哪哪牧哪哪哪哪?
Figure 19. Resource Data EntryDATA RVA = DD Address of Resource Data.
This field contains 32-bit virtaul address of the resource data
(relative to the Image Base).SIZE = DD Size of Resource Data.
This field contains the size of the resource data for this resource.CODEPAGE = DD Codepage.RESERVED = DD Reserved - must be zero.Each resource data entry describes a leaf node in the resource
directory tree. It contains an address which is relative to the
beginning of Image Base, a size field that gives the number of bytes
of data at that address, a CodePage that should be used when decoding
code point values within the resource data. Typically for new
applications the code page would be the unicode code page.8.2 Resource ExampleThe following is an example for an app. which wants to use the following data
as resources: TypeId# NameId# Language ID Resource Data
00000001 00000001 0 00010001
00000001 00000001 1 10010001
00000001 00000002 0 00010002
00000001 00000003 0 00010003
00000002 00000001 0 00020001
00000002 00000002 0 00020002
00000002 00000003 0 00020003
00000002 00000004 0 00020004
00000009 00000001 0 00090001
00000009 00000009 0 00090009
00000009 00000009 1 10090009
00000009 00000009 2 20090009Then the Resource Directory in the Portable format looks like:
Offset Data
0000: 00000000 00000000 00000000 00030000 (3 entries in this directory)
0010: 00000001 80000028 (TypeId #1, Subdirectory at offset 0x28)
0018: 00000002 80000050 (TypeId #2, Subdirectory at offset 0x50)
0020: 00000009 80000080 (TypeId #9, Subdirectory at offset 0x80)
0028: 00000000 00000000 00000000 00030000 (3 entries in this directory)
0038: 00000001 800000A0 (NameId #1, Subdirectory at offset 0xA0)
0040: 00000002 00000108 (NameId #2, data desc at offset 0x108)
0048: 00000003 00000118 (NameId #3, data desc at offset 0x118)
0050: 00000000 00000000 00000000 00040000 (4 entries in this directory)
0060: 00000001 00000128 (NameId #1, data desc at offset 0x128)
0068: 00000002 00000138 (NameId #2, data desc at offset 0x138)
0070: 00000003 00000148 (NameId #3, data desc at offset 0x148)
0078: 00000004 00000158 (NameId #4, data desc at offset 0x158)
0080: 00000000 00000000 00000000 00020000 (2 entries in this directory)
0090: 00000001 00000168 (NameId #1, data desc at offset 0x168)
0098: 00000009 800000C0 (NameId #9, Subdirectory at offset 0xC0)
00A0: 00000000 00000000 00000000 00020000 (2 entries in this directory)
00B0: 00000000 000000E8 (Language ID 0, data desc at offset 0xE8
00B8: 00000001 000000F8 (Language ID 1, data desc at offset 0xF8
00C0: 00000000 00000000 00000000 00030000 (3 entries in this directory)
00D0: 00000001 00000178 (Language ID 0, data desc at offset 0x178
00D8: 00000001 00000188 (Language ID 1, data desc at offset 0x188
00E0: 00000001 00000198 (Language ID 2, data desc at offset 0x19800E8: 000001A8 (At offset 0x1A8, for TypeId #1, NameId #1, Language id #0
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
00F8: 000001AC (At offset 0x1AC, for TypeId #1, NameId #1, Language id #1
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0108: 000001B0 (At offset 0x1B0, for TypeId #1, NameId #2,
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0118: 000001B4 (At offset 0x1B4, for TypeId #1, NameId #3,
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0128: 000001B8 (At offset 0x1B8, for TypeId #2, NameId #1,
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0138: 000001BC (At offset 0x1BC, for TypeId #2, NameId #2,
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0148: 000001C0 (At offset 0x1C0, for TypeId #2, NameId #3,
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0158: 000001C4 (At offset 0x1C4, for TypeId #2, NameId #4,
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0168: 000001C8 (At offset 0x1C8, for TypeId #9, NameId #1,
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0178: 000001CC (At offset 0x1CC, for TypeId #9, NameId #9, Language id #0
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0188: 000001D0 (At offset 0x1D0, for TypeId #9, NameId #9, Language id #1
00000004 (4 bytes of data)
00000000 (codepage)
00000000 (reserved)
0198: 000001D4 (At offset 0x1D4, for TypeId #9, NameId #9, Language id #2
00000004 (4 bytes of data)
解决方案 »
免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货