3

For ELF files, there is a field near the start of the ELF header that indicates the endianness of the file:e_ident[EI_DATA]. If an application wants to extract data from the header of a given ELF binary, this field can be used to know whether endianness adjustments are needed for extracted integer values.

Is there an equivalent process for determining the endianness of a given PE file, or is it safe to assume that all PE files will use little endianness for stored integer values?

The majority of PE files encountered will likely be compiled for x86 or x86_64 (and, thus, will use little endianness), but the question arises for PE files built for Windows on ARM / ARM64, since many ARM processors have big endian and little endian modes of operation. Also, this article implies that Windows supports/supported running on other architectures like MIPS as well, which may have supported big endianness also.

Improve this question

1 Answer 1

Reset to default
4

Windows platforms have a fixed endianness and do not support running different endianness files. The file format itself uses always little-endian fields.

AFAIK the only Windows platform supporting big-endian was the Xbox 360 (aka Xenon), which can be identified by the machine value 0x01F2 (not publicly documented but probably defined as IMAGE_FILE_MACHINE_PPCBE in source headers). Such files use little-endian headers but contain big-endian instructions and data.

All other Windows platforms (even earlier MIPS and PowerPC NT versions) only supported little-endian configurations.

In addition, the Windows on ARM aka Windows RT platform (ARMv7, IMAGE_FILE_MACHINE_ARMNT=0x01c4) only officially supports Thumb mode instructions. (earlier Windows CE releases supported classic ARM mode too).

Improve this answer
2
  • 2
    After posting I also found this: Windows on ARM executes in little-endian mode. Both the Visual C++ compiler and the Windows runtime expect little-endian data at all times. Although the SETEND instruction in the ARM instruction set architecture (ISA) allows even user-mode code to change the current endianness, doing so is discouraged because it's dangerous for an application. If an exception is generated in big-endian mode, the behavior is unpredictable and may lead to an application fault in user mode, or a bugcheck in kernel mode.
    – recvfrom
    Apr 7, 2018 at 20:49
  • 1
    About IMAGE_FILE_MACHINE_PPCBE, here's the code of a Microsoft open source project which says it is actually called IMAGE_FILE_MACHINE_POWERPCBE – github.com/microsoft/microsoft-pdb/blob/master/cvdump/…
    – Simon Kissane
    Mar 18 at 7:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.