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

eavesdropping the wheels, a close look at TPMS signals

$
0
0
(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 comparison table. Why not?

Logs

$
0
0
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)



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

$
0
0
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).


https://yadi.sk/d/yJRmcMJa3MPpJ7 

3G link + S5066: example of Circuit Mode (HF2000, Swedish Army)

$
0
0
next > 

Nice example of how to send STANAG-5066 data on a 3G link, using the Circuit Mode service provided by the 3G-HF STANAG-4538 profile.
The link is established with the 2-way FLSU procedure: the FLSU_Request PDU (BW5) sent by the caller station specifies the traffic waveforms that will be used during circuit mode, in this case MIL 188-110 (also termed MS110), and it is followed by an FLSU_Confirm PDU by the called station (not heard at my side). Once circuit mode begins, any station can initiate transmissions using the specified traffic waveform. A CSMA/CA process is used to avoid collisions. After the transfer is completed, an FLSU_Term PDU is sent by the caller and the link is terminated (Fig. 1).

Fig. 1
The most interesting aspect is the use of STANAG-5066, which has been detected thanks to the lack of the encryption before the MS110 modem: indeed, STANAG-5066 allows to indentify the Authority/Country by the addresses coded into the Data PDU (D_PDU), unless dummy addresses are used:

Once removed the overhead bits added by MS110, the D_PDUs can be isolated by syncing the resulting bitstream with the sequence 0xEB90 (regardless of type, all the D_PDUs begin with the same sync sequence): the result is displayed in Figure 2.

Fig. 2
The Size-of-Address Field specifies the number of bytes in which the source and destination address are encoded, the address field may be from 1 to 7 bytes in length (as in this case), with the source and destination address of equal length.The first half is the destination address and the second half is the source address:

In this case:
source address: 006.046.000.028
destination address: 006.046.001.010
both belonging to the block 6.46.x.y allocated to Sweden (Table N-6 European National Addressing Schema):

Fig. 3
Almost surely it is the HF2000 System developed by the Italian "Marconi Selex" company:

The user data carried by D_PDUs are structured in a 8-bit code (Fig. 4):

Fig. 4
By the way, the transmission has been copied on 10590.5 KHz/USB and thanks to S5066 Addresses this is the firts time I identify a 3G-HF transmission.
(to be continued here)



PWZ-33 Bazilian Navy and Pactor-FEC frame lengths

$
0
0

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.

unid burst waveform, BPSK 4800Bd / 6KHz Bandwidth

$
0
0

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


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

$
0
0

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


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

$
0
0

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.



 

Logs

$
0
0

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)

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

$
0
0
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

TE-204 (Rockwell AN/USC-11) 75Bd in-band frequency and time diversity HF modem

$
0
0

TE-204 (AN/USC-11) is most commonly used by Allied Air Forces as an air-to-ground messaging system as well as in ground and naval applications. The transmission was heard on 11220.0 KHz/USB, HF-GCS frequency, at 2145 UTC.
The modem converts the incoming serial binary data stream into an FSK audio signal at baseband and appears on-air as MFSK-4 150Bd/440Hz (Figure 1) although the real transfer speed is 75 Baud (75 bit/s in synchronous mode, 75 baud using Baudot chars in the async mode): the reason is in the "in-band frequency and time diversity" mode used by this modem.

Fig. 1 Over-the-air parameters
Four data subcarriers are used at 935 Hz through 2255 Hz with tones spaced every 440 Hz: TE-204 transmits a "mark" on 935 Hz for 6.67 msec period followed by another 6.67 msec period at 1815 Hz. Similarly, a "space" is transmitted at 1375 Hz for 6.67 msec period followed by another 6.67 msec period at 2255 Hz (Fig. 2).

Fig. 2 in-band frequency and time diversity mode
This effectively provides an in-band frequency diversity function for each data bit while also transmitting the same data bit over two(!) separate 6.67 msec periods of time, thus achieving a in-band frequency and time diversity function while transmitting only one tone at time (so the speed is the half of the measured one). As for above, from the perspective of the data-transfer, the modem works as a FSK-2 75Bd/880Hz modem.
No special preamble or SOM/EOM codes are employed, decoding the signal as in the depicted mode will be possible to get the 64-bit KG-84 sync sequence.
By the way, the TE-204 modem is embedded in the  Rockwell Collins MDM2001 Multimode HF Modem.










(unid) GMSK/PSK-2 2380Bd hybdrid HF modem

$
0
0

Odd burst waveform spotted on 5398.2 KHz/USB at different times and SNRs, the better around 2200Z 23 September.
Unless some little variations, bursts have a duration of ~720 msec and are spaced by a 500 msec unmodulated 1800Hz tone. The analysis of a group of bursts after the phase detector exibiths different modulations in each burst but a constant manipulation rate of 2380 symbols/sec (Fig. 1). 

Fig. 1
A detailed analysis of the bursts reveals a mix of GMSK 2380Bd/1500 and PSK-2 modulations, as shown in the following Figures 2 and 3.

Fig. 2
Fig. 3
Single GMSK and PSK-2 segments can be isolated and demodulated but this does not shed light on the nature of the signal (Figs. 4,5)

Fig. 4
Fig. 5
My friend KarapuZ say that such stange mixmodes are usually used by Chinese developers and in the bit stream there may be a recurrent scrambling. Anyway, also according to some tweets exchanged with a HAM guy in France, the transmissions seem to come from East side in respect of my QRA (JN52). Maybe further recordings could help to identify the source.









Nokia M/90 (Panasonic CF-U1): FSK 301-151Bd 780Hz shift

$
0
0
I reported Nokia M/90 / Panasonic CF-U1 301-401Bd/780Hz in this post, this time I copied the 301-151Bd waveform on 10737.7 KHz (cf) around 1235 UTC. In this sample the initial 301Bd burst seems to be used with a different functionality (fig. 1).
Sanomalaite M/90 (SANLA) (Literally "Message device M/90") is a digital, portable and encrypted text-based communications device developed by Nokia and used by all branches of Finnish Defence Forces. From 2013 onward, these devices are being replaced with Panasonic CF-U1 Toughbook.
 
Fig. 1
Note that also in this case, the preamble is always modulated at 301Bd (fig. 2).
 
Fig. 2
For what concerns the characteristics of the demodulated stream, refer to the mentioned post.



https://yadi.sk/d/DhKXi9ga3NLzFg 





Chinese PSK-2 ...and errors in its baud rate measurement

$
0
0
Some days ago I had a talk (...email exchange) with my friend KarapuZ about the way to get correct measurements of the baud rate in noisy signals or in uncommon waveforms. I always relied on the tools provided by SA program as the "Auto define param" and mostly the amplitude detectors, but KarapuZ warned me that sometimes they may fail and notably the "Auto define param" tool fails in case of strictly filtered or weak signals.
As a test, KarapuZ sent me a sample (the "x-Bd" wav file in Figure 1) without specify its baudarate and asking me to measure it.

Fig. 1
I used the "Auto define" tool and the modified amplitude detector searching for the lower more bright line and got a baud rate of 1000 symbols/sec in both their outputs (Fig. 2).
 
Fig. 2
KarapuZ replied: "The speed line of manipulation is 1500 baud unchanged in the preamble! This is a Chinese PSK-2 modem". 
Indeed, in my measurement I simply took in consideration the lower line - as usual - and did not put attention to the discontinuity in the 1000 Hz (999.44) line between preamble and data segments (Figs. 3,4). Really a my hasty measurement (I already had this signal but I forgot).

Fig. 3
Fig. 4
KarapuZ also drawn my attention on the "raster" of the signal that clearly exhibits 15 bits within 10 msec, ie a speed of 1500 baud (Fig. 5)

Fig. 5
Apart from my error in the evaluation of the amplitude detector, why the SA "Auto define param" failed so clumsily?
Quoting KarapuZ "it can be assumed that in the transmitting equipment, filters are used at the output of the signal formation which in some circumstances may influence the determination of the speed of the manipulation of the SA program." So, in order to demonstrate the influence of the filtering in the Chinese PSK-2 signal, KarapuZ synthesized an absolute PSK-2 modulation at 1500 baud with the same 3-bit structure of the Chinese waveform and sent me that file (Fig. 6)

Fig. 6
Then I measured the manipulation speed of the syntesized signal just using the "Auto define param" and it works like a charm.

Fig. 7
 The influences of the filtering is thus well quantifiable (other than visible)

Fig. 8
Things are even more worse since the bitstream  has a relative form and a three-bit structure, visible in raster, which generates many harmonics in the power spectrum! This is China, they love such tricks :)

Fig. 9
Fig.10
Thanks to KarapuZ for the great lesson!

MS-110A & S-4539 adaptive HF modem

$
0
0

Interesting proprietary adaptive HF modem spotted on 6670.0 KHz/USB. The modem uses a set of modified waveforms from 188-110A and STANAG-4539 and switches from 300bps (MS-110A) up to M4800 modes (S-4539) with constant modulation rate of 2400 symbols/sec. Note the presence of the four initial tones in each transmission which are non provided in the mentioned standards.
The link between the caller/called nodes "CAMP" and "OUTPOST" is established and terminated using 2G-ALE MS-141A. Both these callsigns are unknown to me, since their literal meaning they could probably belong to a military-like organized staff, probably Swiss Army or Swiss Emergency, but so far there is no confirmation about.

Fig. 1 - a MS-110A transmission
Fig. 2 - a S-4539 (MS-110B) transmission
Me and KarapuZ investigated the bitstream after the removal of the overheads due to the bearer HF waveforms and found a 128-bit period protocol which exhibits the constant 40-bit sequence 
1111111110111111111111101111011111110110
in the preamble of each transmission (no matter if MS110-A or S-4539).

Fig. 3
After synched the stream on that (supposed) sync sequence, we found  four times repeated 88-bit structures that look like a 88-bit key encoder: probably the (4-times repeated) 80-bit sequences act in the same way of the initialization vectors in KG-84 encrypted data blocks.

Fig. 4






Logs

$
0
0

04215.5  IDR: Italian Navy S. Rosa Rome, I 1555 (cf) FSK 75Bd/850 CARBs "IDR04I(0)/IDR23 /IDR22 /IDR03I(0)/IDR02I(0)/IDR21/" (24Sep17) (AAI)
05398.2: ---: Unid 2000 USB GMSK/PSK-2 2380Bd hybrid modem using burst waveform (23Sep17) (AAI)
06208.5: YSG: Unid 0618 USB 188-141A call ISB, AMD "QTCP" (29Sep17) (AAI)
06248.0: ---: Unid 0555 USB PSK-2 4800Bd modem, 6 KHz bandwidth burst waveform (29Sep17) (AAI)
06303.0: ---: USB 2004 USB 3G-HF 2-way FLSU handshake / LDL32, sending 139-byte Harris "Citadel" encrypted file (22Sep17) (AAI)
06329.0: OSY: Sailmail Brugge, BEL 0641 USB Pactor-IV 1800Bd traffic (20Sep17) (AAI)
06335.0: 8DV9: Bolivarian National Armada of Venezuela (Navy) Vessel "Los Llanos", VEN 0535 LSB 188-141A handshake 2KZ9 / 188-110A Serial (29Sep17) (AAI)
06336.0: ---: Unid 0849 USB 188-110A App.B OFDM 39-tone tfc, link terminated by HARRIS Autolink I (18Sep17) (AAI)
06348.0: FUE: French Navy Brest, F 0745 USB STANAG-4585 600bps/L "DE FUE FUJB BONNE JOURNEE" (02Oct17) (AAI)
06510.0: Z1V: Slovakian Air Force Zvolen, SVK 0723 USB 188-141A handshake S1L Sliak / 188-110A Serial, sending encrypted email using STANAG-5066 and Harris BFTP protocol (29Sep17) (AAI)
06516.0: MedNet: Mediterranean Cruiser Net 0611 J3E/USB English lang. male working cruising vessels (27Sep17) (AAI)
06670.0: CAMP: Unid 1507 USB USB 188-141A handshake OUTPOST / proprietary HF modem using modified 188-110A Serial & STANAG-4539 waveforms, 128-bit secondary protocol, prob. 88-bit key encoded (02Oct17) (AAI)
06715.0: ---: Unid 0709 USB 3G-HF 2-way FLSU handshake / LDL448 transfer, sending 1291-byte encrypted file (20Sep17) (AAI)
06728.0: 810001: Unid 0725 USB 188-141A sounding (04Oct17) (AAI)
06801.0: D20: NPRD Net Dubrovnik, HRV 0824 USB 188-141A sounding (03Oct17) (AAI)
06803.0: OG00: Austrian Military, AUT 0700 USB 188-141A handshake PO00 / 188-110 App.B OFDM 39-tones, LPC10 ANDVT (04Oct17) (AAI)
06831.0: P34: NPRD Net, HRV 0701 USB 188-141A sounding (20Sep17) (AAI)
06836.5: B22: (Netherlands Military?) 0723 USB 188-141A rptd 2-way handshakes with B21, no follow-up (03Oct17) (AAI)
06846.0: SVK: Unid 0758 USB 188-141A call DHJ (04Oct17) (AAI)
06964.0: ---: Unid 0734 ISB LINK-11 CLEW traffic (02Oct17) (AAI)
07509.0: ---: Unid 0746 USB 3G-HF MDL transfer using LDL512, sending 29KB 'Citadel' encrypted file (27Sep17) (AAI)
07656.2: XLA: French MoD, F 1355 USB 188-141A handshake XLB / THALES HFXL modem tests (handshake on the upper channel) (03Oct17) (AAI)
07685.0: NX50: Unid 2052 USB USB 188-141A call ZM64 (02Oct17) (AAI)
07685.0: NX50: Unid 2053 USB USB 188-141A call ZM60 (02Oct17) (AAI)
07685.0: ZM41: Unid 2056 USB USB 188-141A call NX50 (02Oct17) (AAI)
07739.0: 3127: Sonatrach, ALG 0741 USB 188-141A sounding (20Sep17) (AAI)
07775.0: DU6: Polish Military, POL 0636 USB 188-141A call OS5 (23Sep17) (AAI)
07775.0: DU6: Polish Military, POL 0732 USB 188-141A call FO7 (16Sep17) (AAI)
07813.0: X44: Moroccan Army, MRC 0632 USB 188-141A sounding (23Sep17) (AAI)
07830.0: ZD02: Algerian Military, ALG 0826 USB 188-141A call AT01 (27Sep17) (AAI)
07838.0: A98: Chinese net, CHN 2100 USB USB 188-141A call D78 (02Oct17) (AAI)
07885.0: SHARK25: Unid presumed Egyptian Net, EGY 0638 USB 188-141A call HQ2 (18Sep17) (AAI)
07924.0: HOWBATNET035: Unid 0829 USB 188-141A call MDBNGCMNET035 (03Oct17) (AAI)
07942.2: BYN21: Swedish Armed Forces, S 2027 USB 3G-HF 1-way FLSU / MIL 188-110A Serial, Circuit Mode tfc to NZH21 using STANAG-5066 unid UDOP client (22Sep17) (AAI)
07964.0: ZM65: Unid 1955 USB USB 188-141A call NX50 (02Oct17) (AAI)
08000.5: HBLZDRD1: Roumenian Military, ROU 0706 USB 188-141A call HFJCDRD1 (15Sep17) (AAI)
08040.0: TWLC1: Guardia Civil Santander, E 1959 USB 188-141A call TXFA5 (02Oct17) (AAI)
08054.0: FN05: Algerian Military, ALG 1337 USB 188-141A call to FN03 (21Sep17) (AAI)
08054.0: FN05: Algerian Military, ALG 1339 USB 188-141A handshake FN01 / 188-110A Serial (21Sep17) (AAI)
08054.0: IU02: Algerian Military, ALG 0835 USB USB 188-141A handshake IU01 / 188-110A Serial, sending data prob. using FED-1052-D (27Sep17) (AAI)
08060.0: ---: Unid 0610 USB 3G-HF LDL512 transfer, sending 14KB 'Citadel' encrypted file (29Sep17) (AAI)
08182.0: XDV: DHFCS station, UK 2019 USB 188-141A 2-way handshake XSS, no data transfer (22Sep17) (AAI)
08389.0: ---: Unid 1145 (cf + 1500Hz) Sitor-A "TEST" (27Sep17) (AAI)
10311.0: ---: Unid 1442 USB 3G-HF FLSU handshake / HDL+ transfer (21Sep17) (AAI)
10356.0: ---: Unid 1734 USB 3G-HF FLSU asynchronous call, no reply (21Sep17) (AAI)
10387.0: ---: RUssian Diplo/Mil, RUS 1515 USB CIS.45 33.33Bd selCall-WakeUp / CIS-60 35.5 Bd -> CIS-45 40Bd, same physical modem  (21Sep17) (AAI)
10425.0: ---: Unid 0743 USB 2-way FLSU handshake / Circuit Mode service using 188-110A serial (20Sep17) (AAI)
10425.0: ---: Unid 1000 USB 3G-HF FLSU asynchronous call, no reply (20Sep17) (AAI)
10425.0: ---: Unid 1740 USB 3G-HF FLSU handshake / LDL512, 27KB file transfer (21Sep17) (AAI)
10425.0: JAI: Unid 0911 USB 188-141A call OJ6 (20Sep17) (AAI)
10425.0: XPU: UK DHFCS? 0749 USB 188-141A call SRX (20Sep17) (AAI)
10429.0: 2157: Unid 1358 USB 188-141A call to 2159 (21Sep17) (AAI)
10447.0: R03: Roumenian MAECT Bucharest #3, ROU Unid 0814 USB 188-141A handshake MOG Athens Embassy / 188-110A Serial, sending email using STANAG-5066 with fictious Addresses (20Sep17) (AAI)
10482.0: CENTR2: Roumenian MAECT Bucharest #2, ROU 0832 USB 188-141A handshake YPM31 / 188-110A Serial, sending encrypted email using STANAG-5066 and Harris BFTP protocol (25Sep17) (AAI)
10580.0: ---: Unid 0942 USB 3G-HF FLSU asynchronous call, no reply (20Sep17) (AAI)
10719.0: ---: Russian Intel/Mil, RUS 1130 USB CIS-45 HDR modem v1, OFDM 45-tone 33.33Bd PSK-2, two bursts series (26Sep17) (AAI)
10737.7: ---: prob. Finnish Defence Forces 1238 (cf) Panasonic CF-U1 (Nokia M/90), Adaptive MSG-Terminal FSK 301Bd/151Bd 780Hz shift (29Sep17) (AAI)
10785.0: SAO: Unid Spanish Net 0944 USB 188-141A calling all stations (@@?) (20Sep17) (AAI) [1]
10785.0: SAO: Unid Spanish Net 1002 USB 188-141A calling any station (@?@), informing "in position" [FRM][SAO][CMD AMD][EN POSICION ] (20Sep17) (AAI) [1]
10785.0: SARRIOCERLER: Unid Spanish Net 0925 USB 188-141A call AMARILOCERLER, no reply (several calls) (20Sep17) (AAI) [1]
10796.0: RAA: M32a Russian Navy HQ St. Petersburg, RUS 0837 CW simplex w/ RCRE "RCRE DE RAA", "RAA DE RCRE K", "RAA QRR3 QDW 10540 K", "RCRE OK QRR3 QDW 10540 k", "RAA K" (20Sep17) (AAI)
10950.0: TYLEC79CAL65: Polish Military, POL 0805 USB 188-141A call HR6 (19Sep17) (AAI)
11059.0: TU4: Polish Military, POL 0757 USB 188-141A call SZ1 (28Sep17) (AAI)
11217.0: UKE304: RAF E3D AWACS 1205 USB 188-141A handshake XSS / METARs request & reply (27Sep17) (AAI)
11220.0: ---: Unid 2145 USB TE-204/USC-11 MFSK-4 HF modem 75Bd, in-band frequency and time diversity mode (21Sep17) (AAI)
11403.0: PEGASO: EVA (Escuadrón Vigilancia Aérea) Spanish AF Torrejón de Ardoz, S 0802 J3E/USB, warns the network to switch to the secondary feq. (25Sep17) (AAI)
11544.0: ---: Russian Intel/Mil, RUS 0803 USB CIS-3000 PSK-8 3000Bd followed by CIS MFSK-64 (32+32) (28Sep17) (AAI)
12193.0: ---: Russian Mil/Gov, RUS 1348 USB CIS-112 OFDM 112-tone 22.22Bd BPSK modem (14Sep17) (AAI)
12380.0: ---: Unid 1346 USB 3G-HF 2-way FLSU handshake / HDL6 transfer (25Sep17) (AAI)
12681.0: ---: Turkish Military, TUR 1200 USB FSK 200Bd/800Hz with KG-84C encryption followed by voice-comms, then short 188-110A Serial 75bps (19Sep17) (AAI)
13146.0: ---: Russian Navy, RUS 1411 (cf) CIS Navy "Akula", FSK 500Bd/1000 (29Sep17) (AAI)
13391.0: ---: Russian Intel/Mil, RUS 0700 USB CIS FTM-4, MFSK-4 150Bd (effective 37.5:Bd) 4000Hz modem (tones at: -6, -2, +2, +6 KHz) 8 mins lasting (26Sep17) (AAI)
14570.0: ---: Unid, prob. Ukrainian Net, 0654 USB 6 x 100Bd/120Hz VFT, 1 out of 6 (27Sep17) (AAI)
16619.5: ---: Unid 1303 USB 4800Bd BPSK modem, 6 KHz bandwidth burst waveform, 120ms ACF (21Sep17) (AAI)
17453.1: N57: Chinese Military, 1400 USB 188-141A calling A99 (25Sep17) (AAI)

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

$
0
0
[read all the posts about this topic]

data block
Adding the data blocks to form a single file show a repeated 33-byte length pattern which precedes the "magic string", probably  a  common heading to all the messages (Fig. 1). As well as for the "magic string", it's difficult to say the scope of these sequences: indeed, further analysis will focus on the data block trying to get some meaningful. Recordings, help and tips are welcome!

Fig. 1

Some interesting observations from the recent catches.

1. I had the chance to copy a transmission on 5206.3 KHz followed by an identical one on 5059.4 KHz after few seconds (Fig. 2). This is quite easy to accomplish since they use S-4538 FLSU for link setup, so the stations of the network are synched and scan the same pool of frequencies at same times. Repetitions increase the reliability of the system but do not know if it was just a planned episode or a routine scenario (more powerful monitoring tools would help...)

Fig.2

2. Usually transmissions are originated from nodes belonging to 006.046.000.zzz block (mostly HWK01) and directed to nodes of the 006.046.001.zzz block. This time I copied a trasmission inside the 006.046.001.zzz block (never copied so far), namely from BYN21 (006.046.001.006) to NZH21 (006.046.001.052).
As above: episode or a normal way to operate?

Fig.3

3. Luckily I copied some transmissions probably just few minutes after the start of a new epoch time of the timestamp clock and thus with a timestamp exhibiting a length of 7, 8 and then 9 bytes (Fig. 4). This is a full automated system working in a FIFO logic, ie the messages are wrapped and forwarded in the same order they arrive  (first came first served).  As well as for the IDs, the wrapper does not use a fixed length for the timestamp: it simply catches the value, computes its length and arrange them in the form {<length>,<content>}. This clarifies why so far I found transmissions with 9 and 10 bytes lengths.
As already debated, the variable lengths of IDs and timestamp affect the length of the data block since it shall be computed to fit the max transmission unit of the protocol (2039 bytes). 


Fig.4


STANAG-5066 Addresses and "Magic Strings"
heard so far:


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

[006.046.001.zzz] block
FRJ    006.046.001.001 *
BYN21  006.046.001.006 *
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
NZH21  006.046.001.052 *
VJL    006.046.001.054

ZAPCA
ZAPCG
ZAPCK
ZAPCH *
ZNTCH *
ZRTBC
ZRTBD
ZXPBC
ZXPBD
ZXPBG
ZXPCK
ZXPDA *
ZXPDK *

* new ones


[read all the posts about this topic]
 

THALES mention

OFDM modem 12+12 tones 48Bd (Marconi 25-tones)

$
0
0

Probably a simplex transmission heard on 6246.5 KHz/USB. Although the SNR is poor, it's possible to see a central un-modulated tone a + 1500Hz  that splits the signal in two identical parts which I analyzed separately. The results show an OFDM modulation of 12 + 12 tones at a rate of 48 symbols/sec; the on-air constellation seems to be QPSK on each channel.

Fig. 1
Fig. 2
Fig. 3
 The initial part exhibits an upper un-modulated tone and a short FSK

Fig. 4

 Modem name and users are unknown to me.

Update:
thanks to hf_linkz who pointed me to the correct identification of this modem: it's the "Marconi 25-tones" as depicted here:
http://signals.radioscanner.ru/base/signal125/ 
https://www.sigidwiki.com/wiki/Marconi_Selenia_25-Tone_Modem  





ISB ARQ system heard in the 6 MHz maritime band

$
0
0

Robust ISB ARQ system heard on 6231.5 KHz/USB (Maritime Mobile band) 2800Hz offset from carrier, around 0630z on 12 October and in which the two side bands are used as follows:

- on USB: user data transfer using adaptive 2400 Baud PSK-2 and QPSK burst waveform, according to the channel conditions and the feasible data-rate. Initial bursts use PSK-2 modulation at 2400 Baud;
- on LSB: link and traffic management (ACKs and mode used for data transfer) using 1500 Baud PSK-2/QPSK waveform; 

is not clear if the change of the mode used for data transfer is signaled in the management channel by the caller or it is requested by the called station.

Fig. 1 - user data transfer waveform (USB channel)

Fig. 2 - link and traffic management waveform (LSB channel)
At least in this sample, data bursts last 2088 msec for PSK-2 and 3144 msec for QPSK, the initial bursts have a duration of 520msec; link and traffic management bursts last 310 msec. PSK-2 and QPSK data bursts exhibit strong ACF spikes every 523 msec which suggest a 1256 symbols frame structure (Fig. 3); initial data bursts have ACF = 0, probably Walsh modulation is used (Fig. 4).

Fig. 3
Fig. 4
Talking with KarapuZ about this system, he proposed to have a look at the KLN Networks website since they are testing a proprietary 3G HF hybrid system to support the ship traffic in Artic regions [1]. In that high latitudes satcomm links can't be easily used since geostationary satellites do not cover these areas, moreover due to the long dark periods the low portion of HF shall be used (lack of F layers). Perhaps may catches are related to their tests... but it's only my guess (I emailed them to ask a confirm and maybe shed some ligth on this system).





Viewing all 623 articles
Browse latest View live


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