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

Thales HDR Single Tone modem? (TRC-3600/3700 family)

 

I rcently spent a bit of time monitoring the data transfer sessions which frequently happen on 6478.0 KHz/usb in ARQ mode. As usual, transfers start with the link setup stage: the particular and distinguishable shape of the ALE burts makes it possible to identify the Thales Systeme-3000 Skymaster ALE. The initial part of the ALE burts is SDPSK (Symmerical Differential PSK) modulated at 2000 Baud speed with a carrier frequency of 1600 Hz; as you see, transitions do not traverse the origin and the information is stored in the transitions and not in the states (figure 1). The initial part is followed by short MFSK-8  125 Baud segment that is not compatible with MS 188-141 2G-ALE although the scope be the same (they use different tones library).

Fig. 1 - Systeme-3000 Skymaster ALE

The SDPSK part exhibits a 50ms ACF that corresponds to a 100-bit frame (figure 2)

Fig. 2

Data bursts are PSK-8 modulated at a symbol rate of 2400 Bd and exhibt a 106.6 msec ACF (corresponding to 256 symbols) but adopt diferent frame structures: likely it's due the the adaptive feature of the modem which therefore adopts different data rates and waveforms (figs 3,4).

Fig. 3

Fig. 4

The presence of the Systeme-3000 ALE bursts - and thus a Thales proprietary waveform - suggest that the 2440Bd/PSK8 waveforms (used for data) are sourced by the High Data Rate modem incorporated into the TRC-3600/3700 family of combat radios. Quoting TRC-3600 datasheet: "It integrates a high data rate, multiwaveform, single tone modem (from 75 to 5400 bps) and a vocoder (800 - 2400 bps) associated to a high security digital COMSEC chip. The performances of the modem, the use of powerful error correction codes and the use of real time adaptive procedures enable to offer reliable HF links even on a severely degraded ionospheric path. The links are automatically optimized in real time according to the possibilities of the HF channel".

...and yes, yet another 106.6 ms ACF waveform.

 https://disk.yandex.com/d/GAB7inxTA7-QWw

"Akula" almost always holds surprises

"Akula" almost always holds surprises when it happens to came across its transmissions, is the case of a recording kindly sent me by my friend ANgazu that is characterized by at least three points:

1) the transmitter was used as soon as it was powered-on or in-standby: you may notice a slight frequency increase of a few seconds, about 37, before reaching the working frequency (figure 1): say that it's a kind of "cold-start" maybe due to an urgency call?

Fig. 1

2) one of the bursts is sent in inverse polarity (figures 2,3)

Fig. 2

Fig. 3

3) the initial bursts consist of a train of pulses (not always of the same number) instead of the usual 500Bd BPSK (figure 4)

Fig. 4

Also notice the transmission of the lower tone before and after the messages, it seems that the involved modems have different behavior. The number of the exchanges is also unusual.

However, it must be borne in mind that the current times are ...quite "particular".

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

Some comments about the German Navy STANAG-4285 fleet broadcast

updated
I noticed that in their STANAG-4285 600bps/Short fleet broadcast the German Navy use a 7-bit framing consisting of [5-bit data] + [one parity bit (even parity)] + [one pahsing bit], such framed stream is differential encoded and then forwarded to the S4285 modem.

Fig. 1 - 7-bit framing adopted in S4285 600bps/Short broadcasts

Fig. 2 - the differential decoded stream is parity bit checkd

Such peculiar framing, a "new one" for me, is used in several frequencies (see Table I) and most likely is thinked for their "domestic" fleet broadcast (as the French Navy does with their characteristic 21-bit framing); indeed in other S4285 frequencies the German-Ny run the NATO "standard" fleet broadcast consisting of the S4285 600bps/Long sub-mode and KW-46 encryption (figure 3).

Fig. 3 - KW-46 sync sequence in S4285 600bps/Long broadcasts

The 5-bit user data are most likely encrypted, the quality of the cryptography can be evaluated with a statistical method or by calculating the Shannon Entropy of a stream. The statistical test determines the randomness of the bit stream, the number of single bits in the stream is counted, then the double bits, then the triple bits and so on to the end. The result is a graph: If the information is not systematic, the adjacent columns should be half the size of the previous ones. The tes for these bit streams show good encryption quality. The measure of the Shannon Entropy can be used, in a broad sense, to detect whether data is likely to be structured or unstructured. 8 is the maximum, representing highly unstructured, 'random' data. Properly encrypted or compressed data should have an entropy of over 7.5

Fig. 4 - measurements about the presence of encryption in the 5-bit user data sub-frames

I also noticed that each 773 frames (5411-bit length blocks) a sequence of 588 bit length is inserted into the stream for a total length of 5999 bits (figures 5,6): that sequences are not repetitive, do not have a defined period, do not have a parity bit check, and do not seem  generated by a polynomial (at least in my attempts).

Fig. 5

Fig. 6

Just two coincidences:

1) in differential mode the bits after the inserts are of the same number of the inserted 7-bit frames (84)

2) as you know, the block consisting of 773 7-bit frames plus the 588 inserted bits has a length of 5999 bits that corresponds to a 10 seconds interval of a  stanag-4285 transmission at 600 bps (unless 1 bit)

 

In my opinion the 588-bit blocks are inserted before the differential encoder:

 

and they could be the "control bits" (also termed "EDAC bits", Error Detection And Correction bits) which are appended to the source bits after their comparison with a parity check matrix (1). If so, the dimension of the check sub-matrix shall be:

- (588 rows, 5411 columns) if the check is applied to [5-bit data]+[parity bit]+[phasing bit], ie to the whole 7-bit frame
- (588,4638) if the check is applied to [5-bit data]+[parity bit]
- (588,3865) if the check is applied to [5-bit data] only

 

Obviously, the possibility of such a matrix presupposes the use of a polynomial of degree 588 (!). 

But I have still some doubts. Data integrity is in some way "ensured" by the use of the parity bit and the differential encoder, moreover data are FEC encoded (rate 1/2) and interleaved by the S4285 modem, so why use a such complex CRC? It is also necessary to take into account the processing time necessary for the formation of one 588-bit block (and check it at receive side) since up to 5411 comparisons are required for each single EDAC bit (more than 3 million comparisons per block in the worst case, more than 2 million  in the better one).

 

Frequencies/modes so far monitored along with DFs of Tx sites (TDoA algorithm) are reported in this page.

 

18th June update

Discussing with my friend cryptomaster we think that the differential mode probably does not apply, indeed this "trick" of converting the phasing-bit to the parity-bit was noticed for istance some times ago when anaylzing the Chinese PSK2 2400Bd serial waveform:

https://i56578-swl.blogspot.com/2021/12/chinese-psk2-2400bd-serial-waveform.html
Repeating the tests of my friend, I took a small amount of bits from an unsystematic stream (fig. 7a) and reshaped them to a 10-bit period stream (fig. 7b), then I edited the last column by inverting some bits and turned them into a phasing bits column (fig. 1c). As a result of the differential decoding, I received a uniform parity check, except for the first combination of bits (fig. 7d).

 

Fig. 7

That said, it could be that they use a channel which is designed to work with a 7-bit framing (for istance the one used in the "standard" NATO fleet broadcast) to send 5-bit encrypted data. If so, they have to add two bits (1's) to the 5-bit encrypted data and two bits (0's) to the 5-bit framed Initialization Vectors (perhaps to distinguish them?). The 588-bit CRC (computed on 773/761 frames) instead is sent as-is. Is not clear if CRC is computed on five or seven bit frames.

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

 

(1) As usual, code verification is carried out by comparing each line of code in turn with all the 588 rows of the check sub-matrix: the vertical correspondences of the "1s" positions in the code line and in the row #n of the check sub matrix are counted. If the matches are even then the correspondent position #n in the EDAC bits will be "1", otherwhise (ie matches are a odd number) will be "0". The values 1/0 of the EDAC bit will be the opposite in case of odd parity.

a curious 8N1 async 188-110A transmission (MoD RK)

Interesting recording of a Kazakh-Mil transmission sent to me by my friend cryptomaster. The transmission was heard on 10213.0 KHz / USB at 0656 UTC and dates back to March 2021: not as recent but still interesting given the nature of the sent message and the used HF waveform: ie, MIL 188-110.

 

the message
After decoding, the bit stream has a clear 10-bit period due to use of the 8N1 asynchronous frame: eight data bits, no parity, and one stop bit (figure 1)

Fig. 1

Two annotations can be made after removing the start and stop bit columns:

1) The data block is preceded and closed by a repetitive pattern which is part of the binary sequence generated by the polynomial x^9+x^8+x+1, probably for synchronization purposes (figure 2)

Fig. 2

2) The data consists of a compressed file, more precisely of a "zipped" file, as understood by the presence of the characteristic ZIP header 50 4B 03 04 (0x04034b50 stored in little-endian byte order):

Fig. 3

The quality of the signal is quite good and therefore it allows to go back to the source file by saving the 8-bit file with the extension .zip and then proceed to its decompression using the common unzip app. A decoding tool shall also be needed for recovering "scrambled" text into Cyrillic alphabet, google translate will do the rest (basically, it's a sample of the communications status report).

the used HF waveform
As said, the transfer is performed by a 188-110A Serial modem running at 150 bps. One might wonder why a CIS member country uses a NATO/US standard such as MIL-STD 188-110 for domestic communications. Well, some considerations need to be made.
In May 1994, Kazakhstan joined NATO's Partnership for Peace program, which entailed political consultations and joint military operations, and agreed an Individual Partnership Action Plans - IPAP (1) with NATO. Other than take part in NATO's REGEX exercises, since 2006 Kazakhstan has hosted the Steppe Eagle international tactical military exercise annually in cooperation with NATO and regional partner, the exercise was last held in June 2019 (2). Therefore, from what has been said their communications are likely to be based on these standards. And just not waveforms.
I extracted a frame (at time 3:37) from a youtube video, published by the Military Engineering Institute of Radio Electronics and Communications of the Ministry of Defense of the RK [1], where the use of a "Western-made" HF transceiver is clearly visible (figure 4):
 

Fig. 4

Well, I did some image search and found that the used device is the Tadiran HF-6000 produced by the Israeli Elbit System (figure 5):

Fig. 5

Further research confirms Kazakhstan's interest in military radio equipment manufactured by Elbit [2].

A final consideration must be made regarding the way used for the transfer of the message, or at least for this message. In addition to the 8N1 framing, it's to notice the lack of a datalink protocol, ie the message is sent "as is" and not as an attachment to an email message (for example). This "direct" way of transferring files is easier to encounter in less sophisticated waveforms such as FSK.

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

(1) Individual Partnership Action Plans (IPAP) are plans developed between NATO and different countries which outline the objectives and the communication framework for dialogue and cooperation between both parties.

(2) Steppe Eagle exercises have been canceled for political reasons or due to unease on the part of Kazakhstan regarding the United States.Of course, there’s a more obvious reason that the Steppe Eagle exercises have not been held since the summer of 2019: the COVID-19 pandemic.
https://thediplomat.com/2022/02/.../steppe-eagle-exercise-will-no-longer-fly/

[1] https://www.alem-edu.kz/en/university/voenno-inzhenernyj-institut-radioele/
[2] https://en.tengrinews.kz/military/kazakhstan-bought-israeli-technologies-for-producing-7718/