| Packet Parsing Tool Summary | |
| Tool | What It Reads | File Byte Order Handling | Network (On‑the‑Wire) Byte Order | Host Byte Order Conversion | Mixed‑Endian .pcapng | Practical Rule of Thumb | One‑Line Summary | What It Does with These Bytes |
| hexdump | Raw bytes (-C); other formats can interpret numbers. | Does not interpret file structure | Does not interpret protocols | Numeric modes use host order | Not supported | Use when you want to see the exact bytes exactly as stored | Raw byte viewer with zero understanding of packet or file structure | Just show these raw bytes. You must know what they mean. Nothing is parsed. |
| xxd | Raw bytes + ASCII; -e changes word display. | Does not interpret file structure | Does not interpret protocols | -g groups; -e reverses words | Not supported | Use for quick visual inspection of headers or magic numbers | Hex + ASCII display of bytes with no protocol awareness | Just show these raw bytes. You must know what they mean. Nothing is parsed. |
| od | Raw bytes (-t x1) or numeric values. | Does not interpret file structure | Does not interpret protocols | Host order; GNU --endian overrides | Not supported | Use when you want grouped numeric views of bytes | Byte dump tool that formats values but does not understand meaning | Just show these raw bytes. You must know what they mean. Nothing is parsed. |
| tcpdump | Parsed packets | libpcap reads PCAP and a PCAPNG subset | Decodes fields by their protocol | Converts values for display | libpcap limits | Use for fast human‑readable packet inspection | Packet parser; file support depends on libpcap | Reads supported PCAPNG files. Changing section byte order and some other features may be rejected; retain errors. |
| dumpcap | Capture engine only | Writes correct byte order into files | Captures bytes provided by the capture path | Not applicable (no display) | Writes; no offline parsing | Use only to capture packets, not to interpret them | High‑performance packet capture tool with no dissection | Writes captures; inspect the output header for byte order. Does not dissect an existing capture. |
| tshark | Dissects supported packets | Reads file and section byte order | Decodes fields by their protocol | Converts values for display | Supported; verify version | Use for dissection; retain version, settings and warnings | Full Wireshark dissector engine in command‑line form | Reads each section byte order and supported blocks. Decoding depends on file features, dissectors and available data. |
| pktmon
Windows | pktmon reads its own internal .etl capture logs (binary Event Tracing for Windows format). | Inspect the converted PCAPNG section header to establish byte order; do not infer it from the analysis computer. | Captures at Windows stack components; bytes can differ from wire traffic because of offload, truncation and capture location. Live text example: pktmon start --capture --log-mode real-time | Conversion encodes PCAPNG fields; protocol bytes retain their own field conventions. | Format supports per-section byte order; reader support varies. | For Pktmon ETL: pktmon etl2pcap capture.etl --out output.pcapng. For this NDIS ETL, use Microsoft etl2pcapng.exe. Keep the original and conversion log. | ETL-to-PCAPNG creates a derivative. Match the converter to the provider and verify packet counts, times and warnings. | Keep the ETL and hash both files. A conversion is not proof that all event context or packets survived. Do not interpret zero output as an empty ETL without checking provider support. |
| What It Reads | The Mental Model That Usually Clicks | Clarifying Byte Order Concepts |
| Byte modes show stored bytes; numeric modes interpret them. | Byte order is defined per protocol field. | 1. Byte order on the wire (Network Byte Order) | |
| Parsed packets → the tool understands file format and protocols. | Capture files may be big‑ or little‑endian. | | Many fields are big-endian; SMB2 uses little-endian. |
| | | Check the format; do not infer it from the CPU. | | Examples: IP headers, TCP ports, DNS IDs are big-endian in the packet regardless of OS. |
| File Byte Order Handling | | Parsing tools sit in the middle and translate. | | | | |
| Refers to how .pcap or .pcapng metadata is read. | hexdump / xxd / od: bytes or numeric views | 2. Byte order in the file (PCAP/PCAPNG) | |
| Affects timestamps, lengths, headers in the capture file; not packet payloads. | tcpdump / tshark → show meaning | | Affects how the pcap file format itself is parsed, such as: |
| | | dumpcap → only records, never explains | | | Packet timestamp | |
| Network (On‑the‑Wire) Byte Order | Trace = http-google101.pcapng | | | Captured length | |
| IP/TCP fields are big-endian; this is not universal. | xxd or hexdump | | | Interface metadata | |
| Parsing tools interpret fields accordingly. | xxd -g 1 -s 62840 -l 64 http-google101.pcapng | | Defined in magic numbers or section headers: | |
| | | -g 1 : group by 1 byte | | | | .pcap: entire file has one byte order |
| Host Byte Order Conversion | | -s 62840 : first EPB in this exact capture | | | .pcapng: each section declares its own byte order |
| Tools convert values so they make sense on your CPU (usually little‑endian). | -l 64 : show 64 bytes (lowercase L) | | | | | |
| This is why port numbers, lengths, and IDs appear “correct” when printed. | hexdump -C -n 64 -s 62840 http-google101.pcapng | 3. Host/CPU byte order (Little vs Big endian) | |
| | | tcpdump -nn -r http-google101.pcapng | | CPU byte order affects native numeric interpretation |
| Mixed‑Endian .pcapng | | PCAPNG support depends on libpcap and file features. | | Decode using the byte order declared by the format |
| TShark supports mixed sections; validate your reader/version. | tcpdump -nn -vvv -XX -r file.pcap | | | | |
| | | tshark -n -r http-google101.pcapng -V | | | | |
| | | | | | | | |
| Byte ordering is one of those things that's trivial to state and surprisingly easy to get wrong in practice. |
| 1. Little-endian — Least Significant Byte (LSB) first. Common on x86/x64; determine capture byte order from its headers. | | |
| 2. Big-endian — Most Significant Byte (MSB) first. Used by IP/TCP numeric fields; other protocols may differ. | | | |
| 3. Split-word 64-bit — A 64-bit value represented as two sequential 32-bit halves: | | | Field width | Not CPU architecture | |
| High word at the lower file address, low word at the higher address. | | | 32 bit = 4 bytes | Example: EPB Interface ID |
| Each half is independently byte-ordered according to the file's native endianness. | | 64 bit = 8 bytes | Example: ordinary 64-bit counter |
| The sequence of the halves is structural — fixed by the format specification, not by byte-order encoding. | Split-word 64-bit | 64-bit (8-byte) value is divided into two 32-bit (4-byte) words |
| In little-endian sections, this differs from an ordinary 64-bit integer; in big-endian sections, the bytes coincide. | Use the field definition, not CPU word size. |
| EPB timestamps use split words; dropped-packet counters use ordinary unsigned 64-bit values. | | | | |
| The FOUR Contexts — this is where it gets operationally important. | !!!!! WARNING !!!!! |
| A PCAP file contains multiple byte-order conventions operating simultaneously.
Most analysts conflate them, and that's where errors creep in. | EPB timestamps use two 32-bit words: high, then low.
Other 64-bit fields can be ordinary integers. |
| Context 1 — Decode capture metadata using its declared file or section byte order. | The EPB timestamp PCAPNG spec defines it as two fields laid out in the file in this order: |
| PCAP magic bytes: d4 c3 b2 a1 = little-endian microseconds; a1 b2 c3 d4 = big-endian microseconds. | Timestamp (High) — 4 bytes, upper 32 bits | |
| Nanosecond PCAP: 4d 3c b2 a1 = little-endian; a1 b2 3c 4d = big-endian. | | Timestamp (Low) — 4 bytes, lower 32 bits | |
| PCAPNG: 0a 0d 0d 0a identifies SHB. BOM at SHB +8: 4d 3c 2b 1a = little; 1a 2b 3c 4d = big. | Each half uses its section byte order, independent of the reading computer. |
| Use each field width: versions and IDB link type are 16-bit; EPB Interface ID and lengths are 32-bit. | But the relationship between the two halves is fixed by the spec — high word first, low word second. |
| GNU od: specify --endian=little or --endian=big when decoding multi-byte values. | That ordering is not byte-order encoding. It's structural. |
| Context 2 — Packet data contains captured bytes for the declared link type. | | EPB timestamps are 64-bit ticks; use the interface resolution and offset. |
| Decode each protocol field by its specification; SMB2 is a little-endian counterexample. | | You must reconstruct before converting. | |
| EtherType, IP Total Length, TCP/UDP port numbers, sequence numbers, window size — all big-endian. | Read the field definition: split timestamp words and ordinary 64-bit counters differ. |
| The container retains captured bytes; capture location, offload and truncation can affect what was recorded. | Decode high and low in section order; ticks = (high << 32) | low. |
| Context 3 — Your host's native byte order is what raw dump tools use when they interpret multi-byte values as integers. | Do not decode a little-endian EPB timestamp as one ordinary uint64. |
| On x86, that's little-endian. | | | If you want timestamps parsed automatically: | |
| This is the lens through which hexdump -e and od -t u2 / -t u4 / -t u8 read data. | | tshark -n -r file.pcapng -T fields -e frame.time_epoch |
| Context 4 — PCAPNG split-word 64-bit fields. Enhanced Packet Block | | | Epoch seconds where present. Simple Packet Blocks have no timestamp. |
| The Enhanced Packet Block (EPB) timestamp is two 32-bit halves written sequentially: | IF you MUST….. | | |
| Timestamp (High) at the lower offset, Timestamp (Low) at the higher offset. | | To manually extract and decode from hex, use: | |
| Decode each half with the section byte order (GNU od --endian=... -t u4), then combine. | | xxd -g 1 -s 84 -l 8 PacketParsing.pcapng | |
| A split timestamp is not an ordinary little-endian uint64. | | This file: | high=244847; low=2919940207; ticks=1051612777463919; UTC=2003-04-29T10:39:37.463919Z |
| A little-endian uint64 read places the stored high word in the low 32 bits, and vice versa. | Legacy PCAP timestamps do not have this problem. | |
| In a big-endian section, an ordinary uint64 read gives the same numeric value for these bytes. | They are two independent 32-bit fields with separate meanings |
| The error from swapping words depends on the values; there is no fixed error factor. | ts_sec plus a microsecond or nanosecond fraction, selected by PCAP magic. |
| For a general decoder, read two uint32 values in section order and combine high before low. | ts_sec alone omits the fractional part of the recorded time. |
| | | | | EPB: combine ticks, apply interface units/offset. PCAP: seconds plus fraction. |
