18 September 2017

unid STANAG-5066 RCOP/UDOP client, Swedish Army (update-3)

wrapper protocol MTU and data-block length 
As shown in Figure 1, if the length of the data-block is longer than the max allowed value (1977 bytes in this case) it is segmented into smaller blocks. The timestamp header in the segmented block remains unchanged while the current data-block number and the data-block length are updated. The data-blocks are not filled if their length is smaller then the maximum allowed value. [1]
 
Fig. 1
Moreover, the maximum lenght of the data-block changes according to the length of the Source/Dest IDs, as shown in Fig. 2
Fig. 2
Now let's have a look at a D_PDU which transports the wrapper protocol. The S-5066 D_PDUs are visible once removed the 188-110A overhead and synched the bitstream on the sequence 0xEB90 (all D_PDUs, regardless of type, begin with the same 16-bit synchronisation sequence).
As shown in Fig. 3, the Application Data, ie the data coming from the S-5066 client application (our wrapper protocol), begin just after the Application Identifier field of the UDOP/RCOP U_PDU. It's worth noting that  the Apllication Identifier is "0x8008", that just belongs to the values which are available for user-defined applications (S-5066 Annex F, table F5).
Fig. 3
So far I found the same 4-byte sequence "00 00 00 01" for both RCOP and UDOP protocols and, in my opinion, it is a sort of identifier of the wrapper protocol PDU (Fig. 4)
 
Fig. 4
Given the initial 4-byte "identifier" and the lengths of all the headers, the Maximun Transmission Unit (MTU) of wrapper protocol is equal to 2039 bytes for both RCOP and UDOP protocols:

ID{5,HWK01}{5,HWK01}{3,001}{3,002}{10,2367731361}{0}{1975,......}{0}
4 + 56 + 1975 + 4 = 2039 bytes

ID{5,HWK01}{3,VJL}{3,001}{3,002}{10,2223461543}{0}{1977,......}{0}
4 + 54 + 1977 + 4 = 2039 bytes

As for above, the maximum lenght of the data-block must vary according to the lenght of the sender/destination IDs and the used timestamp format (9 or 10 digits):

*10-digit timestamp {10,2367731361} (15-byte length)
1975 bytes (Dest ID = 5 bytes)
1977 bytes (Dest ID = 3 bytes)

*9-digit timestamp {9,nnnnnnnnn} (13-byte length)
1977 bytes (Dest ID = 5 bytes)
1979 bytes (Dest ID = 3 bytes)

It's interesting to note in Fig.5 that in case of use of UDOP protocol each D_PDU is transmitted twice unless the last. This makes sense to improve the reliability, since the nature of UDOP protocol itself (a basic connection-less protocol) and the use of S-5066 non-ARQ service.
Also note in Fig.5 that the C_PDU is segmented into 200-byte size C_PDU segments (each segment will be encapsulated in one D_PDU !): as you see, the overhead bytes added by C, S and U sublayers are present only in the first segment (although it's repeated).


Fig. 5
Curiosly, the used C_PDU-Segment size (200 bytes) is the same than the one used in the segmentation examples depicted in STANAG-5066 C.4.2 Edition 3, in our case the max size of C_PDU is 2051 bytes (Fig. 6).
Fig. 6

Since the Maximum C_PDU-Segment size within a D_PDU is a configurable parameter, the choice of a 200-byte size and the "double send" of the UDOP D_PDUs are probably a STANAG-5066 configuration implemented to support the wrapper protocol client. 


STANAG-5066 Addresses and "Magic Strings" 
So far, these are the heard S-5066 Addresses and "Magis Cstrings":

[006.046.000.zzz] block
HWK01   006.046.000.028, 006.046.000.102
ZMK002  006.046.000.037

[006.046.001.zzz] block
DWY    006.046.001.009
PFY    006.046.001.010
ZHO    006.046.001.028
RJY    006.046.001.029
GZL    006.046.001.030
HEH    006.046.001.034
HEH002     --"--
CAU    006.046.001.046
VJL    006.046.001.054


ZAPCA
ZAPCG
ZAPCK
ZRTBC
ZRTBD
ZXPBC
ZXPBD
ZXPBG
ZXPCK 

[1] you may read other posts about this topic by browsing the tag Swedish Army

15 September 2017

Logs


05775.0: RCV: Russian Navy HQ Black Sea Fleet, RUS 1912 CW, "RIC87 DE RCV QTC 209 8 7 0915 209 = ..."
06248.8: HWK01: Swedish Armed Forces, S 0632 USB 3G-HF 1-way FLSU / MIL 188-110A Serial, Circuit Mode tfc to PFY using S5066 unid UDOP client (29Ago17) (AAI)
06280.4: HWK01: Swedish Armed Forces, S 0739 USB 3G-HF 1-way FLSU / MIL 188-110A Serial, Circuit Mode tfc to HWK01 using S5066 unid UDOP client (29Ago17) (AAI)
06329.0: OSY: Sailmail Brugge, BE 0620 USB (cf + 1500Hz) Pactor-III, working vessel PG8069  (06Sep17) (AAI) [1]
06424.5: IDR: Italian Navy S.Rosa Rome, I 0825 J3E/USB radio-check with offshore ships, daylight QRG (29Ago17) (AAI)
06733.0: 5UL: Italian Navy ship, I 0935 J3E/USB call to IDR, asking "QRV on F1B" and KG-84 traffic using RATT 75Bd/850 (29Ago17) (AAI)
06873.5: XDV: DHFCS Unid station, UK 0604 USB 188-141A handshake XSS / 188-110A serial modem (29Ago17) (AAI)
06931.0: ---: Unid 0750 USB THALES (prob. TRC-1752) traffic using proprietary S4285 waveform 600bps/L, ARQ mode (29Ago17) (AAI)
06957.0: ---: German red Cross, D 0725 USB PacTOR-I, call to DEK8810 (29Ago17) (AAI)
06980.0: ---: Unid 0712 USB 3G-HF 2-way FLSU handshake / tfc using HDL12 (29Ago17) (AAI)
07401.0: ZEMD: Zollboot Emden, D 0608 USB 188-141A call ZLST (12Sep17) (AAI)
07457.0: ---: Unid 0656 188-110 Appendix B OFDM 39-tone followed by Arabic voice comms (26Ago17) (AAI)
07505.8: ---: French MoD, F 1310 USB THALES HFXL modem tests using 9-10 x 3KHz channels, STANAG-4539 compatible waveform (12Sep17) (AAI)
07520.0: ---: Unid 0715 USB 3G-HF FLSU/HDL failed call (12Sep17) (AAI)
07667.0: ---: Unid 0709 USB 3G-HF 2-way FLSU handshake / tfc LDL512, Harris ' Citadel' encrypted 977-byte file (29Ago17) (AAI)
07692.0: 2LG: Moroccan Police, MRC 2041 USB 188-141A call to 2QH (25Ago17) (AAI)
07776.0: KA37: Unid (Tunisian Net?) 1857 USB 188-141A sounding (08Sep17) (AAI)
07890.0: KB24: Algerian Military, ALG 1613 USB 188-141A call NX10 (09Sep17) (AAI)
07902.0: WARSZAWA1: Polish MoI (MSWiA), POL 0828 USB 188-141A, call to KRAKOW (04Sep17) (AAI)
07930.0: ---: Unid 0619 USB 3G-HF 2-way FLSU handshake / HDL+ transfer (12Sep17) (AAI)
07990.0: HWK01: Swedish Armed Forces, S 0758 USB 3G-HF 1-way FLSU / MIL 188-110A Serial, Circuit Mode tfc to PFY using STANAG-5066 unid UDOP client (12Sep17) (AAI)
08067.0: ---: Russian Mil/Intel, RUS 0717 (cf) FSK 50Bd/500, 128-bit ACF (prob. Moroz) (12Sep17) (AAI)
08079.0: CENTR2: MFA Bucarest, ROU 0657 USB 188-141A handsahake OJP embassy / 188-110A Serial, sending STANAG-5066 email (12Sep17) (AAI)
08132.0: BP21: Bundespolizei Küstenwache Patrol Vessel 'Bredstedt', D 0752 USB 188-141A handshake / R&S GM2100 serial modem PSK-8 waveform, positions report email to BPLEZS using R&S X.25 (26Ago17) (AAI)
08142.5: ---: Unid 0606 USB THALES (prob. TRC-1752), traffic using proprietary S4285 waveform 600bps/L, ARQ mode (12Sep17) (AAI)
08162.0: 035: Hungarian Army, HNG 1356 USB 188-141A handsahake 082 / opchat using HARRIS AVS scrambler (12Sep17) (AAI)
08190.0: CINUS: Guardia di Finanza patrol boat, I 0813 USB 188-141A call to MESSINA (26Ago17) (AAI)
08207.0: AB3: Maltese Navy vessel, MLT 0817 USB 188-141A handshake ABA / voice radio-check using callsigns 0A (for ABA) and O??? (for AB3) (14Sep17) (AAI)
08303.0: IDR: Italian Navy HQ S.Rosa Rome, I 0810 J3E/USB calling IHAN (prob. ship ANTEO) for radio-check, no reply (12Sep17) (AAI)
08582.0: PWZ33: Brazilian Navy, B 2005 (cf) Pactor-FEC 100Bd, navigational warnings, 2026Z s/off (30Ago17) (AAI)
09038.0: GRIFFIN: TF Griffin Camp Bondsteel, HRV 0810 USB USB 188-141A sounding (31Ago17) (AAI)
10368.0: ---: Australian MHFCS net, AUS 1025 ISB: FSK 600Bd/340Hz on LSB, FSK 50B/340Hz on USB (08Sep17) (AAI)
11028.0: CM1: Algerian Air Force, ALG 0812 USB 188-141A handshake COF/ 188-110A Serial, Harris Citadel encrypted tfc (09Sep17) (AAI)
11083.0: RDL: Russian Navy, RUS 0820 FSK/Morse "RDL RDL RDL 22222 0315 0519816 08 16408 6555O ..." (09Sep17) (AAI)
11160.0: ---: Unid 0657 (cf) R&S-ARQ 228.6Bd/170 (ALIS), calling address 210 (05Sep17) (AAI)8JKY
11262.0: JOTA: Spanish Air Force, E 0940 J3E/USB ATC working AME3506 leaving Spanish airspace  (09Sep17) (AAI)
11360.0: KORSAR: Ruassian AF, RUS 0857 J3E/USB radio check with other ground nodes: POLIS, PROSELOK, DAVLENIYE, KLARNETIST, POLOTNOJ, KASTY, MAGNETRON (09Sep17) (AAI)
11450.0: ---: Unid 1519 USB Chinese Navy 4+4 PSK-8 75Bd modem (25Ago17) (AAI)
11478.0: ---: Unid 0820 USB 3G-HF FLSU async call (09Sep17) (AAI)
12129.5: ---: Russian Gov/Intel/Mil?, RUS 0753 (cf) FSK 100Bd/2000, no traffic (05Sep17) (AAI)
12138.8: ---: Russian unid source, RUS 0900 USB MFSK-21/13 tones, 31.5/63 Bd, 125/250 Hz spaced (11Sep17) (AAI)
12151.0: ---: Russian Gov/Intel/Mil?, RUS 0826 USB CIS-3000 PSK-8 3000Bd followed by CIS MFSK-64 (32+32) (05Sep17) (AAI)
12164.0: K4MT: M42b Russian Diplo Network, RUS 0720 CW call "NT9P NT9P NT9P DE K4MT K4MT K" (08Sep17) (AAI)
12164.0: K4MT: M42b Russian Diplo Network, RUS 0736 (cf +1000Hz) FSK 50Bd/500 5FGs msg, followed by CW "QRU ? K" (08Sep17) (AAI)
12200.0: 4MTK: Unid 0834 CW call 9PNT "9PNT DE 4MTK" (05Sep17) (AAI)
12209.0: ---: Russian Gov/Intel/Mil?, RUS 0930 USB CIS-60 OFDM 60-tone 35.5 Bd HDR modem, female voice prob asking QSL (05Sep17) (AAI)
12221.0: ---: Unid (prob. Bulgarian Diplo Net) 0915 USB RFSM-8000 modem using data-masking, tfc with stn operating 5 KHz upper (05Sep17) (AAI)
12464.0: RFH71: Russian Navy LS Novocherkassk (142), RUS 0908 CW msg to RCV Black Sea HQ "RCV DE RFH71 2 9 3 1 5 5 1 2 0 1 2 9 3 K" (05Sep17) (AAI)
12464.0: RFH71: Russian Navy LS Novocherkassk (142), RUS 0721 CW, "RCV DE RFH61 QYT QSX 10984 K" (08Sep17) (AAI)
12464.0: RJI48: Russian Navy (prob. Naval Aviation Transport), RUS 0953 CW msg to RCV Black Sea HQ "RCV DE RJI48 RJI48 QSA2 QRV K" (05Sep17) (AAI)
12464.0: RMX62: Russian Navy, RUS 1003 CW msg to RCV Black Sea HQ "RCV DE RMX62 RMX62 QSA? K" (05Sep17) (AAI)
12949.0: ---: 0738 USB BPSK 19200Bd burst system, 24KHz bandwidth (12Sep17) (AAI)
13062.7: TR: Unid Spanish user 0855 USB voice-call to DP announcing a message is going to be sent (in Spanish language), STANAG-4285 600bps/L with KG-84 encryption (05Sep17) (AAI)
14411.0: RDL: Russian Navy, RUS 0847 (cf) FSK/Morse/250Hz, 5FGs msg: "RDL RDL RDL 36855 52267 36855 52267 36855 52267 K" ("36855 52267" rptd 3 times) // 14664.0 KHz (06Sep17) (AAI)
14440.0: IQNS: Russian Military, RUS 0859 CW msg to 8JKY "8JKY 8JKY 8JKY DE IQNS IQNS ZYW SYL ZNIL QYT9 K" (06Sep17) (AAI)
14462.0: ---: Unid 0812 USB 3-of-6 multitone 40Bd/400Hz modem, sending all symbols set. (06Sep17) (AAI) [2]
14540.0: RJF94: Russian Naval Aviation Transport, HQ Moscow RUS 0859 CW msg to RJF95 "RJF95 RJF95 DE RJF94 RJF94 QSA? K" (06Sep17) (AAI)
14556.0: RIW: Russian Navy HQ Moscow, RUS 0844 CW msg to RJP30 "RJP30 DE RIW QSA? QTC k" (06Sep17) (AAI)
15016.0: ANDREWS: USAF AFB, US 0949 J3E/USB test count "1 2 3 4 5 5 4 3 2 1" (06Sep17) (AAI)
15016.0: SIGONELLA: US NAS, 0952 J3E/USB test count "1 2 3 4 5 5 4 3 2 1" (06Sep17) (AAI)
15157.0: ---: Unid 1238 USB BPSK 4800Bd, unid burst traffic using 6KHz bandwidth (no WBHF) (25Ago17) (AAI)

11 September 2017

MFSK 21/13 tones 31.5/63 Bd (125 and 250 Hz spaced)


unid MFSK modem spotted on 12138.8 KHz/USB, according to the suppressed carrier during MFSK, and switching from 21-tones 31.5Bd (125Hz shift) to 13-tones 63Bd (250Hz shift).  Note also the espansion of the spectrum since the occupied bandwidth varies from 2600Hz (MFSK-21) to 3000 Hz (MFSK-13).

Fig. 1
Fig. 2
Apart from the two edge tones, the MFSK-13 uses the same ten odd tones of the MFSK-21 waveform:

Fig. 3
Transmissions may have different duration, maybe depending on the length of the messages to be sent: from few seconds up to 6 minutes (the longest I copied). Sometimes the transmissions use only the MFSK-21 waveform and two adiacent channels for the peers (maybe ISB?):

Fig. 4

The MFSK-21/13 signal was also copied on 9280.0 KHz (frequency of the carrier) and reported in radioscanner here. They ascribe the transmissions to not well identified "domestic" (Russian?) telecomm operators.



 

8 September 2017

K4MT/NT9P Net, Russian Intel/Diplo (M42b)


K4MT/NT9P network, also known as Enigma designator M42b, is a quite common Russian Intel/Diplo network which uses both CW-Morse and FSK 50Bd/500: I spotted several trasnmissions this morning on 12164.0 Khz, just before a G3 (strong) geomagnetic storm passing: FSK is transmitted with its cf at +1000Hz.

Fig. 1
In this recording, FSK follows a CW call "NT9P NT9P NT9P DE K4MT K4MT K" and in turn it's followed by a "CFM QRU K" request: most likely the CW is used for setup or operators chat. The FSK is a Baudot 5FG coded stream using a preamble and 7-bit period (fig. 2):

Fig. 2
note the markers at every group of 50 x 5FGs (Fig. 3):
Fig. 3


7 September 2017

unid burst waveform, BPSK 4800Bd / 6KHz Bandwidth


Bursts copied on USB 16975.0 and 17157.0 KHz, in the 16-17 MHz Marine band segment. The waveform uses BPSK modulation at 4800 Baud and a bandwidth of 6 Khz, the copied bursts have a duration of ~386 and ~505 msecs.
Speed and bandwidth lead to think to MIL 188-110C App.C "WBHF" but this standard povides BPSK/4800Bd waveform only for 9 KHz bandwidth.

Fig. 1

Fig. 2

Fig. 3


1 September 2017

PWZ-33 Bazilian Navy and Pactor-FEC frame lengths


Some days ago my friend KarapuZ pointed my attention on a FSK transmission running on 8582.0 KHz/USB and that, at a first glance, appeared a bit uncommon. Once analyzed and decoded it was identified as PWZ-33 ERMRJ (Estação Rádio da Marinha no Rio de Janeiro) belonging to Brazilian Navy and operating in Pactor-FEC at 100Bd/200: just another proof of the "Occam's razor" (simpler theories are preferable to more complex ones).
Given the time we spent on signal analysis and the differences between Pactor-FEC modes, maybe is worth to publish a short post about it.

Pactor-FEC is a synchronous simplex system based on Pactor and used for broadcast transmissions, ie it has no acknowledge return channel and the receiving stations perform error correction. The Pactor-FEC modem uses a FSK 200Hz shift waveform and operates adaptively so the baud rate can be either 100 or 200 Baud: during daylight time the speed of 200 Baud may be successfully used, while in night time, due to the propagation distortions,  the speed may necessitate a reduction to 100 Baud. 
The speed influences the period lenght of Pactor-FEC and due to the positive/negative coding, the BEE software is a bit confused and computes periods lengths as the double of the real ones and shows seemingly equal period lengths in both the cases (Figure 1):

200Bd speed: frame length 194 bits (period: 388 = 194+194)
100Bd speed: frame length 97 bits (period: 194 = 97+97) 

Fig. 1
Indeed, altough Pactor-FEC frames consist of the same fields (header, data, status and 16 bit CRC calculated over the entire frame  except the header) their lengths differ.   As per above: at speed of 100 Baud the data field is 64 bits (8 bytes), while at 200 Baud the data field increases to 160 bits (20 bytes) as shown in Figs. 2,3. 

Fig. 2 - Pactor-FEC 100Bd/200 frames
Fig. 3 - Pactor-FEC 200Bd/200 frames
To increase reliability data are transmitted twice (in positive/negative), as shown by a decoding of a short fragment in Fig. 4

Fig. 4

In contrast to Pactor, all data blocks are in consecutive order with no or little space between them: indeed, Pactor 200Bd has 250-bit length frames (Fig. 5).

Fig. 5 - Pactor 200Bd Vs Pactor-FEC 200Bd
You may find many other informations about Pactor-FEC as well as about PWZ-33 (I'd like to ask QSL: I know they confirm reception reports): this is just a little contribution to shed a bit light on Pactor-FEC.

28 August 2017

a weird 3G-2G scenario or a likewise weird coincidence?

For interoperation with legacy systems, STANAG-4538 stations must be capable of accepting and establishing logical links using the second generation Automatic Link Establishment (2G-ALE) protocol specified in MIL-STD-188-141B Appendix A (188-141A). Indeed, STANAG-4538 #4.6.5 "Dual Demodulation" allows this scenario while stations are in the "scanning" state (Fig. 1)
Fig. 1
Looking at the waterfall in Figure 2, it seems that a calling station transmits its FLSU_Request PDU and then, after about 2.6 seconds, it sends a 188-141 2G-ALE call on that same channel.

Fig. 2
Assuming that the heard station can operates in 2G/3G way, and assuming that the FLSU_Confirm response was not sent or not received, this is a violation of S4538. Indeed, since the caller PU did not receive the FLSU_Confirm response, it must send up to N “xDL_Terminate” PDU’s (to abort the ARQ protocol) followed by the FLSU_Terminate PDU. If this were a Circuit Traffic scenario, the “xDL_Terminate” PDU’s would not be necessary, and the caller could send the FLSU_Terminate PDU immediately after the failed call response.

As shown in Figure 2, there is a FLSU_Request PDU only! So:

- or this is a weird way to operate (no Terminate PDUs before the 2G call) for a S4538/S5066 switch

Fig. 3

- or it's a likewise weird coincidence, ie two different stations (and different networks too?) putting their calls in the same channel. 
Anyway, no reply was heard.

Fig.4
BTW, the 2G-ALE Addresses in the play were: XPU (the caller station) and 1VR (the called station).

It's useful to note that you can forward S5066 data link protocols into a 2G-ALE or a 3G-ALE established logical link, BUT you can't do the same when using S4538 xDL data link protocols: in this case the logical link shall be establieshed using 3G ALE (LSU,FLSU).


https://yadi.sk/d/yJRmcMJa3MPpJ7 

25 August 2017

Logs

06233.0: ---: Unid 0622 USB 3G-HF 2-way FLSU handshake / LDL128 tranfser, Harris "citadel" encrypted 811 bytes file (03Ago17) (AAI) (AAI)
06247.4: HWK01: Swedish Armed Forces, S 0632 USB 3G-HF 1-way FLSU / MIL 188-110A Serial, S-5066 Circuit Mode service, unid RCOP client sending data to VJL (01Ago17) (AAI)
06721.0: ADW: Andrews AFB, US 0506 USB MIL 188-141A sounding (28Jul17) (AAI)
06888.5: ---: Unid 2150 USB (cf +1500Hz) R&S ALS 228.6Bd/170, continuous selcall to 210 (16Ago17) (AAI)
06957.0: ---: Unid German Red Cross stn, D 2223 ISB (cf +/- 1700Hz) PacTor-I, selcall DEK25 (14Ago17) (AAI)
06957.0: 049118: German Red Cross, D 2153 LSB USB MIL 188-141A sounding (14Ago17) (AAI)
07450.0: ABC7: Croatian Military, HRV 0745 USB MIL 188-141A call ABH3 (24Ago17) (AAI)
07467.0: PO1: Slovakian Military, SVK 0720 USB MIL 188-141A call SL2 (04Ago17) (AAI)
07509.0: ---: Unid 0711 USB 3G-HF 2-way FLSU / MIL 188-110A Serial, Circuit Mode service (25Ago17) (AAI)
07520.0: ---: Unid 0610 USB 3G-HF FLSU async call, no reply (25Ago17) (AAI)
07545.5: ---: Unid 0815 (cf) Unid encrypted FSK 75Bd/850, // 8204.5 (26Jul17) (AAI)
07594.5: IEA23: Carabinieri Milano,I 0632 LSB radiocheck with IEA20 (25Ago17) (AAI)
07606.0: WK1: US DoS unid station 0527 USB MIL 188-141A call WK2 (18Ago17) (AAI)
07641.0: NX40: Algerian Military, ALG 0654 USB MIL 188-141A call XS74 (03Ago17) (AAI)
07647.0: ---: Russian Intel/Diplo, RUS 0735 USB MFSK-64 (32+32) 45Bd modem (24Ago17) (AAI)
07650.0: ---: Unid 0710 USB 3G-HF 2-way FLSU handshake / HDL+ transfer (04Ago17) (AAI)
07665.0: ---: Unid 0620 USB 3G-HF FLSU request / MDL LDL128 transfer, sending 515 bytes 'Citadel' encrypted file (05Ago17) (AAI)
07713.0: ---: Unid 0738 USB STANAG-4197 ANDVT (24Ago17) (AAI)
07720.0: ASB01D: French Naval Network, F 1013 USB MIL 188-141A call LMP03D, CMD AMD "TEST AMD ASTROLABE" (26Jul17) (AAI)
07830.0: TZ0: Algerian Military, ALG  0755 USB MIL 188-141A call AT01 (24Ago17) (AAI)
07840.0: ---: Unid 0752 USB 3G-HF FLSU call followed by 188-141A XPU call to 1VR, just a perfect coincidence or a mixed 3G/2G ALE system? (24Ago17) (AAI)
07860.0: 123: Algerian Military, ALG 2250 USB MIL 188-141A call AT20 (14Ago17) (AAI)
07860.0: PC20: Algerian Military, ALG 2254 USB MIL 188-141A call NX20 (14Ago17) (AAI)
07860.0: XEN: Unid UK-DHFCS node, UK 0726 USB MIL 188-141A call XSS (05Ago17) (AAI)
07868.0: 2014: Turkish Red Crescent, TUR 1556 USB MIL 188-141A call 40113 [CMD AMD][//A05 4011] (04Ago17) (AAI)
07868.0: 2020: Turkish Red Crescent, TUR 0551 USB MIL 188-141A sounding (12Ago17) (AAI)
07890.0: PE11: Unid 0536 USB MIL 188-141A call to NX10 (18Ago17) (AAI)
07890.0: RS003: Unid CS/RS-Net 0708 USB USB MIL 188-141A handshake RS004 / MIL 188-110A Serial, sending Harris "Citadel" encrypted file using FED-1052 DLP (27Jul17) (AAI)
07898.5: ---: Unid 0709 USB (cf +1500Hz) R&S-ARQ 228.6Bd/170 (ALIS), calling address 478 (14Ago17) (AAI)
07930.0: ---: Unid 0429 USB 3G-HF 2-way FLSU handshake / HDL12 tranfser (28Jul17) (AAI)
08083.5: ---: Unid 0710 USB (cf +1500Hz) R&S-ARQ 228.6Bd/170 (ALIS), calling address 69 (14Ago17) (AAI)
08086.5: ICI: Italian Coast Guard MRCC Roma, I 1037 J3E/USB radio check w/ IGNS patrol vessel CP 277 (04Ago17) (AAI)
08092.0: 83401: Turkish Emergency Net, TUR 1428 USB MIL 188-141A sounding (13Ago17) (AAI)
08132.0: BP21: Bundespolizei Küstenwache Patrol Vessel 'Bredstedt', D 1503 USB MIL 188-141A calling BPLEZS (05Aug17) (AAI)
08132.0: BP24: Bundespolizei Küstenwache Patrol Vessel 'Bad Bramstedt', D 1530 USB MIL 188-141A calling BPLEZS (05Aug17) (AAI)
08132.0: BP25: Bundespolizei Küstenwache Patrol Vessel 'Bayreuth', D 1506 USB MIL 188-141A calling BPLEZS (05Aug17) (AAI)
08132.0: BP26: Bundespolizei Küstenwache Patrol Vessel 'Eschwege', D 1543 USB MIL 188-141A calling BPLEZS (05Aug17) (AAI)
08151.0: TYMT2: Spanish Police Toledo, E 0514 USB USB MIL 188-141A sounding (12Ago17) (AAI)
08182.0: XJM: DHFCS (unid) station, UK 0733 USB MIL 188-141A call XSS (24Ago17) (AAI)
08184.0: PEGASO: EVA (Escuadrón Vigilancia Aérea) Spanish AF Torrejón de Ardoz, S 0910 J3E/USB, voice-comms with TIGRE then data using 188-110A Serial modem (24Ago17) (AAI)
08196.5: ICI40: Italian Coast Guard Compamare Rimini, I 0703 J3E/USB calling ICI08 8^ MRSC Ravenna for radio check (03Ago17) (AAI)
08207.0: ABA: Maltese Navy, MLT 0617 USB MIL 188-141A call AB3 [CMD AMD][/>A2001  ] (01Ago17) (AAI)
08218.0: ---: Unid 0739 USB 3G-HF 2-way FLSU handshake / HDL12 transfer (14Ago17) (AAI)
08327.0: ---: Unid 0645 USB 3G-HF FLSU async call, no reply (25Ago17) (AAI)
10964.0: ---: Russian Navy, RUS 1610 (cf) CIS Navy "Akula", FSK 500Bd/1000 (04Ago17) (AAI)
11090.0: FIRST: Unid Russian net, RUS 1325 USB MFSK-17 126Bd/125Hz burst system (prob. a selcall waveform) / Russian male voice call "FIRST calling TWENTIETH" (27Jul17) (AAI)
11135.0: GANOB8: Unid (presumed Egyptian net) 0723 USB MIL 188-141A call HQ4, AMD "IFBUIFSHS" (21Ago17) (AAI)
11226.0: GUA: USAF AFB Guam, GUM 1538 USB MIL 188-141A sounding (02Ago17) (AAI)
11226.0: PLA: USAF Lajes Fields, AZR 1002 USB MIL 188-141A calling ICZ [HOWS MY DATA?], handshake / voice radio-check  "Sigonella this is Lajes for early voice check, how copy?" (28Jul17) (AAI)
11430.0: ---: Unid 0810 USB 3G-HF 2-way FLSU handshake / HDL12 transfer (21Ago17) (AAI)
11476.0: 2307: Unid 1514 USB MIL 188-141A call 2302 (04Ago17) (AAI)
11500.0: 2014: Turlish Red Crescent, TUR 1533 USB MIL 188-141A call 40113 [CMD AMD][//A05 4017] (04Ago17) (AAI)
11555.5: HBZ: Unid 0704 USB USB MIL 188-141A handshake HFC / MIL 188-110A Serial, sending Harris 'Citadel' encrypted file (28Jul17) (AAI)
14570.0: ---: Unid Ukrainian MIL station, UKR 0605 USB/VFT ITU-T R.38A, channels 1,2,3,4 in stdby - 5,6 active (21Ago17) (AAI)
14581.5: Russian Navy, RUS 1345 T600 50Bd/40 (04Ago17) (AAI)
14969.5: ---: Unid Prob Ukrainian Net 0535 (cf) FSK 100Bd/2000 T-207 encryption (21Ago17) (AAI)
15055.0: ---: Unid 0630 USB STANAG-4197 ANDVT (21Ago17) (AAI)
16986.0: ---: South African Navy, RSA 1421 USB MHF50 HF modem (04Ago17) (AAI)
7669.0: ZM53: Unid 0927 USB USB MIL 188-141A call NX50 (30Jul17) (AAI)
7685.0: ZM62: Unid 0925 USB USB MIL 188-141A call NX50 (30Jul17) (AAI)



24 August 2017

eavesdropping the wheels, a close look at TPMS signals

(ANgazu, Rapidbit, i56578)
My friend ANgazu encouraged me to have a more close look at the signals that populate the V/UHF world and possibly begin to analyze some of them. He invited me to collaborate in the study of TPMS (Tire Pressure Monitoring System) signals: an interesting "in-car" wireless network  designed to monitor the air pressure inside the pneumatic tires on various types of vehicles. Indeed, my collaboration was limited to do a "parallel" study, confirming and commenting the results obtained by ANgazu and his colleague Rapidbit (both from radiofrecuencias.es).


Briefly, "TPMS uses battery-powered pressure sensors inside each tire to measure and transmit tire pressure. Each sensor module communicates its data via a UHF transmitter, commonly the 315 MHz or 433 MHz bands are used. The receiving tire pressure control unit, in its turn, analyzes the data and sned results or commands to the central car computer to trigger warning messages on the vehicle dashboard. The tire pressure sensors will wake up in response to two triggering mechanisms: a speed higher than 40 km/h, detected by an on-board accelerometer, or an LF (125 KHz) RFID activation signal". 
You may find in the web a lot of tech and legal informations about these systems (just to mention United States and European Union which mandates TPMSs on all new vehicles), although, as far as we know, SIGINT-style approaches are quite few: so we decided in favour of this post.

Actually there is not an outright TPMS standard: communications protocols are proprietary, data transmissions commonly use the 315 MHz or 433 MHz bands, and ASK as well as  FSK modulation. Frame structures are different and depend on the manufacturers, mainly the data sent by a TPM sensor are: the sensor ID, temperature and pressure of the associated tire,  sensor status and a CRC field. There is no authentication between sensor and remote control unit, neither encryption of data.
In our case, the system uses the 433 MHz & FSK modulation and each sensor sends a 8-burst train every about 60 seconds, in Figure 1 the dead times between signalings have been deleted.

Fig. 1 - 8-burst trains
Each TPM sensors repeats 8 times the same message at not regular time intervals to avoid collision problems, although collisions and overlappings are frequent, as in Figure 2 (note how the sensors use two slightly different frequencies).

Fig. 2
The on-air FSK waveform have a shift of ~ 550 KHz and a speed of 20.150 KBaud (Fig. 3), once decoded it exhibits a 150-bit length frame consisting of a 10-bit length preamble followed by 140-bit data using Manchester encoding (Figs. 4,5).

Fig. 3 - FSK parameters
Fig. 4 - Auto Correlation Function
Fig. 5 - 150-bit period (4 bursts)
In Figures 6a/b, 1-out-of-8 bursts for every TPM sensor during 10 trains were decoded and ordered: the resulting bitstream are the 70 bits info that each wheel sends during about the firts ten minutes from start. In normal use, tx are every 60 seconds bat can be more frequent if  some parameter is not right or vary, eg at the start of car motion as in this case; more over, the car can ask for tx using LF (RFID).
There are some bitfields with exhibit regular repetitions of patterns (at every 4 bursts), static patterns and variable ones. Particularly, note that the second and third field reach almost constant values after 3-4 minutes: these are the temperature and pressure values (the capture begins when the car is stationary).

Fig. 6a - 70 bits info that each wheel sends in ~10 minutes
Fig. 6b - 1-0 view
Most likely, the structure is: 8-bit sync, 8-bit temperature, 8-bit pressure, 32-bit sensor ID, 5-bit flags (sensor status), 8-bit CRC, and 1-bit EOM. Perhaps  some bits are used as field sync, but there are no info about that. In this case, using the bit sequence "10" as field separator, we get: 6-bit sync, 6-bit temperature, 6-bit pressure, 32-bit sensor ID, 3-bit sensor status, 8-bit CRC, and 1 bit EOM (Figs. 7a/b).

Fig. 7a
Fig. 7-b

At least this protocol, and most likely all the others, does not use encryption or a form of authentication, and the car implementation does not perform basic input validation. Moreover, TPMS messages can be correctly received up to 10m from the car with a cheap antenna and up to 40m with a basic low noise amplifier, so the cited shortcomings  allow for remote spoofing of TPM sensor messages and may cause security and privacy vulnerabilities. 
Could it be used as feasible way to track cars? Think that each TPM sensor sends its 32-bit static identifier in every message and the length of the identifier field could render the IDs sufficiently unique to track cars, in these case using the 4-upla: 
01101011101001000010011011101101
01101010100101111010111110111101
01101010100101111010001110111101
01101010101001010000001100000101
On the other hand, just the choice of the "open-protocol" solution allows to use aftermarket products or multi-protocol sensors that come “pre-loaded” with many sensor protocols in a single sensor body; this way the TPM sensors are not so tightly linked to the car manufacturer and ultimately to the car. But, who knows how it will evolve?
 
At present we decided to not mention car and sensors manufacturers, anyway - for study purposes only - you could send your recordings along with the manufacturers of the "copied" TPM sensors so to build up a sort comparison table. Why not?

We know there are some pieces of software which are able to decode and identify TPMS such as:
https://github.com/jboone/tpm differents 
https://github.com/merbanan/rtl_433 
but what we'd like to do  is a bit more "radio" approach rather than a purely software approach. As suggested by ANgazu, there are many 433 files here:
github.merbanan/rtl_433_tests
Files are .dat but after some analysis, format for SA is 8U and sample rate is 250000. There are about 4 TPMS models that can be a good reference for us. We think that join these two approaches will offer two different views of the same signals!




20 August 2017

Rohde & Schwarz ALIS (RS-ARQ): pool size and frame length

Like in other ALE systems, during an ALIS call [1] the caller station transmits a defined number of "calling" frames so that the called station could have enough time to scan the frequencies of the current pool and, in case of late entry, could ever receive at least three frames for synchronization and data acquisition (Fig. 1).
Fig. 1 - ALIS late entry support to facilitate data acquisition
Thus, the number of the transmitted frames during an ALIS call is not fixed but depends on the size of the current pool of frequencies: roughly it is = (3 x number of pool frequencies) + 1. Don't know what is the maximum of frequencies for each pool and the maximum of different pools which are allowed by the ALIS processor.
I had a look at some ALIS calls and surprisingly found different ACF results, eg (Fig. 2): 

~358.6 ms for a pool size = 6
~376.1 ms for a pool size = 8
~402.2 ms for a pool size = 9
~402.8 ms for a pool size = 10
~415.5 ms for a pool size = 11
(although there are some decoder indecisions about pool sizes 9 and 10).

Fig. 2 - pool sizes and ACFs
Since the system operates at constant speed (228.6 symbols/sec), the higher is ACF and the greater the number of symbols per frame and so also the length of the frames is not fixed but it depends on the the pool size.
This dependence is even more neat looking at the demodulated stream in Figure 3, in which you can highlight a fixed 61-bit data block, following a variable length block consisting of a single field (here termed as "FC").

Fig. 3 - pool sizes and frame lengths
82-bit period for a pool size = 6
86-bit period for a pool size = 8
95-bit period for a pool size = 11

It's easy to note that the extra-lenght (period length - 61) matches the number of the frames to be transmitted for each pool size, according to the relation:
number of frames ~ (3 x pool size) + 1

Figure 4 shows the "vertical" comparison of the 61-bit block for three different pool sizes (6,8,11) and a my rough reading of their bitfields structure; the decoder outputs in the right boxes help to identify values and differences.
It's easy to see that the first 15-bit field (0-14) is the address of the called station, while the 23-bit last field (38-60) is probably transmitted for sync/correlation since this field exhibits the same pattern in all the 3 frames; if so, the rightmost bit should be the first to be transmitted. The 23-bit middle field (15-38) is the "status" of the caller station (FSK, voice, data, ARQ, adaptive reaction, fixed operation on a single frequency, frequency hopping mode, message key for frequency hopping mode, ...).
It's worth noting that, despite other ALE waveforms, the caller address is never transmitted.
(Note that the 3 bitfields structure "15 + 23 + 23" is only a my reading, since, for example, it could also be described as "15 + 24 + 22" or using a different number of bitfields!) 

Fig. 4 - 61-bit block structure
As you see, no field contains informations for the pool size (the middle field can't store the pool size because the first two frames have diffrent pool sizes and same value for this field!).  

Given the above, the fact that the decoder prints out the size of the selected pool of frequencies (as in Fig. 1), means that this information is obtained from the "parsing" of the variable lenght block (FC block) of the frame. I just wrote "parsing" because in this block, rather than a numeric value, they adopted a "positional" rapresentation by using the lenght of the block and the position of the 1-value bit, which is right-shifted in each received frame (Fig. 5).

Fig. 5 - FC blocks
One could say that the FC block looks like a function table of a n-bit shift register, in which each received frame acts as a transition of the clock input. 
Besides enumerate and identifiy the received frames, and consequently the pool size, the implementation of the FC block could also be used as a timing logic for re-sync the receive modem. But that's just a my opinion.

Please note that I do not own professional analysis tool so the numbers could be a bit inaccurate or different, anyway I think the underlaying reasoning remains valid. Who knows? maybe someone from R&S will read and comment... 



[1] quoting Hoka Electronic: "Some people call RS-ARQ (Rohde & Schwarz simplex ARQ) as ALIS but strictly speaking, ALIS is only the automatic link processor and frequency management system. It is not responsible for generating the traffic. ALIS is therefore somewhat of a misnomer. The modems generating the traffic are the GM857 and GM2000. Our suggestion is to stick with RS-ARQ as the system name."