From a CTF solver to a traffic analysis workbench
FlowSage started from a very practical CTF problem: the answer is usually in the capture, but getting to it means manually correlating sessions, decoding payloads, reconstructing application-layer behavior, and testing one scattered hypothesis after another. I wanted to fold that repetitive work into a single coherent workflow instead of assembling a pile of scripts every time.
Across versions it grew from flag extraction into protocol analysis for network investigations, security research, and traffic forensics: common enterprise protocols, industrial control traffic, Bluetooth and USB data, CAN, streaming media, and command-and-control traffic.
One engine, two ways to work
FlowSage ships both a command-line build for scripting and batch processing, and a desktop GUI for interactive investigation. Both entry points share the same Go analysis engine.
flowchart TB
CLI["CLI / automation and batching"] --> CORE["Shared Go analysis engine"]
GUI["Desktop GUI / interactive analysis"] --> CORE
CORE --> PROTO["Protocol-aware analysis"]
CORE --> ARTIFACTS["Findings and extracted artifacts"]
The GUI is built with Vue 3, TypeScript, Vite, and Wails v2. It supports file history, batch import, categorized results, session inspection, request and response views, a hex viewer, and JSON export, and it can import PCAP and JSON directly. The CLI targets automation scripts, batch jobs, and server environments; my own usual path is to export dissections from Wireshark as JSON and hand that to FlowSage. Platform support differs between the two: the GUI covers Windows 10/11 (x64/ARM64), while the CLI covers Windows, Linux, and macOS (x64/ARM64).
Analysis across very different traffic
FlowSage pairs broad protocol coverage with task-specific analyzers. CTF scenarios include flag extraction, SQL injection traffic reconstruction, USB keyboard and mouse data recovery, and Telnet session rebuilding. Later versions added industrial protocols such as Modbus and Siemens S7, Kerberos analysis, WebShell traffic decoding, RTSP/RTMP streaming analysis, CAN traffic inspection, and Cobalt Strike Beacon analysis.
v3.6.0 ships 38 protocol analyzers and an expanded CMS fingerprinting engine. That number is the analyzer list for that release; real coverage still depends on the build and the samples in front of you — protocol implementations have edges, and I won’t claim that any sample parses cleanly.
Engineering problems
- Rebuild before explaining. Session reconstruction is keyed on TCP sequence numbers and handles segmentation and out-of-order delivery. Useful analysis usually depends on stitching application-layer exchanges back together from packet fragments; field parsing comes later.
- Handle protocol heterogeneity. One workflow has to face HTTP, DNS, industrial protocols, and device protocols — data models with almost nothing in common. Get the abstraction wrong and everything after it turns into patches.
- Extract information around the task. The goal is not tidy field parsing, but recovering the artifacts and behaviors that answer an analyst’s actual question. File extraction, repair of corrupted data, and encoding detection all serve that.
- Support more than one interaction model. A shared engine lets automation and interactive investigation reuse the same capability, instead of maintaining two implementations that slowly drift apart.