Chapter 11 Portable Executable File Format IN THIS CHAPTER + Understanding the structure of a PE file + Talking in terms of RVAs + Detailing the PE format + The importance of indices in the data directory + How the loader interprets a PE file MICROSOFT INTRODUCED A NEW executable file format with Windows NT. This for- mat is called the Portable Executable (PE) format because it is supposed to be portable across all 32-bit operating systems by Microsoft. The same PE format exe- cutable can be executed on any version of Windows NT, Windows 95, and Win32s. Also, the same format is used for executables for Windows NT running on proces- sors other than Intel x86, such as MIPS, Alpha, and Power PC. The 32-bit DLLs and Windows NT device drivers also follow the same PE format. It is helpful to understand the PE file format because PE files are almost identi- cal on disk and in RAM. Learning about the PE format is also helpful for under- standing many operating system concepts. For example, how operating system loader works to support dynamic linking of DLL functions, the data structures in- volved in dynamic linking such as import table, export table, and so on. The PE format is not really undocumented. The WINNT.H file has several struc- ture definitions representing the PE format. The Microsoft Developer's Network (MSDN) CD-ROMs contain several descriptions of the PE format. However, these descriptions are in bits and pieces, and are by no means complete. In this chapter, we try to give you a comprehensive picture of the PE format. Microsoft also provides a DLL with the SDK that has utility functions for inter- preting PE files. We also discuss these functions and correlate them with other in- formation about the PE format. 223 224 Part 11: Undocumented Windows NT Overview of a PE File In this section, we discuss the overall structure of a PE file. In the sections that fol- . sections s variou s comprise e fil E P A . format E P e th t abou l detai o int o g e w , low Because Microsoft's 32-bit operating systems follow the flat memory model, an ex- s a h suc , executable n a f o s part t differen , Still . segments s contain r longe o n e ecutabl e executabl n a f o s part t differen e Thes . characteristics t differen e hav , data d an e cod d store a dat f o n concatenatio a s i e fil E P a , Thus . sections t differen s a d store e ar in sections. A few sections are always present in a PE file generated by the Microsoft linker. d generate e fil E P A . names t differen h wit s section r simila e generat y ma s linker r Othe with the Microsoft linker has a .text section that contains the code bytes concate- nated from all the object files. As for the data, it can be classified into different cat- egories. The .data section contains all the initialized global and static data, while the - liter g strin s a h suc , data y read-onl e Th . data d uninitialize e th s contain n sectio s .bs e som s contain o als n sectio s Thi . section a .rdat e th n i d store s i , constants d an s al other read-only structures, such as the debug directory, the Thread Local Storage n sectio a .edat e Th . chapter s thi n i r late n explai e w h whic , on o s d an , directory ) (TLS contains information about the functions exported from a DLL, while the .idata sec- tion stores information about the functions imported by an executable or a DLL. The .rsrc section contains various resources, such as menus and dialog boxes. The .reloc section stores the information required for relocating the image while loading. , earlier d mentione s A . significance y an e hav t no o d s section e th f o s name e Th o als n ca s Programmer . sections e th r fo s name t differen e us y ma s linker t differen g data_se a #pragm d an g code_se a #pragm e Th . own r thei f o s section w ne e creat . compiler t Microsof h wit g workin e whil s section w ne e creat o t d use e b n ca s macro The operating system loader locates the required piece of information from the data e fil f o w overvie n a t presen l wil e w , Shortly . headers e fil e th n i t presen s directorie . detail e mor n i m the t a k loo n the d an s header e Fil E P a f o e Structur - head s variou s contain e fil E P a , data l actua e th f o g consistin s section e th m fro t Apar . sections e th n i t presen n informatio t importan e th d an s section e th e describ t tha s er . familiar k loo t migh s byte 2 t firs e th , file E P a f o p dum x he e th t a k loo u yo f I Aren't they M and Z? Yes, a PE file starts with the DOS executable header. It is fol- lowed by a small program that prints an error message saying that the program cannot be run in DOS mode. It's the same idea that was used in 16-bit Windows ex- . DOS r unde n ru s i e imag E P e th f i , executed s i e cod m progra s Thi . ecutables After the DOS header and the DOS executable stub comes the PE header. A field e 4-byt e th h wit s start r heade E P e Th . header w ne s thi o t s point r heade S DO e th n i signature "PE" followed by two nulls. The PE format is based on the Common Object Chapter 11: Portable Executable Eile Format 225 e fil t objec e th y b d followe s i e signatur E P e Th . Unix y b d use ) (COFF t Forma e Fil d produce s file t objec e th r fo o als t presen s i r heade s Thi . COFF m fro d borrowe r heade by Microsoft's 32-bit compilers. This header contains some general information about the file, such as the target machine ID, the number of sections in the file, and so forth. The COFF style header is followed by the optional header. This header is op- tional in the sense that it is not required for the object files. As far as executables and DLLs are concerned, this header is mandatory. The optional header has two e Th . files F COF l al n i d foun e b n ca d an F COF m fro d inherite s i t par t firs e Th . parts second part is an NT-specific extension of COFF. Apart from other NT-specific infor- e Th . directory a dat e th s contain o als t par s thi , type m subsyste e th s a h suc , mation data directory is an array in which each entry points to some important piece of in- formation. One of the entries in the data directory points to the import table of the . on o s d an , DLL e th f o e tabl t expor e th o t s point y entr r anothe , DLL r o e executabl n informatio f o s piece t differen e th f o s format d detaile e th t a k loo l wil e W later in this chapter. f o y arra n a s i e tabl n sectio e Th . table n sectio e th y b d followe s i y director a dat e Th e th t abou n informatio t importan e th s summarize r heade n sectio A . headers n sectio respective section. Finally, the section table is followed by the sections themselves. e Befor . file E P a f o n organizatio e th f o w overvie n a u yo s give s thi t tha e hop e W diving into the details of the PE format, let's discuss a concept that is vital in inter- preting a PE file. ... s Addres l Virtua e Relativ All the offsets within a PE file are denoted as Relative Virtual Addresses (RVAs). An . memory n i d loade s i e executabl n a h whic t a s addres e bas e th m fro t offse n a s i A RV This is not the same as the offset within the file because of the section alignment n a r fo s requirement t alignmen n sectio e th s specifie r heade E P e Th . requirements executable image. A section has to be loaded at a memory address that is a multi- ple of the section alignment. The section alignment has to be a multiple of the page ; requirements e attribut e pag t differen e hav s section t differen e becaus s i s Thi .