Walk me through the Windows PE file format and what parts you inspect when triaging a sample.
Short answer
A PE file starts with the DOS header and its e_lfanew pointer to the PE/NT headers, which hold the File Header and Optional Header (entry point, image base, subsystem). It is divided into sections — .text for code, .data, .rdata, .rsrc for resources — each with a virtual address and raw size. During triage you read the import table for suspicious APIs, the section table for odd names and high entropy that hint at packing, the timestamp and rich header, embedded resources, and any digital signature. Mismatches between these tell you a lot before you ever run the file.
The Portable Executable (PE) format is the container Windows uses for .exe, .dll, and .sys files. Interviewers ask about it because most Windows malware ships as a PE, and a fluent analyst can read a sample's intent straight from its structure before running anything.
The structure
Every PE opens with the legacy DOS header (the MZ magic and the "This program cannot be run in DOS mode" stub). Its e_lfanew field points to the PE/NT headers: the File Header (machine type, number of sections, timestamp) and the Optional Header (the entry point, image base, subsystem, and the data directories that locate the import and export tables, resources, and relocations). After the headers comes the section table — typically .text (code), .data and .rdata (data and read-only data), .rsrc (resources like icons and embedded payloads), and .reloc.
What to inspect and why
- Import table. Which DLLs and APIs the binary links against is the clearest capability hint.
VirtualAlloc+WriteProcessMemory+CreateRemoteThreadscreams process injection;InternetOpen/WinHttpConnectmeans network;CryptEncryptsuggests ransomware. A near-empty import table with onlyLoadLibrary/GetProcAddressimplies dynamic API resolution to hide intent. - Sections. Odd names (
.UPX0, random strings), a section that is writable and executable, or a raw size of zero with a large virtual size all suggest a packer. High entropy (close to 8.0) flags compression or encryption — a strong packing indicator, though legitimate compressed resources also score high. - Resources, timestamp, rich header, signature. Embedded executables in
.rsrc, a faked or zeroed timestamp, an inconsistent rich header, or a missing/invalid Authenticode signature each add weight.
The best answers connect a field to the conclusion it supports rather than just listing header names.
Likely follow-ups
- What does an import table dominated by GetProcAddress and LoadLibrary suggest?
- Why is high section entropy a red flag, and what is its limitation as a signal?
- What can the rich header or compile timestamp tell you about a sample?