Turning FortiGate Logs and Hex Dumps Into Packet Evidence

The reality: you rarely get a clean capture

In a textbook, an investigation starts with a well-formed PCAP. In practice, it starts with whatever someone could grab: a FortiGate diagnostic sniffer log, a few lines of hex pasted into a ticket, the output of a command-line capture on a box you can't get a file off. The packet data is in there — it's just wrapped in text a normal analyser won't open.

Throwing that evidence away because it isn't a .pcap is a mistake. Reading it by eye, byte by byte, is a slower mistake. The useful middle path is to normalise the text back into capture data you can investigate properly.

What these text formats actually contain

Most text-based packet evidence falls into a few familiar shapes, and each one is closer to a real capture than it looks:

• FortiGate-style sniffer logs: timestamped packet lines, often with headers and a hex payload, produced by a firewall's built-in capture. It's a capture — just serialised as text.
• Hex dumps: raw bytes rendered as hex (frequently with an ASCII gutter). Whether from a CLI tool, a debugger, or a pasted snippet, those bytes are a frame or a payload.
• Text sniffer output: line-oriented captures from command-line tools, sometimes truncated, sometimes complete, usually copy-pasteable but not directly openable.

Why normalising beats reading hex by eye

You can decode a header by hand. You shouldn't have to. Once text-based evidence is normalised into a packet model, everything you'd normally do becomes available again: filtering, protocol categorisation, following a stream, spotting the anomaly in context. The evidence stops being a wall of characters and becomes something you can navigate.

It also keeps your investigation consistent. If a finding from a firewall log lands in the same packet log, with the same detail view and the same traceability as a finding from a capture file, your report doesn't have a weak seam where the evidence came from text instead of a PCAP.

Practical tips when the source is messy

Text evidence is often incomplete, and pretending otherwise leads to bad conclusions. A few habits keep you honest:

• Preserve timestamps. Timing is frequently the whole story, and it's the first thing lost in a sloppy copy-paste. Keep the original time information wherever the source provides it.
• Watch for truncation. Logs and pastes get cut off mid-frame. Know which packets are complete and which are partial before you reason about payloads.
• Keep the raw text. Normalised evidence should always trace back to the original log or dump, the same way a finding traces back to frames — so anyone can check your work against the source.