STANAG-5066 over MIL 188-110A: Polish CD/TDF messaging

I spent some days monitoring the transmissions of a Polish net on 5094.0 KHz/USB, traffic occurs mainly in the morning from Monday to Friday and consists of ALE link setup followed by voice radio-checks (sometimes) and data exchanges which may last several seconds, up to some minutes (figure 1). Link setup, as usual, is performed by using 2G-ALE 188-141. Results of the analysis of the traffic waveform show the use of 188-110 ST with an high adaptive rate and a good SNR ratio due to the proximity of the receiver [1]; the sub carriers have a slight slip, just a few Hz, from the nominal value of 1800 Hz.

Fig. 1 - a complete transfer

The demodulated bitstreams, such as the one in figure 2, have period lengths that reveals the use of the STANAG-5066 suite at the datalink layer, presence which is also confirmed by the numerous detection of the 16-bit synchronisation sequences 0x90EB, tipycal of that Standard.

Fig. 2 - a demodulated bitstream

The bitstreams have been analyzed using my "STANAG-5066 Dissector" tool [2]; below the traffic-flow output that clearly shows the use of the ARQ (DATA-ACK, ACK-ONLY, DATA-ONLY (simplex)) and non-ARQ (EXP NON-ARQ DATA) transfer modes: 

looking at the waterfalls shown in figure 1, the ARQ segments are recognizable by the different fading patterns.

Further "technical" information can be extracted by examining the data transfer frames as the one shown below:

The most interesting one is the use of a CFTP-based application to send data. The Compressed File Transfer Protocol (CFTP) sends compressed e-mail over an HF link using a file transfer protocol, rather than a mail transfer protocol. Messages produced by an mail application are processed by a MTA (Mail Transfer Agent), compressed in CFTP, segmented in the STANAG 5066 Basic File Transfer Protocol (BFTP), and passed to the subnet interface by the STANAG 5066 Reliable Connection Oriented Protocol (RCOP). At the receiving node, this process is reversed, and the uncompressed e-mail message is delivered to the receiving MTA for delivery or forwarding. CFTP provides the most bandwidth-efficient exchange of data just using BFTP to send compressed file, both the protocols are defined by STANAG-5066 Annex F.10.2.2. By the way, it's interesting to note the use use of HBFTP, see figure 3, that likely stands for the Harris implementation of BFTP protocol (that's a first clue in favour of the use of Harris hardware/software solutions).

Fig. 3

As mentioned, a complete data transfer session (from the link setup to its closure) can last up to some minutes, with large silence intervals during which messages are retrieved and processed for forwarding. Almost all the link requests are sourced by the callsign WA1 (that is likely the net-control station). All messages are delivered to recipients using informal mails which emerge after unpacking the HBFTP--.gz files. 

Usually each session begins with a voice radio-check followed by a "bilateral" QRA request/response (figure 4): perhaps the QRA strings have something to do with message routing, anyway a certain QRA is always sent by a same station (see below).

Fig. 4 - QRA exchanges bewteen WA1,ST3

Quite a bit of information can be gleaned from examining the headers of the mails.
The "From:" "To:" fields allow you to understand who the user of the messaging system is, in this case the top level domain .pl (pl = Poland) suggests a Polish mil/gov newtork; the mail domain is .ga8.pl and the nodes involved in this exchange are WA1 and ST3 (the same callsigns used in the ALE exchanges). The prefix "WMT" used in the mail addresses (such as wmtwa1@wa1.ga8.pl) clearly indicates the use of Harris RF-6760W Wireless Message Terminal (WMT) application, and quite surely they also use the RF-6750W Wireless Gateway (WG) application. The hostnames "cwt.radio" (station WA1) and "radio7de49420a" (station ST3) are also exposed. By comparing the mail addresses and the relative STANAG-5066 frames is then possible to go back to the respective S-5066 addresses WA1 011.000.000.001 and ST3 011.000.000.003 (see below).
A (quite old) Microsoft Outlook version is the used mail application, therefore the HF network nodes use Windows Microsoft-based PCs. The X-HSMTP-Hop (Harris SMTP) header shows that the recipient node is at 1-hop distance (DP and NP values).
[Received: from] "Stanowisko25" (Polish "stanowisko" stands for station, office) is the name the sending or relaying computer, probably the remote mail server used to forward mail from external mail server to WG, or to forward outbound mail from WG. Stanowisko25 should also provide user mail box from wich mail is "pulled from" to the client.
Most of the times, a message mail (QTC) follows the QRA exchange: such mails adopt a same schema:

the first four numbers stand for
message number (21)
group number (30)
day of the month (19)
time (08.30)

time indication seems to have a granularity of 30 minutes (hh.00, hh.30)

Five Z-coded strings follow:
= ZKV = ZAD ZDI ZHN ZQL =

Apparently, the texts resulting from the Z-code translation make little sense, it must be said that each Country can have its own coding that differs from the standard one.

The actual messages always consist of twenty-seven 5-FIGS/LTRS groups:

63118 72301 92285 23977 56651 38765 93511 62687 40203 90410
88997 12303 96027 23809 18777 24397 88893 98093 69555 27998  
76296 75891 88515 47584 32907 35614 45654

GHUYD  GHIKU  XDIFV  BHYTR  KJHGF  OIASG  DLJJG  TEIIA  SIIYT OEIYS
LIPJO  IUIIH  EJDFC  GHJUE  OINHG  POPPY  HGJPP  UIPPI  BYUDE  OPUUY
IIPEL  IIIJM  FDJRE  HDBCF  KJFDV  YTRUD  KOIUP

Fig. 5

Sometimes the 27 groups are sent in two different mails, sometimes in the same mail or grouped (notice that the message numbers are in descending order):

 

messages recepit is then confirmed in a single message:

It may happens that a mail has a MIME type "MS-TNEF" (1) attachment which is encoded using Base64 (2). MS-TNEF (Transport Neutral Encapsulation Format) is a proprietary format used by Microsoft Exchange and Outlook when sending messages formatted as Rich Text Format (RTF), the TNEF part appears as a long sequence of hexadecimal digits, either in the message itself or as an attached file usually named WINMAIL.DAT Unfortunately, most non-Microsoft e-mail clients cannot decipher TNEF blocks, consequently WINMAIL.DAT files serve no useful purpose since the un-formatted message is always sent. Indeed, you may decode the WINMAIL.DAT block from Base64 (figure 6) and then read its contents using a specific tool such as Winmail Opener [4]:  as you see, contents are the same! Notice the path of the mail message within the sending computer at ST3 (C:\Harris\WMTwmt.pst).

Fig. 6 - decoding from base64

You may also decode from Base64 using the command-line tool "base64.exe" [5]:

 

Fig. 7

TNEF encoded mails are about four times larger than their respective Plain Text ones, consequently - if both are sent with the same speed/interleaver - sending RTF-formatted mail needs more air-time, decreasing the overall throughput of the system. Since the purpose of such mails, in my opinion they should turn off TNEF in all their Microsoft mail clients:

-rwxr--r--  1 antonio antonio  663 lug 15 12:31 000_HBFTP--38  (QRA mail - plainTetxt)
-rwxr--r--  1 antonio antonio 2891 lug 15 12:33 000_HBFTP--40  (QRA mail - RFT)
-rwxr--r--  1 antonio antonio  889 lug 13 09:23 023_HBFTP--13  (QTC mail - plainTetxt)
-rwxr--r--  1 antonio antonio 3713 lug 13 11:07 015_HBFTP--48  (QTC mail - RTF)

Back to the user identification, the "star net" calls (3) issued by WA1 (TIS [WA1] TO [GA8]) helped to identify the name of the network and the callsigns of the nodes that compose it. Moreover, given the long monitoring, I also had the opportunity to record some voice radio checks which were then translated from Polish with the help of some UDXF friends; in this way it was possible to trace the names of the stations and match them to their respective callsigns (see below). The voice op-chats highlight a large share of women in service.
Then I did some further investigation about the hostname "stanowisko25" and found that stanowisko.pl is a Linux-based virtual private server (VPS), IPv4 address 85.128.128.104, hosted by the Polish company nazwa.pl [3]. Likewise, the hostname kabina2 indicates the kabina.pl VPS (it shares with stanowisko the same IPv4 address 85.128.128.104 and the same physical host). The server seems to filter out incoming telnet connections to TCP port 25 from unallowed IPv4 addresses, packets are simply dropped with no response. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software (figure 8).

 

Fig. 8

The gathered information allow to draw a (tentative) structure of the 5094.0 KHz HF network at present day (figure 9):

station: Barbin(g) 12 Net-Control Station,
ALE address: WA1 (likely Warzawa 1)
STANAG-5066 address: 011.000.000.001
mail address: wmtwa1@wa1.ga8.pl
hostname: cwt.radio
associated QRA: 0370,3369,4295,6063,6138,9287,9339,9542,...

station: Alik 64
ALE address: AL6
STANAG-5066 address: 011.000.000.005
mail address: wmtal6@al6.ga8.pl
hostname: radiozbamqxsqq
associated QRA: 7213,4382,6385,8352,8463,...

station: Depozytor 32
ALE address: DE3
STANAG-5066 address: 011.000.000.006
mail address: wmtde3@de3.ga8.pl
hostname: SOHARRIS1
associated QRA: 2849,3668,...

station: Fenix 69
ALE address: FE6
STANAG-5066 address: 011.000.000.004
mail address: wmtfe6@fe6.ga8.pl
hostname: kabina2
associated QRA: 5362,9462,...

station: Kraków 20
ALE address: KR2
STANAG-5066 address:
mail address:
hostname:
associated QRA:
(several ALE exchanges logged but no data transfers)

station: Stawka 38
ALE address: ST3
STANAG-5066 address: 011.000.000.003
mail address: wmtst3@st3.ga8.pl
hostname: radio7de49420a
associated QRA: 2564,3497,6253,6380,...

Fig. 9 - presumed structure of the Polish HF network GA8 (at July 2022)

The lack of cryptography and the  op-chats style (maybe volunteers?) make me think of Polish Civil Defence (CD) or Territorial Defence Force (TDF) as the most likely user.

Same type of traffic was heard on August 2016:
https://i56578-swl.blogspot.com/2016/08/yet-another-email-exchange-via-stanag.html 

 

Last minute update:

It's much more probable that both "stanowisko" and "kabina" are just random domains registered with nazwa.pl, the IP address they point to is one of the servers hosting the default page / landing page of all nazwa domains" as my friend ZZZ (whom I thank) emailed me.

 

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

(1) MIME type "MS-TNEF" (Transport Neutral Encapsulation Format) is a proprietary format used by the Microsoft Exchange and Outlook e-mail clients when sending messages formatted as Rich Text Format (RTF). When Microsoft Exchange thinks that it is sending a message to another Microsoft e-mail client, it extracts all the formatting information and encodes it in a special TNEF block. On the receiving side, a Microsoft e-mail client processes the TNEF block and re-formats the message. When you receive a TNEF-encoded message with a non-Microsoft e-mail client, the TNEF part appears as a long sequence of hexadecimal digits, either in the message itself or as an attached file usually named WINMAIL.DAT.

(2) The MIME (Multipurpose Internet Mail Extensions) specification (RFC 1341 and successors) defines a mechanism for encoding arbitrary binary information for transmission by electronic mail. Triplets of 8-bit octets are encoded as groups of four characters, each representing 6 bits of the source 24 bits. Only characters present in all variants of ASCII and EBCDIC are used, avoiding incompatibilities in other forms of encoding such as uuencode/uudecode.

(3) As per MIL 188-141 Appendix A, a star net call is identical to a one-to-one call, except that the called station address is a netaddress. The purpose of a net call is to rapidly and efficiently establish contact with multiple prearranged (net) stations (simultaneously if possible) by the use of  a single net address, which is an additional address assigned to all net members in common.

[1] http://websdr.printf.cc:8901/
[2] https://i56578-swl.blogspot.com/2021/02/a-stanag-5066-off-line-dissector.html
[3] https://www.nazwa.pl/vps/
[4] https://www.eolsoft.com/freeware/winmail_opener/
[5] https://disk.yandex.com/d/df8P6EkaaXrDLw