24 February 2026

A 142-byte Data Link Protocol with fragmentation support

The signal captures used for this post were recorded a few days ago on 6369.0 kHz (USB) and kindly provided by my friend Kosmod; below is my analysis, which took inspiration from some observations just shared by Kosmod.

Notes:
* the following analysis remains provisional and subject to further revision;
* field designations are my own and are used for clarity and convenience of presentation;
* unless otherwise specified, all values enclosed in square brackets are in hexadecimal format.

HF Waveform Analysis
Despite the spectral appearance of the signals (Figure 1), the transmissions do not appear to be ARQ-based, as no return acknowledgments (ACKs) were observed in the demodulated bitstreams. This is further supported by the consistent fading profiles observed, which indicate that both short and long bursts likely share the same transmission path and originate from the same station. It is likely that this is a strictly unidirectional protocol. Physical layer employes MS-110A waveform, captures include various data rates (300, 600, 1200, and 2400 bps), all employing a Short Interleaver. 

Fig. 1 - part of 6369.0 KHz recordings

MS-110A demodulation of the bursts clearly indicates the use of the 8N1 asynchronous format, as shown in Figure 2.

Fig. 2 - 8N1 framing format in a demodulated bitstream

Protocol Headers Analysis
Following the removal of start/stop bits, the bitstreams are characterized by fixed-length frames with a 9-byte headers, all beginning with the same 16-bit ynchronization (SYNC) word 0xD000, likely with the least significant bit (LSB) transmitted first. Based on the observed bitstreams, byte following the SYNC (i.e., the 3rd byte) is interpreted as a Length Field for a total frame size of 142 bytes: the value 0x8C (140 decimal) representing the remaining payload (142 total bytes minus the 2 initial SYNC bytes). The reduced values in this byte, e.g. 0x6A, 0x68, 0x81, indicate a fragmented payload, typically occurring when the transmitted data does not fully occupy a standard "block". In these cases, the length field allows the receiver to correctly identify the end of valid data and ignore any subsequent padding.
Header alignment is achieved by locking the bitstream to the SYNC sequence and a 142 bytes (1136 bits) frame length, as illustrated by the HEX dumps in Figures 3a and 3b.

Fig. 3a - HEX dump of demodulated bitstreams

Fig. 3b - HEX dump of demodulated bitstreams

Note that, following the 9-byte header, the initial packet (index 0x00), and occasionally subsequent ones, begin with the fixed sequence [00 AA 79 50 D1 00 00 E9 00], which likely represents static payload values or a secondary synchronization pattern.

The proposed frame header structure is shown in the following Table I; it details the byte-level organization of the headers, assuming a Little-endian (LSB first) convention for multi-byte fields:

Table I - proposed frame header structure

The protocol utilizes a nested counting structure. Byte 5 functions as a Logical Block index, while Byte 4 acts as a Fragment index. Notably, every time Byte 5 increments, Byte 4 resets to its base value 0xD1. This behavior confirms that Byte 4 is not a global counter, but a local sequence identifier used to order individual fragments within each specific logical block.
The analysis of the Fragment ID field (Byte 4) suggests that the counter is limited to the lower nibble. The constant high-nibble value of 0xD (1101​) likely serves as a system flag, while the lower nibble provides the effective fragment index (0000 - 1111). This bitfield bifurcation explains why the byte appears to start at 0xD1 rather than 0x01. The lower-nibble implementation constrains the fragment index to a maximum value of 0xF​ (15 decimal).
The reset interval for the Logical Block index (e.g., per session, per 24-hour cycle, or per transmission burst) remains to be determined pending further signal acquisition.

SAR (Segmentation and Reassembly) Analysis
To ascertain the field functions and the underlying fragmentation hierarchy, an assessment of the headers from multiple consecutive bursts is required (see Figure 4). 

Fig. 4 - HEX dumps of multiple consecutive bursts for block 0x74

Burst #1
[D0 00 8C D1 74 04 00 00 00]
[D0 00 8C D1 74 04 00 01 00]
[D0 00 8C D1 74 04 00 02 00]
[D0 00 81 D1 74 04 00 03 00]
Burst #2
[D0 00 0C D2 74 04 00 03 00]
Burst #3
[D0 00 0D D3 74 04 00 04 00]
Burst #4
[D0 00 0D D4 74 04 00 04 00]
[D0 00 0D D4 74 04 00 04 00] 

 1    2   3    4   5   6  7   8   9 <----- bytes 

a) It is highly probable that the 0xD0 byte within the synchronization word serves a dual purpose: providing physical layer alignment while simultaneously acting as a Start-of-Frame (SoF) marker for the first fragment. Under this model, the 0xD0 marker initiates the block transmission, with all subsequent fragments identified by the sequence in Byte 04 (0xD1,0xD2,0xD3, etc.).

b)The block size field (bytes 6–7) utilizes a Little-Endian (LSB first) unsigned integer format. A value of 0x0400 indicates a 0-indexed count, confirming a total of five packets (00 through 04) within the sequence. 

c) The Packet Index field (bytes 8–9) also utilizes a Little-Endian (LSB first) unsigned integer format, indicating the relative position of the packet within the current logical block.

d) Evidence of cross-burst fragmentation is found in packet 0x03:
- Burst #1: packet 0x03 was captured with a truncated payload length of 0x81 (129 decimal);
- Burst #2: the remainder of packet 0x03 was transmitted with a payload size of 0x0C (12 decimal).

e) The aggregate length (129+12=141 bytes) slightly exceeds the standard 140-byte frame payload capacity. This discrepancy suggests that packet 0x03 was too large for a single transport frame and was intentionally fragmented across two consecutive physical bursts, indexed as fragment IDs 0xD1 and 0xD2 respectively.

f) The fact that packet 0x04 is so small, 0x0D bytes in bursts 3-4, compared to the others 0x8C bytes, is sent last and is spread across two different fragments (and bursts) suggests it is a trailer or checksum packet for the entire block.

Sumarizing:
Burst #1, Logical Block 0x74 Fragment ID 0xD1: occupied by packets 00, 01, 02, and the first part of 0x03
Burst #2, Logical Block 0x74 Fragment ID 0xD2: reserved exclusively to finish the "overflow" of packet 0x03
Burst #3 & #4, Logical Block 0x74 Fragment IDs 0xD3 & 0xD4: dedicated to packet 4

The relationship between the different layers of the protocol is shown in Figure 5 (elements are not to scale). The diagram shows the decomposition of logical block 0x74 into its constituent fragments (0xD1–0xD4) and the subsequent packets (00–04). Note the one-to-one mapping between logical fragments and physical bursts.

Fig. 5 - different layers of the protocol, the diagram is conceptual and not to scale

The diagram shown  in Figure 6 illustrates the SAR (Segmentation And Reassembly) process, i.e., the relationship between the physical burst transmission and the logical packet reassembly, highlighting cases of fragmentation and sequence continuity (all values are in Hex).

Fig. 6 - Segmentation And Reassembly process of block 0x74 (5 packets)

Consistent results are achieved through the analysis of other bursts, such as those associated with the transmission of block 0x76 (Figs. 7,8).

Fig. 7 - HEX dumps of multiple consecutive bursts for block 0x76

Fig. 8 - Segmentation And Reassembly process of block 0x76 (9 packets)

Conclusions
This is highly likely a (unid) proprietary protocol; unfortunately, at the time of writing, there are no available hypotheses regarding the transmitter site, nor the potential end-user. The protocol employs non-uniform fragmentation, where the payload size per burst is inconsistent; packet captures indicate potential truncation or the presence of trailing zero-fill sequences to maintain frame alignment. The architecture utilizes a 142-byte fixed frame with a 9-byte header to manage data encapsulation. The data stream is structured into logical blocks, mapped to individual packets, and transported via physical bursts, a process orchestrated by the Block ID ➔ Fragment ID ➔ Packet Index hierarchy.
However, based on the recordings at my disposal, the protocol does not always follow a strictly linear progression as the one shown by the diagram above. In some instances, the data flow incorporates non-linear repetitions or sequence adjustments, although the reassembly process itself does not change, e.g.:
- packet re-injection: high-index packets are interrupted by the re-insertion of earlier packets;
- fragment reversion: the sequence occasionally "rewinds" to repeat the final fragments of a previous packet before continuing with the current one.
These events can manifest either as a direct repetition of previously transmitted data or as a continuation of a previous packet's fragment sequence. 

Technical Comparisons and Alignment With Standards
- STANAG-4538 parallels: the architectural choices of this protocol, specifically the SAR mechanism and burst-oriented delivery, show significant functional parallels with the xDL protocols described by STANAG-4538. However, unlike the ARQ-based nature of xDL protocols, based on the captures at my disposal this protocol operates in a purely unidirectional mode, prioritizing redundancy over acknowledgments (1).
- STANAG-5066 & MS-110A correlation: the observed strategy also aligns closely with STANAG-5066 architectural principles. Similar to how STANAG-5066 segments data for transmission over MIL-STD-188-110A (MS-110A) modems, this protocol maps logical fragments directly to physical bursts. This is particularly evident in its configuration, where the absence of a return channel mirrors the high-reliability tactical stacks used in HF communications to ensure data persistence through noise (2).

Coming Up
While the proposed structure provides a good framework for understanding the protocol's behavior, additional captures are required to better define it. However, to avoid overcomplicating this discussion, detailed analyses of non-linear SAR and reassembled packets/blocks will be addressed in a forthcoming dedicated post.

As a side note, a special mention to Kosmod who is a great signals hunter... and a good provider :)

https://disk.yandex.com/d/TfhM9dfTb-ECww

(1) STANAG-4538 (3G), defined as an "all-in-one" monolithic protocol, integrates link setup (FLSU) and data transport (xDL) within a single ecosystem, utilizing its own proprietary waveforms specifically optimized for symbiotic operation between the modem and the data link layer.

(2) STANAG-5066 (2G) operates as a layered Data Link protocol. It serves as an interface between applications and the physical layer. Unlike STANAG-4538, it does not possess a dedicated waveform family; instead, it leverages standard external waveforms such as MIL-STD-188-110 (A/B/C/D) or STANAG-4539 to "feed" the underlying physical modem.

No comments:

Post a Comment