Yet another interesting catch of an email-over-HF session, this time recorded on 14360.0 KHz/LSB at 1608z [1]. The usual procedure is used: logical link setup by 2G-ALE 188-141A 3-way handshake (SADLW caller node, SJJES called node) followed by half-duplex data transmission by means of 188-110A modem (figure 1). The data transfer mode uses ARQ acknowledgements to achieve reliable data transmission; each 188-110 segment lasts 15 seconds, delay of the correspondent ACK acknowledgements is 1500 ms, round-trip time is about 19.8 seconds.
 |
| Fig. 1 |
During the link setup procedure, special AMD messages are sometimes used to trigger 188-110A data transfer (FAXDATA CK) or chat (AMDCHAT16), as for example:
[16:29:39][TO][SFHWF][CMD AMD][FAXDATA CK][CMD LQA NO RESPONSE MP=(7) SINAD=(31) BER=(5)][TIS][SEQDI]
[18:54:50][TO][SFDAN][CMD AMD][AMDCHAT16][CMD LQA NO RESPONSE MP=(7) SINAD=(31) BER=(15)][TIS][SWHPY]
However, other type of files are sent w/out those preceeding commands. Other than the ordinary ALE calls and soundings, stations quite frequently exchange AMD strings: maybe it deals with a type of dictionary-based chat but it's only a my guess (figure 2).
 |
| Fig. 2 |
1. protocol analysis
The terms defined below are used to refer to specific types of data objects in defining the protocol:
datagram: an ordered sequence of data bytes incoming from an user application such as an email client
data segment: an ordered sequence of data bytes that occur consecutively within a datagram
packet: a data segment with datalink protocol incapsulation, also known as Potocol Data Unit (PDU)
tx_frame: a sequence of packets (PDUs) to be delivered to the HF modem
segment: an HF modem transmission (ie, an on-air tx_frame)
The datalink protocol emerging after 188-110A overhead removal has a characteristic packet length of 127 bytes or 1016 bits (figure 3) and probably that is reason because it is reported as a not-well specified "Period-1016" protocol, sometimes also referred to as "Brazil-1016". However, as evidenced by the analysis' results, it's actually a proprietary datalink protocol developed by Datron as part of the company HF email software application named "DatronLINK" (1).
The data stream consists of two different type of packets; notice the 1:2 ratio existing between the number of packets of first two tx_frames and the 4th (the 3rd is a "special" tx_frame) although they have same symbols rate and same duration: the reason is that while the first two tx_frames are modulated at 300 bps the following ones have a double rate modulation (600 bps) and then allow eight packet positions.
 |
| Fig. 3 |
The analysis of the bitstreams allows to do some "reverse engineering" of the datalink protocol so to understand its format and contents. Let's start with the firts two tx_frames (figure 4)
 |
| Fig .4 |
byte 1: This field has always the value 0x01, perhaps it indicates the Type of the packet (data or ARQ)
byte 2: Src/Dst Address field. The different signal strengths and fade patterns in figure 5 indicate that while the segment 1 is sent by the caller, the segment 2 is sent by the called node, therefore the alternation of the field' contents is due to the switch between the destination and source address. Anyway, I do not know if the field is the "source" address or the "destination" one. Since its length, up to 255 nodes can be addressed, and that number is the "limit" of a such a network.
 |
| Fig. 5 |
bytes 4,5: the Sequence Number field is a 16-bit field that refers to the position occupied by the data segment whithin the datagram coming from the upper layer application, the value is expressed in ascending order.
byte 6: the Packet Number (or Packet Index) field is the ordinal position of the packet within the tx_frame, is expressed in descending order such that packet number = 0 indicates that the packet occupies the last position in the tx_frame. I think that by numbering the packets in descending order, the receive node will be aware of how many packets the current tx_frame is made up of.
bytes 7-121: Data Segment field. If the data segment has a length less than 115 bytes (because it includes the last data bytes of the datagram), a sequence of null data bytes (of value zero) is appended to the data segment so as to extend its length to 115.
bytes 122-125: 32-bit Cyclic Redundancy Check (CRC)
byte 126: this field has always the value 0x80, as the first field but in reverse order
byte 127: (seecond) Src/Dst Address field. As said above, this field assumes alternate values in segments 1,2 where traffic flows in two directions. Obviously, if one of the two fields is the source address the other is the destination one (and vice versa).
 |
| Fig .6 |
Given that only 2 packets are to be sent (sequence numbers 0,1) the transmitter fills the (otherwise unused) remaining packet positions with repetitions of packets already residing in the current tx_frame, the receive node will inspect the sequence number of each packet received without errors, and use the sequence numbers to identify and discard duplicate packets.
 |
| Fig. 7 |
Given their double data rate (600 bps), segments 3,4 allow 8 packet positions per tx_frame, with the exception of the 3rd tx_frame which consists of only two packets. However it must be noted that the data rate changes (from 300 bps to 600 bps) just in segment 3, thus it's probable that the transmitter uses a "special" 2-packet tx_frame just to test the feasibility of the new mode. This also implies that the datalink application controls the 188-110 modem.
 |
| Fig. 8 |
 |
| Fig. 9 |
 |
| Fig. 10 |
2. ARQ analysis
Beyond the "local" reception, I think it's interesting to see how that transmission was actually received at the recipient' sites: that can be done by analyzing the ARQ packets (figure 11) used to transfer acknowledgements bewteen the receiving and the sending node.
ARQ packets have a structure of 45 bytes in length which corresponds to 360 bits or 120 PSK-8 tribit symbols, thus each ARQ packet needs a transmission time of 50 msec when modulated at a symbol rate of 2400 Baud (on-air packet duration is 1700 msec).
 |
| Fig. 11 |
The Format and content of the ARQ packets can be deduced by joining the four demodulated streams and, although I do not know the structure, some fields can still be identified and described:
Type: probably the "protocol field" that identifies this PDU as an ACK PDU
Src/Dst Address: tow fields each consisting of 8-bit address of the sending and receiving node
dtg: indentifies the datagram that is being acknowledged;
Selective Acknowledgements: in the form of an ACK bit-mask that contains one ack bit for each of the packets that can be received in a tx_frame (32 bit = 32 tx_frames sent in a single 188-110 segment at 2400 bps). Each bit indicates whether the corresponding packet of the "dtg" datagram (ie the corresponding data segment) was received without errors; 1 = ACK (was received successfully); 0 = NAK (not received successfully). Indeed, the number of 1's in the four selective acknowledgements fields match the number of the packets sent in the correspondent four tx_frames (ie: 4,4,2,8).
CRC: 32-bit Cyclic Redundancy Check
 |
| Fig. 12 |
 |
| Fig. 13 |
 |
| Fig. 14 |
The compressed data segments in tx_frames 1,2 consist of the files SADLW59957835.TXS and SJJES122502203.TXS: the filenames contain the ALE callsigns of the nodes involved in the transfer followed by a 8/9 digits number, that number, as well as the extensions ".TXS", is unknown to me. After "inflating" (ie decompressing ZLIB data), the files have the contents F 59678430.MSG\size(?) and C 59678430.MSG\0
 |
| Fig. 15 |
According with what I saw so far, the first two tx_frames of a data transfer always follow the same paradigm, my guess is that it's a kind of simple negotiation such as "ready to send message_ID" followed by "ready to receive message_ID" so that the receive node is aware about "what" will be sent in the tx_frames that will follow (figure 16).
 |
| Fig. 16 |
The reassembled data segments sent within tx_frames 3,4 - as expected - consist of the ZLIB compressed file 59678430.MSG. Once inflated, headers and body of the message offer interesting insights and information (figure 17).
 |
| Fig. 17 |
Message-ID header <001001d85407$ffb3b020$0100007f@s0v7n0> reports the host domain/name s0v7n0: this is the host where the being observed message was created
From and To headers "DatronLINK - SADLW" <SADLW@radio.mail> and "DatronLINK - SJJES" <SJJES@radio.mail> indicates that DatronLINK is the HF email application used: a powerful application developed by Datron and designed to automate message and file transfers over radio links (1), most likely the email domain radio.mail is the default name provided by the application. That domain is clearly not suitable for outbound messaging therefore the gateway function must therefore be provided by the application.
The References header <1E084D883DFC47E2A5AA8429E352B4D7@RT7000PC1> indicates that the message is a reply to a previous one (or a forwarded one), as also indicated by the presence of the "--- Original Message ---" string. Notice the host domain/name RT7000PC1 that indicates a generic PC1 host which is almost surely wired to a Datron RT-7000 transceiver
The Subject: header =?big5?B?UmU6ILGhuOogwuC1b8SlvtSrSKTl?= is particularly interesting: according to RFC 2047 MIME the string must be parsed as: =? <charset> ? <encoding> ? <coded text> ?=
where:
charset = big5,
encoding = B (BASE64),
and coded text = UmU6ILGhuOogwuC1b8SlvtSrSKTl
big5, also indicated in the charset attibute, is a Chinese character encoding method used in Taiwan, Hong Kong, and Macau for traditional Chinese characters (2), BASE64 is a 6-bit encoding (3). Thus I processed the coded text "UmU6ILGhuOogwuC1b8SlvtSrSKTl" in simple steps using CyberChef tool [3] and google translator (figure 18):
1. convert from Base64 [2]
UmU6ILGhuOogwuC1b8SlvtSrSKTl → Re: ±¡¸ê ÂàµoÄ¥¾Ô«H¤å
2. decode to big5
Re: ±¡¸ê ÂàµoÄ¥¾Ô«H¤å → Re: 情資 轉發艦戰信文
3. translate from Chinese to English:
Re: 情資 轉發艦戰信文 → Re: Intelligence forwarding naval warfare letters (as expected!)
 |
| Fig. 18 |
subject: header and body of the "Original Message" contain (apparently) incomprehensible ASCII characters which, as specified by the big5 charset, must be encoded in Chinese characters (figure 19):
 |
| Fig. 19 |
As above, the Chinese strings:
情資 轉發艦戰信文
收悉請回覆級職姓名及 QSL
FM 532 值機員 電信士官長 李春賢
are then translated into English by using some on-line tools:
Google:
Intelligence information Forwarding the warship letter
Upon receipt, please reply to the title and QSL
FM 532 Check-in Operator Telecommunications Master Chief Li Chunxian
Yandex:
Intelligence forwarding naval warfare letters
Please reply to the rank name and QSL when you receive it
FM 532 check-in crew Telecommunications Non-commissioned Officer Li Chunxian
Baidu:
intelligence information forwarding ship war letter
Received, please reply the name of the rank and QSL
FM 532 check-in attendant telecommunications Sergeant Li Chunxian
Bing:
Intelligence Forward the ship battle letter
Please reply to the grade name and QSL
FM 532 Check-in Non-Commissioned Officer Li Chunxian
DeepL:
Information Forwarding Letter from Warships
Received, please reply with name and QSL of rank
FM 532 Flight Attendant Telecommunications Chief Petty Officer Lee Chun Yin
The translated texts , although they slightly differ, lead one to think of a "Navy" email traffic (since the term "warship"); FM 532, which appears in the signature of the parent message, could be the Pennant Number of the warship, while Li Chunxian is the name of the sender.
4. users
I did just a bit of OSINT activity aimed at the finding the relationships between the collected information (Datron, RT-7000, time zone, Big5, FM 532, Li Chunxian, ...) and ended up with the Republic of China Navy, also known as Taiwanese Navy, as the source (also confirmed by frequency/5-LTRS callsigns). To support the finding, I have added two documents from the "Taiwan Department of Defense" and "Taiwan Naval Technical School" confirming the use of the Datron RT-7000 systems by Taiwanese Navy. Figures 20 (procurement of RT-7000 data communication system maintenance) and 21 (courses of Taiwan Naval Technical School) exhibit some relevant extracts. In figure 20, one should know that years 111-113 refer to the Taiwanese time reckoning (Minguo calendar) and correspond to 2022-2024 in the Christian calendar.
 |
| Fig. 20 |
 |
| Fig. 21 |
No particular information about Mr. Li Chunxian except his "role" aboard, as can be deduced from the email signature. Same for the term FM 532 since it could be the "operator code" or, as said, the Pennant Number of a warship: in the latter case it could refer to the Taiwan Navy's "Panshi AOE 532" Fast Combat Support Ship (figure 22), but it's just my speculation!
 |
| Fig. 22 - "Panshi AOE 532" Fast Combat Support Ship, Taiwanese Navy |
Then I wondered why the nickname "Brazil-1016" was chosen to identify the DatronLINK protocol and found a document which literally states "[...] the acquisition of HF equipment from DATRON World COMMUNICATIONS,INC. it is due to the existence of software owned by this manufacturer that performs management of all existing HF Gateway network in the Brazilian Navy" (figure 23).
 |
| Fig. 23 |
The document comes from the "Brazilian Navy - Navy Internal Control Center, Department of Public Management and Process Monitoring" and it's related to the direct hiring of DATRON World COMMUNICATIONS, INC. for the acquisition of seven HF/SSB - RT 7000 transceiver devices, to meet the needs of patrol ships "Grajau", "Guaiba", "Grauna", "Goiana", and the tugboat "Triunfo".
So, most likely some UTE listener, not knowing the real name of the application (that is "DatronLINK"), thought of giving the name "Brazil-1016" to that 1016-bit datalink protocol because largely used by the Brazilian Navy. Just as we do when - for example - we call "CIS-60" the Russian OFDM 60-tone waveform... just because we do not know its real name.
The above document dates back to 2013 but other more recent ones (dated 2018 and 2020) show that the Brazilian Navy could still use the same devices:
 |
| Fig. 24 - MINISTRY OF DEFENSE BRAZILIAN ARMY (2020) |
 |
| Fig. 25 - BRAZILIAN NAVY DIRECTORATE OF NAVY EDUCATION (2018) |
5. conclusions
ROC Navy uses Datron devices (RT-7000 transceivers) and software application (DatronLINK suite) for their informal HF email exchange. The military standards 188-110A and 188-141A are used respectively as HF waveform and for 2G link-setup procedure. Email messages are forwarded using a Datron proprietary ARQ datalink protocol based on 127-byte length packets and ZLIB compression, user data bytes are sent in backwards order (byte-back). The assets use 5-letter callsigns, sometimes shortened to 3, all starting with the same letter. The used email application is compatible with Outlook Express and run on Windows-based PCs.
https://disk.yandex.com/d/pIGJ_6bauGB7rA
(1) DatronLINK (32-bit Windows-based application) can be used with Microsoft Outlook, Outlook Express and other POP/SMTP email clients ad run on appropriate laptop or desktop computers with Datron’s E110A MIL-STD-188-110A/B HF modem and 7000-series radios. DatronLINK fully manages the attached radio sub-system including core radio and ALE functions providing automatic station linking with selection of best channel using MIL-STD-188-141A compatible FED-STD-1045A ALE (7000ALE). The system uses ARQ and FEC protocols to ensure error-free data communications up to 9600 bps with the E110A modem while simultaneously optimizing the data rate to existing HF channel conditions. Datron World Communications was acquired by Titan in September 2001. Titan is now part of the L-3 Communications group of companies. As of 2007, L-3 calls itslef as "L-3 Communications Titan Group".
(2) The People's Republic of China (PRC), which uses Simplified Chinese characters, uses the GB 18030 character set instead. Big5 gets its name from the consortium of five companies in Taiwan that developed it.
(3) BASE64 encoding is represented by six bits (2^6 = 64): during encoding each group of 24 bits (3 bytes) is represented by four 6-bit Base64 digits. During decoding, it is symply set back to eight bits (refer in Table 1 of RFC 2045).
[1] KiwiSDR receiver at OZ1AEF Skanderborg, Denmark
[2] https://www.base64decode.org/
[3] https://gchq.github.io/CyberChef/
No comments:
Post a Comment