(unid) synchronous transfer protocol over MS-110A & FED-1052 DLP

Durings the last few days I have monitored the frequency 7762.0 KHz/U and collected very interesting recordings of transmissions regarding a (possible) synchronous transfer protocol which sits at a higher layer than the datalink one. All transmissions use MS-110A as the HF waveform and most of them use FED-1052 App.B as Data Link Protocol (DLP)(1): Figure 1 is an example in this regard. Since the use of FED-1052 DLP, the HF waveform could likewise be FED-1052 serial (single-tone) given that the two waveforms are interoperable. Links are performed using 2G-ALE handshakes (MS-141A), logged callsigns are K01, k02, K03, K08, K13, and K14. 

Fig. 1

1. The demodulated bitstreams of the first four Tx segments ("A" in Figure 1) have a common 26-byte (10+16) length initial sequence which may be seen as consisting of the two Hex strings/sequences shown in Figure 2:

[16 16 16 16 16 16 16 16 16 16] [8E 5C 0B AA 97 30 56 E6 93 A2 B3 FB 6D 1A E2 01] 

Fig. 2 - initial Hex sequences

The two initial strings are followed by an apparently random 224-bit/28-byte sequence which is 3 times repeated: that sequence is unique for each Tx segment so that it could be an Initialization Vector (IV): the repetitions are indeed a good clue (Figure 3):

[54 6A 59 86 D8 0D 5E EE 94 AF B7 25 C1 DB 44 A8 BF 4B F9 DF AF F4 BF 1D 94 F9 6D 3F]

[FA D6 B4 C8 3D 50 BA 06 F1 E7 4C 22 02 A5 86 48 F9 6D AA 76 29 3C 0A E0 51 E8 61 FF] 

[58 FC 4A D4 09 C2 82 9B 75 93 16 2D 8A 11 B1 D3 8A DE F1 55 79 2E 52 E1 53 02 E2 B5]
[A7 55 A7 B1 8E E9 68 96 84 DF 57 FA AF A2 09 E9 EA DB D5 53 16 9F 20 E7 93 75 24 86]

Fig. 3 - 28 bytes sequences

The bitstreams end with a 20-byte string of 0x16, just the double of the length of the initial 0x16 sequence:

[16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16]

Fig. 3 - ending Hex sequences

Since these Tx segments are sent using the 2400bps/voice mode, the data blocks between the (presumed) IVs and and the ending sequences could consist of secure digital voice. The Shannon entropy value computed on data blocks (7.792888420337759) could suggest encrypted or compressed files. Just to be thorough, I thought about checking whether the repeated 28-bytes sequences were SHA-224 digests (64 rounds, by default) of the following data blocks, but the results did not confirm this hypothesis.

2. The bitstreams resulting after demodulating the other 12 Tx segments ("B" in Figure 1) are recognized as FED-1052 App. B "DLP Data Link Protocol" frames (also known as HF Data Link Protocol, HFDLP). Quoting FED-1052 standard #50.1.1.1 Frame sync pattern:  Each new transmission over the physical channel shall begin with a three byte (24-bit) frame synchronization pattern to identify the following traffic as DLP processed traffic. The frame synchronization sequence in hexadecimal format, shall be "5C5C5C". The sync pattern shall be transmitted such that the first eight bits in order of transmission are "00111010" (see Figure 4).

Fig. 4 - FED-1052 DLP sync patterns

Looking at the Source and Destination Address fields (2) in the hexdumps of Figure 5, it's possible to see the exchanges of DLP frames between the addresses 03 (0x3330, ASCII 30) and 01 (0x3130, ASCII 10): forward and reverse directions are due to the ARQ feature of DLP protocol. Notice that the DLP addresses 01 and 03 match the ALE callsigns K01 and K03 used during the link setup process (Figure 5).

Fig. 5 - DEF-1052 DLP frames exchanges

More precisely, each DLP transfer consists of 3 frames (Figure 6):  the first is a data frame (bytes block delimited by 0x16) while the 2nd and 3th are control frames.

Fig. 6

DLP data frames consist of 56-bytes "packages", thus the re-assembly process produces files that have lengths in multiples of 56 (112, 168, 224, ...). By the way, packages are the result of a "fragmentation" of messages received from the user (or from a higher-layer protocol).

The small files resulting after the re-assembly process (and the removal of FED-1052 DLP overhead) are not in clear-text... and here things get interesting. 

The files start with a common 18-byte (10+8) sequence which may be seen as consisting of two Hex strings:

[16 16 16 16 16 16 16 16 16 16] [DF 73 0D 1D 5B 22 53 81]

and term with the 20 bytes Hex sequence:

[16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16 16] 

Also in this case, the ending 0x16 sequence is the double of the length of the initial 0x16 sequence (Figure 7):

Fig. 7

The 0 value bytes are padding bytes added to the last package to obtain the 56-byte size: it can easily be verified for each packet by subtracting the "data" bytes from the "received" ones. Quoting FED-1052 standard #50.4.3.1.2: All data frames shall be of the same size [...] this implies that the last data frame of a message may need to be padded with fill bits. The receive terminal will use the transmit message size information to determine where the message is to be truncated in order to remove the fill bits from its output data stream. The 16-bit graphic rapresentations are shown in Figure 8.

Fig. 8

 

Data consist of a few bytes, I do not think they are compatible with digital voice or "informal messages", maybe they are numerical data even if some format does not emerge.

3. I know that 0x16 is the <SYN> "Synchronous Idle" (TC9) ASCII control character. It is used in synchronous transmission systems to provide a signal from which synchronous correction may be achieved between data terminal equipments, particularly when no other character is being transmitted. The SYNC char was also used in syncrhonous modems at start and end of info blocks. So, the initial sequences of SYNC make me think of a kind of "synchronous transfer protocol" sitting at higher-layer.
Moreover, from the bitstreams analysis, it seems to me that the protocol is used to send different type of data and in different modalities: some types of data (Tx segments "A" in Figure 1) are forwarded directly to the MS-110A/FS-1052 modem, other types of data (Tx segments "B" in Figure 1) are first managed by FED-1052 DLP and then forwarded to the MS-110A/FS-1052 modem. Maybe the two initial strings announce the type of the following data blocks, but it's only a my guess.

By the way, the long durations of the 2G-ALE scanning call provide some indications about the number of the available channels: assuming full compatibility(!) with MS-141, the collected scan lists should be >= 20 channels (3). User should be Dutch MIL... but it's not confirmed.

Fig. 9 - 2G-ALE MS-141 scan call

 

https://disk.yandex.com/d/CrXu2QY4-AP9vQ 

(1) The HFDLP is a selective repeat ARQ protocol with the ability to adaptively vary several parameters in response to changing channel conditions. A transmission usually consists of a data series, containing several data frames, or a single control frame. Every frame contains a CRC. Before data transfer commences, HFDLP terminals exchange control frames to negotiate the number of data bytes per data frame (56 to 1023), the number of data frames per data series (1 to 255), and a few other characteristics of the data transfer procedure.

(2) As per FED-1052 standard, Source Address and Destination Address fields are restricted to two bytes each, LSB first. 

(3) 188-141 A.5.5.3.1 "If the called station (JOE) is known to be listening on the chosen channel (not scanning), the calling station (SAM) shall transmit a single-channel call that contains only a leading call and a conclusion (see upper frame in figure A-29). Otherwise, it (SAM) shall send a longer calling cycle that precedes the leading call with a scanning call of sufficient length to capture the called station’s receiver as it scans (lower frame in figure A-29). The duration of this scanning call shall be 784ms for each channel that the called station is scanning.

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

Yet another interesting catch of an email-over-hf session using FED-1052 Datalink Protocol (DLP, Appendix B) and IDEA encryption. The transmission was recorded on 09187.0 KHz/usb 1357z: encrypted MIL 188-141A 2G-ALE to set up links and switch to MIL 188-110A serial tone waveform for emal traffic via FED-1052 App.B DLP (Data Link Protocol); ASCII-7 data are encrypetd using CFB64 "IDEA" algorithm. Headers are unencoded so you can read both the sender and recipient, in this sample:

sender: ZJ1, root@bfzj1f1.is.bf.intra2.admin.ch

recipient: ZA1, statist@bf.intra2.admin.ch

email ID: "stat-ZJ1-20181113135501" (2018.11.13, time: 135501)

The FQDN (Fully Qualified Domain Name) "intra2.admin.ch" indicated in the e-mail addresses suggests an intranet of the central administration of the Swiss Federation: likely this is the Swiss Army or the Diplo Service.

A more detailed post about such transmissions can be read here.

Fig. 1 - on air signals, MIL 188-110A Serial Tone waveform

Fig. 2 - FED-1052 App.B stream

FED-1052 to deliver IDEA encrypted HF email (likely Swiss Mil/Diplo)

Interesting transmission heard on 15888.0 KHz/usb at 0734z likely from Swiss Army units (callsigns ZJ1, ZA1) and consisting of a 188-141A "linking protection" handshake followed by 188-110A 300bps/Long. FED-1052 App.B Data Link Protocol (DLP) [1] is used at link layer to deliver an "IDEA" encrypted email file. 

Fig. 1 - the typical 520-bit period of FED-1052 after 188-110 Serial removal

 

Some information can be obtained from the analysis of the email headers (see below and Figure 2): for example, besides FED-1052 DLP, they use Thales TRC-3700 20W HF manpack radio [2] and IDEA (International Data Encryption Algorithm) encryption [3].
IDEA algorithm is developed at ETH in Zurich, Switzerland, and its patents are heald by the Swiss company Ascom-Tech AG. IDEA uses a block cipher with a 128-bit key, and is generally considered to be very secure. It's interesting to notice that in year 2008 Ascom Security Solutions has been commissioned by Armasuisse to deliver telecommunications equipment as part of the 2007 armaments programme: Thales TRC-3700 radio is termed as "SE-240 tactical short-wave radio" in that document: 

https://www.totaltele.com/435984/Ascom-orders-from-Swiss-army

By the way, "Armasuisse" is the Federal Office for Defence Procurement agency for armaments of Switzerland and is affiliated with the Federal Department of Defence, Civil Protection and Sport. 

Fig. 2 - HEX stream after FED-1052 removal

54 52 43 2D 33 37 30 30 20 28 54 68 61 6C 65 73 29
TRC-3700 (Thales)
indication of the HF radio used by ZJ1 (never seen before in HF emails, except in domain names)

5A 4A 31 72 6F 6F 74 40 62 66 7A 6A 31 66 31 2E 69 73 2E 62 66 2E 69 6E 74 72 61 32 2E 61 64 6D 69 6E 2E 63 68
ZJ1 root@bfzj1f1.is.bf.intra2.admin.ch
5A 41 31 73 74 61 74 69 73 74 40 62 66 2E 69 6E 74 72 61 32 2E 61 64 6D 69 6E 2E 63 68
ZA1 statist@bf.intra2.admin.ch
Callsigns of sender and recipient (ZJ1 and ZA1) and their email addresses. The term "intra2" leads to think of a intranet belonging to admin.ch which is a domain hosted by SWISSGOV-ETZ. Notice that ZJ1 is "root" at the hostname bfzj1f1.is (bf zj1 f1).
 
45 6D 61 69 6C 20 49 44 3D 28 22 73 74 61 74 2D 5A 4A 31 2D 32 30 31 38 30 37 33 30 30 37 33 31 30 30 22 20 29
Email ID=("stat-ZJ1-20180730073100" )
email id looks like the email subject:  "stat-ZJ1" followed by timestamp 2018-07-30 07.31.00
The acronym/abbreviation "stat" could mean station, status, or statistics: notice that the recipient is statist@ 

45 6E 63 72 79 70 74 69 6F 6E 4D 6F 64 65 3D 20 43 46 42 36 34
EncryptionMode= CFB64
Cipher feedback (CFB) mode using 64-bit blocks

49 44 45 41 4B 65 79 49 64 3D 20 32 30 31 31 30 34 30 34
IDEAKeyId= 20110404
IDEA Key identifier
 
49 6E 69 74 69 61 6C 56 65 63 74 6F 72 3D 20 35 35 38 32 41 42 42 30 36 41 36 30 34 45 35 34
InitialVector= 5582ABB06A604E54 
128-bit Initialization Vector (IV)

62 65 67 69 6E 20 36 36 36 20 2F 74 6D 70 2F 43 46 42 36 34 30 31 36 33 35 32 35 42 35 45 42 46 30 41 32 45 42 37 42 36 44 34 2E 64 61 74
begin 666 /tmp/CFB640163525B5EBF0A2EB7B6D4.dat
the file being transmitted is stored in the /tmp directory of a Linux/Unix system. Notice the encryption mode (CFB64) at the beginning of the filename.

-- encrypted data follows --

It seems that they always transfer .dat files whose filename is composed of "CFB64" followed by 22 uppercase alphanumeric characters. Maybe the (off-line) encryption procedure stores the encrypted files in the /tmp directory and assigns them a unique filename.

As shown in Figure 3, the email text and the .dat file are coded in the standard ASCII 8-bit format but since the first bit is "0" they use the ASCII-7 code, ie none of the additional character combinations (128-255) is used.

Fig. 3

It's noticeable that - at least in my catches - the IDEAKeyId field has always the same value "20110404" (April 4th, 2011 ?).

https://yadi.sk/d/Pl3QYEoD3ZiHVe

[1] Sending files using MS188-110A and FED-STD 1052 App.B
[2] https://www.thalesgroup.com/en/worldwide/defence/hf-3000-skyfst
[3] http://www.quadibloc.com/crypto/co040302.htm

cars, chameleons, networks... (update 2)

OPL-OPn net (5424.0 KHz)

I have already talked here about this QRG, where the heard ALE addresses were 5B, AB, 1PB, 1PC, 2PB, and 3PB (the so-called PB net), but in these days, at least from 1st December, in that same frequency I heard addresses as OPL, OP1, OP2, OP3, and OP4 (so the name OPL-OPn net). Transmissions start from about 0800 UTC and OPL seems to act as the net-control station. The used technology is the same than PB net, i.e. 188-110A and FED-1052 App.B for the messaging system, and 2G-ALE for the link setup, aside just three 188-110 App.B/FED-1052 App.A frames (see below).

 

Fig. 1

Same QRG and same nodes configuration mean the same source, OS BiH, and the same stations: just a "rotation" of the tactical on-air ALE addresses. I do not know if it's a monthly update or if the update was due to some other reason, further monitorings will help in this direction.

As expected, once removed 188-110A and FED-1052 headers, I got files with ARX and TNEF extensions but this time I had more luck: since the informal nature of the messages (in the reported example, a simple list of sent/received telegrams) these were sent in clear-text. The reading of the extracted files in Figs 2,3 confirms the source and the rotation of the on-air addresses while the e-mail addresses of the network nodes remain unchanged (see Fig.5 of the Part I for what concerns 5PBR), so the old 5B, AB, 1PB, 1PC, 2PB, 3PB,... and the current OPL, OP1, OP2, OP3, OP4,... refer to the same nodes of a single radio-network belonging to OS BiH and running on 5424.0 KHz/USB.

Fig. 2

Fig. 3

Thre is an oddity in one of the recordered transmissions: the presence of three 188-110 App.B/FED-1052 App.A frames just before the link termination (Fig. 4).

Fig. 4

This is the first time, on my side, I see such modality during the e-mail exchanges monitored in this frequnecy: it's hard to say if it just belongs to this transmission or it appeared randomly from some other (unid) source. Anyway, it's worth noting that its time-position in the transmission flow is correct as well as its obsolescence is justified by the use of FED-1052.

https://yadi.sk/d/W19eZn8W32AwPg 

cars, chamaleons, networks, and other stories (I)

For some days I monitored (and I'm still monitoring) some frequencies on 5 MHz band, hearing curious MIL 188-141A  "cars" addresses such as OPELHFMREZA, VOLVOHFMREZA,... (here denoted as HFMREZA-net) as well as FORDBRTP and FORD1BRTP  (BRTP-net), and same other ones in the format 1PB, 2PB,... (PB-net) and ABC7, ABD1,... (AB-net).  This post is about the identification of the first three networks,  a second post will cover the AB network and possible updates. Maybe I will be criticized for the share of this kind of "do-it-yourself COMINT", but its purpose is only hobbystic; sensitive and confidential messages contents, if any, are anyway not published.

car-HFMREZA net (5120.0 KHz)
MIL 188-141A is used for the link setup and, after the 3-way handshake, data are sent using STANAG-5066  and MIL 188-110A as HF waveform (fig.1): a quite common 2G configuration. The prefixes used in the ALE address are some popular automotive brands as FIAT, FORD, OPEL, SKODA, and VOLVO, while GAMA is maybe the less popular "Georgia Automotive Manufacturers Association" or the GAMA Automotive Aenter, but it could be intended as the third letter of the Greek alphabet or  as "collection". As a further option, in my opinion the most interesting, GAMA was a German maker of toys, usually cars and trucks.
Anyway, at least in my logs, GAMA always initiates the ALE sessions which precede the transmissions of data, thus acting as the net-control station.

fig. 1

In some bitstreams, obtained after removing the S-5066 headers, I could find compressed files which are originated by HBFTP protocol. As known, BFTP (Basic File Transfer Protocol) is based on the ZMODEM protocol and is often used in conjunction with CFTP protocol to transfer e-mail messages from one SMTP e-mail server to another, as specified in the Annex F of S-5066 profile. The file HBFTP--3.gz is reported in this example (fig. 2).

fig. 2 - BFTP zipped file

Since BFTP is used for informal interpersonal e-mail only, it may happen that such messages are transmitted in clear-text, thereby facilitating the identification of the network through the contents and the headers added by the SMTP server that forwards the e-mail message.  As expected, and with a bit of luck, the extracted file HBFTP--3.eml offer some useful tips and clues.

fig. 3

The points indicated as 1 and 4 inform about the configuation of the station(s). The e-mail addresses wmtuser@GAMA.ok and wmtuser@VOLVO.ok reveal that the messaging system, and most likely the connected radio, are provided by Harris: wmtuser, or  WMT user, is just the default username used in Harris RF-6750W Wireless Gateway (WG) and RF-6710W Wireless Messaging Terminal (WMT). The underlaying PC run a Microsoft OS, likely Windows 2000 Professional or Windows XP Professional; Office Outlook is  the e-mail client running at GAMA, but also Outlook Express is used (eg at station VOLVO).

From the timestamp, point 3, we can get informations about the geographic area since it exposes the time-zone of the system: in this case +0200, ie GMT +2. The time-zone helps European people like me to parse the hostname osbihbutmir, visible in point 2, and the suffix HFMREZA. Indeed, the latter can be split in HF MREZA where MREŽA is a Slavic word for "network" (google-translator is your friend): the geographic area matches the time zone. About the hostname, since BiH is a well-known ISO Country Code for that area, osbihbutmir could be split in "os bih butmir". Well, now let google do the work for you: simply enter that string, hit enter, browse some results pages and you will get the HF network we're talking about.

The official site has the English version so that you can browse its pages and find many interesting informations such as HQ locations, structure, sectors, multimedia and so on.  Specifically, "Butmir" (indicated in the hostname of the station GAMA) is the AF Operational Command HQ and we have seen above that  GAMA just act as the net-control node. About the other stations (VOLVO, FIAT, OPEL,...) they belong to the "ok" e-mail domain which almost 100% stands for  Operativna Komanda, hence the HFMREZA-net could be the main radio-network. Difficult to say their locations and their role in the "structure" diagram shown in the web site.
About the HF equipment, still from the web site we learn that Harris RF-5800 was aleady owned in September 2009, just seven years ago, during their partecipation at "NATO Combined Endeavor"  as PfP country.

I do not go beyond, anyone on their own can obtain from the web all the (public!) informations he wants; moreover the e-mails contents, although interesting, are out of the scope of this blog.

PB net (5424.0 KHz)
Same origin and owner emerge also by the analysis of this newtork, even if the configuration of the nodes is a bit different: same ALE technology (118-141A) and HF waveform (188-110A) but messaging is achieved using FED-1052 rather than S-5066 (fig. 4). It's hard to say if the choice of 1052 is due to specific requirements or if the network shall be upgraded. The addresses logged during the monitoring are 5B, AB, 1PB, 1PC, 2PB, and 3PB: 5B seems to play the net-control role.

fig. 4

Once removed FED-1052 DLP protocol headers, I got files with ARX and TNEF extensions. 
Files whith the .ARX extension are known as ARX Compressed Archive files, however other file types may also use this extension. Regardless of the extensions, a "path" inside the sender host is exposed in one of the received ARX files:

TNEF (Transport Neutral Encapsulation Format) is a proprietary e-mail attachment format used by Microsoft Outlook and Microsoft Exchange Server. TNEF attachments can contain security-sensitive information such as user login name and file paths from which access controls could possibly be inferred. This format is probably used since TNEF files may contain information used by only Outlook to generate a richly formatted view of the message, such as embedded (OLE) documents or Outlook-specific features such as forms, voting buttons, and meeting requests. Note also that native-mode Microsoft Exchange 2000 organizations will, in some circumstances, send entire messages as TNEF encoded raw binary independent of what is advertised by the receiving SMTP server. An interesting and complete description of TNEF can be read here.

One of the TNEF files obtained from the monitoring is shown in fig. 5.

fig. 5

Point 3 confirms the use of Harris equipment (although a confirm is not needed since the use of FED-1052), but the most relevant are the points 1 and 2 which show the stations in the play: specifically (from the cited web site) 3PB stands for 3 Pješadijski Bataljon (3rd Infantry Battalion) with headquarter in Bijeljina, and 5B stands for 5 Pješadijska Brigada (5th Infantry Brigade). By the way, all the addresses heard from this nework can be easily "humanized" through the official web site (thanks to Patrick for his hint).

About the contents, TNEF4 file consists of Outlook MAPI strings which their meaning can be retrieved from the web. I just want to point that, since:
PR_ORIGINAL_SENDER_EMAIL_ADDRESS contains the e-mail address of the sender of the first version of the message, that is, the message before it is forwarded or replied to;
PR_DISPLAY_NAME contains the message sender's display name;
most likely this message is a reply sent by 3PB to a previous message received from 5B.


BRTP net (5025.0 KHz)
For what concern FORDBRTP and FORD1BRTP addresses, belonging to the third monitored network, they probably form a two-points circuit rather than a network: so far I never logged other xxxxBRTP addresses, at least on that frequencies. 
These stations use the same configuration  of the first net (ie S-5066 + MIL 188-110A) as well as the "automotive brand" suffix in their ALE addresses. The traffic in this "circuit" seems to be less frequent and unfortunately I could not yet hear good quality transmissions. My friend Kristian successfully suggested Brigada Taktičke Podrške (Tactical Support Brigade) for BRTP.

Sumarizing 
From what seen above:

1. the three networks are operated by the same Authority;
2. HFMREZA-net and BRTP-net use STANAG-5066 and 188-110A;
3. network PB-net use FED-1052 and 188-110A;
4. all the three networks use 188-141A 2G-ALE technology, Harris equipment and Microsoft Windows systems;
5. stations, and hence the netwoks, belong to different e-mail domains.

About the different messaging systems, it's worth noting that the Harris RG-6750 Wireless Messaging Gateway software (WMG) provides mixed networks compatibility between stations with STANAG-5066 and stations with FED-1052 by running simultaneous 5066-1052 sessions.

Processing the STANAG-5066 headers, thus except the 1052 PB-net, it is possible to derive the on-air 5066 addresses of the (heard) nodes:

GAMAHFMREZA   000.000.000.001
FIATHFMREZA   000.000.000.003
FORDHFMREZA   ? (prob. 000.000.000.005) *
OPELHFMREZA   000.000.000.007           
SKODAHFMREZA  000.000.000.009      
VOLVOHFMREZA  000.000.000.011           
FORD1BRTP     000.000.000.012
FORDBRTP      000.000.000.013
*  note that when alphabetically sorted they use odd numbers in the 4th byte of the 5066 address.

Now, since:

• 5066 adresses are contiguous passing from HFMREZA-net (ending with 011) to BRTP-net (beginning with 012);   
• so far I never heard "cross" links among the three networks (eg: xHFMREZA <--> xPB) hence the ALE networks are not overlapping;
• so far I never heard traffic between two "peripheral" nodes (eg: VOLVO <--> FIAT);

they could use a "star" network topology, or rather a "tree" network topology, where traffic between two peripheral nodes, or between two net-control nodes, is routed ouside the HF network. Indeed, looking at the routing rows in the e-mail headers (fig. 6), the stations have a "radio1" asset and it could indicate the existence of a second radio (say radio2) - at the same site - that belongs to a different station which, in turn, belongs to a different network and e-mail domain... but this is another speculation.

(to be continued)