4 November 2019

Baudot FSK 100Bd/500 (unid Rus Gov/Mil)

Interesting async ITA2 5N1.5 FSK 100Bd/500 tuned on 11019.0 Khz some days ago. Once demodulated, the content consists of (off-line) encrypted 5LGs groups. Note also the slight deviation of the speed.


The transmission ends with the FSK-MORSE op-chat "CFM QRQ 100 QBN K": almost surely Russian Gov/Mil users.


Same 5LGs format and 5N1.5 framing was found in the reception reported in this post, with the difference that the latter has a speed of 50 Baud.


17 October 2019

async FLSU call followed by STANAG-4197 (3G-HF "circuit mode")

This transmission was logged and recorded by my friend DK8OK Nils on 11228.0 KHz/USB, and refers to op-comms between  "INY" Trapani-Birgi airport and "DHN66" Neuteveren/Geilenkirchen NATO air base (INY provides technical-operational and logistical support to the AWACS of the E-3A Component, based in Geilenkirchen). Nils kindly sent me the file for its analysis.
The sample is an example of a STANAG-4538 3G-HF FLSU (Fast Link Setup) asynchronous call followed by traffic in "circuit mode" (data continuous, not packed); short voice comm is in the middle. Although synchronous calls are the preferred mode in 3G networks, async calls might be used if the called (or the caller) station may not have achieved net synchronisation. 
The BW5 burst waveform used by FLSU is recognizable in the initial PSK-8 segment from its duration and from the conveyed tribit symbols (2432), as it results from the cross correlation function and the demodulated stream (Fig. 1).

Fig. 1 - CCF/ACF and demodulated stream
According to Annex C to STANAG-4538, the async call of FLSU protocol begins with the LBT (listen before transmit) for at least one dwell period, followed by the transmission of 1.35N (nearest integer value) Async Request PDUs on the requested link frequency, where N is the number of channels in the scan list, and 1.35 is the duration of each dwell period in seconds. The async call procedure ends with a single LFSU Request PDU (Fig. 2).

Fig. 2 - async FLSU PDUs
Looking at the 50-bit payloads in Fig. 2, type 3 (011) PDUs are sent 10 times and are followed by a single type 0 (000) PDU: since PDUs type 3 indicate the Async_FLSU_Req PDU, and type 0 indicates the FLSU_Request PDU, the sample exactly matches the async call procedure as above. By the way, it's worth noting that since up to 10 Async_FLSU_Request PDUs are used, 7 are the allocated channels for this network.


001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 011 111111 010010 11011011
001 00 0000101000 0000001010 1 0 000 111111 010010 01001101

The STANAG-4197 waveform following the call is most likely used in a ANDVT modem in order to achieve secured voice transmission.  
Notice the apparent lack of the fourth doppler tone at 2812.5 KHz: indeed, it's seems just barely visible in the bottom sonagram of Fig.3: probably a defect/malfunction of the HF modem. 

Fig. 3 - STANAG-4197 segment

4 October 2019

NILE/Link-22 168-bit packets (STANAG-4539 TDMA WF2 waveform)

(updated)
For background it might be helpful to read the posts:
TDMA waveforms, Annex D to STANAG4539 
NILE/Link-22 traffic waveform #2 

In the sample being analyzed, the 270 symbols of the Media Code Frames are transmitted at the modulation rate of 2400 baud and follow the QPSK waveform #2 structure that consists of 8 sections with 18 symbols DATA blocks and 15/16 symbols Mini Probes (MP). 

Fig. 1
Table 1 - Modulation Type and Contents for WF2 (Annex D to STANAG-4539 Edition 1)
The number of Media Code Frames to be transmitted per TDMA slot (i.e. a burst) is specified to the modem by the Link-22 System Network Controller (SNC) based on the Data Link Processor (DLP) supplied parameters and hence the size of the number of network packets that shall be used to accomodate the incoming messages.
In this sample each slot is composed of 9 frames each consisting of 168 bits, as specified in Annex D to S4539 (WF2, RS(36,21) in Table 2) and in a Link-22 publication [1] about the minimun size of a network packet (Table 3). Both the Tables refer to HF Fixed Frequency operations (HF FF).

Table 2 - Waveform Summary (Annex D to STANAG-4539 Edition 1)
Table 3 - Link-22 transmission media types (Understanding voice and data link networking [1])
My friend YING coded a sofware to demodulate and decode Link-22 WF2 samples, he kindly sent me a decoded bitstream and gave me some interesting insights: "I also found that (1) most of waveforms meet the RS(36,21), and seems only a little meets the RS(36,30). (2) all the RS decode bits have the byte 0x0B, which is strange" YING says. Indeed, the bitstream has a very interesting pattern (Fig. 2):

Fig. 2- Link-22 decoded stream (168 bits window)
Even more interesting is the hex representation of a single TDMA slot (9 frames) which exhibits features that are not immediately visible at glance in the bitwise representation:

48-bit fields A and A' has the same contents

4-bit fields marked with "*" differ by 0x8
4-bit fields B and B' has the same contents
4-bit fields C and C' has the same contents

- fixed position of the byte 0x0B (as noted by YING)

         A          B             C          A'         B'   C'
 ----------------- *-             -  ----------------- *-    -
 29 FB 1F A9 44 20 A9 C4 9F 96 C4 1F 29 FB 1F A9 44 20 29 0B 1E
 5F CA E1 95 32 11 57 F8 E9 A7 3A 23 5F CA E1 95 32 11 D7 0B 22
 DB A6 9E 99 B6 7D 28 F4 6D CB 45 2F DB A6 9E 99 B6 7D A8 0B 2E
 8C F5 65 E3 E1 2E D3 8E 3A 98 BE 55 8C F5 65 E3 E1 2E 53 0B 54
 22 D4 3F A6 4F 0F 89 CB 94 B9 E4 10 22 D4 3F A6 4F 0F 09 0B 10
 3E CB AC CD 53 10 1A A0 88 A6 77 7B 3E CB AC CD 53 10 9A 0B 7A
 7A A0 B0 DD 17 7B 06 B0 CC CD 6B 6B 7A A0 B0 DD 17 7B 86 0B 6A
 FE F5 04 CE 93 2E B2 A3 48 98 DF 78 FE F5 04 CE 93 2E 32 0B 78
 3C B6 D0 A7 51 6D 66 CA 8A DB 0B 11 3C B6 D0 A7 51 6D E6 0B 10

(each 168-bit row is a 112.5ms Media Code Frame)


Quoting STANAG-5522 TACTICAL MESSAGE CONSTRUCTION: "Link-22 tactical messages are functionally oriented, variable length strings of an integer number of up to eight 72-bit words (Tactical Message Words).  These 72 bits words are formatted into network packets by the System Network Controller.  Parity bits for Forward Error Correction are applied at the Network Packet level". This means that what we see are network packets and not solely Link-22 messages.
If it's easy to verify that the number of Media Code Frames carried by a burst is 9, it is however difficult to establish the number of 72-bit words and hence the possible format of the message (from 72 up to 576 bits long). Help in this direction comes from the hex stream. Link-22 traffic is usually encrypted by KIV-21/LLC, a stand-alone in-line network crypto device: the stream, however, does not seem encrypted. Looking at the Link-22 Functional Diagram in Fig. 3, the NETSEC FUNCTION block provides akso an unencrypted interface for the transfer of control and status information (C&S):

Fig. 3 - Link-22 Functional Diagram (STANAG-5522 Edition 1)
Thus, an easy conclusion could be that each 112.5ms frame transports two unencrypted Link-22 words (144 bits) plus 24 bits low-level overhead (Error Detection And Correction (EDAC) bits, flags, spare, etc.?). Table 4 confirms my guess:

Table 4 - Waveforms, RS code rate, and Link-22 words
("Technical handbook for radio monitoring HF", Roland Proesch)
Table 5 is the result of a my comparison between Tables 2 and 4: it turns out that a fixed length of 24 bits is always appended. Curiously, this length is 1/3 (24 bits) of the length of a Link-22 word (unfortunately Table 5 is limited to the waveforms WF1-3 since the new annexes to STANAG-4539 are not at my disposal).

TABLE 5
Just as a test I tried a quite raw suddivision in which the fields that have the same values occupy the same positions within two Link-22 words:

 71                      00           71                       00
 --------------------------            --------------------------   
 29 FB 1F A9 44 20 A9 C4 9F  96 C4 1F  29 FB 1F A9 44 20 29 0B 1E
 5F CA E1 95 32 11 57 F8 E9  A7 3A 23  5F CA E1 95 32 11 D7 0B 22
 DB A6 9E 99 B6 7D 28 F4 6D  CB 45 2F  DB A6 9E 99 B6 7D A8 0B 2E
 8C F5 65 E3 E1 2E D3 8E 3A  98 BE 55  8C F5 65 E3 E1 2E 53 0B 54
 22 D4 3F A6 4F 0F 89 CB 94  B9 E4 10  22 D4 3F A6 4F 0F 09 0B 10
 3E CB AC CD 53 10 1A A0 88  A6 77 7B  3E CB AC CD 53 10 9A 0B 7A
 7A A0 B0 DD 17 7B 06 B0 CC  CD 6B 6B  7A A0 B0 DD 17 7B 86 0B 6A
 FE F5 04 CE 93 2E B2 A3 48  98 DF 78  FE F5 04 CE 93 2E 32 0B 78
 3C B6 D0 A7 51 6D 66 CA 8A  DB 0B 11  3C B6 D0 A7 51 6D E6 0B 10

However, the byte-oriented view is misleading and actually makes a poor sense since the words and overheads are structured in bits rather than in bytes. (1)
Moreover, it should be noted that we do not have to deal with clean and reassembled packets but just with decoded on-air symbols. I mean that Link-22 network packets may undergo a fragmentation and probably that is what we are facing: indeed, the autocorrelation of the bitstream exhibits a strong value of 96 bits i.e. just one 72-bit word plus 24-bit overhead (Fig. 4). 

Fig. 4 - TDMA slot autocorrelation
Summary
Based on the above, we think that the analyzed sample consists of unencrypted Link-22 F-series C&S messages, although it could also be 70-bit Link-16 messages which are encapsulated in Link-22 structure. At least for waveforms WF1-3, the network controller always adds 24 bits overheads to the incoming Link-22 messages: we need more time to study this block and find the CRC sequence (if any).

24-bit overheads update (October, 4)
The packets after WF2 RS(36,21) decoding consist of 144 bits which are needed to convey two words, plus 24 bits of overhead. Referring to Figure 3, these packets are somewhere inside the Signal Processing Controller block which performs modulation and demodulation, as well as error detection and correction (EDAC). Well, I think the 24 bits overhead partly consist of CRC bits (I do not think a CRC-24 is used).
As STANAG-5522 seems to suggest, Link-22 applies the CRC to the whole of words of each packet (i.e. not to each word). Although actually I do not know neither the length of the CRC neither its positioning inside a packet, most likely Link-22 uses a CRC-16 parity check. The remaining 8 bits could be used to accomodate the needed bits for the packet header and maybe one or more additional spare bits so to match the numbers of the k-bytes used for Reed Solomon encodings.
Indeed, as you can see in table 5, the value of k in RS(n,k) codings is 3 bytes longer than the room needed to convey the words. According to the waveform being used, SPC will package words, header, and CRC bits into a packet of the appropriate number of bits for modulation and transmission. 
(to be continued)

(1)
The data fields used are of 3 types: binary, logical, and numeric. Binary data fields are one bit fields containing a 0 or 1. The meaning of the value of each field is described in the applicable message definition. Logical data fields are multibit fields whose bit configurations represent logical values as described in the applicable message definition. Numeric data fields are multibit fields whose bit configurations represent actual numeric values. Spare fields are included in some messages. When transmitted, these spare fields will be encoded as zero and shall not be processed upon receipt. 

16 September 2019

CIS Makhovik (T-230) in CIS-12 and PSK2/1200bps waveforms

Recently my friend KarapuZ gave me the chance to analyze a CIS-12 bitstream and I took the opportunity to wotk on the "format" of Makhovik and then compare the CIS-12 stream with other Makhovik  streams coming from PSK2/1200bps modulations. The results are rather interesting even if the lack of official documentation and the number of available samples do not allow any exact classification but only hypotheses.

Makhovik (the "flywheel") is a well known Soviet-Mil crypto system also used by The National People's Army of the former German Democratic Republic (NVA, Nationale Volksarmee). Although someone classifies Makhovik as vocoder, it can can be used for time-multiplexed encryption of both voice and data up to 9600 bps. It's official name is "T-230 bundle ciphering device for teleprinter and data connections" and was designed to operate in UHF but very often is found in LF and in HF.
T-230 main unit (Fig. 1) consists of four slots:
AT-3002M multi-channel modem for LF channels,
AT-3004D multi-channel modem for HF channels (CIS-12 waveform, also known as MS5 or "Fire"),
AT-3001M voice scrambler (five per unit system maximum),
AT-3025 signaling unit and pager (two per device system).
The T-230-1A is a single-channel version of the T-230. The device contains the cipher, modem and radio as well the vocoder. The system is constructed with 3 modules / blocks and provides  two 1200bps channels in its basic configuration. Several T-230-1A can be used in stationary operation with the modem of the multi-channel variant, AT-3002 and AT-3004D. 8 keys can be set for a maximum of 8 subscriber networks.

Fig.1 - a T-230 system
AT-3004D/AT-3104 (CIS-12)
CIS-12 is a pseudo OFDM 12-tone (+ 1 pilot) waveform using PSK2 or PSK4 modulation at speed of 120 Baud while the modem name is AT-3004D (or its newer counterpart AT-3104). Channels 1-10 are used for data, 11 and 12 are test/service channels, therefore the "aggregate" speed is 1200 Baud (just as the baudrate of the waveform of T-230-1A system).
The structure of the preamble (Fig. 2) in some way resembles the one described in MIL 188-220 Appendix D, "standards for COMSEC transmissions": I refer to that terminology just for the sake of clarity and to better illustrate my guess, as said there is no confirm about it. 

Fig.2 - CIS-12 Makhovik
The two "frame sync" blocks consist of the 15 bits repeating pattern "000010100110111" (or "111101011001000" according to the polarity).
The block bewteen the two frame sync blocks is the more interesting (Fig. 3). It consists of 511 bits long pseudo-random sequences generated by the primitive polynomial x^9+x^5+1 [1], thus meeting with ITU Recommendation O.153 [2]. This pattern is primarily intended for error measurements at bitrates up to 14.4 kbit/s. Anyway, 511-bit length sequences are also used for synchronization purposes as in 188-110B "39-tone parallel mode" (see Appendix B #5.4.3). Since the 511-bit block is not reinserted, I tend to think that it's used to sync the receive side (the modem or the crypto device). It's worth noting that although ITU O.153 reports that the longest sequence of ZEROs is 8 (non-inverted signal), I found some sequences with a greater length: maybe it can depend on the OFDM demodulator or the quality of the signal, or maybe the used sequences are not fully ITU O.153 compliant.

Fig.3 - CIS-12 511-bit sequences
Finally, what I call here as the "Message Indicator" is a 720-bit long block consisting of 8-time triplicate 30-bit sequences. This part is composed of eight strings of 30 bits and each string is repeated 3 times (Fig. 4). The x3 redundancy, as well as in other krypto device as KG-84, is used to improve the accuracy and realiability of the reception. Encrypted data follow this block.

Fig.4 - CIS-12 720-bit MI
T-230-1A (PSK2 1200bps)
The same blocks (sync,511,MI), with a different arrangement, can be observed in a full sample of a PSK2 1200bps (file "_b" in the downloadable zip archive). In this case the 15-bit sync pattern is reinserted several times as well as the MI blocks (Fig. 5).

Fig.5 - T-230-1A Makhovik
In my archive I found other samples that presumably are attributable to T-230-1A (files "_a" and "_c" in the downloadable zip archive): unfortunately I went late on these transmissions therefore it was not possible to examine their preamble.
In these samples (Fig. 6) the 15-bit sync frame block is missing but, as I specified, it could be inserted at the start of the transmission. A second interesting feature is the use of sequences of 511 bits of length BUT which are not originated by the polynomial x^9+x^5+1! 
 
Fig.6 - other PSK2 1200bps samples with Makhovik format

All the three PSK2 samples anyway have the same 30-bit MI structure as the one seen in CIS-12 (Fig. 7)


Fig.7 - 30-bit MI blocks

I would like to point out that this post does not claim to provide a description of the Makhovik encryption protocol but is just limited to the presentation of results obtained from the analysis of some samples: further (many) recordings are needed as well as tips and help from friends.

https://yadi.sk/d/j9HShkWFQo5z9g


[1] https://en.wikipedia.org/wiki/Linear-feedback_shift_register
[2] https://www.itu.int/rec/T-REC-O.153/en

10 September 2019

STANAG-4285, async Turkish "T-15"

05300.0 KHz/USB (intruding the 60mt amateur band), Turkish Mil prob. from Izmir area, TUR. STANAG-4285 600bps/L carryng async 5N1.5 (Turkish "T-15") stream: most likely encrypted pseudo-random naval broadcast since after removal of start/stop bits the resulting 5-bit stream does not autocorrelate (ACF = 0). A similar S4285 transmission but with 15/128 bits length period has already been reported here.
Notice that "T-15" is not an official name nor a well-known name: it's just a nickname I use in this blog to refer to this Turkish 15-bit format.

 



Signals and recordings gathered thanks to KiwiSDRs: kiwisdr.yo3iul.ro, sdr.ok2kyj.cz.

update

I gladly add a comment from my friend Valentin (cryptomaster): "The encrypted information was transmitted in "start-stop" mode with a 5-bit code with the addition of 1 bit - "start" and 1.5 bit stop. Since the transmitting equipment is designed to transmit an integer number of bits, the two halves of the code accumulated during the transmission are added up to one additional bit (0.5 + 0.5 = 1). Thus, a period of 15 bits is obtained.
The 5-bit code statistics are uniform, which confirms the use of encryption." 



26 August 2019

6 KHz wideband OFDM-160 PSK2/QAM-16

6 KHz wideband OFDM-160 30.469 Bd/37.5 Hz PSK2 & QAM-16 spotted on 10342 KHz (CF), probably it's connectd to the OFDM-80 seen a few days ago. Some packages of this  transmission have PSK2 modulation, other QAM-16. ACF of the transfers is equal to zero. As suggested by my friend KarapuZ, for a correct analysis it is necessary to load only the central body of a package excluding preamble and trailer.
Friends from radioscanner.ru have noticed versions of this OFDM with QPSK, PSK8, and QAM-32 modulations in the channels.



Transfers begin and end with short MFSK sessions although they are shifted upwards with respect to the central frequency of the OFDM. Don't know if the MFSK waveforms are used for link establishment or for other communication-oriented signaling.


23 August 2019

CIS-75 FSK 75Bd/250, LFSR 128-bit sequence (tentative)

This post is a follow-on of the previous one and shows some findings due to the collaboration between myself and my friend Valentin (cryptomaster).

We saw that CIS-75 uses a 128-bit length pseudo-random sequence which is inserted repeatedly in the data stream probably to re-sync the receive modem. As it turned out, the sequence is transmitted in positive and negative polarity according to an alternation  of patterns which are easily identifiable by inspecting the stream with a window of 385 bits width (Fig. 1)

10101011010100010100110100000100101100010000110010000001101011110100100100011100111000001110100011011000011110111011001100000000

Fig. 1 - sequences patterns
The sequence positions emerge after descrambling the stream using either the x^8+x^6+x+1 polynomial or the x^9+x^8+x^7+x^6+x^2+1 polynomial (Fig. 2): since they are not primitive polynomials the 128-bit sequence can't be considered as an m-sequence [1] but rather a scrambler sequence. Notice that the descrambled streams show opposite polarity.

Fig. 2 - descrambled stream
The sequences (the positive and negative one) have the interesting property of being both parts of the same 256-bit sequence generated by the polynomial 9,8,7,6,2 ...subject to some errors that apparently have been added to the sequence in order to complicate its analysis.

1110010011110000100010011001111111101010110101000101001101000001
0010110001000011001000000110101111010010010001110011100000111010
0011011000011110111011001100000000101010010101110101100101111101
1010011101111001101111110010100001011011011100011000111110001000


Interestingly, if the stream is decoded in differential mode the sequence changes its length to 127 bits and acquires only one polarity (Fig. 3): in this case both the descrambler polynomials 8,6,1 and 9,8,7,6,2 are suitable (Fig. 4).

Fig. 3 - sequences in the diff. decoded stream
Fig. 4
We also saw that syncing the diff. stream, the sequences appear in regular positions so that they could also be used to separate data blocks, but it's just our guess (Fig. 5).

Fig. 5 - sinched stream
During one of his monitorings, Valentin caugth an interesting transmission: after a stop the only "space" frequency was emitted for a long time and then followed by a short-term transmission (~ 3 sec). The signal contains the 128-bit sequence that we discovered and another 114-bit sequence repeating in the stream: the most interesting thing is that also that sequence is a consequence of the mentioned scramblers (Fig. 6 shows the descrambled stream).

Fig. 6


By the way... just another feature: when the modem works in idle mode the speed is set to 100 Bd (Fig. 7). Actually, in idle mode a "meander" is transmitted with a frequency of 50 Hz. The source of this frequency is a 50 Hz AC network. The meander is used to correctly configure the correspondent station, as well as to ensure that no one else occupies the HF frequency.
Notice that 50 Hz frequency originates a 100 bps stream: "1" value during the positive period (the first half cycle) and "0" value during the negative period (the second half of the cycle): if considered as speed, then it is 100 bps. 


Fig. 7

CIS-75_stream.bin
CIS-75_diff_stream.bin
Short_75-250.wav
izh.swl.su_2019-08-15T09_38_31Z_9187.00_usb_idling.wav

[1] http://www2.siit.tu.ac.th/...m-sequence.pdf

Signals for analysis was mostly gathered thanks to the KiwiSDRs:
http://sdr.ok2kyj.cz:8073/   (Pohorany near Olomouc, Czech Republic)
http://r3tio.proxy.kiwisdr.com:8073/  (Nizhny Novgorod, Russia)
http://kiwi-kuo.aprs.fi:8073/  (Kuopio, Finland)

20 August 2019

OFDM-80 30Bd/37.5Hz

Unid (to me) OFDM 80-tones 30Bd/37.5Hz K=1/4, spotted with good SNR on 9400 KHz (cf) and resampled to 9600 Hz.

Fig. 1
Some channels show a clear PSK2 modulation while in other channels I could not successfully detect the used modulation (looks like a differential PSK but I could be wrong).

Fig. 2 - observed modulations
Data seem to be sent in blocks while the ACF of the transfer is 133.4 ms with a bit of instability which is probably due to the observed modulations in the channels (see Fig. 2). Since the aggregate speed of 2400 symbols/sec (30x80), the ACF value reveals a 320-symbols length frames. 

Fig. 3
The signal was recorded using the KiwiSDR http://sdr.ok2kyj.cz:8073/ (Pohorany near Olomouc, Czech Republic).

14 August 2019

CIS-75 FSK 75Bd/250

CIS-75-75/250  is a Russian/CIS system supposed in use by Military in HF. As its name, this system use F1B modulation with 250 Hz shift and 75 bps speed, most likely a broadcast with linear encryption (ACF=0). The transmission was heard today on 9188 KHz (cf), operating continuously from the first morning. It's worth noting that during the days back, while I was monitoring the Swiss-MIL on 9187 KHz/USB, this FSK signal was not present: maybe 9188 KHz is not a primary channel, but it's a my guess.


According to several TDoA localizations, the site of Tx is in the area of Moscow.


kiwi-kuo.aprs.fi_2019-08-14T13_08_37Z_9188.00_iq.wav

13 August 2019

Defence Australia 188-110 Serial transmissions

The Australian 188-110A Serial running on 14385.0 KHz/USB (600bps KW-46/KIV-7M secured broadcast) and 10407.0 KHz/USB (2400bps 1536-bit TDM protocol), already discussed here, are most likely originated from Defence Australia Tx sites which are located in North West Cape (Exmouth) and Townsville (Bohle River).