Showing posts with label UUCP. Show all posts
Showing posts with label UUCP. Show all posts

13 July 2023

PolAF, UUCP over RSX.25 to exchange HF email messages

tags: , , , ,

I have already encountered the Rohde & Schwarz RSX.25 protocol in some transmissions of the German BPOL and Italian GdF, this time (just a few days ago) I spotted such transmissions from the Polish AirForce (Siły Powietrzne - Ministerstwo Obrony Narodowej, MON) on 6884 KHz/USB where they use R&S GM2100 proprietary waveforms as HF bearer and UUCP over RSX.25 to send PostMan II email messages (Figure 1). Transmission were recorded using a Polish KiwiSDR [1].

Fig. 1

Particularly, one of the transmissions being analyzed refers to the nodes with ALE address WARSZAWA2 and BYDGOSZCZ:

TO WARSZAWA2 TIS BYDGOSZCZ
TO BYDGOSZCZ TIS WARSZAWA2
TO WARSZAWA2 TIS BYDGOSZCZ User Unique Function 00 07 (CMD USER UNIQUE WORD)

The used 2G-ALE protocol is the well-known standard 188-141A: the first thing that catches the eye is the use of a User Unique Function (UUF) [2] with the value 00 07 (14-bit ASCII [nul][bel]) in the third frame of the ALE handshake. User Unique Functions enable the transmission of a manufacturer-specific Unique Index which may be used for controlling the subsequent data transmission protocol; in this case, the value 0007 is most likely the particular "index" that R&S uses to signal UUCP/RSX.25 protocol to the receive node.

Data are sent using the HF waveform "Signal Format", a so-called R&S proprietary advanced waveform provided by their GM2100/GM2200 HF modem. The used waveform is the quite common 2400Bd PSK8 occupying a 3 KHz bandwidth (Figure 2). With 8PSK the net data rate of the serial modem is 5400 bit/s, errors are at first corrected by FEC, which reduces net data rate to 2700 bit/s. 

Fig. 2

The framing consists of a 192-symbol sequence preamble followed by one ore more data blocks each consisting of 64-symbols: 48 unknown symbols (coded data) + 16 known symbols ("test sequences"). The postamble terminates the data blocks and consists of a 64-symbol End Of Message sequence. Except for the presence of an initial TLC section(s), the total length is then a multiple of 64 symbols.

Fig. 3

Figure 4 shows the ACF/period of the GM2100 waveform: since the 2400 Baud, the ACF value of 133.33ms corresponds to a 320-symbol period, ie to five 64-symbol data blocks.

Fig. 4

The length of 320 symbols is due to the fact that the 16-symbol test sequences are actually "segments" of a longer 80-symbol sequence and so they are five times repeated, as visible in Figure 4 (unless demodulation errors), hence the length of (48+16)×5=320 symbols, or 960 bit since each PSK8 symbol is mapped to a tri-bit sequence (000...111). 

Fig. 5

After the removal of the HF waveform overhead, the well-known 8-bit patterns of RSX.25 emerge (Figure 6). RSX.25 literally stands for R&S adaptation of wired X.25 protocol to the HF radio channel,ie a modified AX.25 packet radio protocol.
Quoting R&S papers: "RSX.25 organizes the data to be transmitted in packets, which are successively transferred to the data modem. The packets contain a variable number  of  frames, the number per packet depending on radio-link quality and being adapted at regular intervals. The data transmitted in a packet are distributed among the frames. The length of the frame data is variable and also depends on radio-link quality: in channels of very good quality, a frame contains up to 250 data  bytes, in strongly disturbed channels 4 bytes. Errors escaping FEC are eliminated by the ARQ procedure of the RSX.25 protocol." [3]

Fig. 6

The transmitted data are obtained after the removal of RSX.25 encapsulation and packets' reassembly, the file (Hex codes and ASCII text) is edited using the XVI32 hex editor [4] and shown in figure 7. Some known "reserved words" and syntax say that's an email transport performed by the use of UUCP: 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).
 
Fig. 7

UUCP (Unix-to-Unix copy) 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 RSX.25. The human-readable version of  the UUCP "conversation" (just the initial part)  is shown in Figure 8.
 
Fig. 8

The messages can be parsed according to the UUCP protocol internals [5] so to get some other informations about users, SW/HW equipment... and so on.
 
login...Connected...OK 
login section

S Bydgoszcz_HF -pz -vgrade=z -R -N07 ROKN07 Pyie Uy
UUCP handshake 
S  caller hostname = Bydgoszcz_HF
-pz -vgrade=z  requests the called system to only transfer files of the specified grade or higher = z (grades in UUCP links means 'priorities')
-R  caller UUCP understands how to restart failed file transmissions. Supported only by System V Release 4 UUCP, so this is a System V release.
-N07 - caller UUCP understands the Taylor UUCP size negotiation extension (only for UUPlus, so this is UUPlus)
ROKN07 – called station acknowledgement of ‘R’ options. The caller UUCP is acceptable, it specified `-N', and the called UUCP also understands the Taylor UUCP size limiting extensions
Pyie  the called station supports the following UUCP protocols y, i, e
Uy  the calling station selects which protocol to use out of the protocols offered by the called station, in this case the UUCP protocol 'y'
 
pm2mrs -CR D.0097 0666 dso22odn@bydgoszcz.airforce.pl 0x3d26
most likely R&S PostMan II messenger
D.0097 file to send
0666 mode of file, if UUPlus always = 0666 for outgoing files
dso22odn@bydgoszcz.airforce.pl file name
0x3d26 file size (15654 bytes) 

rsmail -v2 -f dso22odn@bydgoszcz.airforce.pl dsocop@warszawa2.airforce.pl
Since PostMan offers  e-mail, fax and file transfer, my guess is that the additional command rsmail (most likely R&S mail)  following the pm2mrs invocation just specifies the email service
dso22odn@bydgoszcz.airforce.pl the caller station (ALE address: BYDGOSZCZ) is the "22 Ośrodek Dowodzenia i Naprowadzania" (22 Command and Guidance Center) [6] located st Bydgoszcz Airport: it's a civilian airport but shared with the Polish Air Force
dsocop@warszawa2.airforce.pl it's the called station (ALE address: WARSZAWA2) , "dso cop" is probably the Armed Forces Operational Command in Warzawa (it's a my guess)
It's interesting to note that in some other recordings the email address are user@warszawa2.airforce.pl and user@bydgoszcz.airforce.pl ("user@" is the common default username as in other message handling systems), although the ALE address remain the same, ie WARSZAWA2 and BYDGOSZCZ.
 
BZh9
Bzip2 4 bytes header, here starts the file to be sent (Bzip compressed)
BZ  Signature (0x425A magic number)
h Bzip2 (h is for Huffman coding)
9  increments of 100 kB block-size uncompressed


It's really obvious that the two stations belong to the Polish Air Force (indeed "airforce.pl" is the email domain name) as well as the use of R&S hardware/software equipment (STANAG/MIL-STD waveforms cannot be used along with the RSX.25 protocol [7]). 
A bit of OSINT demonstrates the R&S support to the Polish Armed Forces:
as well as the use of R&S XK2500L and XK2900L radios (along with Harris RF-5800) at the "Radio Center, Region 4 Air Force ICT Support":
 

Must be noted that PostMan II (now superseeded by PostMan III) is a combined R&S hardware & software product running on a Unix-like communication server: hence the use of such OS, at least in the mail server of the local nets.


Further catches could offer the chance to gather some more intelligence.
 
 
 
2 comments:

26 April 2018

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

tags: , ,
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: 

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






1 comment:
Subscribe to: Posts (Atom)