For background read the previous post
I ended the previous post hoping to recover new transmissions to understand more about the used application-layer protocol, and somehow this happened: my friend Kosmod indeed kindly sent me several transmissions he recorded on 20779.5 KHz/USB. The recordings date back to the end of 2024 (November) and this allowed me to understand how - actually - there has been a sort of evolution/improvement of the application-layer protocol that sits above UDP and which is therefore responsible for the UDP payloads.
2024 transmissions follow the same schema: initial MS-141A link setup between ALE address 101 (caller) and 102 (called), then MS-110A running 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) type 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 used during link setup
* IP-type Client/Application, ie 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 previous post... but there is a very important difference compared to the 2025 recordings: here the length of the UDP payload is 32 bytes instead of 16! (double length).
 |
| Fig. 3 - analysis of an IP packet |
Below I report the 32-byte payloads related to 10 consecutive transmissions: as you can easily see, these are repeated transmissions, probably 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 every payload, likely a sequence 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), other 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 slightly 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 used as a rendezvous/control/signaling port. Moreover, I thinked of missed or incorrect receptions: this is suggested, other than by repeated transmissions, also by some text-mode op-chats also reported by Kosmod in his comment to the previous post; chats are in Italian language and, according to some 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 ONE AH AH AH)
"RICEVUTO QUALCHE EMAIL? DUE SU 15... MI LASCIA PERPLESSO" (RECEIVED ANY EMAILS? TWO 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 rather the message creation time. It's important to note that the timestamps correspond to the recording dates, except for the time (hours:minutes:seconds):
There is something wrong though, because the timestamp in the payloads CANNOT be later than the time of their reception! Since the Unix timestamp is timezone-agnostic, perhaps 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 hour 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 little comparison.
00 10 → Possibly a message type or some identifier (2 bytes). Hex 0x0010 = 16 decimal (the length of the message!)
00 03 → Another 2-byte field, could be message type or command. Hex 0x0003 = 3 decimal.
06 00 → Could represent a flags field, version, or sub-type. Hex 0x0600 = 1536 decimal.
72 C6 → Often a transaction ID, session ID, or another 2-byte value. Hex 0x72C6 = 29318 decimal.
C0 A8 65 0F → This looks exactly 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 some other 2-byte value. Hex 0x0CC3 = 3267 decimal.
Both payloads share the same core structure:
[ Header | Opcode | Flags | TxID | IP #1 | Value ]
that strongly 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 important because, as I said, they highlighted an improvement/adaptation of the application-layer protocol; equally important will be new 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 technical advisor on matters of military relevance.
No comments:
Post a Comment