Portable Executable - Revision history

~2025-39367-79: PE is and was NEVER used for object files -- see COFF

2025-12-09T04:07:57Z

PE is and was NEVER used for object files -- see COFF

← Previous revision		Revision as of 04:07, 9 December 2025
Line 4:		Line 4:
	\| name = Portable Executable		\| name = Portable Executable
	\| icon =		\| icon =
	\| extension = <code>[[.exe]]</code>, <code>[[Dynamic-link library\|.dll]]</code>, <code>[[.sys]]</code>, <code>.acm</code>, <code>.ax</code>, <code>.cpl</code>, <code>.drv</code>, <code>.efi</code>, <code>.mui</code>, <code>.ocx</code>, <code>.scr</code>, <code>.tsp~~</code>, <code>.mun~~</code>, <code>.msstyles</code>		\| extension = <code>[[.exe]]</code>, <code>.com</code>, <code>[[Dynamic-link library\|.dll]]</code>, <code>[[.sys]]</code>, <code>.acm</code>, <code>.ax</code>, <code>.cpl</code>, <code>.drv</code>, <code>.efi</code>, <code>.mui</code>, <code>.ocx</code>, <code>.scr</code>, <code>.tsp</code>, <code>.msstyles</code>
	\| mime = application/vnd.microsoft.portable-executable<ref>{{Cite web\|url=https://www.iana.org/assignments/media-types/application/vnd.microsoft.portable-executable\|title=application/vnd.microsoft.portable-executable\|access-date=2017-03-26\|last=Andersson\|first=Henrik\|date=2015-04-23\|publisher=IANA}}</ref>		\| mime = application/vnd.microsoft.portable-executable<ref>{{Cite web\|url=https://www.iana.org/assignments/media-types/application/vnd.microsoft.portable-executable\|title=application/vnd.microsoft.portable-executable\|access-date=2017-03-26\|last=Andersson\|first=Henrik\|date=2015-04-23\|publisher=IANA}}</ref>
	\| owner = Currently: [[Microsoft]]		\| owner = Currently: [[Microsoft]]
Line 14:		Line 14:
	\|=		\|=
	}}		}}
	'''Portable Executable''' ('''PE''') is a [[file format]] for native [[executable code]] on 32-bit and 64-bit [[Microsoft Windows\|Windows]] [[operating system]]s, as well as in [[UEFI]] environments.<ref>{{Cite web \|title=Portable executable (PE) - Definition - Trend Micro IN \|url=https://www.trendmicro.com/vinfo/in/security/definition/portable-executable-pe \|access-date=2022-11-10 \|website=www.trendmicro.com}}</ref> It is used for native executables ({{mono\|.exe}}), dynamic link libraries ({{mono\|.dll}}, {{mono\|.ocx}}), system drivers ({{mono\|.sys}}), ~~object code (~~{{mono\|.~~obj~~}}) and many other types of files. The PE format supports storing the data required to load and start an operating system [[process (computing)\|process]] {{endash}} including references to [[dynamic link library \|dynamic link libraries]], tables for importing and exporting [[application programming interface]] (API) functions, resource management data and [[thread-local storage]] (TLS) information.		'''Portable Executable''' ('''PE''') is a [[file format]] for native [[executable code]] on 32-bit and 64-bit [[Microsoft Windows\|Windows]] [[operating system]]s, as well as in [[UEFI]] environments.<ref>{{Cite web \|title=Portable executable (PE) - Definition - Trend Micro IN \|url=https://www.trendmicro.com/vinfo/in/security/definition/portable-executable-pe \|access-date=2022-11-10 \|website=www.trendmicro.com}}</ref> It is used for native executables ({{mono\|.exe}}, {{mono\|.com}}), dynamic link libraries ({{mono\|.dll}}, {{mono\|.ocx}}), system drivers ({{mono\|.sys}}, {{mono\|.drv}}) and many other types of files. The PE format supports storing the data required to load and start an operating system [[process (computing)\|process]] {{endash}} including references to [[dynamic link library \|dynamic link libraries]], tables for importing and exporting [[application programming interface]] (API) functions, resource management data and [[thread-local storage]] (TLS) information.

	According to the [[Unified Extensible Firmware Interface\|Unified Extensible Firmware Interface (UEFI)]] specification, the PE format is also the accepted standard for executables in EFI environments.<ref>{{cite web \|url=https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf \|title=UEFI Specification, version 2.8B}}, a note on p.15, states that "this image type is chosen to enable UEFI images to contain Thumb and Thumb2 instructions while defining the EFI interfaces themselves to be in ARM mode."</ref> On Windows NT systems, it currently supports a range of [[Instruction set architecture\|instruction sets]], including [[IA-32]], [[x86-64]] (AMD64/Intel 64), [[IA-64]], [[ARM architecture\|ARM]] and [[ARM64]]. Before the advent of [[Windows 2000]], Windows NT (and by extension the PE format) also supported [[MIPS architecture\|MIPS]], [[DEC Alpha\|Alpha]], and [[PowerPC]] architectures. Moreover, thanks to its use in [[Windows CE]], PE has maintained compatibility with several MIPS, [[ARM architecture\|ARM]] (including [[ARM architecture#Thumb\|Thumb]]), and [[SuperH]] variants.<ref name="PE Format (Windows)">{{cite web\|url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx\|title=PE Format (Windows)\| access-date=2017-10-21}}</ref>		According to the [[Unified Extensible Firmware Interface\|Unified Extensible Firmware Interface (UEFI)]] specification, the PE format is also the accepted standard for executables in EFI environments.<ref>{{cite web \|url=https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf \|title=UEFI Specification, version 2.8B}}, a note on p.15, states that "this image type is chosen to enable UEFI images to contain Thumb and Thumb2 instructions while defining the EFI interfaces themselves to be in ARM mode."</ref> On Windows NT systems, it currently supports a range of [[Instruction set architecture\|instruction sets]], including [[IA-32]], [[x86-64]] (AMD64/Intel 64), [[IA-64]], [[ARM architecture\|ARM]] and [[ARM64]]. Before the advent of [[Windows 2000]], Windows NT (and by extension the PE format) also supported [[MIPS architecture\|MIPS]], [[DEC Alpha\|Alpha]], and [[PowerPC]] architectures. Moreover, thanks to its use in [[Windows CE]], PE has maintained compatibility with several MIPS, [[ARM architecture\|ARM]] (including [[ARM architecture#Thumb\|Thumb]]), and [[SuperH]] variants.<ref name="PE Format (Windows)">{{cite web\|url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx\|title=PE Format (Windows)\| access-date=2017-10-21}}</ref>

imported>InternetArchiveBot: Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5) (Tomkozak61 - 26303

2025-10-02T00:09:50Z

Rescuing 1 sources and tagging 0 as dead.) #IABot (v2.0.9.5) (Tomkozak61 - 26303

← Previous revision		Revision as of 00:09, 2 October 2025
Line 1:		Line 1:
	{{short description\|~~File~~ format}}		{{short description \|Executable file format}}
	{{distinguish\|Portable application\|Windows Preinstallation Environment}}		{{distinguish\|Portable application\|Windows Preinstallation Environment}}
	{{Infobox file format		{{Infobox file format
	\| name = Portable Executable		\| name = Portable Executable
	\| icon =		\| icon =
	\| extension = <code>.~~acm~~</code>, <code>.ax</code>, <code>.~~cpl~~</code>, <code>.~~dll~~</code>, <code>.~~drv~~</code>, <code>.~~efi~~</code>, <code>[[.~~exe]]~~</code>, <code>.~~mui~~</code>, <code>.~~ocx~~</code>, <code>.~~scr~~</code>, <code>.~~sys~~</code>, <code>.tsp</code>, <code>.mun</code>, <code>.msstyles</code>		\| extension = <code>[[.exe]]</code>, <code>[[Dynamic-link library\|.dll]]</code>, <code>[[.sys]]</code>, <code>.acm</code>, <code>.ax</code>, <code>.cpl</code>, <code>.drv</code>, <code>.efi</code>, <code>.mui</code>, <code>.ocx</code>, <code>.scr</code>, <code>.tsp</code>, <code>.mun</code>, <code>.msstyles</code>
	\| mime = application/vnd.microsoft.portable-executable<ref>{{Cite web\|url=https://www.iana.org/assignments/media-types/application/vnd.microsoft.portable-executable\|title=application/vnd.microsoft.portable-executable\|access-date=2017-03-26\|last=Andersson\|first=Henrik\|date=2015-04-23\|publisher=IANA}}</ref>		\| mime = application/vnd.microsoft.portable-executable<ref>{{Cite web\|url=https://www.iana.org/assignments/media-types/application/vnd.microsoft.portable-executable\|title=application/vnd.microsoft.portable-executable\|access-date=2017-03-26\|last=Andersson\|first=Henrik\|date=2015-04-23\|publisher=IANA}}</ref>
	\| owner = Currently: [[Microsoft]]		\| owner = Currently: [[Microsoft]]
			\| magic = <code>4D 5A</code> (<code>MZ</code> in [[ASCII]])<br>and<br><code>50 45 00 00</code> (<code>PE</code>)
	\| genre = [[Binary file\|Binary]], [[executable]], [[object code\|object]], [[shared libraries]]		\| genre = [[Binary file\|Binary]], [[executable]], [[object code\|object]], [[shared libraries]]
	\| extendedfrom = [[DOS MZ executable]]<br />[[COFF]]		\| extendedfrom = [[DOS MZ executable]]<br />[[COFF]]
Line 13:		Line 14:
	\|=		\|=
	}}		}}
	~~The~~ '''Portable Executable''' ('''PE''') ~~format~~ is a [[file format]] for [[executable~~]]s, [[object file\|object~~ code]]~~, [[Dynamic-link library\|dynamic-link-libraries]] (DLLs), and binary files used~~ on 32-bit and 64-bit [[Microsoft Windows\|Windows]] [[operating system]]s, as well as in [[UEFI]] environments.<ref>{{Cite web \|title=Portable executable (PE) - Definition - Trend Micro IN \|url=https://www.trendmicro.com/vinfo/in/security/definition/portable-executable-pe \|access-date=2022-11-10 \|website=www.trendmicro.com}}</ref> It is ~~the standard format~~ for executables ~~on Windows NT-based systems, including files such as <code>~~.exe~~</code>~~, ~~<code>~~.dll~~</code>~~, ~~<code>~~.~~sys</code> (for~~ system drivers), ~~and <~~code>.~~mui</code>~~. ~~At its core, the~~ PE format ~~is a structured~~ data ~~container that gives the Windows~~ operating system ~~loader everything it needs to properly manage the~~ [[~~Executable~~\|~~executable code~~]] ~~it contains. This includes~~ references ~~for~~ [[~~Library (computer science)#Dynamic linking~~\|~~dynamically linked~~ libraries]], tables for importing and exporting [[~~Application~~ programming interface~~\|APIs~~]], resource management data and [[thread-local storage]] (TLS) information.		'''Portable Executable''' ('''PE''') is a [[file format]] for native [[executable code]] on 32-bit and 64-bit [[Microsoft Windows\|Windows]] [[operating system]]s, as well as in [[UEFI]] environments.<ref>{{Cite web \|title=Portable executable (PE) - Definition - Trend Micro IN \|url=https://www.trendmicro.com/vinfo/in/security/definition/portable-executable-pe \|access-date=2022-11-10 \|website=www.trendmicro.com}}</ref> It is used for native executables ({{mono\|.exe}}), dynamic link libraries ({{mono\|.dll}}, {{mono\|.ocx}}), system drivers ({{mono\|.sys}}), object code ({{mono\|.obj}}) and many other types of files. The PE format supports storing the data required to load and start an operating system [[process (computing)\|process]] {{endash}} including references to [[dynamic link library \|dynamic link libraries]], tables for importing and exporting [[application programming interface]] (API) functions, resource management data and [[thread-local storage]] (TLS) information.

	According to the [[Unified Extensible Firmware Interface\|Unified Extensible Firmware Interface (UEFI)]] specification, the PE format is also the accepted standard for executables in EFI environments.<ref>{{cite web \|url=https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf \|title=UEFI Specification, version 2.8B}}, a note on p.15, states that "this image type is chosen to enable UEFI images to contain Thumb and Thumb2 instructions while defining the EFI interfaces themselves to be in ARM mode."</ref> On Windows NT systems, it currently supports a range of [[Instruction set architecture\|instruction sets]], including [[IA-32]], [[x86-64]] (AMD64/Intel 64), [[IA-64]], [[ARM architecture\|ARM]] and [[ARM64]]. Before the advent of [[Windows 2000]], Windows NT (and by extension the PE format) also supported [[MIPS architecture\|MIPS]], [[DEC Alpha\|Alpha]], and [[PowerPC]] architectures. Moreover, thanks to its use in [[Windows CE]], PE has maintained compatibility with several MIPS, [[ARM architecture\|ARM]] (including [[ARM architecture#Thumb\|Thumb]]), and [[SuperH]] variants.<ref name="PE Format (Windows)">{{cite web\|url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx\|title=PE Format (Windows)\| access-date=2017-10-21}}</ref>		According to the [[Unified Extensible Firmware Interface\|Unified Extensible Firmware Interface (UEFI)]] specification, the PE format is also the accepted standard for executables in EFI environments.<ref>{{cite web \|url=https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf \|title=UEFI Specification, version 2.8B}}, a note on p.15, states that "this image type is chosen to enable UEFI images to contain Thumb and Thumb2 instructions while defining the EFI interfaces themselves to be in ARM mode."</ref> On Windows NT systems, it currently supports a range of [[Instruction set architecture\|instruction sets]], including [[IA-32]], [[x86-64]] (AMD64/Intel 64), [[IA-64]], [[ARM architecture\|ARM]] and [[ARM64]]. Before the advent of [[Windows 2000]], Windows NT (and by extension the PE format) also supported [[MIPS architecture\|MIPS]], [[DEC Alpha\|Alpha]], and [[PowerPC]] architectures. Moreover, thanks to its use in [[Windows CE]], PE has maintained compatibility with several MIPS, [[ARM architecture\|ARM]] (including [[ARM architecture#Thumb\|Thumb]]), and [[SuperH]] variants.<ref name="PE Format (Windows)">{{cite web\|url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx\|title=PE Format (Windows)\| access-date=2017-10-21}}</ref>
Line 31:		Line 32:
	===Layout===		===Layout===
	[[File:Portable Executable 32 bit Structure in SVG fixed.svg\|thumb\|Structure of a Portable Executable 32 bit]]		[[File:Portable Executable 32 bit Structure in SVG fixed.svg\|thumb\|Structure of a Portable Executable 32 bit]]
	A PE file consists of several headers and sections that instruct the [[dynamic linker]] about on how to map the file into memory. An executable image consists of several different regions, each requiring different [[memory protection]] attributes. To ensure proper alignment, the start of each section must align to a page boundary.<ref>{{cite web \|url=http://www.csn.ul.ie/%7Ecaolan/pub/winresdump/winresdump/doc/pefile2.html \|title=The Portable Executable File From Top to Bottom \|access-date=2017-10-21}}</ref> For instance, the ''.text'' section, which contains program code, is typically mapped as an execute/read-only. Conversely, the ''.data'' section, which holds global variables, is mapped as no-execute/read write. However, to conserve space, sections are not aligned on disk in this manner. The dynamic linker maps each section to memory individually and assigns the correct permissions based on the information in the headers.<ref name="Peering Inside">{{cite web \|url=https://msdn.microsoft.com/en-us/library/ms809762.aspx \|title=Peering Inside the PE: A Tour of the Win32 Portable Executable File \|date=30 June 2010 \|access-date=2017-10-21}}</ref>		A PE file consists of several headers and sections that instruct the [[dynamic linker]] about on how to map the file into memory. An executable image consists of several different regions, each requiring different [[memory protection]] attributes. To ensure proper alignment, the start of each section must align to a page boundary.<ref>{{cite web \|url=http://www.csn.ul.ie/%7Ecaolan/pub/winresdump/winresdump/doc/pefile2.html \|title=The Portable Executable File From Top to Bottom \|access-date=2017-10-21 \|archive-date=2017-10-20 \|archive-url=https://web.archive.org/web/20171020180919/http://www.csn.ul.ie/~caolan/pub/winresdump/winresdump/doc/pefile2.html \|url-status=dead }}</ref> For instance, the ''.text'' section, which contains program code, is typically mapped as an execute/read-only. Conversely, the ''.data'' section, which holds global variables, is mapped as no-execute/read write. However, to conserve space, sections are not aligned on disk in this manner. The dynamic linker maps each section to memory individually and assigns the correct permissions based on the information in the headers.<ref name="Peering Inside">{{cite web \|url=https://msdn.microsoft.com/en-us/library/ms809762.aspx \|title=Peering Inside the PE: A Tour of the Win32 Portable Executable File \|date=30 June 2010 \|access-date=2017-10-21}}</ref>

	===Import table===		===Import table===
Line 57:		Line 58:

	==See also==		==See also==
	* [[a.out]]		* {{Annotated link\|a.out}}
	* [[Comparison of executable file formats]]		* {{Annotated link\|Application virtualization}}
	* [[Executable compression]]		* {{Annotated link\|Comparison of executable file formats}}
	* [[ar (Unix)]] since all COFF libraries use that same format		* {{Annotated link\|Executable compression}}
	* [[Application virtualization]]

	==References==		==References==

imported>MCSjojo: /* Address Space Layout Randomization */ Rewrote due to minor accuracy issues and verbosity

2025-06-21T20:40:33Z

Address Space Layout Randomization: Rewrote due to minor accuracy issues and verbosity

← Previous revision		Revision as of 20:40, 21 June 2025
Line 37:		Line 37:

	=== Address Space Layout Randomization (ASLR) ===		=== Address Space Layout Randomization (ASLR) ===
	~~PE files aren't [[position-independent code\|position-independent]] by default; they are compiled to run at a specific, fixed memory address.~~ Modern operating systems use ~~Address Space Layout Randomization (~~[[Address space layout randomization~~\|ASLR~~]]) ~~to make it~~ harder ~~for attackers~~ to exploit ~~memory-related vulnerabilities~~. ASLR ~~works by randomly changing~~ the ~~memory address of important parts of~~ the ~~program every time it's loaded~~. This includes the base ~~address of the program itself~~, shared libraries ~~(DLLs)~~, ~~and~~ memory ~~areas like the~~ heap and stack. ~~ASLR rearranges the address space positions of key data areas of a process, including the base of the~~ [[~~executable~~]] ~~and the positions of the~~ [[~~Stack-based memory allocation~~\|~~stack~~]], [[~~Dynamic memory allocation~~\|~~heap~~]] ~~and~~ [[~~Library~~ (~~computer science~~)\|~~libraries~~]]~~. By randomizing these memory addresses each~~ time ~~an application is loaded, ASLR prevents attackers from being able to reliably predict memory locations~~.		Modern operating systems use [[Address space layout randomization]] (ASLR), a process that makes a PE file's in-memory layout unpredictable and therefore harder to exploit. During ASLR, the [[Loader (computing)\|loader]] randomizes the virtual addresses where key components reside. This includes the executable's base, [[Shared library\|shared libraries]], the [[Dynamic memory allocation\|heap]], and the [[Call stack\|stack]]. Most PE files are not [[Position-independent code\|position-independent]] because mainstream [[Compiler\|compilers]] emit some absolute references relative to an assumed base. To cope with randomized rebasing, the [[Linker (computing)\|linker]] stores a [[Relocation (computing)\|.reloc]] table that lets the loader adjust those references at load time.

	== .NET, metadata, and the PE format ==		== .NET, metadata, and the PE format ==

imported>LevWings: /* growthexperiments-addlink-summary-summary:3|0|0 */

2025-06-10T13:45:16Z

growthexperiments-addlink-summary-summary:3|0|0

← Previous revision		Revision as of 13:45, 10 June 2025
Line 21:		Line 21:
	== History ==		== History ==

	Microsoft first introduced the PE format with [[Windows NT 3.1]], replacing the older 16-bit [[New Executable]] (NE) format. Soon after, Windows 95, 98, ME, and the Win32s extension for Windows 3.1x, all adopted the PE structure. Each PE file includes a DOS executable header, which generally displays the message "[[New Executable\|This program cannot be run in DOS mode]]". However, this DOS section can be replaced by a fully functional DOS program, as demonstrated in the Windows 98 SE installer. Developers can add such a program using the <code>/STUB</code> switch with Microsoft's linker, effectively creating a [[fat binary]].<ref>{{cite web \| url=http://msdn.microsoft.com/en-us/library/7z0585h5.aspx \| title=/STUB (MS-DOS Stub File Name) \| date=3 August 2021 }}</ref>		Microsoft first introduced the PE format with [[Windows NT 3.1]], replacing the older 16-bit [[New Executable]] (NE) format. Soon after, Windows 95, 98, ME, and the Win32s extension for [[Windows 3.1x]], all adopted the PE structure. Each PE file includes a DOS executable header, which generally displays the message "[[New Executable\|This program cannot be run in DOS mode]]". However, this DOS section can be replaced by a fully functional DOS program, as demonstrated in the Windows 98 SE installer. Developers can add such a program using the <code>/STUB</code> switch with Microsoft's linker, effectively creating a [[fat binary]].<ref>{{cite web \| url=http://msdn.microsoft.com/en-us/library/7z0585h5.aspx \| title=/STUB (MS-DOS Stub File Name) \| date=3 August 2021 }}</ref>

	Over time, the PE format has grown with the Windows platform. Notable extensions include the [[.NET]] PE format for managed code, PE32+ for 64-bit address space support, and a specialized version for [[Windows Embedded Compact\|Windows CE]].		Over time, the PE format has grown with the Windows platform. Notable extensions include the [[.NET]] PE format for [[managed code]], PE32+ for 64-bit address space support, and a specialized version for [[Windows Embedded Compact\|Windows CE]].

	To determine whether a PE file is intended for 32-bit or 64-bit architectures, one can examine the Machine field in the IMAGE_FILE_HEADER.<ref>[https://gdatasoftware.com/blog/pebitnesstrick PE trick explained: Telling 32 and 64 bit apart with naked eye] by Karsten Hahn</ref> Common machine values are <code>0x014c</code> for 32-bit Intel processors and <code>0x8664</code> for x64 processors. Additionally, the Magic field in the <code>IMAGE_OPTIONAL_HEADER</code> reveals whether addresses are 32-bit or 64-bit. A value of <code>0x10B</code> indicates a 32-bit (PE32) file, while <code>0x20B</code> indicates a 64-bit (PE32+) file.<ref>[https://docs.microsoft.com/en-us/windows/win32/debug/pe-format PE Format] at Microsoft.com</ref>		To determine whether a PE file is intended for 32-bit or 64-bit architectures, one can examine the Machine field in the IMAGE_FILE_HEADER.<ref>[https://gdatasoftware.com/blog/pebitnesstrick PE trick explained: Telling 32 and 64 bit apart with naked eye] by Karsten Hahn</ref> Common machine values are <code>0x014c</code> for 32-bit Intel processors and <code>0x8664</code> for x64 processors. Additionally, the Magic field in the <code>IMAGE_OPTIONAL_HEADER</code> reveals whether addresses are 32-bit or 64-bit. A value of <code>0x10B</code> indicates a 32-bit (PE32) file, while <code>0x20B</code> indicates a 64-bit (PE32+) file.<ref>[https://docs.microsoft.com/en-us/windows/win32/debug/pe-format PE Format] at Microsoft.com</ref>
Line 31:		Line 31:
	===Layout===		===Layout===
	[[File:Portable Executable 32 bit Structure in SVG fixed.svg\|thumb\|Structure of a Portable Executable 32 bit]]		[[File:Portable Executable 32 bit Structure in SVG fixed.svg\|thumb\|Structure of a Portable Executable 32 bit]]
	A PE file consists of several headers and sections that instruct the [[dynamic linker]] about on how to map the file into memory. An executable image consists of several different regions, each requiring different memory protection attributes. To ensure proper alignment, the start of each section must align to a page boundary.<ref>{{cite web \|url=http://www.csn.ul.ie/%7Ecaolan/pub/winresdump/winresdump/doc/pefile2.html \|title=The Portable Executable File From Top to Bottom \|access-date=2017-10-21}}</ref> For instance, the ''.text'' section, which contains program code, is typically mapped as an execute/read-only. Conversely, the ''.data'' section, which holds global variables, is mapped as no-execute/read write. However, to conserve space, sections are not aligned on disk in this manner. The dynamic linker maps each section to memory individually and assigns the correct permissions based on the information in the headers.<ref name="Peering Inside">{{cite web \|url=https://msdn.microsoft.com/en-us/library/ms809762.aspx \|title=Peering Inside the PE: A Tour of the Win32 Portable Executable File \|date=30 June 2010 \|access-date=2017-10-21}}</ref>		A PE file consists of several headers and sections that instruct the [[dynamic linker]] about on how to map the file into memory. An executable image consists of several different regions, each requiring different [[memory protection]] attributes. To ensure proper alignment, the start of each section must align to a page boundary.<ref>{{cite web \|url=http://www.csn.ul.ie/%7Ecaolan/pub/winresdump/winresdump/doc/pefile2.html \|title=The Portable Executable File From Top to Bottom \|access-date=2017-10-21}}</ref> For instance, the ''.text'' section, which contains program code, is typically mapped as an execute/read-only. Conversely, the ''.data'' section, which holds global variables, is mapped as no-execute/read write. However, to conserve space, sections are not aligned on disk in this manner. The dynamic linker maps each section to memory individually and assigns the correct permissions based on the information in the headers.<ref name="Peering Inside">{{cite web \|url=https://msdn.microsoft.com/en-us/library/ms809762.aspx \|title=Peering Inside the PE: A Tour of the Win32 Portable Executable File \|date=30 June 2010 \|access-date=2017-10-21}}</ref>

	===Import table===		===Import table===
Line 37:		Line 37:

	=== Address Space Layout Randomization (ASLR) ===		=== Address Space Layout Randomization (ASLR) ===
	PE files aren't [[position-independent code\|position-independent]] by default; they are compiled to run at a specific, fixed memory address. Modern operating systems use Address Space Layout Randomization ([[Address space layout randomization\|ASLR]]) to make it harder for attackers to exploit memory-related vulnerabilities. ASLR works by randomly changing the memory address of important parts of the program every time it's loaded. This includes the base address of the program itself, shared libraries (DLLs), and memory areas like the heap and stack. ASLR rearranges the address space positions of key data areas of a process, including the base of the [[executable]] and the positions of the [[Stack-based memory allocation\|stack]], [[Dynamic memory allocation\|heap]] and [[Library (computer science)\|libraries]]. By randomizing these memory addresses each time ~~the process~~ an application is loaded, ASLR prevents attackers from being able to reliably predict memory locations.		PE files aren't [[position-independent code\|position-independent]] by default; they are compiled to run at a specific, fixed memory address. Modern operating systems use Address Space Layout Randomization ([[Address space layout randomization\|ASLR]]) to make it harder for attackers to exploit memory-related vulnerabilities. ASLR works by randomly changing the memory address of important parts of the program every time it's loaded. This includes the base address of the program itself, shared libraries (DLLs), and memory areas like the heap and stack. ASLR rearranges the address space positions of key data areas of a process, including the base of the [[executable]] and the positions of the [[Stack-based memory allocation\|stack]], [[Dynamic memory allocation\|heap]] and [[Library (computer science)\|libraries]]. By randomizing these memory addresses each time an application is loaded, ASLR prevents attackers from being able to reliably predict memory locations.

	== .NET, metadata, and the PE format ==		== .NET, metadata, and the PE format ==

94.134.212.196: fix typo

2025-04-07T12:43:10Z

fix typo

New page

{{short description|File format}}
{{distinguish|Portable application|Windows Preinstallation Environment}}
{{Infobox file format
| name = Portable Executable
| icon =
| extension = <code>.acm</code>, <code>.ax</code>, <code>.cpl</code>, <code>.dll</code>, <code>.drv</code>, <code>.efi</code>, <code>[[.exe]]</code>, <code>.mui</code>, <code>.ocx</code>, <code>.scr</code>, <code>.sys</code>, <code>.tsp</code>, <code>.mun</code>, <code>.msstyles</code>
| mime = application/vnd.microsoft.portable-executable<ref>{{Cite web|url=https://www.iana.org/assignments/media-types/application/vnd.microsoft.portable-executable|title=application/vnd.microsoft.portable-executable|access-date=2017-03-26|last=Andersson|first=Henrik|date=2015-04-23|publisher=IANA}}</ref>
| owner = Currently: [[Microsoft]]
| genre = [[Binary file|Binary]], [[executable]], [[object code|object]], [[shared libraries]]
| extendedfrom = [[DOS MZ executable]]<br />[[COFF]]
| containerfor =
| containedby =
|=
}}
The '''Portable Executable''' ('''PE''') format is a [[file format]] for [[executable]]s, [[object file|object code]], [[Dynamic-link library|dynamic-link-libraries]] (DLLs), and binary files used on 32-bit and 64-bit [[Microsoft Windows|Windows]] [[operating system]]s, as well as in [[UEFI]] environments.<ref>{{Cite web |title=Portable executable (PE) - Definition - Trend Micro IN |url=https://www.trendmicro.com/vinfo/in/security/definition/portable-executable-pe |access-date=2022-11-10 |website=www.trendmicro.com}}</ref> It is the standard format for executables on Windows NT-based systems, including files such as <code>.exe</code>, <code>.dll</code>, <code>.sys</code> (for system drivers), and <code>.mui</code>. At its core, the PE format is a structured data container that gives the Windows operating system loader everything it needs to properly manage the [[Executable|executable code]] it contains. This includes references for [[Library (computer science)#Dynamic linking|dynamically linked libraries]], tables for importing and exporting [[Application programming interface|APIs]], resource management data and [[thread-local storage]] (TLS) information.

According to the [[Unified Extensible Firmware Interface|Unified Extensible Firmware Interface (UEFI)]] specification, the PE format is also the accepted standard for executables in EFI environments.<ref>{{cite web |url=https://uefi.org/sites/default/files/resources/UEFI%20Spec%202.8B%20May%202020.pdf |title=UEFI Specification, version 2.8B}}, a note on p.15, states that "this image type is chosen to enable UEFI images to contain Thumb and Thumb2 instructions while defining the EFI interfaces themselves to be in ARM mode."</ref> On Windows NT systems, it currently supports a range of [[Instruction set architecture|instruction sets]], including [[IA-32]], [[x86-64]] (AMD64/Intel 64), [[IA-64]], [[ARM architecture|ARM]] and [[ARM64]]. Before the advent of [[Windows 2000]], Windows NT (and by extension the PE format) also supported [[MIPS architecture|MIPS]], [[DEC Alpha|Alpha]], and [[PowerPC]] architectures. Moreover, thanks to its use in [[Windows CE]], PE has maintained compatibility with several MIPS, [[ARM architecture|ARM]] (including [[ARM architecture#Thumb|Thumb]]), and [[SuperH]] variants.<ref name="PE Format (Windows)">{{cite web|url=https://msdn.microsoft.com/en-us/library/windows/desktop/ms680547(v=vs.85).aspx|title=PE Format (Windows)| access-date=2017-10-21}}</ref>

Functionally, the PE format is similar to other platform-specific executable formats, such as the [[Executable and Linkable Format|ELF]] format used in [[Linux]] and most [[Unix-like|Unix-like systems]], and the [[Mach-O]] format found in [[macOS]] and [[iOS]].

== History ==

Microsoft first introduced the PE format with [[Windows NT 3.1]], replacing the older 16-bit [[New Executable]] (NE) format. Soon after, Windows 95, 98, ME, and the Win32s extension for Windows 3.1x, all adopted the PE structure. Each PE file includes a DOS executable header, which generally displays the message "[[New Executable|This program cannot be run in DOS mode]]". However, this DOS section can be replaced by a fully functional DOS program, as demonstrated in the Windows 98 SE installer. Developers can add such a program using the <code>/STUB</code> switch with Microsoft's linker, effectively creating a [[fat binary]].<ref>{{cite web | url=http://msdn.microsoft.com/en-us/library/7z0585h5.aspx | title=/STUB (MS-DOS Stub File Name) | date=3 August 2021 }}</ref>

Over time, the PE format has grown with the Windows platform. Notable extensions include the [[.NET]] PE format for managed code, PE32+ for 64-bit address space support, and a specialized version for [[Windows Embedded Compact|Windows CE]].

To determine whether a PE file is intended for 32-bit or 64-bit architectures, one can examine the Machine field in the IMAGE_FILE_HEADER.<ref>[https://gdatasoftware.com/blog/pebitnesstrick PE trick explained: Telling 32 and 64 bit apart with naked eye] by Karsten Hahn</ref> Common machine values are <code>0x014c</code> for 32-bit Intel processors and <code>0x8664</code> for x64 processors. Additionally, the Magic field in the <code>IMAGE_OPTIONAL_HEADER</code> reveals whether addresses are 32-bit or 64-bit. A value of <code>0x10B</code> indicates a 32-bit (PE32) file, while <code>0x20B</code> indicates a 64-bit (PE32+) file.<ref>[https://docs.microsoft.com/en-us/windows/win32/debug/pe-format PE Format] at Microsoft.com</ref>

==Technical details==

===Layout===
[[File:Portable Executable 32 bit Structure in SVG fixed.svg|thumb|Structure of a Portable Executable 32 bit]]
A PE file consists of several headers and sections that instruct the [[dynamic linker]] about on how to map the file into memory. An executable image consists of several different regions, each requiring different memory protection attributes. To ensure proper alignment, the start of each section must align to a page boundary.<ref>{{cite web |url=http://www.csn.ul.ie/%7Ecaolan/pub/winresdump/winresdump/doc/pefile2.html |title=The Portable Executable File From Top to Bottom |access-date=2017-10-21}}</ref> For instance, the ''.text'' section, which contains program code, is typically mapped as an execute/read-only. Conversely, the ''.data'' section, which holds global variables, is mapped as no-execute/read write. However, to conserve space, sections are not aligned on disk in this manner. The dynamic linker maps each section to memory individually and assigns the correct permissions based on the information in the headers.<ref name="Peering Inside">{{cite web |url=https://msdn.microsoft.com/en-us/library/ms809762.aspx |title=Peering Inside the PE: A Tour of the Win32 Portable Executable File |date=30 June 2010 |access-date=2017-10-21}}</ref>

===Import table===
The ''import address table'' (IAT) is used as a lookup table when the application calls a function in a different module. The [[Dynamic-link library|imports]] can be specified by ordinal or by name. Because a compiled program cannot know the memory locations of its dependent libraries beforehand, an indirect jump is necessary for API calls. As the dynamic linker holds modules and resolves dependencies, it populates the IAT slots with actual addresses of the corresponding library functions. Although this adds an extra jump, incurring a performance penalty compared to intermodular calls, it minimizes the number of memory pages that that require [[copy-on-write]] changes, thus conserving memory and disk I/O. If a call is known to be intermodular beforehand (if indicated by a [[Dynamic-link library|dllimport]] attribute), the compiler can generate optimized code with a simple indirect call [[opcode]].<ref name="Peering Inside" />

=== Address Space Layout Randomization (ASLR) ===
PE files aren't [[position-independent code|position-independent]] by default; they are compiled to run at a specific, fixed memory address. Modern operating systems use Address Space Layout Randomization ([[Address space layout randomization|ASLR]]) to make it harder for attackers to exploit memory-related vulnerabilities. ASLR works by randomly changing the memory address of important parts of the program every time it's loaded. This includes the base address of the program itself, shared libraries (DLLs), and memory areas like the heap and stack. ASLR rearranges the address space positions of key data areas of a process, including the base of the [[executable]] and the positions of the [[Stack-based memory allocation|stack]], [[Dynamic memory allocation|heap]] and [[Library (computer science)|libraries]]. By randomizing these memory addresses each time the process an application is loaded, ASLR prevents attackers from being able to reliably predict memory locations.

== .NET, metadata, and the PE format ==

In a .NET executable, the PE code section contains a stub that invokes the [[Common Language Runtime|CLR]] virtual machine startup entry, <code>_CorExeMain</code> or <code>_CorDllMain</code> in <code>mscoree.dll</code>, much like it was in [[Visual Basic]] executables. The virtual machine then makes use of .NET metadata present, the root of which, <code>IMAGE_COR20_HEADER</code> (also called "CLR header") is pointed to by <code>IMAGE_DIRECTORY_ENTRY_COMHEADER</code> (the entry was previously used for [[COM+]] metadata in COM+ applications, hence the name{{cn|date=July 2024}}) entry in the PE header's data directory. <code>IMAGE_COR20_HEADER</code> strongly resembles PE's optional header, essentially playing its role for the CLR loader.<ref name="PE Format (Windows)"/>

The CLR-related data, including the root structure itself, is typically contained in the common code section, <code>.text</code>. It is composed of a few directories: metadata, embedded resources, strong names and a few for native-code interoperability. Metadata directory is a set of tables that list all the distinct .NET entities in the assembly, including types, methods, fields, constants, events, as well as references between them and to other assemblies.

==Use on other operating systems==
The PE format is also used by [[ReactOS]], an open-source operating system created to be binary-compatible with Windows. Historically, it has also been used by other operating systems such as [[SkyOS]] and [[BeOS]] R3. However, both SkyOS and BeOS eventually moved to [[Executable and Linkable Format|ELF]].{{citation needed|date=March 2021}}

The [[Mono (software)|Mono development platform]], which aims to be binary compatible with the Microsoft [[.NET Framework]], uses the same PE format as the Microsoft implementation. The same goes for Microsoft's own cross-platform [[.NET Core]].

On [[x86]](-64) [[Unix-like]] operating systems, Windows binaries (in PE format) can be executed using [[Wine (software)|Wine]]. The [[HX DOS Extender]] also uses the PE format for native DOS 32-bit binaries, and can execute some Windows binaries in DOS, thus acting like an equivalent of Wine for DOS.

[[Mac OS X 10.5]] has the ability to load and parse PE files, although it does not maintain binary compatibility with Windows.<ref name="chartier">{{cite web|last=Chartier |first=David |title=Uncovered: Evidence that Mac OS X could run Windows apps soon |work=Ars Technica |url=https://arstechnica.com/journals/apple.ars/2007/11/30/uncovered-evidence-that-mac-os-x-could-run-windows-apps-soon |date=2007-11-30 |access-date=2007-12-03 |quote=... Steven Edwards describes the discovery that Leopard apparently contains an undocumented loader for Portable Executables, a type of file used in 32-bit and 64-bit versions of Windows. More poking around revealed that Leopard's own loader tries to find Windows DLL files when attempting to load a Windows binary. }}</ref>

[[UEFI]] and EFI firmware use PE files as well as the Windows [[Application Binary Interface|ABI]] x64 [[calling convention]] for [[UEFI#Applications|applications]].

==See also==
* [[a.out]]
* [[Comparison of executable file formats]]
* [[Executable compression]]
* [[ar (Unix)]] since all COFF libraries use that same format
* [[Application virtualization]]

==References==
{{reflist}}

== External links ==

* [https://docs.microsoft.com/en-us/windows/desktop/Debug/pe-format PE Format] (latest online document, changes in time)
* Microsoft Portable Executable and Common Object File Format Specification. [https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff.docx Revision 11.0, Jan 2017]; [https://bytepointer.com/download.php?name=pecoff_v10.docx Revision 10.0, Jun 2016]; [https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v83.docx Revision 8.3, Feb 2013]; [https://web.archive.org/web/20100923032233/http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v8.docx Revision 8.2, Sep 2010]; [https://web.archive.org/web/20081211013825/http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v8.docx Revision 8.1, Feb 2008]; [https://web.archive.org/web/20060706172855/http://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/pecoff_v8.doc Revision 8.0, May 2006]; [https://web.archive.org/web/20030724131335/http://www.microsoft.com/whdc/hwdev/download/hardware/pecoff.doc Revision 6.0, Feb 1999]; [https://bytepointer.com/resources/pecoff_v5.0.htm Revision 5.0, Oct 1997]; [https://bytepointer.com/resources/pecoff_v4.1.htm Revision 4.1, Aug 1994]; [https://bytepointer.com/resources/pecoff_v4.0.htm Revision 4.0, Sep 1993]
* [https://openwatcom.org/ftp/devel/docs/pe_and_symbols.pdf Tool Interface Standard (TIS) Formats Specifications for Windows Version 1.0] (Intel Order Number 241597, TIS Committee, Feb 1993)
* [https://bytepointer.com/resources/oleary_pe_format.htm Portable Executable Format] (Micheal J. O'Leary, Microsoft Developer Support)
* [https://web.archive.org/web/20080907145154/http://msdn.microsoft.com/en-us/magazine/ms809762.aspx Peering Inside the PE: A Tour of the Win32 Portable Executable File Format]. [[Matt Pietrek]], Microsoft Systems Journal, March 1994
* An In-Depth Look into the Win32 Portable Executable File Format. [[Matt Pietrek]], [[MSDN]] Magazine. [https://web.archive.org/web/20021105233944/http://msdn.microsoft.com/msdnmag/issues/02/02/PE/default.aspx Part I, February 2002]; [https://web.archive.org/web/20021105025618/http://msdn.microsoft.com/msdnmag/issues/02/03/PE2/default.aspx Part II, March 2002]
* [https://archive.today/20130130042959/http://www.ntcore.com/files/dotnetformat.htm The .NET File Format by Daniel Pistelli]
* [http://blog.dkbza.org/ Ero Carrera's blog describing the PE header and how to walk through]
* [http://www.andreybazhan.com/pe-internals/ PE Internals provides an easy way to learn the Portable Executable File Format]
* [http://www.pe-explorer.com/ PE Explorer]

{{Executables}}

[[Category:Executable file formats]]
[[Category:Windows administration]]