Quantcast
Channel: diario SWL I-56578 Antonio
Viewing all 623 articles
Browse latest View live

email over HF using RSX.25 and GM2X00 waveforms (R&S PostMan II)

$
0
0
I had already met the "combined" Rohde & Schwarz RSX.25 ARQ protocol + GM2X00 waveforms some time ago, in that case UUCP sessions were exchanged between German BPOL patrol boats and the ashore station server in order to transmit and store the positions of the vessels: the analysis is posted here
This time I was lucky to spot transmissions where RSX.25 ARQ protocol and GM2X00 waveforms are used by the R&S message handling system "PostMan II" to send emails between Italian GdF patrol boats and between patrol boats and ashore commands. Such transmissions, along with 188-141 2G-ALE messages exchanges, can be heard by monitoring some known frequencies such as 6450 (noised by close S4285 transmissions), 8190 (sometimes with co-channel interference from Saudi-AF and Israeli-Ny), and 12431 all usb. Unfortunately it could be a long and fruitless monitoring since emails transmissions are not frequent.

R&S PostMan II is a combined hardware and software product, the hardware platform is a communication server running on the Linux operating system and also controlling the connected radios. Notice that PostManII uses the advanced waveforms provided by GM2X00 HF modems since STANAG/MIL-STD waveforms cannot be used together with the RSX.25 protocol; if interoperability is needed the transmission method defined in STANAG-5066 protocol and 110A/4539 HF waveforms can be applied.

Fig. 1 - R&S PostMan II email gateway

Commands and associated files coming from PostMan, who sits at application layer, are segmented and encapsulated into RSX.25 frames which in turn are transported on air by GM2X000 HF waveforms; therefore in order to get the PostMan bitstream you need to demodulate the received signal, extract RSX.25 frames, remove their encapsulation and finally reassembly the segments into a single file (here termed "infoData.tmp"): what I got is shown in Figure 2.

Fig. 2 - infodata.tmp file, PostMan commands togheter with the (Bzip2 compressed) email file
Now let's have a close look to the first bytes of the Hex/ASCII coded infoData.tmp file, i.e. to the PostMan commands (Fig. 3).

Fig.3
"infoData.tmp"

OC0008 pm2mrs -CR D.000t 8 0666 simo@oltramonti.gdf.it 0x3da rs*ail -v2 -fsimo@oltramonti.gdf.itsimo@cagliari.gdf.it # Ú#º¦BZh94AY&SYèså  ...

R&S PostMan II commands
pm2mrs = PostMan II messenger(?) R&S
-CR  = (?)
rs*ail -v2 -f = rsmail -v2 (version2) -f (?)

email addresses
simo@oltramonti.gdf.it = sender, patrol vessel "Oltramonti"
simo@cagliari.gdf.it = recipient, ashore station Cagliari

Bzip2 4 bytes header
BZ = Signature (0x425A magic number)
h = Bzip2 (h is for Huffman coding)
9 =  increments of 100 kB block-size uncompressed


... compressed email file bytes follow (I did not unpack it!)

Some comments:
1) Since PostMan offers  e-mail, fax and file transfer, I think that the additional command rsmail (most likely R&S mail) that follows the pm2mrs invocation just specifies the email service.
2) In order to reduce the transmission time, both the emails text body and attached files always undergo data compression.
3) For what concerns the email addresses simo@<ALE-address>.gdf.it, it seems that each radio (with its own name, ALE address and PostMan address) belongs to one station so that each station has one unique e-mail domain name where the ALE-address is also the hostname. All the email addresses have the same local-part "simo": I do not know if it's the PostMan default username (just like "user" for Harris RF-6750 mail gateway) or if it's the special GdF entity/role/staff with delegation to the message handling system.
4) The uncoloured strings are not constant in the PostMan sessions I heard, they could be related to the underlying Linux OS layer or to some other parameters (eg, 0x3da could be a file length). Below the strings of another captured (and a bit distorted) PostMan session:
C004 pm2mrs   -CR Dû;004 06D5   simo@cappelletti.gdf.it 0x565 rsmail -v2 -f simo@cappelle tti.gdf.it simo@roma.gdf.it

As said above, PostMan command and files are segmented and encapsulated into RSX.25 frames which in turn are transported on air by GM2X000 HF waveforms. 
The RSX.25 protocol is the R&S adaptation of wired X.25 protocol to the HF radio channel. RSX.25 organizes the data to be transmitted in packets, which are successively transferred to the data modem. The packets contain a variable number  of  frames depending on radio-link quality and being adapted at regular intervals. RSX.25 has a typical 8-bit period (Fig. 4) with recognizable patterns and is visible once removed the overhead due the GM2X00 "advanced" HF serial waveform.

Fig. 4 - typical RSX.25 bitstream
GM2X00 HF waveforms are based on a PSK-8 constellation modulated at a symbol-rate of 2400Bd. The frame structure consists of an initial 192 symbol sequence followed by a data block consisting of 64-symbols frames each composed of 48 unknown (data) symbols + 16 known symbols (probe). The postamble, terminating the data block, has a structure which is basically the same as the one of the data frames but it contains a stop-code sequence instead of information data.

By the way, these are the R&S HF equipments used in the two stations (*):
P.V. 5 "Oltramonti" patrol boat [1]
- XK2500 500W, antenna dipole Whip 8 mt mod. STA80 + tuner FK855C3
- XK2100L 150W, antenna dipole + tuner HX002M1
"Cagliari" Aeronaval Group, Operational Control Room
- XK2900 1 KW, antenna HX002
- XK859C1 1 KW, antenna HX002



(*) these informations are publicly available from the GdF website:
http://www.gdf.gov.it/
 
[1] http://www.naviecapitani.it/.../GDF/G%205%20Oltramonti.htm


use of the radio address format "RSPeer" for direct delivering of messages (R&S PostMan II)

$
0
0
This post can be considered as a continuation of the previous one in which the use of Rohde & Schwarz PostMan was shown: in that post, rsmail sending "classic" email over HF, was analyzed. In order to find other interesting RSX.25 sessions I started to look for my files and old recordings and finally I recovered an interesting transmission of the Italian Coast Guard (Guardia Costiera, say It-GC) on 12270.5 KHz/usb dated January 2016 consisting of the combined RSX.25 and GM-2X00 HF waveform.
 
Fig. 1
I probably went late on that transmission and so I probably lost the initial RSX.25 exchanges but after the demodulation of the signal - although weak - an interesting session came up that uses the Rohde & Schwarz address format "RSPeer" to send a file between two radios. The received signal does not have a good SNR but its interpretation is nevertheless possible, below the file I got after the removal of the GM2X00 HF waveform and RSX.25 demodulation:


...
c„%Ì, TNF8c19f176-c647-11e5-ab22-000c2940a7d1.tmp v˜ xŸ>"©  ' E €  1 1
CP940 RSPEER:CP940,Administrator   N €  à  1 O   € !  +*V    ,ØCµá ªG )@§Ñd€
+ ¤¾£ n Ý T  ROMA RSPEER ROMA,ROMA   0  'ROMA'  0  0   *)  ì  #  &)
...

file being sent (most likely, see below)
TNF8c19f176-c647-11e5-ab22-000c2940a7d1.tmp

RSPeer address format addresses
CP940, Administrator = patrol vassel "DATTILO" CP-940, callsign IGUB [1]
ROMA, ROMA = Guardia Costiera HQ Roma, callsign ICI [2]

Quoting the paper ADP010679 [3] "The R&S address format RSPeer ensures the direct delivery of the message to the computer of the addressee, i.e. the message is physically available on the hard disk of the recipient, the usual detour to the SMTP server being avoided. This delivery procedure excludes any misuse of and unauthorized access to the mail traffic of a network and ensures that one's own information is secure. This type of addressing also minimizes the data exchange on the frequencies available and so eases the traffic load of the radio network."

Further and more interesting details emerge if the HDLC protocol decoding is used at data-link layer, i.e. just before the RSX.25 demodulation(!): in particular, the strings related to MicroSoft Exchange  are highlighted

(OHDLC-layer.bin)
...
940a7d1.tmp v˜   xŸ>"©      •þÿÿÿþÿû(F°€œøÞÿÿÿ6(F°àš›Þÿÿÿ
ÿ(F¿ 2   Ì, TNF8c19f176-c647-11e5-ab22-000c2940a7d1.tmp v˜  

xŸ>"©    tÑ(F°   ä    è € IPM.Microsoft Mail.Note 1€ €    
PIM 291000A GEN 16ô €    à 6 (F± ' E €  1 1 CP940 RSPEER:CP940,Administrator
O € ! h›(F² 74F1198C47C6E511AB22000C2940A7D1ý  þ    ÿ Z µ;ÂÀ,w ¡¼ 
 Úµ(F³ +*V    ,ØCµá ªG )@§Ñd€  Ñd€ + ¤¾£ n%Ý T ROMA RSPEER:ROMA,ROMA 'ROMA'
...

I believe the CP940 user is sending an outlook message in rich text format (RTF) encapsulated into Microsoft "Transport Neutral Encapsulation Format"(TNEF) [4] instead of sending an SMTP (HTML or Plain Text mode) email. The original filename is probably 940a7d1.tmp while the filename TNF8c19f176-c647-11e5-ab22-000c2940a7d1.tmp and the 32-char lenghth string 74F1198C47C6E511AB22000C2940A7D1 are something related to MS-Exchange TNEF encapsulation (I believe the TNF converted file and the key/identifier of the message).
For what concerns PIM 291000A GEN 16, it is probably the time when the message was prepared, expressed in the format: DayHourMinuteAnte(Post)Meridiem Month Year (something like PIM = Product Information Management ???), i.e. 29 January 2016 10.00 AM; indeed it matches the time I recorded the transmission, i.e. 29 Jan 2016 at 10.25 or sent 25 mins after its preparation (Fig. 2).


Fig. 2
That said, PostMan performs an "address gateway" to email networks (SMTP, X.400, MS-Mail) with different address formats (Fig. 3).

Fig.3

So far, I never heard 188-141 ALE messages form It-GC ships and ashore stations but I have a guess about it. Several times I copied on 12270.5 and 8196.5 KHz (frequencies operated by It-GC) R&S-ARQ 228.6Bd/170 "ALIS" selcalls such as:

Called address: 40
Pool size: 8
ALIS 2000: No
Ack: true
Followon type: External modem
ECC: PRP
Spectral diversity: Adaptive
Data rate: Fast
Data encryption: No (clear)
Rephase: false
Sending counter: 1


Assuming that 40 is the ALIS address of CP940, it could be that they use the ALIS selcall instead of the 188-141 mode, but it is only a speculation of mine without any confirmation.


https://yadi.sk/d/Zbdfvc_punPUWw
https://yadi.sk/d/liJWgfG8jZGqXQ(OHDLC-layer.bin)

[1]  http://www.guardiacostiera.gov.it/.../scheda-dati-nave-dattilo-cp-940
[2]  http://www.mediasuk.org/archive/ici.html
[3]  http://www.dtic.mil/dtic/tr/fulltext/u2/p010679.pdf
[4]  http://www.fiction.net/blong/programs/tnef2txt/apptnef.txt 

BPol vessels tracking using RSX.25 and GM2X00 waveforms (R&S PostMan II)

$
0
0
Quoting R&S PostMan II brochure "[...] another feature is the capability to track mobile stations by using the global positioning system (GPS). If a station is equipped with a GPS receiver, position data can be transmitted in addition to the actual data after analysis of the National Marine Electronics Association (NMEA) 0183 protocol [1]. The current position of and the route covered by each mobile station can thus be tracked from a command center".  The standard package includes an interface with scanned maps as below: in the left side a screenshot from PostMan and in the right side the correspondent map available from the web [2].

Fig. 1
After analyzing some recordings, I think this system is the one used by BPol (Bundespolizei See) for tracking their patrol vessels: positions are transmitted on HF to the ashore command center using RSX.25 protocol over GM-2X00 waveforms as discussed here.
After removing the GM-2X00 waveform and decoding the RSX.25 bitstream, it is possible to see the UUCP commands that are responsible for transferring a Bzipped file from BPOLBP23 (patrol vessel "Bad Düben", now out of service) to BPOLBPLEZSEE_HF (Operations Center HQ Cuxhaven).

Fig. 2 - RSX.25 bitstream

login: UBPOLBPLEZSEE_HF <MPL>2016-11-28 15:49:52+01,BPOLBP23;2016-11- BPOLBPLEZSEE_HF 15:49:52+01,BPOLBP23; 2016-11-28 15:47:45+01,BPOLBP26</MPL> Connected
Shere=BPOLBP23_HF SBPOLBPLEZSEE_HF -pz -vgrade=z -R -N07 ROKN07 Pyie
Uy  ¸ HN = #E D.05PK D.BPOLBP2C05PK uucp -C D.05PK 0666 "" 0x66
rsgpsadd
ƒ!Z)vL@¬“4m˜ßÐ{ f ã BZh91 ...

The UUCP session has been described in detail in this post, here it's more interesting to dwell on the piped commands uucp file | rsgpsadd

D.05PK D.BPOLBP2C05PK uucp -C D.05PK 0666 "" 0x66 
D.05PK = file to send
D.BPOLBP2C05PK = file name on slave (should be D.BPOLBP2505PK)
uucp = application requesting the file transfer
-C = file has been copied to the spool directory
0666 = mode of file on master for outgoing files
0x66 = 102 Bytes file size

 
rsgpsadd 
rsgpsadd = command to be executed after the transfer, most likely stands for "R&S GPS Add". This program  will process the sent file D.05PK, probably unpacking it and store the lines into a database for the further graphic elaboration (map display).

BZh9
here starts the D.05PK file which is sent in Bzip compressed way:
BZ = Signature (0x425A magic number)
h = Bzip2 (h is for Huffman coding)
9 =  increments of 100 kB block-size uncompressed


The compressed file, once unpacked, consists of two lines, each consisting of four values separated by commas "timestamp, vessel, latitude, longitude"as in the transmission heard on August 10 at 0806 in which the vessel Bayreuth (BPOLBP25), comunicates its position at times 0737 and 0757 (CEST):

2017-08-10 07:37:48 +02, BPOLBP25, 54.023927, 10.800935
2017-08-10 07:57:47 +02, BPOLBP25, 54.023125, 10.800987 


Some comments about these files.
GPS Devices can create a file saving the route they are taken and these files are usually stored in a format called NMEA 0183. Now, as can be seen from the mentioned brochure ("... after analysis of the National Marine Electronics Association (NMEA) 0183 protocol") I believe the 0183 format files cannot be read directly by PostMan so they must be converted into a new file format. Well, the format of the files piped to rsgpsadd command looks like the Waypoint file format. In the waypoint format each line contains a triplet of values separated by commas, these values are a text string (optional), a latitude value and a longitude value.  In the rsgpsadd files it seems that each waypoint line, consisting of the triplet "vessel, latitude, longitude", is preceded by a timestamp string that could be a header value added during the 0183-waypoint conversion. By the way, notice that R&S already developed the "GPS Route Converter" program (NMEA 0183 to waypoint files) to be used by the R&S SMU200A Vector Signal Generator [3]: maybe parts and knowledges from that software is used/embedded in this PostMan application, who knows?

Fig. 3

I tried to use some rsgpsadd commands, recordered on 26 August (2017), to trace the patrol vessel BPOL21 by using a .kml file and google Earth application [4]: these rsgpsadd commands update the position with a resolution of 10 minutes

2017-08-26 09:02:08 +02, BPOLBP21, 54.4225, 12.271833
2017-08-26 09:12:09 +02, BPOLBP21, 54.414833, 12.252
2017-08-26 09:22:09 +02, BPOLBP21, 54.4075, 12.2325
2017-08-26 09:32:09 +02, BPOLBP21, 54.4, 12.212833
2017-08-26 09:42:09 +02, BPOLBP21, 54.3925, 12.193167
2017-08-26 09:52:09 +02, BPOLBP21, 54.385, 12.173


below the map I obtained, the vessel was moving from right to left

Fig.4

[1]  https://www.nmea.org/.../nmea_0183_v_410.asp 
[2]  http://fishing-app.gpsnauticalcharts.com
[3]  https://cdn.rohde-schwarz.com/...GPS_route_converter.pdf
[4]  http://www.gpsvisualizer.com/map_input?form=googleearth
 

STANAG-5066 Annex G, the ancestor to US MIL STD 188-110B and STANAG-4539

$
0
0
The other day I was still trying to figure out something from the burst signals discussed here and here and on that occasion I was using Harris's RF-5710A HF modem. Turning between the various operating modes provided I came across what at first glance seemed a strange waveform: i.e. 5066-G. As far as I know, STANAG-5066 is a protocol standard that does not define waveforms, so I went into detail to see what the hell it is.
Quoting Edition 3 #G.3.0 Implementation Guidance for STANAG 5066 Operation at Higher Rates: "It is clear that higher throughput will be available for the HF long-haul channel in near future (i.e, post 2000). What is not clear is the final form of the waveform standard or standards that will provide these data rates". Notice that the Edition 3 was promulgated on 30 march 2015 and the Annex G is still "information only", ie it is still not mandatory for the purposes of the communication minimum requirements.


Now look at the words "...in near future (i.e, post 2000)": clearly, Annex G has remained unchanged from the first editions of STANAG-5066 (dated before year 2000). Most likely the NATO groups responsible for the standardization preferred a separate STANAG to define the new waveforms since 5066 is a protocol standard, so Annex G is "frozen" and stands like a kind of ancestor to MIL 188-110B and STANAG-4539 (3200 to 12800 bps): these new waveforms used constellations and much of the waveform structure developed for Annex G and added further enhancements. 
Harris developed its implementation of 5066-G, you may find it among the operational modes of their RF-5710A HF modem:


The STANAG-5066 Annex G waveforms provide the highest possible data rates over conventional 3KHz HF channels. A single 1800 Hz sub-carrier is modulated at a constant rate of 2400 symbols per second. the type of modulation varies from QAM-64 to PSK-4 according to the data rate selected. Known data symbols are periodically inserted in the transmitted signal to allow fro adaptive channel equalization at the receiver. Convolutional coding FEC and Viterbi decoding are combine with interleaving to enhance the performance of the receive modem on fading HF channels. Data rates from 3200 bps to 9600 bps are supported together with long, double long, short, and zero interleaving options. An additional 12800 bps uncoded waveform is supported for line-of-sight applications. Automatic detection of the data rate and interleaver setting are provided in the receive mode.

Back to the burst signals (here and here), I tried to demdulate them with 5066-G, despite it is an obsolete mode. Surprisingly, the modem is responsive and distinguishes four different waveforms: 4800L (PSK-8), 8000L bps (QAM-32), 9600L and 12800 bps uncoded (QAM-64), the last two are detected less frequently (Fig. 1). It should be noted that when the same transmission is demodulated using 4539 or 110B you always get the same waveform 12800U.

Fig. 1

I believe neither of the twos (4539/110B and 5066-G) is the appropriate mode to demodulate these burst signals, but in my opinion this attempt is a further clue in favor of a modified 4539 waveform.

(some) October logs

$
0
0

06205.0: ELETTRA11: Italian Ny, I 0822 USB/J3E radio-check with IBIS11 (11Oct18) (AAI)
06690.0: BD9: Unid (Moroccan-Pol ?) 0632 USB 188-141 2G-ALE calling T4N (24Oct18) (AAI)
06733.0: 6628: Ascott-6628 RAF USB 1007 J3E/USB requesting wx reports to TASCOMM for LFLL, LFMN, LICJ, LMML (20Oct18) (AAI)
06922.0: ---: Unid 0824 USB 3G-HF 2-way FLSU handshake / LDL96 transfer,83 bytes 'Citadel' encrypted file (11Oct18) (AAI)
06931.0: ---: Unid (prob from Croatia) 0828 USB STANAG-4285 600bps/S, 2 stations exchanging 128-bit MI encrypted msgs (11Oct18) (AAI)
07559.0: ---: Unid 0715 USB 3G-HF FLSU handshake / HDL24 transfer (24Oct18) (AAI)
07606.0: ---: Unid 0910 USB NILE/Link-22, STANAG-4539 TDMA Waveform #2 (09Oct18) (AAI)
07625.0: ---: Unid 2150 ISB Link-11 CLEW (30Oct18) (AAI)
07856.0: SE3: Polish-Mil, POL 1034 USB MIL 188-141 2G-ALE calling EM4 (31Oct18) (AAI)
07961.0: 32X: Unid 0748 USB 188-141 2G-ALE calling DRX (22Oct18) (AAI)
07961.0: 32X: Unid 0749 USB 188-141 2G-ALE calling DRY (22Oct18) (AAI)
07961.0: FAY: Unid 0638 USB 188-141 2G-ALE calling DRX (24Oct18) (AAI)
08086.0: NX10: Algerian-Mil, ALG 0900 USB 188-141 2G-ALE handshake KB23 / MIL 188-110A Serial (20Oct18) (AAI)
08132.0: BP25: Bundes Polizei patrol vessel "Bayreuth", D 0835 USB 188-141 2G-ALE handshake BPLEZSEE HQ / GM2X00 HF modem serial waveform, updating GPS position (23Oct18) (AAI)
08162.0: 093: Hungarian Defense Forces, HNG 0755 USB 188-141 2G-ALE calling 035 (22Oct18) (AAI)
08190.0: --- : Unid 0645 USB 3G-HF HDL+ transfer (18Oct18) (AAI)
08190.0: CAPPELLETTI: GdF Patrol Boat Cappeletti G094, I 1005 USB 188-141A 2G-ALE handshake ROMA, sending email using R&S PostMan II and X.25 over GM2100 modem (11Oct18) (AAI)
08218.0: ---: Unid 1720 USB 3G-HF 2-way FLSU handshake / HDL+ transfer (03Oct18) (AAI)
08677.0: ---: Unid, prob. KNL Networks CNHF (Cognitive Networked HF) 0725 USB PSK-2 48000Bd waveform, 576-bit period (16Oct18) (AAI)
08684.5: ---: Unid, prob. KNL Networks CNHF (Cognitive Networked HF) 0742 USB BPSK/QPSK 2400Bd waveform (11Oct18) (AAI)
08722.0: AB1: Maltese Navy, MLT 1745 USB 188-141A 2G-ALE calling EB7 (03Oct18) (AAI)
09120.o: PP7: Polish-Mil, POL 1152 USB 188-141 2G-ALE calling ML2 (23Oct18) (AAI)
09162.0: ---: Unid 1204 USB 3G-HF FLSU handshake / LDL448 transfer, 859 bytes 'Citadel' encrypted file (23Oct18) (AAI)
10185.0: MIRADOR2: Unid 1417 USB 188-141A 2G-ALE sounding (06Oct18) (AAI)
11118.0: ---: Unid 0607 USB (offset + 1500Hz) Siemens CHX200 F1-modem (CHP-200) FSK 249Bd & 250Bd/170Hz, selcall mode (10Oct18) (AAI)
12194.0: CM6: Commandement de la 6e Région Militaire Tamanrasset, ALG 0638 USB 188-141 2G-ALE calling TIN (18Oct18) (AAI)
12457.0: ---: Unid, prob. KNL Networks CNHF (Cognitive Networked HF) 1340 USB 6KHz WideBand PSK-2 4800bps waveform (14Oct18) (AAI)
12780.0: ---: Unid, prob. KNL Networks CNHF (Cognitive Networked HF) 0810 USB 18KHz WideBand PSK-2 19200bps waveform (14Oct18) (AAI)
13378.0: ---: Unid 0848 USB MIL 110A & STANAG-4539, STANAG-5066 IP-over-HF sessions (01Oct18) (AAI)
17398.2: ---: DHFCS Cyprus Is. Overseas Stn 1120 USB STANAG-4285/1200bps 1536-bit TDM protocol (prob. DRS GA-205 multiplexer) (28Oct18) (AAI)

two interesting FSK catches: 74.5Bd /250 and 75Bd/200

$
0
0
1) FSK 74.5Bd/250
Some FSK 74.5Bd/250 short transmissions (Fig. 1) have been heard on 11018.0 KHz (CF) sending the same seven bits pattern in postive and in negative polarity (Fig. 2). Since the short transmission time I coould not DF the transmission site.

Fig. 1
Fig. 2
 FSK 74.5Bd/250

2) FSK 75Bd/200
The FSK 75Bd/200 (Fig. 3) is a continuous transmission that can be heard on 8408.0 KHz (CF), most likely an encrypted broadcast (shore-to-ship ?). Several TDoA runs point to the West Mediterranean sea area: the Tx location could be Algeria or Balearic Islands (Fig. 4).

Fig. 3
Fig. 4

The demodulated bitstream does not exhibit ACF spikes (ACF = 0) after normal and differential decoding and can be descrambled using the polynomial x^8+x^6+x+1 but without appreciable results.
A similar transmission (FSK 75Bd/200) was heard on 11 Jan 2018 on 4540.0 KHz. In that case, after differential decoding, the stream showed up a clear 365-bit period (Fig. 5) which is due to the sequence of the scrambler polynomial x^7+x^6+1. The descrambled stream is shown in Figure 6 (thanks to cryptomaster).

Fig. 5
Fig. 6

LINK-11 CLEW, Hamming check matrix

$
0
0
The check of a Link-11 CLEW stream discussed in the end part of this post, can be speed up by using the Hamming check matrix for the H(30,24) coding, ie a 30-bit code word consisting of 24 bits for data + 6 bits for Hamming parity bits (termed EDAC in Link-11 literature). The check matrix is constructed as shown in MIL 188-203-1A #5.2.4.1 and here.

Code verification is carried out by comparing each line of code in turn with all rows of the check matrix, except the extra parity line (the overall parity bit): the vertical correspondences of the "1" locations in the code line and in the row #n of the check sub matrix are counted. If the matches are even then the correspondent location #n in the EDAC bits will be "1", otherwhise (ie matches are a odd number) will be "0" (odd parity).
 
  EDAC           data
110100 000001110101110001100010
010011 111001110010010001111011
110100 111100101110010110011111
100100 010111010000110110000110
010010 011010000000010100100111
110001 010001110110000010010000

     check sub-matrix           identity sub-matrix
111111111111100000000000 010000
111111000000011111110000 001000
110000111100011110001110 000100
001100110011011001101101 000010
101010101010110101011011 000001
111111111111111111111111 111111
Test the first line of code 000001110101110001100010

000001110101110001100010
111111111111100000000000 check matrix line #0
6 matches, EDAC bit #0 shall be 1

000001110101110001100010
111111000000011111110000 check matrix line #1
4 matches, EDAC bit #1 shall be 1

000001110101110001100010
110000111100011110001110 check matrix line #2
5 matches, EDAC bit #2 shall be 0

000001110101110001100010
001100110011011001101101 check matrix line #3
6 matches, EDAC bit #3 shall be 1

000001110101110001100010
101010101010110101011011 check matrix line #4   
5 matches, EDAC bit #4 shall be 0
EDAC bits 0-4: 11010

Test the second line of code 111001110010010001111011

111001110010010001111011
111111111111100000000000 check matrix line #0
7 matches, EDAC bit #0 shall be 0

111001110010010001111011
111111000000011111110000 check matrix line #1
8 matches, EDAC bit #1 shall be 1

111001110010010001111011
110000111100011110001110 check matrix line #2
7 matches, EDAC bit #2 shall be 0

111001110010010001111011
001100110011011001101101 check matrix line #3
9 matches, EDAC bit #3 shall be 0

111001110010010001111011
101010101010110101011011 check matrix line #4   
10 matches, EDAC bit #4 shall be 1

EDAC bits 0-4: 01001
The verification of the remaining combinations confirms the use of the same method of checking (if you want, you can check it yourself).

If only one error is detected, it is corrected and sent to the computer. The computer is also advised that the word contained an error and that it is corrected. If two errors are detected the Hamming decoding can only determine that errors exist but cannot determine which bits are in error.

IP over HF via STANAG-5066 RCOP, MIL 188-110A as HF waveform

$
0
0
Interesting transmissions spotted on 9105.0 KHz/usb at 1240z, user/locations are unid, maybe form US-Mil stations? The transfer concerns IP-over-HF (IPoHF) via STANAG-5066 RCOP protocol [1]: 1380 bytes IP packets are exchanged in directions 192.168.2.48 -> 192.168.12.48 and 192.168.1.48 -> 192.168.14.48 , ESP (IPSec) secure protocol is used.  MIL-STD 188-110A Serial is used as the HF waveform. STANAG-5066 Addresses (001.003.003.103 001.001.001.101) belong to US-DoD. Similar transmissions was heard on 8th October on 13378.0 KHz/usb using 188-110A and S4539 QAM-64 as HF bearers (discussed here) maybe the user is the same.
The sequence of the figures illustrates the various steps that have been performed in the analysis of the signal.

Fig. 1 - 188-110A on-air symbols
Fig. 2 - STANAG-5066 bitstream after the removal of 188-110A overhead
Fig. 3 - hex-dump after the removal of STANAG-5066

The hex-dump file resulting after the removal of STANAG-5066 PDUs encapsulations has been processed using "wireshark" software: IPv4 addresses and headers as well as IPSec encapsulation are clearly visible.

Fig. 4 -


https://yadi.sk/d/wuBIWQ_HSwVRMA
https://yadi.sk/i/6p-izzJatalVwg
https://yadi.sk/i/ulK473q0E2rCNw

[1] https://www.isode.com/whitepapers/ip-over-stanag-5066.html

https://yadi.sk/i/6p-izzJatalVwg


email over hf using FED-1052 DLP and "IDEA" encryption (2)

$
0
0
Yet another interesting catch of an email-over-hf session using FED-1052 Datalink Protocol (DLP, Appendix B) and IDEA encryption. The transmission was recorded on 09187.0 KHz/usb 1357z: encrypted MIL 188-141A 2G-ALE to set up links and switch to MIL 188-110A serial tone waveform for emal traffic via FED-1052 App.B DLP (Data Link Protocol); ASCII-7 data are encrypetd using CFB64 "IDEA" algorithm. Headers are unencoded so you can read both the sender and recipient, in this sample:
sender: ZJ1, root@bfzj1f1.is.bf.intra2.admin.ch
recipient: ZA1, statist@bf.intra2.admin.ch
email ID: "stat-ZJ1-20181113135501" (2018.11.13, time: 135501)
The FQDN (Fully Qualified Domain Name) "intra2.admin.ch" indicated in the e-mail addresses suggests an intranet of the central administration of the Swiss Federation: likely this is the Swiss Army or the Diplo Service.
A more detailed post about such transmissions can be read here.

Fig. 1 - on air signals, MIL 188-110A Serial Tone waveform
Fig. 2 - FED-1052 App.B stream


two interesting MFSK catches

$
0
0
1) MFSK-66 (33+33) 40Bd/40 (presumed)
Transmission heard on 9122.0 KHz/usb on 20 November, 0832z. It looks like they use 2-tones x symbol and a manipulation speed of 40 Bd (Fig. 1). Dividing the spectrum into two equal parts gives a grid of 33 tones, 40Hz spaced, with the expected symbol rate of 40Bd (Fig. 2): this is why I defined the signal as MFSK 33+33 40Bd/40Hz, but I could be wrong. Likely Russian users.


Fig. 1
Fig. 2
Fig. 3

2) 19KHz wide MFSK-17 33.3Bd/1200Hz
Transmission heard on 13386.0 KHz/usb (centered on ~ 13397 KHz) on 20 November, 1156z. Never meet a such wide band MFSK waveform.


Fig. 4
Fig. 5

 

8-ary constellation bursts at 12800bps data rate (2)

$
0
0
Some other observations and updates about the S4539 12800bps 8-ary constellation already discussed here: this post was possible thanks to the collaboration of my friends AngazU, Christoph, Martin G8JNJ, and Sergio.

As shown in Figure 1, the polarity of mini-probes matches the 12800Ubps (6,6,2) setting so no doubt about the proper operation of the used decoders, primarily the Harris RF-5710A model.

Fig. 1a) 287 symbols preamble and sync sequence (red);
Fig. 1b) the actual "6,6,2" setting read from the preamble;
Fig. 1c) the theoretic "6,6,2" setting

Now look at the on-air symbols shown in Fig. 2: S4285 symbols (Fig. 2a) are exactly mapped to a PSK-8 constellation but the S4539 symbols being analyzed occupy different points (Figs. 2b,2c). It looks like a subset of the QAM-64 symbols is used for data  while the 4 "circled" points are the QPSK symbols of the mini-probes. Thus, since no interleaving and no coding are used in 6,6,2 mode (12800bps), the source data must be prepared such that after the scrambling the resulting 6-bit numbers will be mapped only to a 8-point subset of the QAM-64 outer ring. This makes sense and clarify the 12800bps speed, though we do not figure out why this is done.
 
Fig. 2
Figure 3 shows the plots of one frame obtained by Christoph: 256 data symbols + 31 mini-probe symbols: the 31 mini-probe symbols were descrambled and are at I=1,Q=0. As you can see the other points fit perfectly the 8 out-of-20 points of the QAM-64 outer ring [7 3 24 56 35 39 60 28].

Fig. 3 - 256 data symbols + 31 mini-probe symbols
These eight symbols have interesting structure: the 3,7,24,28 symbols are the same of  35,39,56,60 unless the left-most bit and they are at the same distance (32)

 3 000011
 7 000111
24 011000
28 011100

35 100011
39 100111
56 111000
60 111100

According to Christoph, the 6 bits are ABBCDD where ABC identify the point and D+B=1 mod 2. The ABC bits stream exhibit a 480-bit leghth period (Fig. 4).

Fig. 4
Back to the transmissions, our monitoring revealed that the entire sequence lasts about 36 seconds and consists of 6 "clusters", or "sets", each consisting of three channels with same spacing and arrangement:


Lately, our friend Martin G8JNJ noticed in the lower cluster A1 A2 A3 one weaker set (TDoA 100% St Eval) every 30 seconds (approx) and one set of stronger ones every three to five  minutes (approx) which he wasn't able to TDoA. "So that I think I'm hearing more than one transmitter site. It's proving to be very difficult to TDoA the second one, as they transmit much less frequently, but there is a big difference in RX signal strength between the transmissions", Martin says.
A friend of AngazU suggested that they could be developing some kind of turbo equalizer or similar. These emissions would be tests of a  training sequence and they would be measuring errors, convergence time and other parameters under different conditions. Just a guess, if they  succeed, we will see the  full constellation.

By the way, subjecting for example the F1 channel to the k500 decoder it prints out only 1536 decoded bits although it correctly recognizes the 12800U setting. As shown in Figure 5, each burst is made up of 13 frames for a total of 256x13=3328 QAM-64 data symbols that make 3328x6=19968 bits of data! (no interleaving neither coding is used in 12800U mode). Thus it seems that only one data frame (256 x 6) is processed by k500 (possibly the first one?): maybe it's a decoder limitation due the short burst duration? Note that it does not happen when I use the RF-5710A modem.

Fig. 5
(to be continued)

STANAG-5065 MSK300, LF shore-to-ship surface broadcast

$
0
0
Nice catch of a STANAG-5065 MSK300 signal picked up by a colleague using the Alicante Kiwisdr on 145.0 KHz. By the way, we wish here to thanks the owner of Alicante kiwisdr for his kindness allowing the use of his sdr uninterruptedly for long periods.
The signal is transmitted from Guardamar de Segura in Spain (also known as "Torreta de Guardamar" [1]) currently operated by the Spanish Infanteria de Marina to convey messages to submarines.The use of the S5065 Low Frequency MSK300 waveform (surface broadcast) and the "mission" of Guardamar site, suggest that these transmissions could be intended for surfaced submarines or submarines cruising at periscope depth.  
 
Fig. 1- TDoA results (left), Tx location obscured by Google Earth (right)
While other broadcast stations for submarines such as DHO38 or NSY transmit continuously, Guardamar only transmits if there is traffic to send, and, since the low bandwidth that characterizes the LF band, transmissions may last for some more than an hour. Most likely the Thales TRC 2556 VLF/LF digital multi-channel receiver is used aboard [2].

As said, the S5065 MSK 300Bd/150 is the used waveform:

Fig. 2 - MSK 300Bd/150Hz waveform
Messages use 7-bit START-STOP ITA2 (Baudot) code which is then encrypted using the KW-46 crypto equipment. Encryption results in bits 1 to 6 being encrypted and bit 7 (STOP) being replaced with a deterministic unencrypted Fibonacci bit defined by the polynomial x^31+x^3+1 which provides synchronization to the receive KW-46 equipment. 
In MSK300 mode the encrypted data from KW-46 are coded into a (13,12) Wagner error coding scheme and then applied to the MSK modulator (as seen here, processing for STANAG-5065 FSK operations does not include Wagner encoding). As shown in Figure 3, the encoding includes blocking the information into 2 character groups, substituting a parity bit for every second Fibonacci bit to form a (13,12) Wagner odd parity code block (odd numbers of 1s) over 12 informations bits (Fibonacci bit excluded).

Fig. 3 - (13,12) Wagner encoding of KW-46 encrypted stream
In MSK modulations the intelligence is contained in the phase shifts and is not consistent with the frequency shifts, thus the signal can't be demodulated using a generic FSK demodulator.

Fig. 4 - MSK300 phase-plane
After some unsuccessful demodulation attempts I asked my friend Christoph Mayer for help, he too checked the S5065 waveform and kindly sent me an MSK demodulator written by him and re-coded for Octave. The results of the analysis of the modulated stream, shown in Fig. 5 after left shifted, perfectly matches the schema of Figure 3.

Fig. 5 -  S5065 MSK300 stream after demodulation
It's very interesting to note that both the sequence obtained with n F-bits and that obtained with n/2 (n/2 -1) F-bits are attributable to the same polynomial x^31+x^3+1, my guess is that this feature maybe helps the initial synchronization of the FEC process detecting the position of the Wagner odd parity bits.




XMPP over HF radio using STANAG-5066

$
0
0

Interesting transmissions spotted on 4381.0 KHz and 4833.5 KHz (all usb) consisting of MIL 188-110A Serial HF waveform (fixed 600bps/S) and 6-bit code clear text (6x28) & STANAG-5066 as bearer for XMPP Multi-User Chat (MUC)  messages.
XMPP, the Internet Standard eXtensible Messaging and Presence Protocol, is the open standard for Instant Messaging (IM), Group Chat and Presence services. XMPP is widely used for military deployments, where operation over constrained and degraded networks is often essential, particularly for tactical operation. 
Multi-User Chat (MUC) is a central service for military communication. If data is being provided, it makes sense to share it so that all interested parties can see it. For example, it will enable external strategists or lawyers to observe communication in real time, and provide input as appropriate. It often makes sense to share information in the field, for example a group of ships jointly working out who will target what and how. MUC is an important operational capability. 
In XMPP a client connects locally to its server, and then there are direct server to server connections (S2S) to support communication with clients on other servers. The mapping of XEP-0361 (Zero Handshake Server to Server Protocol) onto STANAG-5066 is standardized in "XEP-0365: Server to Server communication over STANAG-5066 ARQ”. XEP-0365 is mapped onto the S5066 SIS and transferred using RCOP protocol.
The 6-bit text and S5066 bitstream (Fig. 1) is obtained after demodulating the 188-110A Serial waveform:
 
Fig. 1
S5066 peers have the addresses 010.050.066.001 and 010.050.066.003 (odd) in 4381.0 KHz channel; the addresses 010.050.066.002 and 010.050.066.004 (even) are used in the 4833.5 KHz channel. These are probably "exercise" addresses since the block 10.50 is allocated to Uganda. 
These transmissions have been monitored for about one day so I could collect hundreds of messages, only some of them are shown below as examples: you can see groupchat messages, Instant Messaging (private messages) and Presence/IQ messages. My friend and colleague Guido @decodesignals logged same transmissions (and same addresses) on 4613.0 Hz, in his catches the S4539 4800bps is used as the HF waveform.

<message
    from='latency.ground@ground.net/2aad61419fb06287'
    to='latency.p8-one@p8-one.net'>
    <body>
    (a3d5bb51-70c3-4152-9a29-ab7cddbb47a3; 20181207T224101.034169)
    Test Message H - Private Message From GROUND Latency Acct
    </body>
    <securitylabel xmlns="urn:xmpp:sec-label:0">
    <displaymarking bgcolor="green">UNCLASSIFIED</displaymarking>
    <label/></securitylabel>
</message>

<message
    from='mission-one@chat.ground.net/LATENCY_GROUND'
    to='mission-one@chat.p8-one.net'
    type='groupchat' id='fmucinte54838a0b2804718'>
    <fmuc xmlns='http://isode.com/protocol/fmuc'
    from='latency.ground@ground.net/8f9f7ba5ca23d374'
    sync_stamp='2018-12-07T22:44:52Z'/>
    <body>
    (29f06ec4-a4a9-4849-bd46-42c54efa42ea; 20181207T224452.309137)
    Test Message T - MUC From GROUND Latency Acct
    </body>
    <securitylabel xmlns="urn:xmpp:sec-label:0">
    <displaymarking bgcolor="green">UNCLASSIFIED</displaymarking>
    <label/>
    </securitylabel>
</message>

<iq
    from='mission-one@chat.ground.net/LATENCY_GROUND'
    to='mission-one@chat.p8-one.net/Supervisor Air'
    type='get' id='d98686c2-d66f-4bdc-9b4e-ceb9911c834e'>
    <query node='http://swift.im#3ScHZH4hKmksks0e7RG8B4cjaT8='
    xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<presence
    from='mission-one@chat.ground.net/LATENCY_GROUND'
    to='mission-one@chat.p8-one.net/LATENCY_GROUND'
    id='fmucint0e52f98befac3522'>
    <fmuc xmlns='http://isode.com/protocol/fmuc'
    from='latency.ground@ground.net/8f9f7ba5ca23d374'/>
    <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

<presence
    from='mission-one@chat.p8-one.net/LATENCY_AIR'
    to='mission-one@chat.ground.net/LATENCY_AIR'
    id='fmucint0572337e8aafbad5'>
    <fmuc xmlns='http://isode.com/protocol/fmuc'
    from='latency.p8-one@p8-one.net/f5ac7b83c2cc6951'/>
    <x xmlns='http://jabber.org/protocol/muc'/>
</presence>

A bit of intelligence gathering can be done by the reading of the messages and from TDoA.
Direction finding  is not easy since the transmissions originate from two different sites, however the results obtained indicate UK as the area of operations (Fig. 2): maybe UK MoD?
Fig. 2 - TDoA result
The namespace attribute fmuc xmlns='http://isode.com/protocol/fmuc can be a clue of the use of the M-Link software developed by Isode for XMPP [1]. By the way, reading some Isode documentation available in the web you can see odd 10.x.y.w S5066 addresses like the ones used in the heard transmissions (Fig. 3)

Fig. 3 - from XMPP5066EVAL.pdf by Isode
Servers names and nodes names as: mission-one@chat.ground.net/LATENCY_GROUND and mission-one@chat.ground.net/LATENCY_AIR, as well as the Test Message format suggest a test phase aimed to measure the latency of air and ground links. Note also that the tests are performed using different HF waveforms: MIL 188-110A Serial 600bps and STANAG-4539 4800bps.

That being said, probaby these are UK MoD test transmissions concerning (Isode) XMPP over HF radio but it's only my guess. Ropey @Topol_MSS27 suggests that "maybe P8 (chat.p8-one.net) is a clue and references new ops for upcoming P-8A's due to join RAF from Nov next year" [2].

(a lot of documentation is publicy available in the web about ISODE XMPP, google is your friend) 
[2] https://www.raf.mod.uk/aircraft/p-8a/ 
 

CIS-79 "TANDEME" OFDM 79-tone

$
0
0

CIS-79 "tandem", OFDM 79-tone spotted on 10790.0 KHz/usb with bad SNR value. The signal is formed by 80 sub-carriers but the higher one (#80) is zeroed and unmodulated. The waveform uses QAM-64 modulation at symbol-rate of 30.5 Baud and 37.5 Hz channel step. No ACF value (=0) has been detected. Each symbol lasts 315 samples (256 +59). 
Note that a "control/service" symbol is sent each three tones using BPSK (Fig. 2): this feature was also commented here but in that case PSK-8 modulation is used. The signal was resampled at 9600Hz before to be analyzed.

Fig. 1

STANAG-5030/MIL-188-140 VLF/LF multichannel broadcast to submarines (tentative)

$
0
0
The Navy ashore VLF/LF transmitter facilities transmit submarine command and control broadcast which is the backbone of the submarine broadcast system. The VLF/LF radio broadcast provides robustness, availability, global coverage, and has seawater penetrating properties. The 200Hz assigned bandwidth for VLF/LF broadcast and the low efficiency (and narrow bandwidth) of the aerials are limiting factors, but the use of Minimum Shift Keying (MSK), a form of Quadrature Phase shift Keying, can allow optimum use of this narrow bandwidth [1]. 
VLF/LF broadcasts to submarines are STANAG-5030 compliantbut unfortunately it's a restricted document so no information is publicy available. Moreover, the new STANAG-4724 is currently being ratified by NATO member states as next evolution.  However, googling the web it's possible to retrieve (few) manufacturers brochures of VLF/LF modulators/demodulators, as the one shown in Fig. 1, and get some informations. These equipments can provide TDM multi-channel broadcast (up to four channels, all 50 baud) and mainly use modulation techiniques as MSK (MSK2 2x50 Baud channels and MSK4 4x50 Baud channels), OQPSK and OOK "on-off keying" (the latter usually associated with the Morse Code).


Fig. 1
waveforms
Reference MSK modulation indicates zero-crossing transitions (eg +1/+1 to -1/-1 and viceversa, +1/-1 to -1/+1 and viceversa) cannot be allowed if phase discontinuity is to be preserved.

I analyzed some easily receivable VLF stations (DHO38, FTA, FUE, GQD, ICV, JXN, NSY, SXA, ...) and found that the phase-plane of some signals exhibits the expected transitions while otherssignals show odd transitions. The answer is to be found in the harmonics spectrum of the signals (Fig. 2): when the carrier is missing  the PLL algorithm locks onto one of the two spectral lines and causes the odd transitions shown in the phase-plane. The presence/absence of the carrier also makes me think of different solutions adopted by manufacturers since MSK should be coherently detected like OQPSK (that implies acquiring the carrier!) or non-coherently detected like FSK. 

Fig. 2 - carrier is missing in signals like FUE
My friend ANgazu pointed out the use of different filtering (Fig. 3). If a Gaussian filter with a Bt of 0.8 or less is in use, as in FUE, the side lobes are attenuated and the modulation is GMSK. NSY has many side lobes so, most probably, no Gaussian filter is in use and modulation is pure MSK. A special case is JXN that uses a cosine filter.

Fig. 3 - differing filterings
That being said, some equalization/correction is needed to emerge the carrier in the midlle of the two tones as shown in Figure 4:

Fig. 4 - FUE constellation after and before equalization
However (G)MSK doesn't seem to be the sole modulation used: using Diff=1 in the phase-plane it turns out that OQPSK-like modulations are used, as in case of FTA and DHO38 (Fig. 5)

Fig. 5
Indeed, MSK is a special case of Continuous-Phase Frequency Shift Keying (CPFSK) which is a special case of a general class of modulation schemes known as Continuous-Phase Modulation (CPM). It is worth noting that CPFSK is a non-linear modulation and hence by extension MSK is a non-linear modulation as well. Nevertheless, it can also be cast as a linear modulation scheme, namely Offset Quadrature Phase Shift Keying (OQPSK), which is a special case of Phase Shift Keying (PSK)... identifying the used modulation may become a nightmare!

data format
Traffic is encrypted and each channel may convey four different types of broadcasts, reference Figure 1:

VALLOR: a VLF/LF single-channel 50 Bd submarine broadcast operating as a backup to the VERDIN (1) system and using KW-46 encryption system (VALLOR is the codename for KW-46 system);
JASON: it's probably a proper feature of the shown product depicted (maybe a codename of an encryption system?);
CLEAR: most likely clear-text traffic (no encryption is used);
ECF: (Empty Channel Filler), in conditions where no messages are available for a transmission channel, Empty Channel Filler data is generated automatically at the transmitter equipment. 


Data are should be arrangend in a stream incorporating in a regular manner a symbol dedicated to synchronization and placed every r data symbols, i.e. in the same format defined by STANAG-5065 in which frames are delimited by the pseudo-random sequence generated by the polynomial x^31+x^3+1 (aka "Fibonacci bits"). These formats may also be related to the patent WO2009071589A2 [2]. Error Correction And Detection (EDAC) should be performed using Wagner coding.
Curiously, I found that GQD uses a 28-bit format and a pseudo-random sequence  generated by the polynomial x^32+x^31+x^4+x^3+x+1 ...but I have to say that in this case I used an FSK demodulator.

Fig. 6

transmit system
Figure 7 shows a simplified block diagram of the VERDIN (1) VLF/LF transmit system. Submarine broadcast is a continuous transmission sequence of prioritized messages which normally lasts two hours. It is generated by ISABPS (Integrated Submarine Automated Broadcast Processor System) and sent to the transmit terminal which is used to multiplex, encrypt, encode, and modulate up to four 50 bps submarine broadcast channels into VLF/LF radio frequency signals which is amplified/radiated by the VLF/LF transmitter antenna. [3]

Fig. 7 - VERDIN system

(to be continued)

(1) VERDIN is a digital data, multichannel communications system operating in the VLF range from shore to deployed submarines. VERDIN permits transmission of up to four 50 Bd channels from an individual transmitter using time division multiplexing.The system is normally operated in a four-channel mode.



some recent (unid) catches in the 8 MHz band

$
0
0

STANAG-4285 async operations


Transmission heard on 8167.0 KHz/usb consisting of S4285 600bps/L transfer. After demodulation, the bitstream reveals ITA2 5N1.5 async operation with encrypted data and looks like the format seen here which is possibly used by Turkish-Mil.




https://yadi.sk/d/PPd1Rl9FZHtTbQ

MIL 188-110A bursts


Since several days I've been listening to 188-110A Serial Tone bursts on 8058.0 KHz/usb, 600bps short interleaving is the used mode. Burst last 1200ms and have a spacing of 500ms.  The long (hours) sessions continuously send the same 240-bit pattern. 


Fig. 1 - 240 bit pattern (reshaped to bytes)
TDoA runs point to Spain. 

Fig. 2

 https://yadi.sk/d/tYRSkswo6gwYiA

MFSK-4 100Bd/400

short transmission heard on 8180.0 KHz/usb, unfortunatelly I went very late on it and I have not had the chance to listen to it anymore. My friend KarapuZ suggests Russian source.


https://yadi.sk/d/JnZGPnoAsoXarQ

Article 0

9MR - Malaysian Navy, uncommon FSK shift and ITA2 framing

$
0
0

(a joint analysis by me and ANgazu)

 

 


9MR 9/10/13 RMMJ MRB MRB RYRYRYRY 9MR 9/10/13 RMMJ MRB MRB SGSGSGSGSG AR JULL JULL
is the Id & "RY/SG" test tape transmitted by 9MR Royal Malaysian Navy (RMN) [1], picked up using the  VR3BG KiwiSDR located in Hong Kong and tuned on 8461.1 KHz and 6483.1 (CF).
The signals exhibit two curious features, at least in the heard test trasmissions: the first consists of the used 50Bd async FSK waveform with the non-standard and quite uncommon 900Hz shift value (Fig. 1).

Fig. 1 - 900Hz shift
The second feature is the framing which is used during the test operations: as you may see in Figs. 2 and 3, they use ITA2 code (5x28) with alternating framings 5N1/5N2, i.e., a character sent with 1 stop bit followed by a character sent with 2 stop bits:

This odd system causes the 15-bit period visible either in the raster of SA either in the bitstream (the latter reshaped to 30-bit in Figure 2). When a block ends, it possibly uses a special character or new line that causes te one bit shift to the left. So far, we never seen such mode.

Fig. 2
Fig. 3

It must be said that many reports indicate the ITA2 framing 5N1 and the FSK waveform 50Bd / 850Hz: these are obviously errors caused by the "goodness" of many decoders which can correctly decode these test tape transmissions even with slightly wrong settings. 

During the last days monitoring we have not yet had the chance to hear traffic on the two mentioned frequencies, just test transmissions, so we can't say if they always use the same shifted 5N1/5N2 framing also in traffic mode: we hope to have better luck in the next days/weeks. By the way, our TDoA direction findings (6483.1 KHz signal) point to Tanjung Gelang, site of RMN's Fleet HQ of the Naval Region I.

Fig. 4
As a final note, the analysis of the 6483.1 FSK  transmission suggests that there maybe some flaw somewhere.
 
Fig. 5


https://yadi.sk/d/d15nXWys6iSuIg (6483.1 KHz)
https://yadi.sk/d/2gmoADztQTwT0w (8461.1 KHz)

last logs of 2018

$
0
0
04833.5: ---: Unid, prob. UK MoD 2114 USB MIL 188-110A serial tone waveform, testing XMPP multi-user chat over HF using STANAG-5066 RCOP protocol. Also logged on 4381.0 Khz. (07Dec18) (AAI)
05290.0: TN5: "ZaSKIS" Base for Stationary Communication and Information Systems SVK-Mil Trencin, SVK 1337 USB MIL 188-141A 2G-ALE, handshake PO2 "VKPRESOV" Presov, STANAG-4285 waveform, FTP transfer of GZIP copressed email & files via STANAG 5066 using HBFTP client (12Dec18) (AAI)
05390.8: HWK01: Swedish Mil, S 1334 USB 3G-HF 1-way FLSU, circuit service mode using MIL 188-110A serial tone waveform, sending wrapped data via STANAG-5066 UDOP client (20Dec18) (AAI)
05787.0: CAMP: Unid 1444 USB MIL 188-141A 2G-ALE, calling all stations, MIL 188-110A serial tone waveform, 5x128-bit MI (10Dec18) (AAI)
06395.0: BS3101: Unid 1427 USB MIL 188-141 2G-ALE, handshake BS3501, no continuation (21Nov18) (AAI)
06796.0: TZSO4: Unid 1003 USB MIL 188-141 2G-ALE, sounding (10Nov18) (AAI)
07572.0: PEGASO: Spanish-AF EVA (Escuadrón Vigilancia Aérea) Torrejón de Ardoz, S 0845 USB aily radio-checks with EVA's stations (KANSAS, ORION, EMBARGO, DAGON, PRIMUS,POLAR,...) (26Nov18) (AAI)
07600.0: FN01: Algerian-Mil, ALG 0834 USB MIL 188-141 2G-ALE, handshake FN02, MIL 188-110A serial tone waveform (26Nov18) (AAI)
07641.0: TXFA5: Guardia Cuvil, E 1057 USB MIL 188-141 2G-ALE, calling TWLL1 (also heard callings to TWLN1, TWVB1, TWVO1) (20Dec18) (AAI)
07840.0: SWA: Unid 0949 USB MIL 188-141 2G-ALE, calling SRX (30Nov18) (AAI)
07840.0: SWA: Unid 0954 USB MIL 188-141 2G-ALE, calling HY8 (30Nov18) (AAI)
07840.0: SWA: Unid 1001 USB MIL 188-141 2G-ALE, calling 8CQ (30Nov18) (AAI)
07841.0: DA09: Unid 0745 USB MIL 188-141 2G-ALE calling DA01 (02Nov18) (AAI)
07922.0: ---: Unid 0944 USB STANAG-4286 600bps/L, sending KG-84 encripted data (16Nov18) (AAI)
07975.0: ---: Unid 0840 (CF) MFSK-11 125Bd/250 792ms ACF, lasting ~47s. Also heard at 0915 (07Nov18) (AAI)
08086.0: JU10: Algerian-Mil, ALG 1413 USB MIL 188-141 2G-ALE, calling NX1 (17Dec18) (AAI)
08146.0: AGH: Iraqi Emergency Response Forces, IRQ  1431 USB MIL 188-141 2G-ALE sounding (08Nov18) (AAI)
08167.0: ---: Unid 1230 USB STANAG-4285 600bps/S, async 5N1.5 (ITA2) transfer, encrypted data (18Dec18) (AAI)
08170.0: ---: UK DHFCS, Cyprus 1730 USB STANAG-4285 2400bps/L bursts, 1536-bit TDM protocol (15Dec18) (AAI)
08327.0: ---: Unid 0852 USB 3G-HF 2-way FLSU handshake, HDL+ transfer (26Nov18) (AAI)
08408.0: Unid 0939 (CF) FSK 75Bd/200 continuous encrypted bcast, TDoA runs point to south-west Med sea. Also heard on 10182.0 (CF) (02Nov18) (AAI)
08630.0: HY8: Unid (Algerian-Af?) 0930 USB MIL 188-141A 2G-ALE calling SRB (12Dec18) (AAI)
08770.0: Unid 1500 USB STANAG-4197 ANDVT system (02Nov18) (AAI)
09000.0: KML: Unid 0856 USB MIL 188-141 2G-ALE, calling MAN (03Dec18) (AAI)
09000.0: MAN: Unid 0859 USB MIL 188-141 2G-ALE, calling KML (03Dec18) (AAI)
09019.0: XSS: DHFCS, UK 1509 USB MIL 188-141 2G-ALE sending wx METARs & TAFs via AMD to UKE303 AWACS for RAF airports Waddington (EGXW) e Brize Norton (EGVN)(08Nov18) (AAI)
09065.0: Russian /Mil/Gov 0832 (CF) FSK 100Bd/500, T-207 encryption (02Nov18) (AAI)
09105.0: ---: Unid (US-Mil?) 1240 USB MIL 188-110A serial, IP-over-HF via STANAG-5066 RCOP, 1380 bytes IP packets from 192.168.2.48 to 192.168.12.48. ESP (IPSec) secure protocol used. STANAG-5066 Addresses (001.003.003.103 001.001.001.101) belong to US-DoD (07Nov18) (AAI)
09187.0: ZJ1: Swiss Army, CH 1357 USB MIL 188-141A 2G-ALE handshake ZA1 using Linking Protection, MIL 188-110A serial tone waveform, sending email via FED-1052 App.B, encrypted ASCII-7 data using CFB64 "IDEA" algorithm (12Nov18) (AAI)
09299.0: DA10: Unid 1151 USB MIL 188-141 2G-ALE calling DA01 (08Nov18) (AAI)
09920.0: DA09: Unid 1400 USB MIL 188-141 2G-ALE calling DA01 (05Nov18) (AAI)
10790.0: ---: Russian Mil/Gov 1110 USB CIS-79 "TANDEME", OFDM 79-tone QAM-64 30.5Bd 37.5Hz, PSK-2 special/control symbol each 3 tones (11Dec18) (AAI)
11029.0: DA03: Unid 1100 USB MIL 188-141 2G-ALE calling DA01 (03Nov18) (AAI)
11371.4: HBLZDRD1: Roumenian-Mil, ROU 0801 USB MIL 188-141 2G-ALE calling HFJCDRD1 (02Nov18) (AAI)
11371.4: HBLZDRzZM: Roumenian-Mil, ROU 0810 USB MIL 188-141 2G-ALE calling HFJCDRzZM (02Nov18) (AAI)
12062.0: HL2: Polish-Mil, POL 1050 USB MIL 188-141 2G-ALE, calling KW7 (17Nov18) (AAI)
14606.0: KA2: (KALI12) Polish KFOR unit, KSV 0915 USB MIL 188-141 2G-ALE handshake PL4 (PLATER04), MIL 188-110A serial tone waveform, sending email via STANAG-5066 using HBFTP client, compressed data using GZIP (12Nov18) (AAI)
14606.0: PL4: (PLATER04) Polish KFOR unit, KSV 1118 USB MIL 188-141 2G-ALE handshake OD8 (ODRYNA08), MIL 188-110A serial tone waveform, sending email via STANAG-5066 using HBFTP client, compressed data using GZIP (10Nov18) (AAI)

unid 1200Bd (G)FSK bursts recorded in Japan

$
0
0

This signal was recorded at different periods using some the KiwiSDRs located in Japan (http://103.2.34.7:8073 http://222.7.151.84:8073http://kiwisdr-jp7fso.ddns.net:8073), it was observed, at least, in three frequencies: 4765, 4626 and 4584 KHz. During night-time good results are also obtained with the KiwiSDR at Irkutsk (Russia), so the origin of the signal seems to be Japan or surroundings. 
My spanish friends ANgazu and Rapidbit (from radiofrecuencias group) did a brief analysis measuring the speed (1200Bd) and the shift between tones (825-890 KHz) and suggesting the GFSK mode (Fig. 1). On my behalf, I veried their measurements and verified that the bursts are 26 secs spaced and carry the same (encrypted?) text sent in async 8N1 mode (Fig. 2), although there are some difference among old recordings and new ones. The stream obtained after removal the start/stop bits does not offer useful information (encryption? not-standard 8-bit alphabet?), same results after descrambled the stream using the polynomial x^3+x^2+x+1. 

Fig. 1
Fig. 2
Maybe some kind of beacon? We thinked that a reference could help others to record and study the signal.



Viewing all 623 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>