186
2 Computer Viruses, Malicious Logic, and Spyware
files; in addition, it can partially execute the existing binary Windows files in DOS,
thus acting like Wine for DOS.
Mac OS X10.5 also supports the ability to load and interpret PE files; however,
they are not fully compatible with Windows.
PE is a modified version of the COFF file format for Unix. PE/COFF is a frequently
used alternative term referring to Windows development.
In Windows NT operating systems, the PE format supports the following architectures of command sets: IA-32, IA-64, and X86-64 (AMD64/Intel64). Until Windows
2000, Windows NT (as well as PE) supported MIPS, Alpha, and PowerPC. Since
PE is used on Windows CE, it still supports several types of MIPS, ARM (including
Thumb), and SuperH.
The main “competitors” of PE files are ELF (used in Linux and most other Unix
versions) and Mach-O (used in Mac OS X).
With creation of a next-generation operating system Windows NT 3.1, Microsoft
switched to PE. All later versions of Windows, including Windows 95/98/ME,
support this format. The format retained limited support for the existing (MZ) to
bridge the gap between DOS-based systems and NT systems. For example, PE/COFF
still includes an MS-DOS executable program, which by default is a stub displaying
the following simple message on the screen: “This program cannot be run in DOS
mode” (or another similar message). PE keeps serving the changing Windows platform. Some of the extensions include the format PE.NET (see below), 64-bit version
known as PE32 + (or sometimes as PE +), and specification for Windows CE.
Now, let us consider the main technical details associated with the purpose and
structure of these PE files. Figure 2.35 shows a simplified structure of standard 32-bit
PE files.
Here, the first two bytes of the PE file contain the signature 0x4D 0x5A—MZ (as a
descendant of the MZ format). After that, the double word at the 0x3C offset contains
the address of the PE header. The latter starts with the signature 0x50 0x45—PE.
Typical structure of a PE file consists of several headers and sections, which show
the dynamic linker how to display the file in memory. The executable image consists
of several different areas (sections), each of which requires different memory access
rights; thus, the beginning of each section has to be aligned with the page border.
For example, the section .text, which contains the program code, is displayed as
executable/read-only, and the section .data containing global variables is displayed
as non-executable/read-and-write. However, in order to avoid wasting the hard drive
space, various sections are not aligned with the page border. Part of the work of
a dynamic linker consists in displaying each section in the memory separately
and assigns specific access rights to the resulting fields according to the directions
contained in the headers.
It should be noted that the .NET platform by Microsoft has expanded the PE
format using functions that support Common Language Runtime—CLR. The additions include the CLR header and the CLR data section. After loading a binary file,
the OS loader forces CLR execution by means of reference in the PE/COFF import
table. CLR then loads the CLR header and data sections.
2 Computer Viruses, Malicious Logic, and Spyware
files; in addition, it can partially execute the existing binary Windows files in DOS,
thus acting like Wine for DOS.
Mac OS X10.5 also supports the ability to load and interpret PE files; however,
they are not fully compatible with Windows.
PE is a modified version of the COFF file format for Unix. PE/COFF is a frequently
used alternative term referring to Windows development.
In Windows NT operating systems, the PE format supports the following architectures of command sets: IA-32, IA-64, and X86-64 (AMD64/Intel64). Until Windows
2000, Windows NT (as well as PE) supported MIPS, Alpha, and PowerPC. Since
PE is used on Windows CE, it still supports several types of MIPS, ARM (including
Thumb), and SuperH.
The main “competitors” of PE files are ELF (used in Linux and most other Unix
versions) and Mach-O (used in Mac OS X).
With creation of a next-generation operating system Windows NT 3.1, Microsoft
switched to PE. All later versions of Windows, including Windows 95/98/ME,
support this format. The format retained limited support for the existing (MZ) to
bridge the gap between DOS-based systems and NT systems. For example, PE/COFF
still includes an MS-DOS executable program, which by default is a stub displaying
the following simple message on the screen: “This program cannot be run in DOS
mode” (or another similar message). PE keeps serving the changing Windows platform. Some of the extensions include the format PE.NET (see below), 64-bit version
known as PE32 + (or sometimes as PE +), and specification for Windows CE.
Now, let us consider the main technical details associated with the purpose and
structure of these PE files. Figure 2.35 shows a simplified structure of standard 32-bit
PE files.
Here, the first two bytes of the PE file contain the signature 0x4D 0x5A—MZ (as a
descendant of the MZ format). After that, the double word at the 0x3C offset contains
the address of the PE header. The latter starts with the signature 0x50 0x45—PE.
Typical structure of a PE file consists of several headers and sections, which show
the dynamic linker how to display the file in memory. The executable image consists
of several different areas (sections), each of which requires different memory access
rights; thus, the beginning of each section has to be aligned with the page border.
For example, the section .text, which contains the program code, is displayed as
executable/read-only, and the section .data containing global variables is displayed
as non-executable/read-and-write. However, in order to avoid wasting the hard drive
space, various sections are not aligned with the page border. Part of the work of
a dynamic linker consists in displaying each section in the memory separately
and assigns specific access rights to the resulting fields according to the directions
contained in the headers.
It should be noted that the .NET platform by Microsoft has expanded the PE
format using functions that support Common Language Runtime—CLR. The additions include the CLR header and the CLR data section. After loading a binary file,
the OS loader forces CLR execution by means of reference in the PE/COFF import
table. CLR then loads the CLR header and data sections.