Decoding UFO-11 MILSATCOM Downlink (MIL-STD-188-181)

While monitoring the UHF band, my friend Kosmod successfully captured and shared a series of military satellite 2400 Bd bursts on 252.2525 and 253.6460 MHz. The signal displays BPSK modulation at 2400 Baud (or 2400 bps, given the 1 bit/symbol efficiency of BPSK).

Fig. 1: waveform analysis of the captured signals

The 253.646 MHz signal falls directly within the downlink range for UHF MILSATCOM. This specific frequency is part of the UFO (UHF Follow-On) and legacy FLTSATCOM constellations operated by the US Navy to provide global coverage for maritime and ground forces.
Technically, this is Channel 14 in the Navy's 'Bandplan Bravo'. While the nominal center is 253.650 MHz, these satellite transponders act as 'bent-pipes', simple relays that repeat the uplink signal across their available bandwidth. Because of this, seeing a signal centered at 253.646 MHz is perfectly normal; it's simply sitting on the lower edge of that 25 kHz wideband assignment.
Based on the location of Kosmod, UFO-11 (USA 174) (1) is the primary "workhorse" for this region. These satellites utilize Global Beams; for instance, a satellite parked at 75°E and at a geostationary altitude of 35,786 km (like UFO-11) covers everything from Central Europe all the way to Western China.

Looking at the differential decoded bitstreams (Figure 2), we are looking at a classic Satellite Military Communication (SATMILCOMM) frame structure. These patterns are highly characteristic of bursts sent over tactical waveforms (like MIL-STD-188-181 or similar UHF SATCOM standards).

Fig. 2 : differential decoded bitstreams

Here is a proposed breakdown of what those specific hex blocks could represent:

1. The Preamble (AA AA AA AA ...)
This is the Bit Synchronization sequence. Purpose: In binary, AA is 10101010. This alternating pattern of ones and zeros allows the receiver's modem to "lock on" to the clock frequency of the transmission.

2. The Sync Word / Frame Marker
The block starting with 46 8B 87 84... is the Frame Synchronization Word. Notice that this block is identical in all three headers. Once the receiver has the timing (from the AAs), it looks for this specific unique bit string to know exactly where the "data" actually begins. It marks the boundary between the "noise/tuning" and the actual message.

3. The Metadata / Packet Header (The Variable Block)
This is the most interesting part. Notice that this section changes in every capture. This block typically contains the Control Channel information. In military protocols, this often includes: Destination/Source IDs, Initialization Vector (IV), Message Length/Type.

4. The Flush / Transition Pattern (8B 87 84 7B ...)
You see this repeating sequence just before the encrypted payload. This acts as a pad or transition gap. It ensures the receiver's hardware buffer is ready and that the cryptographic resync has occurred before the high-entropy (encrypted) data hits the stream. The fact that it repeats exactly five times suggests a fixed-length buffer requirement for the specific radio hardware being used.

A note on the "Encrypted Data": because the data following these headers is encrypted (likely using AES-256 or a sovereign military grade equivalent), it will appear as completely random noise with no repeating patterns. Without the specific cryptographic key and the correct algorithm, that portion cannot be decoded.

The captured transmission is almost certainly not the classic Fleet Broadcast beacon, but rather a more active DAMA/IW Control Channel:
* Fleet Broadcast (Beacons) are usually found at the "low end" of the UFO band (e.g., 250.350 MHz to 250.650 MHz) and they are constant, 24/7 transmissions
* Tactical Data Links (Your Signal) sits in the "Tactical" portion of the bandplan. This area is reserved for Demand Assigned Multiple Access (DAMA) and Integrated Waveform (IW). These channels don't just broadcast one-way; they manage a "conversation" between the satellite and hundreds of ground terminals.

It is interesting to note the parallels with an HF signal captured previously on 7961 kHz (USB): a 3G-HF STANAG-4538 transmission. The demodulated bitstreams exhibit a series of data blocks characterized by a 32-bit framing structure, primarily due to the fixed length of their headers [1].

 https://disk.yandex.com/d/3b9hpOGFoZkp6g

(1) Satellite Profile: UFO-11
NORAD ID: 28117
Current Position (March 2026): It is stationed in a geostationary orbit over the Indian Ocean, currently hovering around 75° East longitude. Coverage: This position provides a massive footprint that covers almost all of Russia (except the extreme Far East), the Middle East, Eastern Europe, and Africa. Inclination: As of 2026, UFO-11 has an orbital inclination of approximately 8.5° to 9°. This means it is no longer perfectly stationary; it appears to drift North and South in the sky over a 24-hour period.
UFO-11 was the final satellite in the UFO series and includes the most advanced digital processing of the bunch.

Communications Payload (The "Bent-Pipe" Hardware)
UHF Channels: 39 Channels (Total), voice and Low-speed data
Wideband: 21 Channels @ 25 kHz used for DAMA/IW
Narrowband: 17 Channels @ 5 kHz    used for legacy tactical teletype/secure voice
Anti-Jam: FHSS (Frequency Hopping), protection for the Fleet Broadcast (FLTSAT)
GBS Payload: 4 Transponders (Ka-Band), high-speed Global Broadcast Service (video/maps).

Signal Technical Specifications
Modulation: BPSK / SBPSK
Symbol Rate: 2400 Baud    
Protocol Standard: MIL-STD-188-181C The "Integrated Waveform" (IW) standard. It governs how the satellite manages multiple users in a single 25 kHz channel.
Frame Structure: TDMA Burst Time Division Multiple Access. The signal consists of a Preamble, a 160-bit Unique Word, a Control Header, and the 5-fold redundant Trailer

[1] https://i56578-swl.blogspot.com/2018/03/unid-32-bit-secondary-protocol.html

BPSK/QPSK Phase Ambiguity and Bit-Shift

Dealing with phase ambiguity and bit shifting in a demodulated BPSK/QPSK bistream are two of the most common obstacles that prevent you from actually understanding what the transmitter sent.

1. BPSK Phase Ambiguity ("Is it Inverted?")
In BPSK, data are represnted by shifting the phase of a carrier wave: 0° might represent a binary '0' 180° might represent a binary '1'.
The problem arises during carrier recovery. The receiver modem has to generate a local reference carrier to demodulate the signal. However,  an "universal" PSK demodulator - as the one of SA Signals Analyzer - cannot distinguish between a carrier at θ and a carrier at θ+180°. The Result: if the demodulator locks onto the phase 180° out of sync, your data gets inverted. Every '1' becomes a '0' and every '0' becomes a '1' (Figure 1). Without a reference, the demodulator has no way of knowing it's reading the entire stream upside down.

Figure 1: Outputs of the "universal" SA PSK demodulator processing the same BPSK signal.

2. The Bit-Shift Problem ("Where does it start?")
Bit-shifting (or timing offset) occurs when the modem's clock isn't perfectly aligned with the incoming symbols. The Cause: even if your frequency is correct, if your "sampling instant" is off, you might sample the signal during a transition between two bits. The Result: this leads to Intersymbol Interference (ISI). I If the shift is bad enough (e.g., a half-symbol shift), the receiver might slip a bit entirely, causing the rest of the data stream to be misaligned with the intended word boundaries (frame synchronization). For istance, if you see 0x33 or 0x66 rather then an expected Sync 0xCC sequence, you might be inverted, or you might just be 2 bits off in your alignment (Table I).

Table I : bit-shift effects

3. How it's fixed by the sender

3.1. Known Sequences (Preamble, Framing Sequences, Pilot/Training Sequences)
Sending a known pattern (e.g., 111101011) at the start of a packet, i.e., a general packet framing (e.g., File headers). For Phase: If the receiver sees the inverse of the preamble, it knows to flip all subsequent bits. For Bit-Shift: The preamble allows the receiver to find the exact "start" of the message, aligning the clock and preventing bit-shifts.

 

3.2. Unique Word (UW) / Synchronization Marker
By periodically inserting a known "Unique Word" (UW), often called Synch Marker or Synch Word, the receiver can constantly check if it's still aligned. If it finds the UW shifted by one position, it shifts its internal buffer to compensate.

3.2.1. Solving Phase Ambiguity with UW
If the receiver is locked 180∘ out of phase, the entire incoming stream is inverted. The receiver looks for the UW (e.g., 011010): if it finds 011010, it knows the phase is correct. If it finds 100101 (the exact inverse), it knows it is 180∘ out of phase. The receiver simply flips every bit in the payload following that inverted UW.

3.2.2. Solving Bit-Shifts with UW
Because the receiver is constantly sampling, it doesn't initially know where "Bit 1" of a frame begins. It just sees a continuous stream of bits. The receiver runs a Cross-Correlation. It slides its "known" UW over the incoming bitstream one bit at a time. When the correlation peak hits its maximum, the receiver has found the exact alignment. It "snaps" its frame buffer to that position. Any bits received before that peak are discarded as noise or previous frame leakage; everything after is the valid payload.
Why not just use the Preamble?
The Preamble (usually alternating 101010) is great for helping the hardware clock "lock on" to the speed of the data, but it’s terrible for alignment because every shift looks the same. The Unique Word is designed to be mathematically "un-ambiguous", it has a sharp autocorrelation peak so the receiver knows exactly which bit is the first bit.

3.2.3 A note about Barker Codes

Barker Codes are the most popular choice for a Unique Word (UW) because they are mathematically optimized to be "self-distinguishable." While any random sequence could technically be a UW, Barker codes are used because they minimize False Positives. If you used a sequence like 1111, the receiver might think it found the start of the frame four different times as the bits slide by. With a Barker code, there is only one clear answer.
In Table II shows the list of the known Binary Barker Codes in a plain text ASCII format.In this representation, a '1' corresponds to +1 (no phase shift) and a '0' corresponds to −1 (180∘ phase shift) in a BPSK system.

Table II: known Binary Barker Codes

3.3. Differential Encoding (DBPSK)
Instead of mapping bits to absolute phases, the source modem map them to changes in phase:
0: Stay the same phase as the last bit.
1: Flip the phase 180° from the last bit.
Even if the receiver is 180° out of phase, the difference between bits remains the same, effectively killing the phase ambiguity problem.
 
3.3.1. Solving Phase Ambiguity with Differential decoding
Instead of searching for a Unique Word to see if the bits are inverted, we change how data are encoded so that an inversion doesn't actually matter: in Differential BPSK (DBPSK), we a bit is mapped to a change in phase.

3.3.2. Solving Bit-Shifts with Differential decoding
Differential decoding does not solve bit-shifts on its own. While it is a "magic bullet" for Phase Ambiguity, it is actually quite vulnerable to Bit-Shifts. Differential decoding works by comparing the current symbol (Sk​) to the previous symbol (Sk−1​). If the receiver has a bit-shift (timing offset), it means the "window" where it samples the sine wave is shifted. Instead of capturing a clean 0° or 180° symbol, it might sample right on the edge where one bit ends and the next begins.
If the receiver is "off by one bit," the differential decoder will compare:
- Bit 2 to Bit 1 (instead of Bit 1 to Bit 0)
- Bit 3 to Bit 2 (instead of Bit 2 to Bit 1)
The math still "works" (no phase inversion), but your entire data stream is now offset. If you were expecting a 16-bit sensor reading, you now have the last 15 bits of that reading plus the first bit of the next one. The data is mathematically "correct" but contextually "garbage."

 

4. QPSK modulation
When we move from BPSK (2 phases) to QPSK (4 phases) the complexity of phase ambiguity and bit-shifting increases significantly. If your Bit-Shift is off by just one bit in a QPSK system, you aren't just starting the message late; you are splitting the symbols in half:
Correct Alignment: [BitA BitB] [BitC BitD] → Symbols read correctly.
1-Bit Shift: BitA [BitB BitC] [BitD BitE] → Every single symbol is now a hybrid of two different intended symbols. The data becomes total "noise."
In QPSK, phase ambiguity can result in four possible rotations (0∘,90∘,180∘,270∘) that swap or invert the I and Q bitstreams, while a single bit-shift misaligns the 2-bit symbol boundaries, completely corrupting the data mapping.
The fundamental difference lies in symbol mapping: while BPSK maintains a 1:1 ratio between bits and symbols, QPSK encodes 2 bits per symbol, making it highly sensitive to bit-alignment errors.

4.1. Bit-Shift (Synchronization Error)
In BPSK: The message simply starts with a delay (or early). If you shift by one bit, the rest of the sequence is still readable, just translated by one position.In QPSK: It is a disaster. Since each symbol is composed of a bit pair (I,Q), shifting by a single bit breaks the original pairings. Every new symbol becomes a "hybrid" (half of the previous symbol and half of the next), making the data completely unreadable (pure noise).

4.2. Phase Ambiguity (Rotation Error)
- In BPSK (2 phases): There are only two possibilities. Either the bits are correct, or they are all inverted (0↔1). It is like looking at a piece of paper upside down: you just need to flip it back.
- In QPSK (4 phases): There are four possibilities (0∘,90∘,180∘,270∘). An incorrect rotation doesn't just invert bits; it can swap the I channel with the Q channel. Bits are reshuffled and inverted according to the rotation pattern (e.g., at 90∘, the I bit becomes −Q).
In summary: In BPSK, the error is linear (bits are either flipped or shifted). In QPSK, a single bit-shift or phase error destroys the very structure of the information. What we can do?
Just like in BPSK, we can decode the data as the change in phase between symbols. The receiver doesn't care about the absolute phase, only the difference (Δθ). Limitation: this still doesn't fix the bit-shift; you still need a Sync Marker to know where the first symbol of the frame is.

Table III: Summary of Carrier Recovery and Synchronization Failures and their Remediation Strategies

 

5. Blind Detection: Analyzing an Unknown Bitstream
If you don't know if a Barker code (or any known Unique Word/Sync Sequence) exists in the stream, you are essentially "flying blind." This is a common scenario in signals intelligence (SIGINT) or when dealing with raw, unformatted streams. Without a known sync pattern, you must use Blind Detection strategies.

5.1. Autocorrelation (ACF)
If the data is packetized, there is almost always a pattern that repeats. By capturing a large buffer of bits and performing an Autocorrelation (xcorr(stream,stream)), you can identify periodicity (using BEE bit-editor, the Autocorrelation is performed by "Find Period" tool).
What to look for: Recurring spikes at regular intervals (e.g., every 1024 bits) indicate frame boundaries. Even without knowing a specific bit-pattern, these spikes identify your Bit-Shift anchor.

 

5.2. Trial and Error (The "Brute Force" Method)
If you suspect the stream is PSK but don't know the phase rotation, you run parallel demodulators for each possible state (0∘ and 180∘ for BPSK; four rotations for QPSK).
The Goal: You scan the resulting bitstreams for recognizable structures, such as ASCII text, protocol headers, or valid CRC checks. If one stream produces valid data while the others produce noise, you have resolved the Phase Ambiguity.

5.3. Look for the "Preamble" First
Before the Unique Word, there is almost always a Preamble (alternating 10101010). Preambles are easier to detect because they have a distinct frequency component. If you find a long string of alternating bits, the Unique Word is almost certainly the very next sequence that follows once that pattern breaks.

5.4. Differential Decoding (The "Safest Bet")
If you don't know the phase and lack a sync sequence, apply a Differential Decoder. If the transmitter used Differential Encoding (DBPSK/DQPSK), the data will become readable because the decoder looks at the change between bits rather than the absolute phase. If the transmitter didn't use it, the data remains garbage, but you have successfully ruled out one major modulation possibility.

6. PSK8 ms-110A s-4285 Specialized Decoders
Specialized decoders for standards like STANAG 4285 or MIL-STD-188-110A automatically resolve phase ambiguity and bit-shifting by using periodic training sequences (probes) and adaptive equalizers to constantly "sound" the channel and re-align the signal in real-time. Unlike a generic demodulator, these systems don't just "lock once"; they use the known structure of the waveform to mathematically calculate and cancel out rotation and timing errors before the data ever reaches the output.

7. Encrypted Bitstreams
Because encryption is mathematically designed to look like pure random noise, there are no repeating patterns or ACF 'spikes' to find within the ciphertext. To solve phase ambiguity and bit-shift in an encrypted stream, you must rely on a known Cleartext Sync sequence to find the exact bit-offset and correct phase so that the encrypted data is perfectly aligned and represented for further analysis. 

 

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