2 December 2019

Unid FSK 400 (401)Bd/800 bursts
(i56578, cryptomaster, KarapuZ)


Unid FSK 400Bd (401)/800 bursts spotted on 13224.0 Khz (cf + 1700), slight distorsion in the speed. ACF=0, no other results if demodulated using differential mode. Transmissions are not frequent and most often consist of a single burst, sometimes two (maybe two stations).

Fig. 1
Quoting my friend KarapuZ "Despite the good recording quality and SNR ratio, in my opinion, the transmitter modulator malfunctions in the frequency discriminator. As a result, we have a bitstream with many errors at the output".

Fig. 2
Comments by my friend cryptomaster follow.
The signal structure of the first burst is shown in Fig. 3, the transfer is considered without translating it into a relative form:
1. A meander with a frequency of 150 Hz (300bps);
2. The preamble is 31 bits (300bps) of the form 0101110001101000010010001010101;
3. Information transfer with a speed of 401.3 bps;
The preamble is marked in yellow:
 
Fig. 3

Other than the frequency discriminator, the signal is distorted by the imposition of a stray frequency of 800 Hz, the intensity increases by the end of the transmission (Fig. 4), perhaps this frequency (800 Hz) is somehow connected with the formation of the separation of the frequencies of manipulation.

Fig. 4
On a bitmap, it looks like the pattern in Fig. 5:

Fig. 5

https://yadi.sk/d/bJ-_r5MwVZDonQ
 

19 November 2019

Indian Navy STANAG-4285 naval broadcasts (tentative)

Follwing a tip from my friend KarapuZ and his recent tweet, I started to monitor 16941.0 KHz to study the STANAG-4285 naval broadcasts from the Indian Navy [1]. They use the quite rare 2400bps/Long sub-mode and decoding produces a lot of errors just due to the high data rate and the huge QSB that sometimes affects the signals. By the way, I used the KiwiSDRs VU Hams located in Kottarakkara Kerala and colombo4s7vk located in Colombo Sri Lanka, the latter is a bit less recommendable.

Fig. 1 - one of the S4285 2400/L heard broadcasts
For what I could see, daily broadcasts starting around 1100 or 1200 Z are transmitted on that frequency. Broadcasts consist of clear-text weather bulletins and 4FG messages to VWGZ (VWGZ is the collective callsign for any/all the Indian Navy ships): indeed, they typically use a four FIG (off-line) encryption system. Either the bulletins and 4FG messages, are sent using the async ITA2 8N1 framing (Figs. 2, 3). 

Fig. 2- 8N1 bitstream after decoding
Fig. 3 - off-line decoding using Harris RF-5710A modem
It is interesting to take a look at some bulletin/message typical contents.

VWGZ
VND 677/16
ECHO BRAVO ZULU
ALPHA KILO UNIFORM
OSCAR KILO NOVEMBER
PAPA ECHO HOTEL
ROMEO QUEBEC XRAY
INDIA INDIA HOTEL
LIMA CHARLIE PAPA
DELTA HOTEL KILO
-P- 160732
GR 158
BT
ZERO ZERO ZERO EIGHT ALFA TWO TWO FOUR EIGHT 9838
6469 5315 6155 6433 5098 8353 7507 5237 5375 4271

...
8394 6708 1257 6554 6238 5987 3600 6023 9076 1083
4574 3021 1116 0342 6063 4300 2248 0008ALFA

BT
GR 158
NNNN

AAAAFIN0M0N9O8P7Q6R5S4T3U2V1
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
**************************************************

A1B2C3D4E5F6G7H8I9J0

where:

VWGZ 
collective callsign for any/all Indian Navy ships

VND 677/16 
indicates the daily serial number of the message in that broadcast, i.e. message #677 of day 16 (indeed 16 november, date of my reception). Don't know what VND stands for.

ECHO BRAVO ZULU 
ALPHA KILO UNIFORM
...
most likely the daily encrypted callsigns for specific ships

-P-
precedence indicator of the message
-R- Routine
-P- Priority
-O- Immediate (Operational Immediate)
-Z- Flash
  

160732
date time of origination, no time zone indicator (!)

GR 158
the number of 4FG in the message (158 in this case)

BT
separation (break), as the usual Morse Code abbreviation 

The 4FG block is always preceeded by a 9 chars string, i.e.: 

ONE NINE NINE TWO ALFA NINE SEVEN TWO FOUR 

I noted that this string is used to "signal" the last two 4FG in the block, respectively the last and the second-to-last:
 
ONE NINE NINE TWO ALFA NINE SEVEN TWO FOUR 9072
2299 4827 3953 0701 6748 2577 4084 8109 5655 4999
...
5904 4854 4358 8628 9964 9687 9032 0282 4140 7567
5029 5582 1302 9724 1992ALFA
;
ZERO ZERO ZERO EIGHT ALFA TWO TWO FOUR EIGHT 9838
6469 5315 6155 6433 5098 8353 7507 5237 5375 4271
...
8394 6708 1257 6554 6238 5987 3600 6023 9076 1083
4574 3021 1116 0342 6063 4300 2248 0008ALFA
;
ZERO THREE NINE NINE ALFA ZERO SIX FIVE NINE 7346
0822 9678 3021 3357 0524 0160 9645 0013 4927 1959
...
5457 3192 3301 5013 5856 9799 0272 2857 8727 9046
1854 5256 7000 0659 0399ALFA


The 4FG blocks usually end with the separation char (BT) folowed by the repetition of the number of encrypted groups in the message (GR nnn), the usual RTTY end-of-message (NNNN) and the strings: 

AAAAFIN0M0N9O8P7Q6R5S4T3U2V1
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
**************************************************

A1B2C3D4E5F6G7H8I9J0

at present I do not know their scope/meaning, maybe test chars, but it makes some sense if they are read respectively as couples [0;1][M;V]:

AAAA
FIN (=finish ?)
0M
0N
9O
8P
7Q
6R
5S
4T
3U
2V
1


and [A;J][1;0]:

A1
B2
C3
D4
E5
F6
G7
H8
I9
J0 


It's worth noting that  in each transmission the most recent message is sent as first (a kind of LIFO). Moreover, some of the messages that were sent in the previous broadcast are re-inserted in the current one, i.e. the broadcast of 1304 Z contains the last message (#679) and the twos (#678 and #677) sent in the previous broadcast of 1255 Z
 

[2019-11-16 1152Z]
VND 677/16
VND 676/16
VND 675/16
VND 674/16

[2019-11-16 1255Z]
VND 678/16
VND 677/16
VND 676/16

[2019-11-16 1304Z]
VND 679/16
VND 678/16
VND 677/16
 


Probably this method is used to improve the reliability of the system but it is not clear to me how the number of messages to be repeated is determined (precedence? duration?).
Sometimes it's possible to see short messages as:

VWGZ
VND 675/16
ZFA
VTH DE GOLF YANKEE
-O-
LIMA ROMEO MIKE
FOXTROT KILO NOVEMBER
160801
ZBQ 0805
BT
NNNN


VTH is listed as the callsign of Indian Navy Mumbai.
Note the Z codes ZFA (Following message has been received) and ZBQ (Message was received at).


Weather bulletins report Weather, Surface Wind, Visibility, Sea State, Swell, and Warnings for specific areas and period of validity (12 hours). The bulletins header indicates the originator of the message just after the precedence indicator: 

-P-  150320
FROM FOCINC EAST
TO   ALL CONCERNED

-R-  141004Z
FROM NAVAREA VIII CO-ORDINATOR
TO   NAVAREA VIII

-P-  160900
FROM CINCAN
TO   ALL CONCERNED


where:

FOCINC EAST: Flag Officer Commanding-in-Chief Eastern Naval Command. The Indian Navy operates three operational Commands, each headed by a Flag Officer Commanding-in-Chief (FOCINC): FOCINC East (Visakhapatnam HQ), FOCINC West (Mumbai HQ), FOCINC South (Kochi HQ).

NAVAREA VIII CO-ORDINATOR: the Chief Hydrographer to the Government of India.

CINCAN: Commander-in-Chief of the Andaman & Nicobar Command. The Andaman and Nicobar Command is the first and only Tri-service (army, navy, air force) theater command of the Indian Armed Forces.

Since some of the weather bulletins also report detailed "LOCAL WEATHER FORECAST FOR VISAKHAPATNAM", probably the broadcasts are transmitted from a COMCEN belonging to the Eastern Naval Command (ENC) HQ in Visakhapatnam [2]. In this respect it's noted that some logs in old WUN/UTNL newletters report "VTP Visakhapatnam" as Indian Navy station operating in CW and RTTY 50Bd/850, but not on 16941 KHz. Actually, I didn't find any "official" allocation for 16941.0 KHz but only a clue related to one of the frequecies that are used for HF communications in the Indian activities in Antarctica (IAP, Indian Antarctic Programme) [3].
Given the period of validity (12 hours, except for the forecast for Visakhapatnam which have 24 hours validity) it makes sense to expect similar broadcasts around 0000Z, likely on a lower HF band.
(to be continued)
kiwisdr.vuhams.net_2019-11-16T12_55_40Z_16941.00_usb.wav 

[1] https://en.wikipedia.org/wiki/Indian_Navy
[2] https://www.indiannavy.nic.in/node/1399#
[3] inpre07e.doc 

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