a WireGuard-like VPN Protocol Adaptation over HF

Disclaimer: The following analysis is based on empirical observation of HF traffic and does not represent an official specification. The identification of protocol messages and roles is a technical hypothesis intended for research purposes.

This post examines what appears to be a custom HF adaptation of the WireGuard VPN protocol [1], a streamlined UDP-native protocol designed for high-performance secure tunneling. While the examined protocol shares characteristics with both MESH and VPN architectures, I have opted for the latter definition. This is because an HF implementation of a mesh protocol is better suited for tactical (field-deployed) theaters rather than the consolidated, fixed-site network observed in this case.

I have used the term "WireGuard-like" in the title because the observed packet structures diverge from standard specifications; nevertheless, protocol-specific signatures suggest a proprietary implementation tailored for transmission over HF links. For convenience, the term "WireGuard" (WG) will be used hereafter to refer to this specific implementation, its framing characteristics, and the field designations identified here.
This analysis also serves as a continuation of the work initiated in [2] [3]; readers are encouraged to refer to those previous posts for background on the operational scenario.

As established in the aforementioned posts, the bulk of the previous captures consists of intermittent 2G-ALE (MS-141A) handshakes between Node 101 (caller) and Node 102 (called). Sometimes handshakes are followed by short MS-110A bursts, carrying encapsulated STANAG-5066 UDP payloads of 16 and 32 bytes. However, a few days ago (February 19), while occasionally monitoring 20779.5 kHz (1), sustained async MS-110A transmissions were recorded, characterized by prolonged data exchanges specifically between nodes 101 and 102 (Figure 1). Unlike the sporadic heartbeats/pings observed earlier, these emissions suggest the transfer of larger, continuous data blocks. My friend Kosmod  kindly shared his recordings with me.

Fig. 1: Waterfall display showing continuous MS-110A bursts on 20779.5 kHz, indicating an active data session between ALE nodes 101 and 102

1. Bitstream Analysis

The MS-110A demodulated bitstreams exhibit the expected 8N1 asynchronous framing format, an example is shown in Figure 2. This format ensures that even if the radio link drops or fades momentarily, the serial framing allows the hardware to re-sync at the very next byte, rather than losing an entire synchronous frame.

Fig. 2: MS-110A 8N1 asynchronous pattern

After stripping the asynchronous start/stop bits, the underlying STANAG-5066 frames are identified via their 0x90EB sync sequence. These frames encapsulate IP traffic within U_PDUs (Unreliable/Unacknowledged PDUs), facilitating data exchange between nodes 011.020.100.101 and 011.020.100.102 (Figure 3a). The U_PDU payloads were subsequently extracted and reassembled, revealing IP/UDP datagrams routed between 192.168.101.15 and 192.168.102.15. Analysis of the reassembled UDP payloads identified a consistent 0x04 initial value, corresponding to WireGuard Type 4 Transport Data packets (2). This protocol identification was further validated by the Wireshark dissector (Figure 3b).

Fig. 3: Example of protocol decapsulation using STANAG-5066 (3a) and Wireshark dissectors (3b)

Figures 3a/3b highlights some interesting elements:

1. Cross-Layer Addressing: source and destination IP addresses are correlated with the ALE and STANAG-5066 node IDs. This mapping confirms a consistent logical-to-physical addressing scheme, verifying the identity of the transceiving stations across the radio link:
ALE address: 101 -> STANAG-5066 address: 011.020.100.101 -> LAN IP address: 192.168.101.15
ALE address: 102 -> STANAG-5066 address: 011.020.100.102 -> LAN IP address: 192.168.102.15

2. Transport Layer Optimization: the capture reveals the implementation of UDP (User Datagram Protocol). This choice is mirrored at the data-link layer by the use of STANAG-5066 Non-ARQ data transfer.

3. Encapsulated Tunneling: further dissection of the UDP payload identifies the use of an HF implementation of WireGuard VPN Protocol, indicating that the session employs a modern, high-performance encryption to secure the traffic.

2. Proposed Protocol Analysis

(All field designations are my own and are used for convenience of presentation)
The following section provides the UDP payloads analysis of the data transfer session illustrated in Figure 4.

Fig. 4: spectral time-frequency analysis

For reference, the following workflow was utilized for signal processing and analysis:

- MS-110A demodulation and asynchronous start/stop bit stripping
- STANAG-5066 protocol dissection
- Extraction and reassembly of segmented U_PDUs (Unreliable Data Protocol Units)
- Wireshark IP packet dissection
- Hexadecimal forensic analysis of the extracted UDP payloads 

The session commences with the standard MS-141A 2G-ALE handshake between Node 101 (caller) and Node 102 (called) which are followed by 3 WG bursts.

WG1 burst:
Internet Protocol Version 4, Src: 192.168.101.15, Dst: 192.168.102.15
User Datagram Protocol, Src Port: 55504, Dst Port: 2753
UDP payload (32 bytes): 002000020003cbf6c0a8650f00000def699713f500010000c0a8660f0000064d

This 32-byte pyload is the first packet of a new session, it serves as the "Announcement" or "Master Synchronization" Type 2 Message . In a high-latency, low-bandwidth environment like HF, you cannot afford the back-and-forth of a standard TCP-style or WireGuard handshake. Instead, the sender "pushes" the entire connection state in this single 32-byte burst.

 

WG2 burst:
Internet Protocol Version 4, Src: 192.168.102.15, Dst: 192.168.101.15
User Datagram Protocol, Src Port: 54107, Dst Port: 2754
UDP payload (28 bytes): 001c00010600a36dc0a8660f0001000ec0a8650f00000def00010002

This 28-byte payload serves as the Synchronized Acknowledgement (ACK) Type 1 Message. It confirms that the receiver has accepted the session parameters (Session ID and Clock) proposed in the initial 32-byte WG1 burst.

 

WG3 burst: The WG3 burst consists of two parts:
WG3_1 part: 

Internet Protocol Version 4, Src: 192.168.101.15, Dst: 192.168.102.15
User Datagram Protocol, Src Port: 55504, Dst Port: 2753

UDP payload (32 bytes): 002000020003cbf6c0a8650f00000def699713f500010000c0a8660f0000064d 

 

In this capture, the third payload seems to complete the MS-141A ALE Three-Way Handshake paradigm, transitioning the link from the "Linking" state to the "Data Traffic" state. Interestingly, the hex for this 3rd packet is identical to the 1st packet. In HF protocols, this usually indicates a re-transmission or a State Enforcement frame to ensure the receiver definitely has the Master Context before the data burst begins.

 

WG3_2 part: 

Internet Protocol Version 4, Src: 192.168.101.15, Dst: 192.168.102.15
User Datagram Protocol, Src Port: 55504, Dst Port: 2753
WireGuard Protocol
    Type: Transport Data (4)
    Reserved: 000000
    Receiver: 0x9ee70200
    Counter: 17225424150020335808
    Encrypted Packet

 

Examination of the UDP payload hexdump reveals a consistent 0x04000000 initial sequence , i.e., a fingerprint of standard-WireGuard Transport Data Type 4 Message. 

 

Fig. 5: hexdump of WG3_2 UDP payload

 

The structural composition of the header is detailed below:

The 16-byte Authentication Tag is always the last 16 bytes appended at the end of the encrypted payload. This tag is the result of the Poly1305 algorithm ChaCha20-Poly1305 for Authenticated Encryption with Associated Data (AEAD).
Note that while the Receiver Index is stored in Little-Endian (WireGuard standard), the Embedded IP (C0 A8...) is stored in Big-Endian (Network Byte Order). This "hybrid" endianness is an indicator of a custom wrapper being used to bridge standard networking with the WireGuard protocol.

In a standard WireGuard implementation, the Nonce (bytes 08-15) is usually just a monotonic counter starting from zero. 

However, this specific capture shows interesting points:

 

1. Identity Injection: by placing 192.168.101.15 (the sender's internal IP) directly into the first 4 bytes of the Nonce, the receiver can verify the source of the packet at the cryptographic layer before even attempting to decrypt the inner payload.

2. Timestamp Alignment: the following 4 bytes (00 00 0d ef) ensure the packet is unique and in sequence.

3. The "Double Match": notice this is an exact match to the 32-byte Master Sync packet analyzed in WG_1 burst. This confirms that the first data packet in a session "inherits" the sequence number and identity used during the handshake to prevent any startup delay on the HF link.

 

Below the complete packet flow summary. 

The captured sequence reveals a three-way synchronization establishment designed to bypass the high-overhead  handshake typically found in standard WireGuard implementations.

In this HF-optimized environment, the 32-byte Master Sync (WG1 burst) functions as a "state-push" mechanism, forcefully synchronizing the absolute Unix Epoch and session identity to satisfy WireGuard's anti-replay requirements in a single burst. The subsequent 28-byte ACK (WG2 burst) confirms bidirectional reachability and IP binding, while the final 32-byte State Lock (WG3_1 part) ensures the receiver is fully primed despite potential HF fading or ALE tuning delays. This robust "handshake-less" initiation minimizes airtime while establishing the necessary cryptographic context for the immediate transmission of WireGuard Type 4 Data packets.

 

Another significant capture reveals the existence of a 16-byte Type 3 Message, which in this context likely functions as a Status/Keep-Alive announcement. Notice that this Type 3 control message is transmitted immediately following the 2G-ALE (MS-141A) handshake, without an instant follow-up data burst, thereby marking the transition from link establishment to tunnel maintenance. Figure 6 displays the transition between the physical (2G-ALE) and logical (WG message) layers.

 

Fig. 6 : transition between the physical (2G-ALE) and logical (Type 3 Message) layers

The following table provides the proposed structure of the Type 3 message:

Internet Protocol Version 4, Src: 192.168.101.15, Dst: 192.168.102.15
User Datagram Protocol, Src Port: 56503, Dst Port: 2753
UDP payload (16 bytes): 0010000306001056c0a8650f0000059d

While Type 1 & 2 messages handle acknowledgments between peers, shorter 16-byte Type 3 messages likely serve as heartbeat signals, periodically announcing the presence of the 192.168.101.15 node to the network.
The immediate transmission of the Type 3 message after the 2G-ALE handshake serves as a bridge between the physical layer (radio synchronization) and the logical layer (tunnel persistence). This ensures that the UDP session is active before the bulk transport of Type 4 encrypted data begins. As seen in previous sequences, the ALE → WG transition is the "acid test" confirming that the system utilizes ALE merely as a pathfinder before immediately handing over control to the tunneling protocol.

 

2.1. Functional Parallelism with MS-141A Sounding 

Critical observation of the traffic patterns reveals Sub-Type 2 Messages 2.1 (02 01) and 2.2 (02 02) appearing either in isolation (Figure 7) or as a three-message exchange (Figure 8), both notably occurring without an immediate follow-up data burst. These behaviors exhibit a functional parallelism with 2G-ALE (MS-141A) sounding transmissions, where unilateral or short-handshake bursts are used to maintain channel state and verify path viability independently of active traffic.

 

Fig. 7 : isolated/probe Type 02  Message without an immediate follow-up handshake or data burst

Analisys of the payload (IP/UDP encapsulation is omitted)
Hex: 0020020200030b03c0a8650f00000de76996f7d300010000c0a8660f00000646

 

 

Figure 8 sows a three-message exchange between nodes 101 and 102 without an immediate follow-up data burst.

 

Fig. 8:  three-message exchange without an immediate follow-up data burst

 

Analisys of the UDP payloads, IP/UDP encapsulations are omitted.

 

WG1 Burst UDP Payload: Initial Sounding (Node 101)
Hex: 0020020200030b03c0a8650f00000de76996f7d300010000c0a8660f00000646

 

WG2 Burs UDP Payload: Response (Node 102)
Hex: 001c0201060019fdc0a8660f0001000ec0a8650f00000de700010002

WG2 payload is 28 bytes and contains the reflected "Echo" of  WG1 payload.

 

WG3 Burst UDP Payoad: Final Confirmation (Node 101)
Hex: 0020020200030b03c0a8650f00000de76996f7d300010000c0a8660f00000646

WG3 payload is a re-transmission of WG1 payload 1 to ensure link stability.

 

Sumarizing:

WG1 (The Sound): Node 101 announces itself and sets the Sync ID to 0x0de7.
WG2 (The Call/Response): Node 102 confirms it heard the sound by reflecting the IP .101.15 and the ID 0x0de7 back to the sender.
WG3 (The Conclusion): Node 101 re-transmits its state to ensure the link is locked. This redundancy is the core of the ALE-logic parallelism, ensuring connectivity even if the first packet had jitter.

 

This confirms that the nodes are handshaking on a state, not just passing data.

 

Observed sequences also show the presence of Sub-Type 1 Messages 1.2 (01 02), appearing either as isolated/probe burst (Figure 9): 

 

Fig. 9: isolated/probe WG burst

 

UDP Payload (IP/UDP encapsulation is omitted)
Hex: 00200102000323aac0a8650f00000df1699706f600010000c0a8660f0000064b

or occurring immediately before a Type 2 Message inside the same Type 4 data exchange burst. Notably, no ACK is issued by the destination peer (typically Node 102) in this specific sequence.

 

Fig. 10

UDP Payload WG1 (IP/UDP encapsulation is omitted)
Hex: 00200102000323aac0a8650f00000df1699706f600010000c0a8660f0000064b

UDP Payload WG2 (IP/UDP encapsulation is omitted)
Hex: 002000020003a325c0a8650f00000dea699713f300010000c0a8660f0000064e

Note the time jump between the two contiguous bursts
Payload A Epoch: 69 97 06 f6 ≈ 07:40:06 UTC
Payload B Epoch: 69 97 13 f3 ≈ 08:35:01 UTC
Delta: 3325 seconds (approx. 55 minutes and 25 seconds).

The fact that Type 04 (Data) follows Payload B immediately, could likely mean that the 55-minute jump in the epoch was a session sesynchronization.

The specific role of Sub-Type 1.2 remains unclear and deserves further investigation. 

 

2.2. Protocol Type Messages

Based on the observed sequences, this WireGuard-like protocol follows a deterministic four-stage lifecycle for link management and data transfer identified by the Type Message IDs:

- Link Initiatior (Type 2 Message): the session originates with an Initiator message utilized to request channel allocation or to "wake up" the remote peer within the STANAG-5066 stack.
- Receiver ACK (Type 1 Message): the responding node returns a Receiver ACK message. This exchange validates link-layer synchronization and confirms that both modems are aligned.
- Link Maintenance/Persistence (Type 3 Message): during periods of data inactivity, the link is sustained via Heartbeat messages. These 16-byte frames likely prevent STANAG-5066 session timeouts and provide the network controller with continuous node reachability status.
- Transport Data (Type 4 Message): once the control plane is stabilized, the Transport Data packets carry the encrypted payload. The persistence of the Receiver Index across distinct captures confirms a long-term security association managed by this custom signaling layer. 

Notice the similarity between the two ACK Types 0001 and 0201.

Interestingly, the protocol utilizes a non-sequential Type Message assignment that deviates from standard handshake conventions. Type 02 functions as the Initiator, signaling the intent to establish a link, while Type 01 serves as the Receiver ACK. This inversion suggests a priority-based numbering system or a derivation from a legacy STANAG-5066 signaling framework, where Type 01 is traditionally reserved for link-layer acknowledgments.

3. Some techical observations

3.1. STANAG-5066 addresses
The addresses utilized in STANAG-5066 (Source: 011.020.100.101; Destination: 011.020.100.102) are formally assigned to an Armenian political or organizational network (STANAG-5066 Table N-9  Middle East National Addressing Schema); however, they are likely dummy/fictitious addresses intended to avoid interference with official NATO-standard communications. Regardless, they do not help in geolocation since these represent logical identifiers that reflect organizational affiliation rather than physical geographical location. They identify "who" is communicating within the network, but they bear no relationship to "where" the transmitter is physically located.

 

3.2. Cross-Mapped UDP Architecture (port asimettry)
In a typical internet deployment, WireGuard is symmetric (e.g., Peer A:51820 ↔ Peer B:51820), however analysis of the UDP datagrams reveals a consistent asymmetric pattern:

    Node 101 TX Path: Local Port 55504 → Node 102 Remote Port 2753
    Node 102 TX Path: Local Port 54107 → Node 101 Remote Port 2754

Looking at previous captures, the local port does not always have the same value but changes (55504,54107,56503,60510,...) while remote ports 2753/2754 remain fixed:

    Node 101 TX Path: Local Port (variable) → Node 102 Remote Port 2753
    Node 102 TX Path: Local Port (variable) → Node 101 Remote Port 2754

The transition from symmetric to asymmetric UDP ports confirms that this is a Radio-Aware implementation. The cross-mapping of ports 2753 and 2754 serves as a synchronization bridge between the synchronous nature of the WireGuard protocol and the asynchronous, half-duplex constraints of HF.

By separating the RX/TX paths into different ports the software knows that anything arriving on ports 2753/2754 is exclusively incoming traffic from the remote peer, eliminating any risk of processing its own transmitted signals. In essence, the port asymmetry transforms a standard peer-to-peer VPN tunnel into a dual-channel "Virtual Circuit" optimized for the unique HF channel. 

Although a search of the IANA port registry yields no official assignments for UDP ports 2753 or 2754, the consistency of their appearance suggests they are de facto service-dedicated ports for this specific protocol.

 

3.3. End-user Identification and Attribution
Regarding the end-user, it can be confirmed with certainty that the entity is an Italian diplomatic/military body, as previous signal captures have intercepted op-chats conducted in Italian language. Furthermore, multiple UDXF logs support this attribution, identifying the ALE exchanges between nodes 101 and 102 as part of an Italian Military Attaché network.

 

3.4. Node Roles and Network Topology
The specific roles of ALE nodes 101 and 102 remain difficult to define, specifically regarding which functions as the HQ node and which as the remote node. However, it is established that node 101 consistently initiates both the link negotiation and the VPN tunnel, while also managing subsequent data forwarding. Based on standard network architecture, this behavior suggests that node 101 likely operates as the remote station (initiating a "call home" procedure), while node 102 functions as the central gateway or HQ. 

Based on the assumption of an Italian Military Attaché entity, it is highly plausible that the remote station (Node 101) transmits periodic diplomatic/military situation reports (SITREPs) to the central headquarters in Rome (Node 102), likely Ministry of Foreign Affairs or Ministry of Defense.

 

3.5. Geolocation and Technical Constraints
Similar uncertainties apply to the geolocation of the two transmitters. The TDoA (Time Difference of Arrival) method employed for Direction Finding (DF) requires a minimum dwell time of 30 seconds from a single transmitting source and at least three receivers synchronized to the monitoring frequency.
These conditions are difficult to meet due to the unpredictable nature of the transmissions (they seem to happen only when a "report" is ready) and the handshake mechanism employed, which involves two distinct transmitting sources alternating rapidly. This rapid switching between the initiator (Node 101) and the responder (Node 102) prevents the TDoA system from maintaining a stable lock long enough for a precise fix. 

3.6. Protocol's timing logic
Examining several captures, significant temporal differences were observed between the WireGuard handshake timestamps in the initiator packets and their actual reception; an example is shown in Figure 11.

 

Fig. 11: temporal difference

 

All data points in the following table were recorded on the same day (2026/02/19), highlighting the intra-day volatility of the protocol's timing logic.

While the synchronization between the packets is evident, the multi-hour gaps between the Internal Timestamp and the Actual Reception time (specifically in Captures C through F) present an unresolved anomaly. At this stage of the analysis, no definitive explanation can be provided for these significant offsets. Several hypotheses remain under consideration: session-based epochs, system clock misalignment (Node 101), or a "store-and-forward" mechanism.

The negative deltas (specifically in Captures A and B) suggest that the internal timestamp functions as an expiration marker, i.e., a Session Validity Deadlines (Time-to-Live): this hypotheses also remains under consideration.

Negative deltas and multi-hour gaps highlight a complex session management logic that requires further data acquisition to be fully decoded and interpreted.

 

By the way, all the 2024/11/28 captures show similar negative deltas.  

 

 

Conclusions

In conclusion, the captured traffic likely represents an HF-customized VPN protocol. Although it deviates from the standard WireGuard specifications, its alignment with observed message structures suggests its specialized HF implementation. This adaptation transcends the capabilities of standard Wireshark dissectors, which are designed for "Vanilla" protocols and may not natively support these physical-layer modifications. This analysis remains a work in progress; further captures will be essential to confirm these findings and refine the protocol details.

 

https://disk.yandex.com/d/H6alLjdFmCy0gg

 

(1) Transmissions do not appear to follow a fixed schedule. According to UDXF logs, there are multiple frequencies to monitor, making simultaneous tracking difficult unless a polling strategy using ALE software with a scanning receiver or a "staring" monitoring approach is implemented across various remote web-based SDRs:
07780.50, 10220.50, 12110.50, 14963.50, 15906.50
17411.50, 18325.50, 19516.50, 20776.50, 20779.50
(all KHz/USB)

 

[1] https://www.wireguard.com , https://www.wireguard.com/papers/wireguard.pdf

[2] http://i56578-swl.blogspot.com/2025/12/udp-datagrams-sent-via-stanag-5066-over.html
[3] http://i56578-swl.blogspot.com/2026/01/udp-datagrams-sent-via-stanag-5066-2.html

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.

S-4481/S-4539 clear-text messages sent using RapidM modem (BRE1TA tests?)

The purpose of this post is to report test transmissions heard on 6963.0 kHz USB and logged during the first week of February by both Kosmod (who sent them to me for analysis) and ANgazu (whose signal was reported by KA0KA and published on the radiofrecuencias.es forum [1]). I don’t claim much credit in this post, other than confirming previous analyses and contributing further insights.
Transmissions continued for several days without interruption, almost entirely using the STANAG-4539 (MS-110B App.C) waveform. One of Kosmod’s recordings was particularly notable, as the STANAG-4539 signal was preceded by a STANAG-4481 transmission at 75 Bd/850 Hz (Figure 1). The mode switch lasted roughly 640 ms.

Fig. 1 - STANAG-4481/STANAG-4539 switch

According to STANAG-4539, each data frame contains a 256-symbol data block followed by a 31-symbol mini-probe of known data, for a total of 287 symbols per frame (119.57 ms @ 2400 symbols/s). Every 72 frames, a 72-symbol subset of the initial preamble is reinserted to aid late acquisition (1) (Figure 2).

Fig. 2 - STANAG-4539 framing

The data rate is 9600 bps, and the modulation used to achieve it is QAM-64. According to STANAG-4539, §4.2.2.1.6, “This [QAM-64] constellation is a variation on the standard 8 × 8 square constellation, which achieves a better peak-to-average ratio without sacrificing the very good pseudo-Gray code properties of the square constellation” (Figure 3).

Fig. 3 - STANAG-4539 constellations

In both cases (STANAG 4481 and STANAG 4539), the modulations are asynchronous and employ an 8N1 framing format, as shown in Figure 4.

Fig. 4 - STANAG-4481 and STANAG-4539 demodulated bitstreams

The transmitted messages are 8-bit ASCII clear text and consist of repeated instances of the same sentence, differing only in the message sequence number:
[binary header][message sequence number][text] 
The portions of the demodulated bitstreams presented below were obtained from two different recordings (header is omitted):

[STANAG-4481]
...
000013 Rapid Mobile HF & V/UHF Data Modem internally generated test message.
000014 Rapid Mobile HF & V/UHF Data Modem internally generated test message.
000015 Rapid Mobile HF & V/UHF Data Modem internally generated test message.
000016 Rapid Mobile HF & V/UHF Data Modem internally generated test message.
...

[STANAG-4539]
...
004820 Rapid Mobile HF & V/UHF Data Modem internally generated test message.
004821 Rapid Mobile HF & V/UHF Data Modem internally generated test message.
004822 Rapid Mobile HF & V/UHF Data Modem internally generated test message.
...

The message sequence numbering is likely continuous across the transition from STANAG-4481 to STANAG-4539 (Figure 2); however, this assessment cannot be confirmed due to unreliable demodulation of the initial segment of STANAG-4539.

Despite the modem-generated test traffic, the end-to-end efficiency η from payload to physical layer transmission can be evaluated for this STANAG-4539 waveform. As shown, the 9600 bps input uses asynchronous framing with 1 start bit and 1 stop bit, meaning each byte is transmitted as 10 bits of which only 8 carry payload; the symbol rate of 2400 Bd employing QAM-64 modulation (6 bits per symbol) results in a gross channel bit rate of 14400 bps. So:

- net useful payload = 9600 × (8/10) = 7680 bps
- transport efficiency relative to 14400 bps rate:
η = 7680/14400 ≈ 0.533  i.e., an effective efficiency of approximately 53.3%

overhead breakdown:
20% from serial framing (start/stop bits)
~26.7% due to physical-layer mechanisms such as FEC, preambles, and synchronization (S-4539) (2)

It's evident that a RapidM (Rapid Mobile) modem is being used that is capable of producing its own test traffic without needing an external server or another device to send data. This feature is often known as loopback testing, built-in test signal generation, or self-test mode.
Unfortunately, there is no publicly documented statement that a specific RapidM modem model generates its own test message, manufacturers often keep detailed test features in restricted datasheets. However, RM2, RM5, RM8, and RM10 RapidM modems all support STANAG -4539 and STANAG- 4481. RM2/RM5 are narrowband tactical modems (up to 9600  bps) with built-in test/loopback capabilities. RM8 is a strategic/naval narrowband modem supporting 9600–19200  bps and 2G/3G ALE, also capable of self-generated test traffic. RM10 adds wideband HF (3–24 kHz) while retaining narrowband 4539/4481 support [2].

Regarding the transmitting antenna’s location, both Kosmod and ANgazu performed direction finding using the TDoA (Time Difference of Arrival) algorithm, and both results pointed to an area near Casteau-Mons in Belgium, very close to NATO’s SHAPE headquarters (3)[3].

Fig. 5 - Direction Finding results

Direction Finding results may further substantiate ANgazu’s hypothesis that the signals could represent test transmissions associated with the NATO BRE1TA (BRASS Enhancement 1 Technical Architecture) program. BRE1TA constitutes a major architectural evolution of the NATO BRASS (Broadcast and Ship-to-Shore) HF communications system, designed to integrate advanced narrowband and wideband HF waveforms, higher spectral efficiency, improved link robustness, and IP-based data services. 

Several hours of monitoring on 6063 kHz USB over the past few days yielded only occasional short STANAG-4285 300 bps long-interleaver transmissions encrypted with KG-84. Reception was further limited by sporadic fading during the morning sessions.

https://disk.yandex.com/d/CXaz6URgUh-3zg

(1) In Change Notice 1 of MIL-STD-110C (January 2012), the United States Department of Defense removed a sentence stating that a “reinserted preamble facilitates acquisition (or re-acquisition) of an ongoing broadcast transmission.”  The reason was that the sentence referred to a feature that had become obsolete. Keeping it in the standard could have caused confusion by implying support for a legacy broadcast capability that was no longer part of the modem design. 

2) The relationship between the nominal user data rate of 9600 bit/s and the over-the-air symbol rate of 2400 baud for the STANAG-4539 QAM-64 waveform is as follows:
- the waveform employs a symbol rate of 2400 symbols per second with 64-QAM modulation, corresponding to 6 bits per symbol. This results in a gross channel bit rate of 14400 bit/s;
- the application of forward error correction (FEC) with coding rate R = 3/4 to a user data rate of 9600 bit/s produces a coded bit rate of 12800 bit/s;
- the remaining capacity of 1600 bit/s (14400-12800), representing the difference between the gross channel bit rate and the coded bit rate, is allocated to waveform overhead. This overhead includes, but is not limited to, miniprobes and periodic preamble reinsertion required to support synchronization and channel estimation functions. 

Figure below shows an example; the 1-second interval is chosen for ease of presentation.

over-the-air symbols/bits in a 1 second interval (STANAG-4539)

(3) The Supreme Headquarters Allied Powers Europe (SHAPE) is the headquarters of NATO's Allied Operations Command (ACO), located in Casteau, near Mons, Belgium. It is responsible for the planning and execution of all NATO military operations worldwide.

[1] https://www.radiofrecuencias.es/viewtopic.php?p=12527#p12527
[2] https://www.rapidm.com/
[3] https://shape.nato.int/

Citadel II 96-bit Initialization Vectors, an interesting update

A great thanks to my friend Kosmod who breakdown a Citadel II encrypted bitstream and saw that the Initialization Vector (IV) composed of 96 bits, 3 times repeated, is followed by a 64-bit field, this one also 3 times repeated. The problem is that the periodicity of the two "patterns" is different, so once the start/sync sequence is removed, it is necessary to set the bitstream period to 96 bits, remove the three IV sequences and then set the bitstream period to 64 bits (as shown in Figure 1).

Fig. 1

A question arises: could it be a 20 bytes/160 bits Initialization Vector composed of two 96 and 64 bits parts, each part 3 times repeated? Well, I think no.

It must be said that a 160-bit IV sequence is unusual, athough double-checked in other bitstreams. That length would be suspicious because most block-cipher sizes are powers of two or use multiples of 32 (32, 64, 96, 128, 256, 512) and since the IV typically matches the cipher’s internal structure or counter construction, a 160-bit length is not impossible but it would be atypical enough that cryptographers would immediately suspect parsing error or mixed fields.

Indeed, some systems prepend metadata or combine nonce + counter (1) and what looks like a single IV may actually be multiple fields, each repeated for robustness; in this case:
-  a 96-bit nonce, likely serving as the true Initialization Vector (2)
- a 64-bit nonce, likely a per-frame synchronization value or session diversifier. In other words: it's something that changes per transmission, maybe the 96-bit IV alone not being the entire initializer.
Because both fields are variable and precede the ciphertext, they could easily be mistaken as a single composite IV.

So, speaking about Citadel II,  why does the 64-bit sequence appear only with the 96-bit IV and not with the 256-bit one?

Fig. 2 - 32 bytes/256 bits IV

It likely comes down to how modern encryption systems structure their nonces. When a shorter 96-bit IV is used, a separate 64-bit counter or sequence field may be transmitted alongside it to guarantee that every message remains unique. With a 256-bit IV, that sequencing data is probably embedded inside the larger nonce itself — so the counter is still present, just no longer visible as a distinct field.  In short: we are not seeing different security levels, but two design approaches:

96-bit IV + external sequencer,
256-bit IV with internal sequencer.

The “missing” 64-bit field (or another length) is most likely hidden inside the larger initialization structure rather than removed.

(1) In cryptography, a “nonce” (short for number used once) is a value that is unique for each encryption operation – it should never repeat with the same key, usually not secret – it can be transmitted openly and used to make encryption different each time – even if  the same plaintext is encrypted with the same key, a different nonce produces a different ciphertext.

(2) A 96-bit IV is mainly used in AES-GCM, AES-CCM, and ChaCha20-Poly1305, where it strikes a balance between security (avoiding collisions) and computational efficiency.