24 October 2016

Unid BPSK 1500Bd (prob. Chinese modem)

Unid modem (prob. Chinese origin) using BPSK modulation at 1500 Baud and 1500 Hz sub-carrier. Since the alternation of frames with different strength, this may be a duplex channel.

fig. 1
fig. 2
fig. 3
Once demodulated, the analysis of the bitstream reaveals an interesting 3 bit structure (fig. 4): my friend Karapuz suggested to try a differential (relative) decoding of the signal.

fig. 4
Differential decoding can be obtained directly by running the proper tool of  the bit-editor or by demodulating the signal using the SA demodulator with option "Diff 1" as in fig. 5

fig. 5
Results are similar and in the output bistream, visually more logical, is visible the sync bit and the two data bits (fig. 6).

fig. 6

19 October 2016

cars, chameleons, networks, and other stories (part II)

In the first part of this post there were the cars, here are the chameleons: such name is not related to the ALE Addresses but rather to the configuration of the stations. A third part will follow in case of news or updates.
The two following networks, although they exhibit different behaviors, share some aspects which lead to think to the same source/organization or at least to the same Country. As said in the first part, the purpose is only hobbystic; sensitive and confidential messages contents, if any, are anyway not published. I'm interested on the way the "boxes" travel and NOT on their content.

Stations and ALE addresses of this network are: ABD1, ABG6, ABF2, ABS5, ABK4, ABH3, and ABC7 that acts as net-control. Transmissions are scheduled on tuesday and thursday from about 0730 UTC and usually follow the schema link-send-terminate. Links are initiates by ABC7 and always in the same order, ie: ABD1 first then, ABG6, ABF2, ABS5, ABK4, and ABH3 as last. Other than 188-141A for ALE, STANAG-5066 is used for messaging and STANAG-4285 as HF waveform (fig. 1), settings are 1200bps and short interleaver. I monitored this net on 5838.0 KHz/USB, that seems to be the main channel, but other frequencies are also used.

fig. 1
In the firts loop, stations are contacted by ABC7 for a radio-check, then  in case the net-control has messages to send, the stations are again contacted and always in the same order. Sometimes the sending phase follows the radio-chek so that the stations are worked one time only, the sending is always preceeded by a voice-exchange of a pair of authentication keys according to the sequence diagram of fig. 2. A common phrasebook for telecommunications, in english, is strictly used.

fig. 2 - sequence diagram
The authentication keys consist of 4 numeric digits for the "my-auth-id" key and 2 numeric digits for the "auth-id" key , eg:

ABC7: alpha bravo x y this is alpha bravo charlie seven, authenticate 79
ABXY: alpha bravo charlie seven, this is alpha bravo x y, my authenticate 6843, authenticate 74
ABC7: this is alpha bravo charlie seven, my authenticate 2895
ABXY: ok send your message

A fter finishing sending the message, the net-control station asks the receiver peer to confirm the message-number then link is terminated and the next station in turn is contacted.

fig. 3 - 188-141A 3-way handshake and Auth keys exchange
The messaging system use the HBFTP protocol to deliver compressed e-mail files, COMSEC devices are not present (unclassified messages?) so, once removed STANAG-4285 and STANAG-5066 overheads, important clues and information can be drawn from an examination of the e-mail headers (fig. 4).

fig- 4
The sender and receiver stations belong to the e-mail domain 123 (point 1) and it's the common domain of all the stations of this network. The message has been received from, and by, the same host whose name is linux.site; "CROZ ESMTP/HMTP Gateway" most likely is the name of the STANAG-5066 application (point 2).  The IP address in the field "Received from" is or localhost (not wired to a LAN ?).
The hostname and the e-mail client fingerprint (point 4) clearly reveal that they use a Linux system, specifically: SUSE Linux 3.1.14. Indeed, the mention of chameleons I adopted  just derives from the official logo of SUSE.
The system language is the plain en-US without  language/keyboard customization.

The use of Linux is per se an interesting and peculiar element of this network, but it's not the only one.  The email includes one attached jpeg/image file whose name is "PRILOG 5 - PRILOG ZA SLANJE E-MAILA.jpg". This language suggest a Slavic origin (google-translator), as confirmed by the system timezone at point "3" (+0200), time-zone and especially the language restrict the candidate Countries to two: HIB and HRV. Anyway, the most surprising fact is that the e-mails I decoded have that same attached filename although it refers two images, in other words  they always use the same name for the attachments (fig. 5).

fig. 5 - two e-mails, different ricipients but same attached filename
On my side I can't rebuild the original images from the received S-5066 fragments but I can see at least the upper part of such images: they are always the same (fig. 6), although the image "B" is the most used in the attachments.

fig. 6
The reasons behind such way to comunicate are obscure: test? steganography?.., difficult to state unless speculations

In the above fig. 2 we have seen that the net-control stations asks a confirm of the received message-number: this a progressive number and matches the subject of the corresponding e-mail. The message-number is initialized to a new initial value at each day and assigned to the subject of the e-mail sent to the first station in the calling list (ie: ABD1, user1@asdf.123) and then is incremented by one at each step (fig. 7).

fig. 7
The choice of the initial value is apparently odd: fig. 8 is an example
06 Oct: initial value 600
11 Oct: initial value 603 
13 Oct: initial value 508
18 Oct: initial value 610  

fig. 8

I spotted a QRG, 5054.0 KHz/USB, where stations of this network do not use 188-141A before messages sending and traffic is less frequent, not to say sporadic.  STANAG-5066 HMTP protocol is used instead of HBFTP (fig. 9) and, as for the AB-net, STANAG-4285 is the transporting HF waveform. The lack of the ALE phase is quite odd since the heard transmissions are not bcasts but rather PtP messages: or links are negotiated in other channels/way or receivers are always in listening state. For sure, no 188-141A means no ALE Addresses to collect from this network. 

fig. 9 - HMTP-66 protocol
By a quick examination of the e-mails headers (fig. 10) it's easy to see that this network belongs to the same organization/authority of the previous AB-net: same OS (Linux SUSE), same STANAG-5066 application (CROZ ESMTP/HMTP Gateway) and - above all - same attachment filename (PRILOG 5 - PRILOG ZA SLANJE E-MAILA.jpg) can't be a coincidence.

fig. 10

Addresses and origin/owner of the networks
I never heard e-mail exchanges between the two nets but only e-mails sent from linux-a5kz to the other stations of AB-net and e-mails sent from linux-2o6y.site to other stations of 5054-net: this leds to think that these are the main stations of their respective networks. It's interesting to pay a look at the e-mail addresses of the two newtorks:

ALE  e-mail address
ABC7 user1@asdf.123
ABD1 user1@sdfg.123
ABG6 user1@dfgh.123
ABF2 user1@fghj.123
ABS5 user1@ghjk.123
ABK4 user1@jklp.123
ABH3      ?

  -  user1@aysxd.111
  -  user1@lost62.111
  -  user1@dres32.111
  -  user1@fejk8.111

As expected, the networks belong to two different e-mail domains "123" and "111": behind such choice there is surely a certain logic but unfortunately do not offer any clue for identification.
AB-net seems to use non-sense (?) alphabetical addresses (asdf, sdfg,...) while 5054-net seems to use a sort of "structured" names (lost62, dres,32, fejk8,...).  It's worth noting that the AB-net addresses, if listed in the order of the calling list,  exhibit a left-shift of 3 letters. According to this schema, ABH3 could have the address user1@klpq.123 (m,n,o seem to be not used).

A big help in the identification of the source is given by the examination of the collected STANAG-5066 nodes addresses:

ALE  Stanag-5066 address e-mail address
ABC7     user1@asdf.123 (ncs)
ABD1     user1@sdfg.123
ABG6     user1@dfgh.123
ABF2     user1@fghj.123
ABS5     user1@ghjk.123
ABK4     user1@jklp.123
ABH3          ?

  -     user1@aysxd.111 (ncs)
  -     user1@lost62.111
  -     user1@dres32.111
  -     user1@fejk8.111

About the assignments of the STANAG-5066 addresses, the global-regional blocks are defined by the 4 most-significant bits of the full length address (i.e., the first element w of the dotted-decimal form w.x.y.z): from fig. 11, 6.x.y.z is assigned to Europe. 

fig. 11
Within the global-regional blocks, specific 5066 addresses are assigned to individual Nations using the second element “x” of the dotted-decimal address form w.x.y.z.
Now, what european nation matches 6.8.y.z ?
The answer is in Table N-6 "National Address Schema" STANAG-5066 Edition 3 Annex N: 5066 is a NATO unclassified document that may circulated freely and is available on:
Sadly, no part of S-5066 Edition 3 can be published but the mentioned Table N-6 matches the "proposed allocations" which are visible at page 14 (here reported in fig. 12) of  a very interesting pdf file freely downloadable from: http://www.hfindustry.com (note that NC3A, NATO C3 Agency, is now NCIA or NATO Communications and Information Agency).

fig. 12

It's worth noting that the stations dfgh.123 and aysxd.111 exhibit the same S-5066 address, i.e. the same node: as far as I know a certain S-5066 address should not be shared by two or more nodes (duplicate address) hence we face the same physical node. Looking at the "Received" headers of one e-mail sent by aysxd.111 (fig. 13) we see that the e-mail is originated (from) and received (by) the same host linux-2o6y.site: this means that the e-mail client and the S-5066 gateway application are running inside that same host. Moreover, the IP address (which refers the sender) is the address of the localhost: this means that the host  linux-2o6y.site, i.e. the S-5066 node, is not wired to a LAN.

fig. 13
Keeping in mind that a node is generally assumed to include the HF modem and radio (and cryptographic) equipment required for communications, a possible explanation could be the configuration in fig. 14, that also clarifies the lack of "cross-messaging" between AB-net and 5054-net: such traffic is handled "inside" the hosts. Unless they assigned the same S-5066 address to two distinct S-5066 nodes or use some other configuration that I do not know.
fig. 14

Rockwell-Collins HF Messenger allows a such configuration (fig. 15) in which two clients, belonging to different domains (i.e. two e-mail accounts), share the same S-5066 resource. Anyway, this is not our case since HFM only run on Windows-based pc and we face a Linux based nodes (SUSE Linux 3.1.14).

fig. 15

STANAG-5066 gateway application
The S-5066 application running in the Linux gateway nodes add the string "CROZ ESMTP/HMTP gateway" in the received-by header, most likely its "fingerprint":

It is an application that acts either as Extended SMTP server (on the LAN side) or as HMTP gateway (on the HF network side). They do not use a Stanag-5066 applications from the most "popular" manufacturers in the place:

IsodeIcon 5066**(development, not released)
Rohde & SchwarzR&S 5066*-(client part in Java)
Selex (Leonardo)MDH*-
Thales-*-(client part in Java)

but rather the MoD preferred to have a proprietary product, entrusting the development of the application to CROZ, an IT Company located in Zagreb and Belgrade http://croz.net/en/, as contractor partner in the project. The result of this collaboration is the NATO Stanag-5066 compatible application named CroS5066 (fig. 16).

fig. 16 - CroS5066 schema
The mean features of the product can be read in their pubblication "CRO FYI" of  September 2009, page 14: the publication is available for reading and download on their web site:
CroS5066 is fully interoperable with other S-5066 systems, positive tests were made during NATO exercises Combined Endeavor 2008 (Lager Aulenbachhere, Germany and Lora Naval Base in Split, Croatia).

(to be continued)

17 October 2016

5MHz Logs

05025.0 FORDBRTP: Unid (prob. Bosnia Herzegovina Defense, BIH) 0739 USB MIL 188-141 2G-ALE calling FORD1BRTP (27Sep16) (AAI)
05032.1 ---: Unid 0618 (cf) FSK 200Bd/160 acf 24bit (prob. telemetry?) (11Oct16) (AAI)
05036.0 K1U: Slovakian Mil, SVK 0616 USB MIL 188-141 2G-ALE calling Z1V (07Oct16) (AAI)
05036.0 Z1V: Slovakian Mil, SVK 0617 USB MIL 188-141 2G-ALE calling S1S (07Oct16) (AAI)
05045.0 ---: Unid 0715 USB Thales TRC-177x modem PSK-8 2400Bd S-4285 modified waveform flwd by Systeme-3000 analog voice scrambler (12Oct16) (AAI)
05054.0 ---: Unid 0804 USB STANAG-4285 transporting STANAG-5066 HMTP commands and data (26Sep16) (AAI)
05075.5 CHFEDR: Greek Air Force, GRC 1851 USB MIL 188-141 2G-ALE handshake with RCLS1 (16Oct16) (AAI)
05095.0 2L: Italian Mil, I 0655 USB/J3E radio-check and voice comms with 3H sounding (05Oct16) (AAI)
05095.0 2LK2: Italian Mil, I 0710 J3E/USB main station, calling 4M54, 7IJ4, 3HF3 (12Oct16) (AAI)
05102.0 ---: Unid 0727 USB MIL 188-141 2G-ALE link protected (04Oct16) (AAI)
05120.0 FIATHFMREZA: Bosnia Herzegovina Defense, BIH 0656 USB MIL 188-141 2G-ALE calling GAMAHFMREZA (26Sep16) (AAI)
05120.0 GAMAHFMREZA: Bosnia Herzegovina Defense, BIH 0730 USB MIL 188-141 2G-ALE calling VOLVOHFMREZA, handshake flwd + MIL 188-110A transporting STANAG-5066 HBFTP gzipped files (23Sep16) (AAI)
05120.0 GAMAHFMREZA: Bosnia Herzegovina Defense, BIH 0748 USB MIL 188-141 2G-ALE calling SKODAHFMREZA (23Sep16) (AAI)
05120.0 OPELHFMREZA: Bosnia Herzegovina Defense, BIH 0732 USB MIL 188-141 2G-ALE calling GAMAHFMREZA (23Sep16) (AAI)
05145.0 ---: Unid (Bulgarian Diplo ?) 0710 USB RFSM-8000 modem with data-masking (29Sep16) (AAI)
05150.0 GX21: Algerian Mil, ALG 0553 USB MIL 188-141 2G-ALE terminate link with PY20 (13Oct16) (AAI)
05156.8 L: MX Beacon "L" St. Petersburg, RUS 0500 CW id "._.. (12Oct16) (AAI)
05162.5 KA5: Polish Mil, POL 0605 USB MIL 188-141 2G-ALE calling KO8 (27Sep16) (AAI)
05200.0 ---: Unid 0713 USB Thales Systeme-3000 analog voice scrambler (13Oct16) (AAI)
05201.0 ---: Unid (OEHxx Austrian Red Cross?) 0657 USB (cf+1500HZ) PacTOR-IV ARQ system (24Sep16) (AAI)
05205.0 4VT1: Italian Mil, I 0715 USB/J3E voice comms with 8OWJ, PD84 (10Oct16) (AAI)
05210.0 MIR: prob. Roumenian Police, ROM 0722 USB MIL 188-141 2G-ALE calling BU4 (04Oct16) (AAI)
05210.0 SIB: prob. Roumenian Police, ROM 0704 USB MIL 188-141 2G-ALE calling BU4 (04Oct16) (AAI)
05230.0 ---: Unid 0700 USB Thales Systeme-3000 analog voice scrambler (05Oct16) (AAI)
05250.0 ---: Unid 0731 USB Sailor-2001 Analog scrambler (29Sep16) (AAI)
05258.0 S32: Moroccan Military, MRC 0604 USB MIL 188-141 2G-ALE sounding (05Oct16) (AAI)
05270.0 IDR: Italian Navy S.Rosa Rome, I 0700 J3E/USB radio-check with Bussola, Orale, Filone then QSY daylight frequency (13Oct16) (AAI)
05298.0 K51: NPRD-Net, HRV 0559 USB MIL 188-141 2G-ALE sounding (07Oct16) (AAI)
05316.0 D20: Croatian NPRD Dubrovnik, HRV 0800 USB MIL 188-141 2G-ALE sounding (29Sep16) (AAI)
05326.0 ---: Unid 0726 USB Thales Systeme-3000 Skymaster ALE handshake flwd + TRC-177x modem (05Oct16) (AAI)
05334.0 035: Hungarian Mil, HNG 0707 USB MIL 188-141 2G-ALE handshake 082 flwd by voice scrambler (29Sep16) (AAI)
05340.0 NAU: US Navy Isabela, PTR 0542 (cf) FSK 75Bd/850 STANAG-4481 modem (05Oct16) (AAI)
05371.5 IW3IPM: Global ALE HFnet 0806 USB MIL 188-141 2G-ALE sounding (15Oct16) (AAI)
05387.0 5B: Bosnia Herzegovina Defense, BIH 0634 USB MIL 188-141 2G-ALE calling 1PB (26Sep16) (AAI)
05387.0 5B: Bosnia Herzegovina Defense, BIH 0636 USB MIL 188-141 2G-ALE calling 2PB (26Sep16) (AAI)
05387.0 5B: Bosnia Herzegovina Defense, BIH 0642 USB MIL 188-141 2G-ALE calling AB (26Sep16) (AAI)
05401.0 KRAKOW: Polish MSWiA Krakow, POL 0605 USB MIL 188-141 2G-ALE calling WARSZAWA2 (03Oct16) (AAI)
05401.0 POZNAN: Polish MSWiA Poznan, POL 0605 USB MIL 188-141 2G-ALE calling WARSZAWA2 (03Oct16) (AAI)
05417.0 PC: Italian Mil, I 0537 J3E/USB calling AP, PS, Caronte, Cerbero (12Oct16) (AAI)
05418.0 4050: Sonatrach, ALG 0554 USB MIL 188-141 2G-ALE sounding (12Oct16) (AAI)
05418.0 4050: Sonatrach, ALG 0557 USB MIL 188-141 2G-ALE sounding (07Oct16) (AAI)
05418.0 4204: Sonatrach, ALG 0536 USB MIL 188-141 2G-ALE sounding (05Oct16) (AAI)
05420.0 SP01: Unid 0658 USB MIL 188-141 2G-ALE calling BZ01 (06Oct16) (AAI)
05424.0 5B: Bosnia Herzegovina Defense 5th Infantry Brigade Tuzla, BIH 0650 USB MIL 188-141 2G-ALE calling 1PC (06Oct16) (AAI)
05424.0 5B: Bosnia Herzegovina Defense 5th Infantry Brigade Tuzla, BIH 0703 USB MIL 188-141 2G-ALE handshake 3PB flwd MIL 188-110A transporting STANAG-5066 TNEF formatted e-mail (13Oct16) (AAI)
05424.0 5B: Bosnia Herzegovina Defense 5th Infantry Brigade Tuzla, BIH 0715 USB MIL 188-141 2G-ALE handshake 2PB flwd by MIL 188-110A transporting FED-1052 data (05Oct16) (AAI)
05424.0 5B: Bosnia Herzegovina Defense 5th Infantry Brigade Tuzla, BIH 0721 USB MIL 188-141 2G-ALE handshake 3PB flwd by MIL 188-110A transporting FED-1052 data (05Oct16) (AAI)
05424.0 5B: Bosnia Herzegovina Defense 5th Infantry Brigade Tuzla, BIH 0729 USB MIL 188-141 2G-ALE handshake AB flwd by MIL 188-110A transporting FED-1052 data (05Oct16) (AAI)
05424.0 5B: Bosnia Herzegovina Defense, BIH 0752 USB MIL 188-141 2G-ALE calling 3PB flwd by MIL 188-110A transporting FED-1052 App.B data (27Sep16) (AAI)
05424.0 5B: Bosnia Herzegovina Defense, BIH 0754 USB MIL 188-141 2G-ALE calling 2PB (27Sep16) (AAI)
05435.5 OEY20: Austian Army, AUT 0552 USB MIL 188-141 2G-ALE calling OEY61 (12Oct16) (AAI)
05441.5 ---: Unid 0610 USB Thales Systeme-3000 Skymaster ALE, then on 5327.5, 5303.5, 5298.0, 5274.5 (05Oct16) (AAI)
05457.0 PL1: Polish Mil, POL 0610 USB MIL 188-141 2G-ALE calling WO8 (14Oct16) (AAI)
05457.0 PR7: Polish Mil, POL 0611 USB MIL 188-141 2G-ALE calling WO8 (14Oct16) (AAI)
05473.5 ---: Unid 0721 USB STANAG-4197 ANDVT modem (29Sep16) (AAI)
05645.0 ---: Italian fisherboats 0640 J3E/USB simplex chats (13Oct16) (AAI)
05684.0 JNRNPR: USAF-NIPRnet Salinas, PTR 0522 USB MIL 188-141 2G-ALE sounding (12Oct16) (AAI)
05723.0 MC1: Slovakian Mil, SVK 0631 USB MIL 188-141 2G-ALE handshake SL2 flwd by voice comms (07Oct16) (AAI)
05732.0 ---: (no call) 0525 USB MIL 188-141 2G-ALE calling Unid 005 (12Oct16) (AAI)
05732.0 RPK: USCG Buoy Tender Elm, US 0507 USB MIL 188-141 2G-ALE sounding (07Oct16) (AAI)
05741.5 ---: Unid 0825 Thales Robust Mode MFSK-8 125Bd (11Oct16) (AAI)
05748.6 KWA37: US Dept. of State station 0703 USB MIL 188-141 2G-ALE calling KWT93 (22Sep16) (AAI)
05748.6 KWA98: US Dept. of State station 0745 USB MIL 188-141 2G-ALE calling KWT93 (22Sep16) (AAI)
05748.6 KWT94: US Dept. of State station 0701 USB MIL 188-141 2G-ALE sounding (27Sep16) (AAI)
05769.0 OP00: Austrian Mil, AUT 0510 USB MIL 188-141 2G-ALE handshake OG00 flwd by MIL 188-110 App.B (06Oct16) (AAI)
05769.0 OP00: Austrian Mil, AUT 0510 USB MIL 188-141 2G-ALE handshake OY00, no traffic (06Oct16) (AAI)
05785.0 MAZZARELLA: GdF patrol boat, I 0639 USB MIL 188-141 2G-ALE calling VIBOVALENTIA (22Sep16) (AAI)
05792.0 2401: Moroccan Civil Protection, MRC 0548 USB MIL 188-141 2G-ALE sounding (07Oct16) (AAI)
05801.0 ---: Unid 0613 USB (cf + 1600Hz) Siemens CHX200 F1-modem (CHP-200)FSK 249Bd & 250Bd (11Oct16) (AAI)
05801.0 ---: Unid 0628 USB (cf + 1500Hz) Siemens CHX200 F1-modem (CHP-200)FSK 249Bd & 250Bd (06Oct16) (AAI)
05818.0 HBLZDRD1: Roumanian Mil, ROU 0713 SB MIL 188-141 2G-ALE calling HFJCDRD1 (14Oct16) (AAI)
05824.0 HBM46: Swiss Military, SUI 0725 VFT-TMS430 2 x 100Bd/180 (channels cf at -500, +500Hz) (29Sep16) (AAI)
05825.0 ---: Ukraine Mil, UKR 0642 USB MFSK-4 (double FSK) 96Bd 500Hz,(tones at -750, -250, +250, +750) (14Oct16) (AAI)
05847.5 CHFEDR: Greek Air Force, GRC 0701 USB MIL 188-141 2G-ALE sounding (11Oct16) (AAI)
05879.0 PY30: Algerian Mil, ALG 0803 USB MIL 188-141 2G-ALE handshake RK30 (29Sep16) (AAI)
05885.0 035: Hungarian Mil, HNG 0650 USB MIL 188-141 2G-ALE handshake 082 flwd by voice scrambler (13Oct16) (AAI)
05892.0 ---: Unid (Mexican Navy ?) 0758 USB TADIRAN proprietary AutoCall MFSK-4 125Bd 300Hz waveform (06Oct16) (AAI)
05900.0 SU5: Polish Mil, POL 0736 USB MIL 188-141 2G-ALE calling HU1 (26Sep16) (AAI)

12 October 2016


signal heard on 5892.0 KHz/USB, 0758 UTC, most likely from Austrian Military. AutoCall is a proprietary ALE waveform by Israeli Elbit Systems "TADIRAN" communication system. AutoCall delivers faster and more reliable link establishment and is recommended when greater tactical efficiency is critical; AutoCall is used eg in TADIRAN HF-6000 radio system. HF-6000 system is also sold by Telefunken Racoms.
model VRC-6020 (20 W)
Some characteristic elements of the signal can be observed from the sonogram:
  • the 1000-Hz tuning/sync beep which preceeds all transmissions;
  • the proprietary MFSK-4 Autocall system's tones centered at 2850 Hz, serving a variety of linking and communication functions;
  • the four tones located at 2400, 2700, 3000 and 3300 Hz

Manipulation speed is 125 symbols/sec and the step between two tones is 300Hz. 

6 October 2016

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.

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.

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.

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.

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:


FORDHFMREZA   ? (prob. *


note that when alphabetically sorted they use odd numbers in the 4th byte of the 5066 address.

According to Harris terminology, one radio (with its own name, ALE/1052 address(es) and 5066 address) belong to one station (with its own station name and e-mail address) and one or more stations belong to one e-mail domain: so each station has one unique e-mail address even if the associated radio has two or more 188-141A/1052 addresses. 

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. Anyway, figure 6 show also that each node is at 1-hop distance (DP and NP values).

fig. 6
I tried to replicate (part of) the HFMREZA star network according the above assumptions (ie 1-hop distance nodes and no cross links): results are shown in fig. 7.

fig. 7
Each station has the other stations in the router table and the final and next values are identical. There are no alternate routes, so there is only a single direct path (1 hop) as seen in fig. 6. I also simulated the transmission of  a test e-mail to wmtuser@fiat.ok using Microsoft Outlook Express as e-mail client: the outgoing message is accepted and placed in TX queue (fig .8).

fig. 8
Unfortunately I do not own Harris modems (the "Asset" column is empty) to simulate the transmission and hence get baseband signals for further analysis and comparisons.

(to be continued)