16_Formats — the import dialog's list, one page per format¶

Level: 201 · for anyone who has opened a binary in a disassembler

One line: Every format on Ghidra's import list is an agreement about where a reader may find the answers a raw byte stream does not give — what is this, which end comes first, how wide is a field, where does a string end — and the twenty-four disagree about every one of those answers, so the questions this library asks of text are asked here of headers.

Ghidra's File > Import File dialog offers a Format list. This chapter gives each entry a page, in the dialog's own order, and this page takes once what the twenty-four share: a first look at the bytes, the four questions a loader has to answer before it reads anything else, and where each format keeps its answer.

The reference throughout is Ghidra's own source, read at the tag of the build installed on this Mac, Ghidra 12.1.3 ↗, and each page links the loader class it describes. Ghidra's opinion is documentation of a reader, not a measurement of a format: what a page records as checked is what its program built and parsed, and a real file measured on this machine is in a dated fence and says so.

The names, as Ghidra 12.1.3 spells them¶

The list this chapter follows was pasted on 2026-09-13, and four of its names are not the ones in the source any more:

Measured 2026-09-13 — the getName() strings of the 24 loader classes in Ghidra 12.1.3 (brew), read from the tag's source; the jars ship the same class names

list says                                  12.1.3 says
DYLD Shared Cache                          DYLD Cache
Ghidra Data Type Archive File (GDT)        Ghidra Data Type Archive Format
Ghidra Zip File (GZF)                      GZF Input Format
Ghidra Zip Debugger Trace File (GZT)       GZT Input Format
the other twenty                           identical

The pages keep the list's names as their titles, because that is what a reader has in front of them, and say the current name where it differs.

The bytes a loader looks at first¶

Fourteen of the twenty-four announce themselves at offset 0, and most of those announcements are readable words: ELF, dex, Joy!peff, MDMP, dyld_v1. Five keep their signature somewhere else — behind a Java stream header, or wherever a DOS header's e_lfanew points. Five have no signature at all, and are recognised by their filename, by parsing, or — for Raw Binary — by nothing, which is the point of that loader.

Verified output of the_import_list_py.py — regenerated by tools/run_examples.py, never hand-typed.

1. THE BYTES A LOADER LOOKS AT FIRST
------------------------------------------------------------------------
   format               at                   bytes                                            reads as             recognised by

   Android APK          0 (and the last 22)  50 4b 03 04                                      (not text)           ZIP; classes.dex inside
   COFF                 0                    4c 01                                            (not text)           a machine type the table knows
   DEX                  0                    64 65 78 0a 30 33 35 00                          dex\n035\0           magic
   DBG                  0                    44 49                                            DI                   magic
   Dump File Loader     0                    4d 44 4d 50                                      MDMP                 one of four words
   DYLD Shared Cache    0                    64 79 6c 64 5f 76 31 20 78 38 36 5f 36 34 68 00  dyld_v1 x86_64h\0    a 16-byte text field
   ELF                  0                    7f 45 4c 46                                      (not text)           magic
   GDT                  6                    2e 30 21 26 34 e9 2c 20                          (not text)           magic, and the .gdt name
   GZF                  6                    2e 30 21 26 34 e9 2c 20                          (not text)           magic, and the .gzf name
   GZT                  6                    2e 30 21 26 34 e9 2c 20                          (not text)           magic, and the .gzt name
   Intel Hex            0                    3a                                               :                    a regex over the first line
   Java Class File      0                    ca fe ba be                                      (not text)           magic
   Mach-O               0                    cf fa ed fe                                      (not text)           one of four magics, or a fat header
   DEF                  -                                                                     -                    the .def name, and one export
   Motorola Hex         0                    53                                               S                    the same regex as Intel Hex
   NE                   e_lfanew             4e 45                                            NE                   MZ first, then this
   MZ                   0                    4d 5a                                            MZ                   magic, and no NE or PE behind it
   PE                   e_lfanew             50 45 00 00                                      PE\0\0               MZ first, then this
   PEF                  0                    4a 6f 79 21 70 65 66 66                          Joy!peff             two tags
   MAP                  -                                                                     -                    the .map name, and a symbol line
   Raw Binary           -                                                                     -                    nothing: every file qualifies
   OMF                  0                    80                                               (not text)           a THEADR or LHEADR record
   XML Input Format     -                                                                     -                    parses as a PROGRAM element
   SARIF Input Format   -                                                                     -                    parses as SARIF

2. COUNTED
------------------------------------------------------------------------
   formats on the list                     24
   with a signature in the file            19
   ...of which the signature is text        10
   ...of which it sits at offset 0          14
   ...of which it sits somewhere else       5
   with no signature at all                5

   A magic number is a number to the program and a picture to the
   person reading the dump, and most of these were chosen so the
   picture reads as a word. The ELF designers went one better: a
   first byte no text file can start with, then the name.

Read the last column. A magic number is two things at once — a number a program compares, and a picture a person reads in a hex dump — and the formats that chose printable ASCII for theirs chose them so the second reading works. 7f 45 4c 46 is the extreme case: the first byte is deliberately not printable, so no text file can begin that way by accident, and the next three spell the name.

Four questions, and where each format keeps the answer¶

A loader needs four facts before it can read a header, and a raw byte stream states none of them. Chapter 1 asked them of a hex dump; this table asks them of a format.

question	the page where it is asked	stated in a field	implied by the magic	fixed by the specification	left to the reader
which end comes first?	The bytes do not say which end	ELF byte 5, DEX `endian_tag`	Mach-O: the magic reads forwards or backwards	PE, COFF, MZ, NE little; Java, PEF and a fat header big	Raw binary, Intel Hex, Motorola Hex
how wide is a field?	Arithmetic has its own width	ELF byte 4, PE's optional-header magic, OMF's low type bit, Motorola's type letter	Mach-O `feedface` against `feedfacf`	everything else	Raw binary
where does a string end?	The NUL byte	a length byte in NE, OMF and PEF; a 16-bit count in Java and GZF; a ULEB128 in DEX	—	a NUL in ELF, Mach-O, PE and COFF; eight fixed bytes for a section name	a line ending in DEF and MAP
which base are these digits in?	Which base did you mean?	—	—	hex without a prefix in Intel Hex, Motorola Hex and MAP; decimal in COFF's `/4` and XML's `LENGTH`; a JSON number in SARIF	—

The first row is the one to hold onto. Only two formats here say which end comes first; one lets you infer it; most simply decided once, in a document you have to have read; and three make the person importing the file choose from a dropdown — which is the same situation as a text file with no declared encoding, one chapter over.

The same question in Rust¶

The byte order is a value, not a type, in every format on this list — so the program that reads one cannot choose from_le_bytes or from_be_bytes at compile time. It has to read a byte, and then pick.

Verified output of which_end_rs.rs — regenerated by tools/run_examples.py, never hand-typed.

1. ELF: BYTE 5 SAYS WHICH FUNCTION TO CALL
------------------------------------------------------------------------
   LSB, 64-bit  bytes 16..20  02 00 3e 00   byte 5 = 1 -> from_le_bytes
                e_type 2  e_machine 0x3e  header will be 64 bytes
   MSB, 32-bit  bytes 16..20  00 02 00 3e   byte 5 = 2 -> from_be_bytes
                e_type 2  e_machine 0x3e  header will be 52 bytes

   Same two numbers out of two different byte layouts, because the
   file said which layout it used. Read the MSB file as if it were
   LSB and e_type is 512 -- a number, not an error.

2. MACH-O: THE MAGIC'S SPELLING SAYS IT
------------------------------------------------------------------------
   written little-endian    cf fa ed fe   read LE 0xfeedfacf   MH_MAGIC_64  64-bit, same order as this reader
   written big-endian       fe ed fa cf   read LE 0xcffaedfe   MH_CIGAM_64  64-bit, the other order

   Ghidra reads the four bytes little-endian and accepts all four
   values; which one it met is what tells it the file's order.

3. TWO BYTES, TWO NUMBERS
------------------------------------------------------------------------
   4d 5a  'MZ'   little 0x5a4d   big 0x4d5a
   44 49  'DI'   little 0x4944   big 0x4449

   A two-byte text signature is one picture and two numbers, and a
   constant in a program has to be one of them. Ghidra's DOS header
   compares against 0x5a4d; its DBG header keeps both.

4. CAFEBABE: THE NEXT FOUR BYTES SETTLE IT
------------------------------------------------------------------------
   a fat Mach-O, 2 slices     ca fe ba be 00 00 00 02   u32 at 4 = 2    <= 30: a slice count
   a Java class, version 69   ca fe ba be 00 00 00 45   u32 at 4 = 69   > 30: a class file

   Both are big-endian at offset 4, so the reader needs no choice
   here -- only a threshold, which is the one file(1) uses.

The twenty-four¶

In the dialog's order. A page is short where the format is a container for something another page owns, and long where the format itself teaches something about bytes.

#	Lesson	The question it answers	Status
1	Android APK	Why is an APK read from its last 22 bytes, and which code page is a filename in?	written, 2026-09-13
2	COFF	How does a loader recognise a file with no magic number at all?	written, 2026-09-13
3	DEX	What is modified UTF-8, and why does a string's length field count UTF-16 units?	written, 2026-09-13
4	DBG	Why is a two-byte signature two different numbers, and how many byte orders does a GUID have?	written, 2026-09-13
5	Dump file	How does one loader tell four kinds of crash dump apart from four bytes?	written, 2026-09-13
6	DYLD shared cache	Where did the dylib the linker names go, and what does a 16-byte text magic buy?	written, 2026-09-13
7	ELF	How can the same header be 52 or 64 bytes, and who says which?	written, 2026-09-13
8	GDT	What is in a Ghidra data type archive, and why does unzip refuse it?	written, 2026-09-13
9	GZF	What does an exported program look like on disk, and what does writeUTF count?	written, 2026-09-13
10	GZT	How does Ghidra decide a file is one of its own, and what does that check skip?	written, 2026-09-13
11	Intel Hex	How does a 16-bit offset field address a 4 GB image?	written, 2026-09-13
12	Java class file	Why does a class file share its magic with a fat Mach-O, and how does file tell them apart?	written, 2026-09-13
13	Mach-O	Why do the magic bytes read backwards, and why does one file use both byte orders?	written, 2026-09-13
14	DEF	What is a text file doing in a list of binary formats, and in which charset is it read?	written, 2026-09-13
15	Motorola Hex	How does an S-record differ from an Intel HEX record carrying the same bytes?	written, 2026-09-13
16	NE	How does a 16-bit executable fit file offsets into 16-bit fields?	written, 2026-09-13
17	MZ	How big does DOS think a modern .exe is?	written, 2026-09-13
18	PE	Why does a PE have three magics, and which field moves when it goes 64-bit?	written, 2026-09-13
19	PEF	What is a 1904 epoch doing in an executable, and what is pattern-initialised data?	written, 2026-09-13
20	MAP	Which columns of a linker map does the loader read, and in which base?	written, 2026-09-13
21	Raw binary	What has to be typed in when the file says nothing?	written, 2026-09-13
22	OMF	What does a format look like when every string has a length byte and every record checks itself?	written, 2026-09-13
23	XML input	How does Ghidra write a program as text, and where do the bytes go?	written, 2026-09-13
24	SARIF input	What happens to a 64-bit address written as a JSON number?	written, 2026-09-13

Families¶

The dialog's order is alphabetical. These are the groupings a reader will actually want, and the page in each that carries the mechanism:

Three generations of one Microsoft lineage — MZ, then NE and PE, each reached through the previous one's e_lfanew; COFF is the object format PE's header was taken from, and DBG the debug data split off a PE.
Two Unix executables and a cache — ELF, Mach-O, and the DYLD shared cache that swallowed every Mach-O library on a Mac.
Three formats that use modified UTF-8 — the Java class file, DEX, and the writeUTF strings in Ghidra's own GZF, GDT and GZT container.
Two hex-text formats from the 1970s and 80s — Intel Hex and Motorola Hex, which Framing a format already took apart as a frame.
Three text inputs and one that is not a format — DEF, MAP, XML and SARIF carry facts about a program as text; Raw binary carries a program and no facts.
The ones from somewhere else — PEF from classic Mac OS, OMF from the 8086, DEX and the APK around it from Android, and the dump file loader, which reads three Windows formats and one Ubuntu text file.

What Ghidra was not asked¶

Nothing here was run through Ghidra's importer. Every page's programs build a minimal instance of the format and parse it back — a header, a table, a string — and what a page says Ghidra checks is read off the loader's source at the 12.1.3 tag and linked. Two things the pages therefore do not claim: that Ghidra would import the bytes the programs build (a loader wants more than a valid header), and that the loader's opinion is the format's specification. Where the two are known to differ, the page says which is being quoted.

A note on the code¶

Every page has one Python program, standard library only, and no program reads a file from the disk: the bytes are built in memory, so the answer key is the same on every machine. A real file measured on this Mac or under Docker is in a dated fence on the page, never in a key, because its bytes belong to the machine that has it.