For background read the previous post
I ended the erstwhile post hoping to recover fresh transmissions to realize more about the utilized application-layer protocol, and someway this happened: my friend Kosmod indeed kindly sent me respective transmissions he recorded on 20779.5 KHz/USB. The recordings date back to the end of 2024 (November) and this allowed me to realize how - actually - there has been a kind of evolution/improvement of the application-layer protocol that sits above UDP and which is so liable for the UDP payloads.
2024 transmissions follow the same schema: first MS-141A link setup between ALE address 101 (caller) and 102 (called), then MS-110A moving at 300bps/L to trasnfer data in async 8N1 mode (Figure 1).
 |
| Fig. 1 - async 8N1 MS-110A |
After removing the start/stop bits, the resulting bistreams consist of Data Transfer Protocol Data Units (D_PDUs) of the STANAG-5066 protocol, as parsed by the S-5066 dissector (as for example in Figure 2). The results are as expected, namely:
* D_PDU (Data Transfer Protocol Data Units) kind 7, NON-ARQ DATA (Non-ARQ data transfer)
* the last 3 digits of the STANAG-5066 Addresses correspond to the respective MS-141A ALE addresses utilized during link setup
* IP-type Client/Application, i.e. IP over HF ("Source and Destination Service Access Point" is 9)
 |
| Fig. 2 - analysis of a STANAG-5066 frames |
The same conclusions (ie expected results) can be drawn by examining IP packets with "wireshark" tool (an example is shown in Figure 3):
* source/destination (LAN) IP addresseses are 192.168.101.15 and 192.168.102.15 (note the digits 101 and 102)
* the IP packet transports User Datagram Protocol (UDP) messages which are addressed to the destination port 2753, the "de-spot" port
Practically, just as in the recordings analyzed in the erstwhile post... but there is simply a very crucial difference compared to the 2025 recordings: here the dimension of the UDP payload is 32 bytes alternatively of 16! (double length).
 |
| Fig. 3 - analysis of an IP packet |
Below I study the 32-byte payloads related to 10 consecutive transmissions: as you can easy see, these are repeated transmissions, most likely due to missed or incorrect receptions:
0020010200035b88c0a8650f0000059f67487bb400010000c0a8660f000002b1
0020010200033eaac0a8650f000005a067487caa00010000c0a8660f000002b4
0020010200033eaac0a8650f000005a067487caa00010000c0a8660f000002b4
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
(2025 payload: 00100003060072c6c0a8650f00000cc3)
By isolating unique payloads you get:
0020010200035b88c0a8650f0000059f67487bb400010000c0a8660f000002b1
0020010200033eaac0a8650f000005a067487caa00010000c0a8660f000002b4
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
Then I tried a parsing of the first payload, results are interesting.
00 20 → 0x0020 = 32 (matches payload length!)
01 02 → likely protocol version or message type
00 03 → subtype / command / channel ID
5b 88 → 0x5B88 = 23432 (this value changes all payload, likely a series number, transaction ID, or session counter)
c0 a8 65 0f → 192.168.101.15 (source IP address!)
00 00 05 9f → 1439 (changes per payload: 1439, 1440, 1445)
67 48 7b b4 → 0x67487BB4 = 1732924340 that decodes cleanly as a Unix epoch timestamp! (seconds), another packets: 67487caa, 6748871e
00 01 → flag or command = 1, constant in all payloads
00 00 → Likely reserved or alignment padding
c0 a8 66 0f → 192.168.102.15 (destination IP address!)
00 00 02 b1 → 689 (changes somewhat per payload: 689, 692, 694)
Given the fixed 32-byte control packet, embedded source/destination IPs, timestamps, repeated sends with identical content, in my opinion UDP port 2753 is here utilized as a rendezvous/control/signaling port. Moreover, I thinked of missed or incorrect receptions: this is suggested, another than by repeated transmissions, besides by any text-mode op-chats besides reported by Kosmod in his comment to the erstwhile post; chats are in Italian language and, according to any UDXF logs, this is likely a military attaché (1):
"MESSO IN CODA 5 EMAIL.....SPERO CHE TI ARRIVI ALMENO UNA AH AH AH" (I QUEUED 5 EMAILS.....I HOPE YOU GET AT LEAST 1 AH AH AH)
"RICEVUTO QUALCHE EMAIL? DUE SU 15... MI LASCIA PERPLESSO" (RECEIVED ANY EMAILS? 2 OUT OF 15... IT LEAVES ME PERPLEXED)
Well, let's work now on the “timestamp” field, bytes 16–19:
67 48 7b b4
67 48 7c aa
67 48 87 1e
Interpreted as big-endian:
0x67487BB4 Decimal: 1732803508 UTC time: 2024-11-28 14:18:28
0x67487CAA Decimal: 1732803754 UTC time: 2024-11-28 14:22:34
0x6748871E Decimal: 1732806430 UTC time: 2024-11-28 15:07:10
Since the same timestamp is repeated across multiple transmissions, it doesn't reflect the sending time, but alternatively the message creation time. It's crucial to note that the timestamps correspond to the recording dates, but for the time (hours:minutes:seconds):
There is something incorrect though, due to the fact that the timestamp in the payloads CANNOT be later than the time of their reception! Since the Unix timestamp is timezone-agnostic, possibly they parse dates in local time by default and then convert to timestamps (without making UTC explicit) or treat local datetime as if it were UTC then convert it to a Unix timestamp: this way you’ll get a timestamp that is shifted by your local offset. It would be a bug, but this way the hr differences would make sense. If my guess is correct, the transmitting station's country should be located in the UTC+2 time zone.
For the sake of completeness, I repeat below the analysis of the payloads recorded in December 2025 followed by a small comparison.
00 10 → Possibly a message kind or any identifier (2 bytes). Hex 0x0010 = 16 decimal (the dimension of the message!)
00 03 → Another 2-byte field, could be message kind or command. Hex 0x0003 = 3 decimal.
06 00 → Could represent a flags field, version, or sub-type. Hex 0x0600 = 1536 decimal.
72 C6 → frequently a transaction ID, session ID, or another 2-byte value. Hex 0x72C6 = 29318 decimal.
C0 A8 65 0F → This looks precisely like an IPv4 address in hex: C0 A8 65 0F → 192.168.101.15 (source IP address!)
00 00 → Possibly padding, reserved, or a 2-byte zero field.
0C C3 → Could be a port, checksum, or any another 2-byte value. Hex 0x0CC3 = 3267 decimal.
Both payloads share the same core structure:
[ Header | Opcode | Flags | TxID | IP #1 | Value ]
that powerfully suggests same protocol or same base message format. Note that the 2024 payloads had an extended basic message with timestamp, status/flag fields, the destination IP address and an additional numeric value.
Other UDP payloads appear to carry DCE/RPC (Distributed Computing Environment/Remote Procedure Calls) protocol: these will likely be explored in a next post.
November 2024 recordings (thanks to Kosmod) were very crucial because, as I said, they highlighted an improvement/adaptation of the application-layer protocol; equally crucial will be fresh recordings of these transmissions made (hopefully) in the next days.
https://disk.yandex.com/d/L4yj5a8xQNpqBA
(1) an armed forces officer assigned by governments to diplomatic missions abroad as a method advisor on matters of military relevance.
