Headers & Sections¶

flowchart LR
    DOS[DOS header<br/>MZ, e_lfanew] --> Stub[DOS stub<br/>+ Rich header] --> NT[NT signature<br/>PE\0\0] --> FH[File header] --> OH[Optional header] --> DD[16 data<br/>directories] --> SH[Section table] --> Data[Section data…] --> Ov[Overlay]

DOS header¶

The first 64 bytes of the file. Only two fields matter to modern loaders: e_magic (5A4D, "MZ") and e_lfanew, the file offset of the NT headers. Unusual e_lfanew values and data hidden in the DOS stub are common tricks in crafted files.

ppee-cli --headers f.exe | grep -E 'e_magic|e_lfanew'

File header¶

In the GUI, Machine and Characteristics have flag pickers.

Optional header¶

Hardening flags¶

OptionalHeader.DllCharacteristics bits:

In the GUI, DllCharacteristics expands into the flags that are set. This NativeAOT ransomware (d1337711….exe) has ASLR, high-entropy VA and DEP, but not GUARD_CF. Its CheckSum is 0 and shown in the error color, with the correct value in Comment.

Check them from a script with the jq helpers, or enforce them in CI with a policy gate.

Data directories¶

The 16 DataDirectory[i] entries (RVA + size) point to the structures described on the other feature pages:

Section headers¶

Each section has a name, virtual address and size, raw pointer and size, and Characteristics:

.text is typically 60000020 (code, RX). Warning signs: a section that is both writable and executable (E00000xx), raw size 0 with a large virtual size (unpacked at run time), or non-standard names (UPX0, .vmp0). The navigator strip flags these visually.

A UPX-packed ransomware dropper (77549422….exe) shows all three signs at once. UPX0 takes 72.7 % of the image in memory but 0 bytes in the file (RawSize 00000000, marked), so it is filled at run time. Its Characteristics decode to Executable, Readable and Writeable, and the non-standard names are in the warning color. The Ratio bars compare each section's share of memory with its share of the file.

Long names: /4, /29, …¶

A section name has 8 bytes. A longer one (MinGW, Go and Rust GNU builds keep their DWARF sections, .debug_info, .debug_line, …) is stored in the COFF string table, and the header holds / and its offset there: /29. PPEE shows the real name everywhere a section is named (the GUI, --sections as /29 (.debug_info), sectionName in strings, and every MCP tool, with the header's own text as rawName in triage_pe). Both forms work where a section is asked for by name: section:.debug_info or section:/29 in decode_bytes and hash_range, and file.dll#section:.debug_info as a layer.

List section names:

ppee-cli --json --sections f.exe | jq -r '.sections | to_entries[] | select(.key|endswith(".Name")) | .value'

For a long name, --json adds Section[i].LongName next to Section[i].Name ("/29" and ".debug_info").

Related CLI: --headers · --dirs · --sections · --set

References¶

• Microsoft PE format specification: the official definition of every header field described here.
• Microsoft PE format specification, section flags: the meaning of each section characteristic bit.
• Microsoft PE format specification, DLL characteristics: the ASLR, DEP, CFG and other security flags in the optional header.