Compression Is the Detector: How ByteFlow Spots Malware Without Parsing a Single Protocol

ByteFlow reads raw PCAP flow bytes and scores anomalies by how hard they are to compress, with no protocol parser in the loop.

ByteFlow doesn’t parse HTTP headers, decode DNS records, or reassemble TLS handshakes. It reads raw PCAP flow bytes and predicts the next one. The prediction error, measured in bits-per-byte, is the entire detector.

The idea: a model trained only on benign traffic learns to compress it well. Malicious traffic looks different at the byte level, so the model is worse at predicting it, and worse prediction means more bits spent per byte. No labels are needed at inference time, no signature database, no protocol grammar to maintain as new versions ship.

On the step-75k checkpoint, benign flows score 0.34 mean BPB (0.23 median). Botnet traffic from CTU-13 scores 5.07 mean. Red-team malware captures score 4.92 mean. A threshold of 2.0 BPB separates the two distributions with almost no overlap: benign p95 sits at 1.01, botnet p25 sits at 3.37. That’s a 4.73 BPB gap between the benign mean and the botnet mean.

Getting a transformer to run over raw bytes at a useful context length is the hard part, since byte sequences are long and full attention over every position is wasteful. ByteFlow’s answer is a five-stage pipeline. A LocalEncoder with sliding-window attention embeds each of 2048 input bytes. A CodingRateChunker then picks 256 of those positions to promote to global context, using the L2² norm of the local hidden state as a proxy for information density, a idea borrowed from coding rate theory. A GlobalTransformer with full causal attention and RoPE runs only over those 256 selected positions, not all 2048. An Upsampler broadcasts that global context back down to every byte position using per-bin learned projections. A LocalDecoder, again sliding-window, produces the final next-byte logits over a 259-token vocabulary: 256 raw byte values plus BOS/PAD, a direction-flip marker, and a flow separator.

The current model, 143.5M parameters, was trained on 825,686 benign flows, 3.83 GB of PCAP payload. That corpus is badly imbalanced: HTTP and DNS make up 82% of it, while SMB and FTP contribute six flows each. The consequence shows up directly in the scores. DNS and HTTP probes are reliable; HTTP is the strongest signal in the whole system, with a benign median of 0.06 BPB. SMB and FTP scores right now measure protocol unfamiliarity, not maliciousness, because the model has barely seen either one.

A balanced retraining corpus, roughly 500k flows with even protocol representation, is next. Until that lands, treat SMB and FTP BPB numbers as noise and trust DNS, HTTP, and SMTP.

Full paper →