Wenn Du wissen willst di ein Exe/
DLL aufgebaut ist so schau am besten in der
MSDN nach
Hab ich schon gemacht. Was ich aber jetzt wissen muss, ist, in der wievielten Section die Exporttabelle steht.
Nach
PE-Optional-Header folgen mehrere Section-Headers. Meine Frage ist nun:
Der wievielte Section Header enthält denn nun die Exporttabelle.
Entweder bin ich im englischen nicht fit genug oder ich habe irgenwas noch nicht verstanden.
Was ich bisher verstanden habe, ist der grundsätzliche Aufbau des
PE Headers. Die Section Headers sind die vorletzten Header, danach folgen die Ressourcen Header (IMAGE_RESOURCE_DIRECTORY). Meine
Dll enthält aber keine Ressourcen.
Was ich noch nicht rausgekriegt habe, ist, der wievielte Section Header denn nun auf die Exporttabelle zeigt, mit der Struktur IMAGE_EXPORT_DIRECTORY. Wo gibt es dazu detailliertere Auskunft.
Die angegebene Doku ist da leider vieeel zu knapp. Warum kann sowas nicht generell detaillierter dokumentiert werden?
Wird doch auch von anderen gebraucht, nicht nur hier von mir.
Wenn natürlich hier:
http://msdn.microsoft.com/en-us/magazine/bb985996.aspx
die Sections in derjenigen Reihenfolge beschrieben sind, in der sie in der library abgespeichert sind, dann natürlich habe ich bereits gefunden, wonach ich suche. Werde das gleich mal ausprobieren.
Delphi-Quellcode:
Figure 1 Section Names
Name
Description
.text
The
default code section.
.data
The
default read/
write data section. Global variables typically go here.
.rdata
The
default read-only data section.
String literals
and C++/
COM vtables are examples
of items put into .rdata.
.idata
The imports table. It has become common practice (either explicitly,
or via linker
default behavior)
to merge the .idata section into another section, typically .rdata. By
default, the linker only merges the .idata section into another section when creating a release mode executable.
.edata
The
exports table. When creating an executable that
exports APIs
or data, the linker creates an .EXP
file. The .EXP
file contains an .edata section that'
s added into the final executable. Like the .idata section, the .edata section is often found merged into the .text or .rdata sections.
.rsrc
The resources. This section is read-only. However, it should not be named anything other than .rsrc, and should not be merged into other sections.
.bss
Uninitialized data. Rarely found in executables created with recent linkers. Instead, the VirtualSize of the executable's .data section
is expanded
to make enough room
for uninitialized data.
.crt
Data added
for supporting the C++ runtime (CRT). A good example
is the
function pointers that are used
to call the constructors
and destructors
of static C++ objects. See the January 2001 Under The Hood column
for details
on this.
.tls
Data
for supporting thread
local storage variables declared
with __declspec(thread). This includes the initial value
of the data,
as well
as additional variables needed by the runtime.
.reloc
The base relocations
in an executable. Base relocations are generally only needed
for DLLs
and not EXEs.
In release mode, the linker doesn'
t emit base relocations for EXE files. Relocations can be removed when linking with the /FIXED switch.
.sdata
"Short" read/write data that can be addressed relative to the global pointer. Used for the IA-64 and other architectures that use a global pointer register. Regular-sized global variables on the IA-64 will go in this section.
.srdata
"Short" read-only data that can be addressed relative to the global pointer. Used on the IA-64 and other architectures that use a global pointer register.
.pdata
The exception table. Contains an array of IMAGE_RUNTIME_FUNCTION_ENTRY structures, which are CPU-specific. Pointed to by the IMAGE_DIRECTORY_ENTRY_EXCEPTION slot in the DataDirectory. Used for architectures with table-based exception handling, such as the IA-64. The only architecture that doesn't use table-based
exception handling
is the x86.
.debug$S
Codeview format symbols
in the OBJ
file. This
is a stream
of variable-length CodeView format symbol records.
.debug$T
Codeview format
type records
in the OBJ
file. This
is a stream
of variable-length CodeView format
type records.
.debug$P
Found
in the OBJ
file when using precompiled headers.
.drectve
Contains linker directives
and is only found
in OBJs. Directives are
ASCII strings that could be passed
on the linker command line.
For instance:
-defaultlib:LIBC
Directives are separated by a space character.
.didat
Delayload import data. Found
in executables built
in nonrelease mode.
In release mode, the delayload data
is merged into another section.