UUCP protocol 'conversations' over HF using RSX.25 and GM2X00 waveforms

This post is intended to complete some previous analysis of the protocols used by the German BPOL for their HF ship-shore communications which are based on the R&S implementation of the X.25 protocol and the proprietary R&S GM-2100 waveform: the scenario is shown in Figure 1: UUCP protocol, who sits on top of RS X.25 , is discussed in this post thanks to a friend of mine who pointed my attention on the upper application layer and gave a big help and contribution in UUCP protocol analysis. 

Fig. 1

UUCP (Unix-to-Unix copy) [1] suite is a set of computer programs and protocols that allow for the remote execution of commands and the transfer of email and files between computers, in this scenario it is used over X.25 and HF-link. The UUCP bitstream (uucp-over-hf.bin)  is obtained after the removal of X.25 overhead and it's edited using the XVI32 hex editor [2]: a XVI32 screenshot is shown in Figure 2.

Fig.2 - XVI32 editor

A UUCP session (termed "conversation") consists of three parts: an initial handshake, a series of file transfer requests, and a final handshake. Before the initial handshake, the caller will usually have logged in the called machine and somehow started the UUCP there: since they use the UUF Index "00000000000111" during the 2G-ALE handshake, most likely UUCP is started at the "dial in" stage by means of the command User Unique Function in the 188-141A message section [3]:

(to)BPLEZS (cmd)|[nul][bel] (tis)BP23
1111100 0000000 0000111

 
The initial part concerns the "login", probably the tags  <MPL></MPL> and <SPL></SPL> are XML markers.

0A 0D 0A 6C 6F 67 69 6E 3A 20 55 42 50 4F 4C 42 50 4C 45 5A 53 45 45 5F 48 46 0A

. . . login: U BPOLBPLEZSEE_HF .

3C 4D 50 4C 3E 32 30 31 36 2D 31 31 2D 32 38 20 31 35 3A 34 39 3A 35 32 2B 30 31 2C 42 50 4F 4C 42 50 32 33 3B

<MPL> 2016-11-28 15:49:52+01,BPOLBP23;

32 30 31 36 2D 31 31 2D 42 50 4F 4C 42 50 4C 45 5A 53 45 45 5F 48 46 0A 0D 20 31 35 3A 34 39 3A

2016-11-BPOLBPLE ZSEE_HF .. 15:49:

35 32 2B 30 31 2C 42 50 4F 4C 42 50 32 33 3B

52+01,BPOLBP23;

32 30 31 36 2D 31 31 2D 32 38 20 31 35 3A 34 37 3A 34 35 2B 30 31 2C 42 50 4F 4C 42 50 32 36 3C 2F 4D 50 4C 3E 0A

2016-11-28 15:47: 45+01,BPOLBP26</MPL> .

42 50 4F 4C 42 50 4C 45 5A 53 45 45 5F 48 46 0A 0D

BPOLBPLEZSE E_HF ..

20 31 35 3A 34 39 3A 35 32 2B 30 31 2C 42 50 4F 4C 42 50 32 33 3B

15:49:52+01,BPOLBP23;

32 30 31 36 2D 31 31 2D 3C 53 50 4C 3E 32 30 31 36 2D 31 31 2D 32 38 20 31 35 3A 34 37 3A 34 35 2B 30 31 2C

2016-11-<SPL>2016-11-28 15:47:45+01,

42 50 4F 4C 42 50 32 36 3C 2F 53 50 4C 3E 0A

BPOLBP26</SPL> .

43 6F 6E 6E 65 63 74 65 64 0A

Connected .

All messages in the initial handshake begin with a `^P' (a byte with the octal value \020, hex  0x10) and end with a null byte (octal \000, hex 0x00) and it is begun by the called machine. The session can be parsed according to: 

http://www.math.utah.edu/docs/info/uucp_5.html#SEC45

10 53 68 65 72 65 3D 42 50 4F 4C 42 50 32 33 5F 48 46 00

10 – UUCP initial handshake message start

Shere = – called hostname = BPOLBP23_HF

00 – UUCP initial handshake message end

10 53 42 50 4F 4C 42 50 4C 45 5A 53 45 45 5F 48 46 20 2D 70 7A 20 2D 76 67 72 61 64 65 3D 7A 20 2D 52 20 2D 4E 30 37 00

10 – UUCP initial handshake message start

S – calling hostname = BPOLBPLEZSEE_HF

-pz - requests the called system to only transfer files of the specified grade or higher = z

-vgrade=z - requests the called system to only transfer files of the specified grade or higher = z (grades in UUCP links means 'priorities')

-R - calling UUCP understands how to restart failed file transmissions. Supported only by System V Release 4 UUCP, so this is a System V release.

- N07 - calling UUCP understands the Taylor UUCP size negotiation extension (only for UUPlus, so this is UUPlus)

07 = 000111 – options (in octal)

xxxxx1 – UUCP support size negotiation

xxxx1x – UUCP supports file restart

xxx1xx – UUCP supports ‘E’ command

00 – UUCP initial handshake message end

10 52 4F 4B 4E 30 37 00

10 – UUCP initial handshake message start

ROKN07 – called station acknowledgement of ‘R’ options. The calling UUCP is acceptable, it specified `-N', and the called UUCP also understands the Taylor UUCP size limiting extensions

00 – UUCP initial handshake message end

10 50 79 69 65 00

10 – UUCP initial handshake message start

50 – P = called station supports the following UUCP protocols y, i, e

00 – UUCP initial handshake message end

10 55 79 00

10 – UUCP initial handshake message start

55 – U = The calling UUCP selects which protocol to use out of the protocols offered by the called UUCP

in this case calling station supports the UUCP protocol 'y' (0x79)

00 – UUCP initial handshake message end

 UUCP ‘y’ protocol (uucico Zmodem protocol) starts here, first packet with pkt number = 0 is a ‘sync’ packet

 

00 00 04 00 10 00 01 04 00 00

00 00 – pkt number (little endian) = 0

04 00 – pkt length (little endian) = 4 Bytes

10 00 – check sum (little endian)

01 – version = 1

04 – max pkt size = 32768/4 = 8192 Bytes

00 00 – flags = none defined

/* trailing 0x00 missing */

01 00 03 00 B8 01 48 4E 00

01 00 - pkt number = 1

03 00 – pkt length = 3 Bytes

B8 01 - check sum

48 = ‘H’ hang up command/command response O

4E = ‘N’ = Slave does not agree to hang up

00 – end of pkt

 

02 00 3D 00 19 23 45 20 44 2E 30 35 50 4B 20 44 2E 42 50 4F 4C 42 50 32 43 30 35 50 4B 20 75 75 63 70 20 75 75 63 70 20

02 00 - pkt number = 2

3D 00 – pkt length = 61 Bytes

19 23 - check sum

45 – ‘E’ command

44 2E 30 35 50 4B 20 – file to send = D.05PK

44 2E 42 50 4F 4C 42 50 32 43 30 35 50 4B 20 – file name on slave = D.BPOLBP2C05PK

75 75 63 70 20 – user or application requesting the file transfer = uucp

2D 43 20 44 2E 30 35 50 4B 20 30 36 36 36 20 22 22 20 30 78 36 36 20 72 73 67 70 73 61 64 64 00

2D 43 20 – option: file has been copied to the spool directory = C

44 2E 30 35 50 4B 20 - if the `C' option appears in options, this names the file to be sent = D.05PK

30 36 36 36 20 - mode of file on master; if UUPlus always = 0666 for outgoing files

22 22 20 – notify = "" = notification not enabled

30 78 36 36 20 – file size = 0x66 = 102 Bytes

72 73 67 70 73 61 64 64 – command to be executed = rsgpsadd

(most likely a PostMan II application which sends GPS data to an ashore data base) 

00 - end of pkt 

 

02 00 83 21 66 5A 29 76 4C 40 AC 93 34 6D 98 DF D0 7B

/* is this noise or …? */

03 00 66 00 E3 13

03 00 – pkt number = 3

66 00 – pkt length = 0x0066 = 102 Bytes

E3 13 – check sum

/* BZIP’ed data follows */

42 5A 68 39 31 41 59 26 53 59 31 B5 92 5D 00 00

15 DE 00 00 10 40 0F 7F F0 10 04 C0 00 20 00 40

94 44 C9 B4 8D EA 21 A1 40 D3 43 23 26 24 08 8B

AE 1A 62 1D B0 EF 05 4D 67 25 41 08 B0 A8 3D 51

B2 9C 96 C3 74 66 4E AB 06 83 94 21 E4 D1 AB 4D

EF C3 44 66 9E 13 F8 E8 D9 A3 61 F8 BB 92 29 C2

84 81 8D AC 92 E8

04 00 00 00 FF FF

04 00 – pkt number = 4

00 00 – pkt length = 00 00 /* this indicates end of file */

FF FF – check sum /* because no data bytes are present, the checksum is set equal to its initial setting */

16 B0 F9 F5 37 DE DC 29 AE 6D 48 D4 1F 34 B5 D6 5E 00 FF A4

/* is this noise or …? */

05 00 02 00 8E 00 48 00

05 00 – pkt number

02 00 – pkt data length

8E 00 – checksum

48 – ‘H’ command from master to hang up connection

00 – end of command pkt

05 00 03 00 CE 01 48 59 00

05 00 – pkt number

03 00 – pkt data length

CE 01 – checksum

48 59 – ‘H’ command, ‘Y’ = agrees to hang up the connection

00 – end of pkt

06 00 03 00 CE 01 48 59 00

06 00 – pkt number

03 00 – pkt data length

CE 01 – checksum

48 59 – ‘H’ command, ‘Y’ = agrees to hang up the connection

00 – end of pkt

After the protocol has been shut down, the final handshake is performed. This handshake has no real purpose, and some UUCP packages simply drop the connection rather than do it (in fact, some will drop the connection immediately after both sides agree to hangup, without even closing down the protocol). 
In the final handshake, the calling UUCP sends six letter O's and the called UUCP replies with seven letter O's. Some UUCP packages always send six O's.

10 4F 4F 4F 4F 4F 4F 00

10 – UUCP final handshake message start

4F 4F 4F 4F 4F 4F – final handshake caller closing sequence = OOOOOO

00 – end of final handshake message

10 4F 4F 4F 4F 4F 4F 00

10 – UUCP final handshake message start

4F 4F 4F 4F 4F 4F – final handshake caller closing sequence = OOOOOO

00 – end of final handshake message

10 4F 4F 4F 4F 4F 4F 4F 00

10 – UUCP final handshake message start

4F 4F 4F 4F 4F 4F 4F – final handshake called closing sequence = OOOOOOO

00 – end of final handshake message

10 4F 4F 4F 4F 4F 4F 4F 00

10 – UUCP final handshake message start

4F 4F 4F 4F 4F 4F 4F – final handshake called closing sequence = OOOOOOO

00 – end of final handshake message

https://yadi.sk/d/0IgkbnUO3UnncJ

[1] http://www.math.utah.edu/docs/info/uucp_5.html

[2] http://www.chmaas.handshake.de/delphi/freeware/xvi32/xvi32.htm 
[3] http://hflink.com/standards/MIL_STD_188-141C.pdf (A.5.6.9 User unique functions)

FSK-2 300Bd/200, 17-bit ACF 6-bit code

FSK-2 300Bd/200 transfer occupying ~500Hz bandwidth, each cycle lasts 6000ms (4640ms data block, 1360ms idling) and shows 17-bit length ACF. Each data block consists of 738 bits (data + framing), data seem to be sent using a 6-bit code. Very strong in JN52.

Fig. 1

Fig. 2

In Fig. 3, although contents are different, it's possible to see repeated sequences in the packets, expecially the last 12 bits of each packet. Same packets also exhibit a same sequence in their initial part. Figure 4 shows the result of the comparison between the first packet on the left in Fig. 3 and the following 10 packets.

Fig. 3

Fig. 4 - comparison between the first packet on the left in Fig. 3 and the following 10 packets

 

The transmission lasted for a long time, I followed it about two hours on Thursday evening  (Apr, 19) from 2030z - when I tuned it - and I still found it there the following morning until 0900z when it stopped. A friend from Northern Portugal reported this signal in UDXF list (18 Apr): "It has been on all morning on 3575.65kHz (USB dial freq)".

The same signal is reported in a post of 2012 (27 Jun) in radioscanner, user and purposes of that transmission/protocol are not yet known or verified.

Nice work indeed by 'cryptomaster': use Diff-FSK, remove extra columns, remove odd parity-bit column and then get the 6 bit code. Great!
http://www.radioscanner.ru/forum/topic36750-184.html#msg1372694 

Fig. 5

 

https://yadi.sk/d/bbYrFyPr3UbYaJ 

FSK two channels in F7B mode, likely an UKR-Net

On 13960.0 KHz I tuned  an apparently MFSK-4 100Bd/1000 transmission spreading about 3000Hz bandwidth: tones at -1500, -500, +500, +1500. After emails exchange with friends, "cryptomaster" from radioscanner suggested that the signal is a F7B mode actively used by Ukrainian Nets. Usually, the two channels transfer T-207 ciphered data. He also warned me that SA program parses these transmissions as classic MFSK-4 therefore the received result doesn't correspond to the truth. Another F7B signal, this one from Ukrainian Mil, was reported here some times ago.

Fig. 1

Fig. 2

The F7B transmission mode deals with signals consisting of two independent, but synchronous channels carrying teletype signals. Modulation used is MFSK-4 (more precisely, FSK2 on 2 independent channels).

The equipment BUK-2D, for example, is one of the equipments used to filter and separate the two channels (thanks to 'cryptomaster').

Fig. 3 - BUK-2D equipment

https://yadi.sk/d/f2PpWmdi3UTaqG

WBHF comms in the 9 MHz band (188-110C/D Appendix D)

Just a couple of good quality recordings of the wideband activity that can be monitored in 9 MHz band. Both the waveforms belong to WBHF 188-110C/D App.D.

The 6 KHz burst is modulated at a symbol rate of 4800Bd and has a 192 symbols frame consisting of 96 data symbols (user data) followed by 96 known symbols (mini-probes): according to TABLE D-XI and TABLE D-XII, this the Waveform ID 1 or ID 2, (scrambled) BPSK modulation, depending on the used data rate (300 or 600 bps, as in TABLE D-II). Note that the BPSK constellations are scrambled to appear, on-air, as a PSK-8 constellation.

 

Fig. 1 - 6 KHz bandwidth bursts

Fig. 2

 
The 9 Khz burst has symbol-rate of 7200Bd and a period length of 2048 symbols. The period length helps to identify the waveform as the Waveform ID 0. Quoting D.5.1.4 "For the case of Waveform ID 0, an 8-PSK data scrambling sequence is utilized [...] this implementation is used to generate 256*8 or 2048 values. For the Walsh Orthogonal Modes the sequences are continuously wrapped around the 2048 symbol boundary". Since the 9 KHz bandwidth, the data rate is 300bps (TABLE D-II).

Fig. 3

Linking is performed using 3GWB extensions (3G ALE FLSU + WBALE). WBHF modes could also deliver video for awareness, such bandwidth allows information rather than data.

Fig. 4

https://yadi.sk/d/i-kCpOlj3UQRwG

https://yadi.sk/d/gkYepjZm3UQS4z

3GWB, 3G ALE extensions for wideband operations (Harris WB ALE)

I was investigating some wideband HF (WBHF) scenarios and spotted unexpected 3G-HF FLSU bursts in some recordings: it's a unexpected presence because for circuit mode connections WBHF is not comprised in the types of traffic that will be delivered on the link (the available types of traffic are listed in STANAG-4538 Table 4.6.1-2). Such transmissions can be observed by monitoring the band around 9.2 MHz.
Reading the Appendix-G to MIL 188-141D, I found an answer to my perplexities: most likely those intercepts are related to 3GWB: a set of "extensions" to 3G-HF linking for wideband. Indeed, quoting MIL 188-1414D §G.5.5.7, "It is possible to set up a narrowband link using 3G-HF FLSU and then to negotiate a wideband channel for traffic via a second handshake that uses 3GWB extensions to the FLSU protocol, the link shall be terminated with FLSU_term. The extensions for this 3GWB mode are not standardized here". Figure 1 provides a timing diagram of all the signalling required. 

 

Fig. 1 - 3G wideband point-to-point link setup example (timing not to scale)

Since Harris developed a similar system for wideband ALE termed "WB ALE" [1] [2], I am inclined to think that part of the heard WBHF transmissions are just examples of WB ALE/3GWB system tests. 

Figure 2 reports a such transmission recorded on 5365.0 KHz/USB. The link setup of standard 3G-HF is unaffected: link request and confirm control FLSU bursts remain unchanged. Harris say that the only modification to 3G linking is the addition of a new traffic type to support wideband data (as I supposed). After the link has been established, both radios simultaneously perform a spectrum sensing operation to determine the currently interference-free bandwidth at each end. Once spectrum sensing has determined the available bandwidth and offset, a second two-way handshake (WB handshake) is used to exchange the required information for the wideband transfer. Once the data transfer is complete, FLSU terminate bursts will tear down the link as is done in 3G-HF.

Fig. 2 - on-air 3G wideband point-to-point link

Fig. 3

By the way, the traffic waveform (Fig. 4) has a symbol rate of 14400Bd and uses the 18 KHz bandwidth.

Fig. 4

I do not have informations about the format of the PDUs (Protocol data Units) employed in the WBALE handshake (are they addressed?), unfortunately the quality of recordings doesn't allow accurate investigations as the ACF and the period framing. I can only state that WB ALE request and confirm bursts last about 530ms and are modulated at 2400 symbols/sec using PSK-8 modulation.  Quoting Harris [1]:

"The two-way WB handshake has been designed using burst waveforms very similar to BW5 of STANAG-4538 and allows the exchange of the following information:

- SNR values measured at each end
- Quantized representation of local interference environment
- Coordinated decision on available bandwidth (i.e. 3, 6, 9, 12, 15, 18, 21, 24 kHz)

- Coordinated decision on offset (i.e. frequency offset of available bandwidth in the up to 24 kHz allocation; offset value is quantized and is in the range of +/- 10500 Hz)
- Coordinated decision on initial data rates.

Bandwidth and offset decisions will be based on either a primary or secondary usage of channel. In primary user mode, bandwidth and offset decisions can be made independently for each direction of transmission. In secondary user mode, bandwidth and offset will be the same in both directions."

Given the latest "D" release of MIL 188-110 (December 2017), it would be interesting to know if Harris has upgraded  WB ALE to support up to 48 KHz bandwidth waveforms introduced by the Appendix D. 

Thanks to KarapuZ who sent me some of his rercordings.

[1] https://yadi.sk/i/ZZRMxf4Cqa832g

[2] https://yadi.sk/i/fZU6oT6KD4llTw

[3] https://www.researchgate.net/.../On-Air-Test-Results.pdf

The multiplicity of abbreviations and acronyms sometimes doesn't help, below what I used:

WBHF, Wideband HF waveforms (MIL 188-110C/D App.D)
3G-HF, third generation HF protocol suite for 3G ALE and data-link (STANAG-4538), FLSU is the 3G-HF Fast Link Setup protocol
3GWB, third generation ALE with wideband extensions
WB ALE (or WBALE), Harris implementation of 3GWB
WALE (or 4G ALE), wideband ALE as for MIL 188-141D App.G, fourth generation ALE

note that WB ALE is not synonymous with WALE since the latter has its own PDUs and waveforms.

188-110A 2400S (prob. Egypt-Ny)

slightly modified 188-110A bursts with some voice comms in Arabic, prob. from Egyptian Ny, spotted on 15950.0 KHz/USB 1320z.

It's interesting to note the well visible three 200ms synchronization pattern segmentes (MIL 188-110 §5.3.2.3.7.2 Sync preamble sequence), confirmed by the 200ms spikes in the preamble ACF. Data blocks ACF exhibits 20ms spikes that makes 48 tribit symbols at the speed of 2400Bd: each data block consisting of 32 symbols of unknown data (user data) and 16 symbols of known data (probes).

Fig. 1

Fig. 2 - ACF values for preamble and data blocks

Fig. 3 - frame structure

The short synch preamble (3x200ms) and the used framing (48 symbols, 32+16) point out the 2400bps/S mode, as confirmed by the 5710A modem. 

Fig. 4

https://yadi.sk/d/sO0S-6IN3UKvST

Asynchronous STANAG-4285 15/128 bit period (possibly Turkish T-15)

6234 Khz/USB STANAG-4285 600bpsL, very long idling periods (hours!) with sporadic asynchronous data transfers consisting of 15 bit and apparently nx32 bit (32,64,...,128) ACF blocks (Fig. 1). The 15-bit Block-A is clearly an async ITA2 5N1.5 stream (Fig. 2). By decoding the whole stream whit the HARRIS RF-5710A modem, also the Block-B seems to use ITA2 and 5N1.5 framing: indeed, the modem does not print bad framing errors. By the way, I do not think a framing change "on the fly" be possible. Looking at Block-B  (Fig. 3), it seems arranged as 4 groups of 4 chars (the fourth as separator), but it's only a my guess.
In both blocks the 5-bit text appears as (off-line?) encrypted.

For a better understanding of the figures keep in mind that bit editors work with an integer number of bits therefore they cannot represent an half bit.

Fig. 1 - data transfer consists of two blocks

Fig. 2 - 15-bit period Block-A

Fig. 3 - 32/128-bit period Block-B

The above images come from a 4285 demodulator output which returns the bits in air, the demodulated stream from 5710A modem (framing 5N1.5) is shown in Figure 4.

Fig. 4

For what concerns the user/source, I had the best SNR using a remote SDR in Greece (http://sdr.telcosol.gr:8073/), probably the transmitter is located in the eastern Mediterranean area: Greece, Cyprus Is. or Turkey. Some friends from radioscanner say it's the Turkish T-15 protocol.

Fig. 5 - monitoring the signal using remote SDRs in Greece and Spain (at same time)

https://yadi.sk/d/KTToEiGP3Twmbx