Depacketisation

What Depacketisation Does

Depacketisation reconstructs a continuous payload from discrete network packets so downstream systems can interpret the data as a stream or frame. In practice, it is the step that turns fragmented transport data back into something decoders, parsers, or application logic can consume.

The process depends on packet order, length fields, sequence markers, and format rules that may arrive across multiple packets. That makes depacketisation a boundary-crossing function, because it has to preserve meaning while reassembling bytes that were never designed to be processed one packet at a time.

Why Depacketisation Is Security-Sensitive

Depacketisation is security-sensitive because the reassembly logic must trust packet metadata just enough to reconstruct data, but not so much that malformed input drives incorrect buffer handling. A small mistake in length tracking, boundary checks, or state management can turn ordinary transport data into memory corruption, truncation, or parser confusion.

In media and real-time protocols, depacketisation often sits directly before decoding or application parsing, so errors can propagate quickly into higher layers. That is why attackers may target the stage with oversized lengths, out-of-order fragments, or crafted marker combinations designed to desynchronise the receiver.

Where Depacketisation Breaks Down

Depacketisation fails when the implementation cannot reliably preserve packet sequence, detect missing fragments, or validate that a reconstructed frame still matches the declared format. The most common failure modes are buffer over-read, buffer overflow, integer miscalculation, frame desynchronisation, and acceptance of malformed or partial payloads.

These weaknesses are usually not about the network itself, but about assumptions inside the reassembly logic. If the code treats attacker-influenced metadata as authoritative, the parser may allocate the wrong size, copy too much data, or continue assembling a frame after the stream state is already invalid.

Where It Appears in Media and Streaming Pipelines

Depacketisation is common in RTP, WebRTC, VoIP, video delivery, and similar streaming systems where payloads are split across packets for transport efficiency. The receiver must rebuild audio or video frames fast enough to keep latency low, which leaves little room for expensive validation or recovery logic.

That performance pressure is part of the risk profile. Fast-path code often favors minimal branching and tight memory operations, so defects can survive longer than in slower parsing layers. A robust implementation therefore needs to balance throughput with strict bounds checking and clear state transitions, especially when packet loss or jitter is normal rather than exceptional.

Risk and Threat Considerations

Depacketisation is a common attack surface because it must accept partially trusted transport data and turn it into structured application input. When that reassembly step is weak, crafted packet sequences can trigger memory errors, parser confusion, or denial of service before higher-level security controls ever see the payload.

Failure mechanism: An attacker abuses malformed lengths, fragmented payloads, or unexpected packet ordering to push the reassembly logic outside safe buffer and state limits.

Impact: The result can be crashes, corrupted frames, dropped sessions, or in severe cases code execution in the component performing depacketisation.

Practitioner Guidance

What to watch for: Treat depacketisation code as parser code, not just transport glue. It should enforce strict bounds, reject impossible frame states, and fail closed when sequence or size metadata is inconsistent.

Practitioner takeaway: The safest depacketisation logic is explicit about packet ordering, frame size, and recovery behavior, because ambiguity at this layer becomes a security bug very quickly.