28 June 2022

unid 150-300Bd/509 FSK

Since some days me and my friend Cryptomaster are discussing an FSK signal detected on 6511.50 Khz (CF). Transmissions starts (and ends) with a long reversals sending at 150 baud speed, messages are repeated and are sent at 300 baud; since the measurement of the shift varies slightly from 507 Hz in traffic mode to 513 Hz in idle (figure 1) we decided to fix it in 509 Hz.

Fig. 1 - FSK main parameters

The bitstream shows a 24-bit lenght period, one of which is the phasing bit (the last column of "0s"); data are preceeded by a 240-bit sequence generated by the polynomial x^12+x^10+x^9+x^3+1.

Fig. 2 - the resulting bitstream after demodulation

 
Again, the question arises of whether or not to use Differential FSK mode: infact, as already cited in some previous posts [1][2], as result of the differential decoding, we get a uniform parity check, except for the first combination of bits (figure 3). We think that the differential mode probably does not apply, and that's a kind of "trick". 

Fig. 3 - parity checked stream obtained after differential decoding

Speaking with some of his friends, Cryptomaster was able to use their particular program capable of detecting the presence of any CRC sequences in bitstreams: as a result, after inverting the 9th column of the stream, a clear H(24,16) coding was found, ie 16-bit data followed by 8-bit CRC. We then found and verified the relative (8,24) check matrix

1 0 1 1 0 0 1 0 1 1 1 1 1 0 0 0   1 0 0 0 0 0 0 0
0 1 0 1 1 0 0 1 0 1 1 1 1 1 0 0   0 1 0 0 0 0 0 0
0 0 1 0 1 1 0 0 1 0 1 1 1 1 1 0   0 0 1 0 0 0 0 0
0 0 0 1 0 1 1 0 0 1 0 1 1 1 1 1   0 0 0 1 0 0 0 0
0 0 1 1 1 0 0 1 1 1 0 1 0 1 1 1   0 0 0 0 1 0 0 0
1 0 1 0 1 1 1 0 0 0 0 1 0 0 1 1   0 0 0 0 0 1 0 0
0 1 1 0 0 1 0 1 1 1 1 1 0 0 0 1   0 0 0 0 0 0 1 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0   0 0 0 0 0 0 0 1

Fig. 4 - the resulting CRC (on the right) computed using the (16,8) check sub-matrix

The program that generated the matrix, during the flow check, "fixed the error" in the 9th column of the bitstream, the correction consists of the reversal of the ninth column, perhaps this is done during signal formation. Something similar has been observed in some CIS signals and in Finnish NOKIA. We also found that the check matrix is generated with the polynomial x^7+x^3+x^2+x+1 (figure 5).

Fig. 5

The message data is therefore made up of 202 bytes, organized in a 16 x 101 bit matrix; statistical analysis does not seem to indicate the use of cryptography (figure 6)

Fig. 6

 

For the sake of completeness, I add that in the first instance we tried to de-interlace the stream thinking that it was previously undergoing a block interleaver: then we get a stream arranged as a (24,101) bit matrix. As a result, a (101,84) check matrix was obtained which really encodes the information. But we were puzzled by the fact that only 101-84 = 17 bits of information remain in each codeword (51 bytes of data transferred) with a Hamming distance of 48: quite irrealistic in our opinion.

Fig. 7

https://disk.yandex.com/d/7JHDI9np2IXR3Q

[1] https://i56578-swl.blogspot.com/2021/12/chinese-psk2-2400bd-serial-waveform.html
[2] https://i56578-swl.blogspot.com/2022/06/akula-almost-always-holds-surprises.html

20 June 2022

"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 


18 June 2022

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.

 
(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.


26 May 2022

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/

18 May 2022

1016-protocol & DatronLINK suite to exchange HF email (R.O.C. Navy)

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
 
byte 3: don't know the meaning of this field, I can only see that the four rightmost bits indicated as dtg have the value 1,2,3 respectively in segments 1,2,3 & 4 so it could refert to the number of the datagram coming from the upper layer application. Perhaps the four leftmost bits indentify the type of the data segments, but it's just a speculation.

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.

Contrary to what happens in tx_frames 1,2 the contents of the second field (Src/Dst Address) do not change because these tx_frames are sent by the same node (the caller). The "Sequence Number" and "Packet Number" fields do not need further comments, their functionality is even clearer in tx_frames 3,4.

Fig. 8

As above, the transmitter adds duplicate packets to fill all the packet positions allowed by the tx_frame (ie 8 available position in 600 bps segments). 
 
Fig. 9
 
That said, the format and contents of the datalink protocol should be the following:
 
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

The relationships existing among the fields Src/Dst Address, dtg, and ACK bit-mask are shown in figure below:
 
Fig. 13

3. message analysis
Working on the bitstreams in order to find something that makes sense, I found that data segments must be read in reverse order: that way, ZLIB header 0x78DA (level 9 compression, the best one, as per RFC 1950) and filenames automagically emerge (figure 14).

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

X-Mailer header reveals that users run Windows-based PCs and Microsoft Outlook Express with a build version 6.00.2800.1106 (discontinued, now superseded by Windows Mail)
 
date: and sent: headers Wed, 20 Apr 2022 00:10:33 +0800  and Tuesday, April 19, 2022 11:53 PM say that the message transfer occurred around local midnight, even if sender and receive PC have probably different settings. UTC offset +0800 and character set Big5 are a great help in narrowing down the user detection area
 
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/