Introduction

The Portable Executable Format is the data structure that describes how the various parts of a Win32 executable file are held together. It allows the operating system to load the executable and to locate the dynamically linked libraries required to run that executable and to navigate the code, data and resource sections compiled into that executable.

Getting over DOS

The PE Format was created for Windows but Microsoft had to make sure that running such an executable in DOS would yield a meaningful error message and exit. To this end the very first bit of a Windows executable file is actually a DOS executable (sometimes known as the stub) which writes "This program requires Windows" or similar, then exits.

The only field of this structure that is of interest to Windows is e_lfanew which is the file pointer to the new Windows executable header. To skip over the DOS part of the program, set the file pointer to the value held in this field:

The SizeOfOptionalHeader member indicates the size (in bytes) of the IMAGE_OPTIONAL_HEADER structure that immediately follows it. In practice this structure is not optional, so that is a bit of a misnomer. This structure is defined as:

The most useful field of this structure (to my purposes, anyhow) are the 16 IMAGE_DATA_DIRECTORY entries. These describe whereabouts (if at all) the particular sections of the executable are located. The structure is defined thus:

Note that if an executable does not contain one of the sections (as is often the case) there will be an IMAGE_DATA_DIRECTORY for it, but the address and size will both be zero.

The image data directories

The exports directory

The exports directory holds details of the functions exported by this executable. For example, if you were to look in the exports directory of the MSVBVM50.dll it would list all the functions it exports, that make up the Visual Basic 5 runtime environment.

This directory consists of some info to tell you how many exported functions there are, followed by three parallel arrays which give you the address, name and ordinal of the functions respectively. The structure is defined thus:

The imports directory

The imports directory lists the dynamic link libraries that this executable depends on and which functions it imports from that dynamic link library. It consists of an array of IMAGE_IMPORT_DESCRIPTOR structures terminated by an instance of this structure where the lpName parameter is zero. The structure is defined as:

The resource directory

The structure of the resource directory is somewhat more involved. It consists of a root directory (defined by the structure IMAGE_RESOURCE_DIRECTORY) immediately followed by a number of resource directory entries (defined by the structure IMAGE_RESOURCE_DIRECTORY_ENTRY). These are defined thus:

Each resource directory entry can either point to the actual resource data or to another layer of resource directory entries. If the highest bit of dwDataOffset is set, then this points to a directory. Otherwise it points to the resource data.

How is this information useful?

Once you know how an executable is put together, you can use this information to peer into its workings. You can view the resources compiled into it, the DLLs it depends on and the actual functions it imports from them. More importantly you can attach to the executable a debugger and track down any of those really troublesome general protection faults. The next article will describe how to attach a debugger and use the PE file format.

I am trying to get a small module of your code to work. What I need is a functionality where I supply the path/name of a DLL, and I get a list of its dependencies (files it 'imports').
How can I instantiate an IMAGE_DATA_DIRECTORY (which would be the import directory) by passing a string (path/name of DLL)?
Any help will be deeply appreciated.

You can use similar access, except it would be all in-process data reads, by mapping the file into memory and then setting up the addresses treating the image base as the base address of the memory mapped file. You need to do some memory address adjustments because the relocations will not have been made. I am working on a solution in C++ that does this from file and will eventually post article here.

Hello,
anybody guide me about how to access the Portable Executable (PE) graphical area. plz also tell me it is possible or not?
i want to access the PE graphical area that is going to display at screen....

Having examined the ExportDirectory section of MSVBVM60.DLL, I find that the three "parallel" arrays appear to be, well...not parallel. For the function address, it appears necessary to use the ordinal value as the table index, not the loopcounter (nFunction) value. This was necessary to get an output that duplicates an expensive, commercial debugger. Can you advise?
Thanks

Also, as an FYI, the my original query is related to named exports ,as in the commercial product. (but I would not expect the named exports to be separated from the un-named exports; they should,I would think, both be in one combined grouping of the three parallel tables??!!??)

I have few questions regarding executable format.
1. How to convert long datetime to datetime format and reverse.
2. Is there any source code avaible for VB.net?
3. I need to change the TimeStamp from VB.NET executable, how do i do this task?