13 January 2018

(differential) FSK 75Bd/200Hz

Unid and quite rare FSK system running at 75Bd and using a 200Hz shift, heard on 4540.0 Khz (central frequency) around 1755z. The measured ACF is = 0 but I went on this transmission after its start, ie when in traffic mode, so I do not know if the initial header part has any pattern that could help in signal identification.

Fig. 1
As said, the ACF is =0 but using the differential decoding you may get a strong 385-bit period (Fig. 2).

Fig. 2
I posted my analysis in radioscanner (my nickname there is "ansanto") asking for comments:
http://www.radioscanner.ru/forum/topic39959-120.html#msg1354462 
and my friend cryptomaster in his reply suggested a "relative" FSK (DFSK2) modulation and pointed that the 385-bit period is due to the length of the scrambler generated by the polynomial x^7 + x^6 + 1. After descrambled the bistream exhibits a 398-bit period (Fig. 3), thanks to cryptomaster.

Fig. 3




11 January 2018

MFSK-11 125Bd/250Hz waveform


Unid MFSK-11 waveform spotted this morning on 7973.0 KHz on USB,  already heard on March 13, 2017 (same frequency) and March 23, 2016 (9300.0 KHz). The waveform is an 11-ary frequency shift keying (FSK) modulation with eleven orthogonal tones spaced by 250 Hz (first tone at 650 Hz), one tone (or symbol) at a time; the tones are transmitted at a rate of 125 tones (symbols) per second (Fig. 1).

Fig. 1
The 792 msec ACF value means a frame length of 99 symbols/sec, given the speed of 125 Baud. Once demodulated (Fig. 2) I converted the 0-A symbols into their quadribit rapresentation using the Hex table 0=0000, ..., A=1010 supposing that each tone represents 4 bits of data.

Fig. 2
The resulting bitstream confirms the framing of 99 quadribit symbols, ie a 396-bit length period as shown in Figure 3.

Fig. 3
It's worth noting that each 99-symbols frame consists of nine blocks, each consisting of just 11 symbols: this is an interesting relation between the number of symbols-per-block and the number of the levels (both 11)!
Presumably it's a CIS waveform, although I did not find any confirmation in other logs. Comments are welcome.

➤ ๐’–๐’‘๐’…๐’‚๐’•๐’†
I want to thanks my friends KarapuZ and cryptomaster who sent me some other useful informations and samples about this waveform. Particularly, a record from KarapuZ must be mentioned: in that case it's possible to observe a 6864-bit (1716 symbols) period 

Fig. 4
 
 





5 January 2018

Swedish Defence 8-bit text ACP-127

Thanks to the help of some friends of mine - Guido, J.S4538 and Karapuz -  I've been studying these transmissions for several months and some of their characteristics (mainly their occurences and format) lead to think that this traffic is most likely the encrypted "8-bit text ACP-127 (SV-7)" from the Swedish Armed Forces, as indicated in one slide of their presentation of the HF2000 system at HFIA Metting 2010 [1] and reported below in Fig. 1 (at present I don't know what the term "SV-7" stands for).

Fig. 1
All the transmissions use the MIL 188-110A Serial waveform with a data-rate of 1200bps and modem running in ASYNC 8N1 mode, they are not preceded by 2G/3G ALE neither by voice calls and happen many times per day w/out an apparent sked.  The transmitted 8-bit (encrypted) text can be obtained using a 188-110A decoder that shall be configured to work in ASYNC mode and  8N1 framing, or you may get the source bitstream by configuring the output of the decoder as ASCII Bits: in the latter way you have to manually remove the start/stop bits in order to obtain the 8-bit text (I mostly used this method to study the "format" of the bitstreams).

๐‘ญ๐’“๐’†๐’’๐’–๐’†๐’๐’„๐’Š๐’†๐’”
As well as with our receivers, monitoring is performed thaks to the use of four remote KiwiSDRs located in Sweden and Finland (Fig. 2)

Fig. 2 - the used KiwiSDRs and map of main RT/x stations
So far these are the spotted frequencies thanks to Guido, J-4538 and Karapuz (all freq. are USB): 

3034, 4228, 4321, 4373, 4396, 4408, 4513, 4522, 5242 


Although in a small percentage, synchronous 188-110A transmissions (still 1200bps/Long) can be received in these channels.
A parallel monitoring of 4396 KHz (using KP20 in Finland) and 4513 KHz (using SM0KOT in the northern part of Sweden) was performed during the morning-time on 20 December 2017 and got some interesting points about these two channels. Looking at the waterfall in Fig. 3, the strengths of the received signals point out different transmitters sites; since the waterfall is related to KP20 SDR, frequency 4396 KHz - on the left in the waterfall - perhaps could be operated by the close Karlskrona Naval Base. Moreover, transmissions on 4396 and 4513 KHz occurred almost simultaneously during all the monitored time (Dec 20th, 2017) but actually it's impossible to say if they carried the same messages.
 
Fig. 3- KiwiSDR KP20 in Finland

However, such behavior was not observed during the first seven days of January 2017: indeed, those two frequencies seem not to be used, as well as 4321, and the trasmissions happen on 4373 KHz (Fig. 4) which was spotted by Karapuz on 2 January.

Fig. 4 -
KiwiSDR KP20 in Finland
➤ ๐‘ข๐‘๐‘‘๐‘Ž๐‘ก๐‘’ On Jan 8th, 4.3 MHz transmissions take place only on the new 4372 KHz. I do not know the reasons for these changes.

๐Ÿด๐๐Ÿ ๐Ÿ๐จ๐ซ๐ฆ๐š๐ญ๐ฌ 
Looking at the bitstreams, it's esay to see that headers and data are arranged in different formats, although the same "8N1" framing is used (Fig. 5).

Fig. 5

"A" format (headers and data are shifted and separated) is used in 4373, 4396, 4408, and 4522;
"B" format (headers and data are contiguous) is used in 4228, 4321, 4513, and 5242;
"C" format (as in "A" but data appears as "fragmented" in separated blocks) is used in 3034.

(for what concerns the 3034 KHz I could record only very few 8N1 transmissions during long-time periods, perhaps it is related to a less used service)

Probably the different formats (and the one used in STANAG-5066 [2]) and the different Tx sites are due to the different recipients, ie: Army, Navy, Air Force and Civil Defence ...but it's only my guess.

๐ญ๐ก๐ž ๐™-๐ฌ๐ญ๐ซ๐ข๐ง๐ ๐ฌ ๐ข๐ง ๐Ÿด๐๐Ÿ ๐š๐ง๐ ๐’-๐Ÿ“๐ŸŽ๐Ÿ”๐Ÿ” ๐ญ๐ซ๐š๐ง๐ฌ๐ฆ๐ข๐ฌ๐ฌ๐ข๐จ๐ง๐ฌ
The most important aspect is the presence of the Z-strings in the messages' headers: these are the same as the strings already seen in the data-blocks of the  S-5066 transmissions from the Swedish Armed Forces [2]. Note also that in both the transmissions the Z-strings are contained within the same sequences  (I catched tens of transmissions, for simplicity I show in Fig. 7 only two of these but the matches are in all the recordings).

Fig. 6 (HEX view)
The 8-bit transmissions use only the Z-strings ZAPD<L> and ZXPD<L> and both are used every day with a prominence of the latter. So far, these are the heard strings:

ZAPD flwd by B,C,D,E,F (ie: ZAPDB, ZAPDC,...)
ZXPD flwd by B,C,D,E,F (ie: ZXPDB, ZXPDC,...)

I saw that the fifth letter of the Z-string does not change during the week, then in the following week it takes the next value in the alphabetical order: for example ZAPDD is used from Mon to Sun then in the following monday it changes into ZAPDE; the same happens for ZXPDD which changes into ZXPDE.
This alphabetical progression  is verified by a long-time monitoring and it's not a simple  "rotation" but rather a way to indicate the week of the year using the last two letters and the convention A=1, B=2, C=3,... so that for example DC = 43, DD = 44 and so on (Fig. 7).



Fig. 7

It is very important to note that the same mechanism has been observed in the variations of the Z-strings in S-5066 transmissions (sporadic catches, not from a monitoring):

ZRTBC and ZXPBC on 6,7 June (BC = 23th week)
ZRTBD and ZXPBD on 15,16,17 June (BD = 24th week)
ZXPBE on 23 June (BE = 25th week)
ZAPCA on 1,2 August (CA = 31th week)

as you see, the dates belong to the number of the week indicated by the last two letters of the Z-strings. Nothing (unless the timestamp header in S-5066 transmissions) seems indicate the time & date of the message, maybe it is contained within the encrypted text.


The Z-strings suffix "DI" was expected during the week 4-10 December to indicate the week #49 but curiously they skipped the letter "I" and adopted "J" to code the number 9 (Fig. 8), maybe to avoid confusion between "I" and "1" ?

Fig. 8 - "DJ" suffix to code week #49 (8x19 view)
It's interesting to note the choice of the letter "K" to code the "0" during the fiftieth week (11-17 December): indeed the suffix "EK" (more precisely the string "ZXPEK") has been found in all the messages of the monitored frequencies (3034, 4396 and 4513) during the week #50. 

As expected, the suffix "KA" (= 01) is used to code the first week of the year: the presence of the ZXPKA string has been confirmed also by the catches of my friends Guido and Karapuz (see the comments to this post). Figure 9 below shows the string ZXPKA in a message received in the firts week of 2018 (Jan 4th): note the use of MS-DMT software configured in Async 8N1 mode. 

Fig. 9 - "ZXPKA" string during the week #01(transmission decoded using MS-DMT)

That said, the Z-strings shall be considered as 3-letters:
ZAP
ZNT (so fare seen only in S-5066 transmissions)
ZRT (so far seen only in S-5066 transmissions)
ZXP


followed by 2-letters (encoded) week of the year, according to:
A = 1, B = 2, C = 3, ..., H = 8, J = 9, K = 0 

It's difficult to say what the initial 3-letters  stand for, maybe they could indicate the precedence of the messages: ie, ZAP for higher priority (flash) and ZXP for routine, or maybe a kind of classification. 
I tried the NATO military Z-signals defined in ACP 131 [3] but their meanings make poor sense in our context.




[1] http://www.hfindustry.com/meetings_presentations/...HF2000_HFIA_2010.pdf 
[2] https://i56578-swl.blogspot.it/2017/06/unid-stanag-5066...client.html
[3] http://www.angelfire.com/va3/navy_mars/ACP131.pdf

 


https://youtu.be/lWNljuCQw_0


24 December 2017

a MS-110A modem running in ASYNC mode

This is a sample of MIL-STD 188-110A Serial 75bps/L modem working in ASCII ASYNC mode and transporting a Citadel encrypted file. The transmission was heard on 7413.0 KHz/USB following a 188-141A handshake between two Algerian Air Force nodes: CM2 (Algerian Air Force Base - Oran, 2nd Regional Command Centre) and COF (Algerian Air Force HQ - Cheraga). 

In ASCII Asynchronous mode the bitstream consists of a 8N1 structure: one start-bit (0), 8 data-bits and at least one stop-bit (1). Each character is transmitted using a total of 10 bits and the 8 data bits are transmitted with the LSB first.

Fig. 1
Working in the ASYNC part, after removed both the start and the stop bits we get the clean 8-bit data where the characterstic pattern of the Harris "Citadel" encryption is easy to identify (Fig. 2).

Fig. 2
A similar example but related to Asynchronous STANAG-4285 can be read here:
http://i56578-swl.blogspot.it/search/label/Stanag-4285%20Async

You may use the MIL-STD Data Modem Terminal (MS-DMT) [1] to verify how the MS-110A works in ASYNC mode (Figs. 3,4)

Fig. 3 - MS-DMT settings for ASYNC mode
Fig. 4
[1]
http://www.n2ckh.com/MARS_ALE_FORUM/MSDMT.html
The latest MS-DMT test build is available at:  
www.n2ckh.com/MARS_ALE_FORUM/MSDMT32v200B1000TB1002_FI.zip

Thanks to  Steve Hajducek for the update, I suggest to subscribe his group at
https://www.facebook.com/groups/MARS.MIL.STD.TOOLS.LIB/




https://yadi.sk/d/1rw59Z0K3QuToC 
(MS-110 Async from Algerian AF)

2 December 2017

Baudot FSK 50Bd/100

.
This FSK transmission was copied on 6330.8 (cf) at 1128z: shift is clearly 100Hz while some problems arise when measuring the speed. Indeed, the measurement of the speed based on FFT may fail in case of non-integer number of bits as in Baudot/ITA2 code where the stop bit lasts 1.5 bit: in this case SA assumes an integer number of bits, so  it prints out a value of 53.47 Baud (Fig. 1)

Fig. 1
In such cases the speed shall be measured using the "raster" tool of SA (Fig. 2): the structure of the frame is 7.5 bit (1 bit start, 5 bit of data and 1.5 stop bit) and the time line is 299.4 msec for 15 bit that makes a speed of 50 Baud.

Fig. 2

Baudod decoders work fine and print out the content of the message after the RYRY sequence, in this case: "ZHGD ZHGD ZHGD DE N4O4 N4O4 N4O4 QRK ? +?". The user is not identified, probably Russian Military.

Fig. 4


update
my friend KarapuZ catch a similar transmission on 5565.0/USB,  callsigns are very similar to the once I had: "ZBNV ZBNV DE 7X6R 7X6R 7X6R QRK ? +?". 

So far, these are the heard callsigns:
ZBNV, ZHGD
N4O4, 7X6R


https://yadi.sk/d/K_eEO7cT3QFLLU