As said in the previous post, in all the monitored transmissions the chosen 3G-HF service is the Circuit Mode, and 1200 bps MIL 188-110A is the used traffic waveform. Data are transferred by STANAG-5066 D_PDUs and both the RCOP (Reliable Connection Oriented Protocol) and UDOP (Unreliable Datagram Oriented Protocol) are used as basic end-to-end transport protocols, but so far the client protocol which run over S-5066 has not been yet identified. Me and my friend Johannes started to analyze these transmissions since several days and below are exposed the tentative results in order to get comments from out there, further posts will follow.
Figure 1 shows two bitstreams after MS-110A removal and after synced on 0xEB90 (S-5066 D_PDU synchronisation sequence): in this cases all the D_PDUs are of type 7 (non-ARQ delivery) and 0 (Simplex data transfer) and carry UDOP and RCOP protocol.
 |
| Fig. 1 |
It's interesting to note in Fig. 2 the initial same structures which are present in all the recordered copies, in both RCOP and UDOP data, after the removal of D_PDU encapsulation
 |
| Fig. 2 |
Let's have a look at ASCII rapresentations of a series of decoded transmissions (Fig. 3):
 |
| Fig. 3 |
Data are structured as a series of headers having the format {<length>,<content>}:
{5,HWK01}{3,PFY}{3,001}{3,001}{10,1570853327}{0}{143,...}{0}
{5,HWK01}{3,ZHO}{3,001}{3,001}{10,2096500086}{0}{625,...}{0}
{5,HWK01}{3,ZHO}{3,001}{3,001}{10,2097463403}{0}{937,...}{0}
...
...
A possible explanation could be:
{5,HWK01}{3,PFY}
source and destination IDs
{3,001}
number of the current data-block (see later)
{3,001}
total number of data-blocks (see later)
{10,1570853327}
most likely a timestamp (see later)
{0}
unknown. So far, never seen something different at this position, probably marks the start of a data block (SOF).
{143,data-block}
number of bytes followed by data.
{0}
unknown. So far, never seen something different at this position, probably marks the end of a data block (EOF).
The particular format of the headers {<length>,<content>} leads to think to a wrapper protocol that acts as a mediator/integrator between two systems (eg X.400 and ACP127 networks, although STANAG-4006 performs that task).
![]()
By the way,"The Sweidish Army uses C2 systems that are not interoperable and data must be manually transferred between them. Sweden began to integrate all the service's C2 systems, at all levels, in 2005 under the name SWECCIS. [...] Swedish Armed Forces HQ tasked FOA, FMV and FHS to propose a vision for a mobile military joint C2 system for 2010, this project has been expanded to include civilian C2 elements [...] the goal is a single C2 environment..."[1].
But it's only a supposition(!), although some clues come also from this picture [2]
But it's only a supposition(!), although some clues come also from this picture [2]
For what concerns the timestamp header, it seems related to the "wrapped" data file. By examining consecutive transmissions, the granularity is in milliseconds and the Epoch Time started on Sat May 13 2017 00:00 CEST (GMT +2): possibly the date on which this "service" came into production?
Looking at Figure 4, if the data-block length is greather than 1977 bytes then it is segmented into smaller blocks, each block consisting of the same {<length>,<content>} headers. In this case, the 'timestamp' header remains unchanged while the 'current data-block' header is updated. Note also that the data-blocks are not filled if their length is less than 1977 bytes.
 |
| Fig. 4 |
Protocol data are transferred in PDUs of 200 bytes length, and in case of UDOP the bitstream just exhibits a strong 1600-bit ACF. Well, looking at the hex rapresentation of an UDOP bitstream (Figs. 5a, 5b) we see that PDUs are sent twice, unless the last PDU and the first PDU of the successives 1977-byte blocks. This makes sense to improve the reliability, since the nature of UDOP protocol itself (it's a basic connection-less protocol) and the use of S-5066 non-ARQ service.
 |
| Fig. 5-a |
 |
| Fig. 5b |
A not clear point is the presence of the number 8008 in all the records (Fig. 6) just before the headers elements. Maybe a TCP/UDP port? if so, it's the HTTP alternate port (IANA).
 |
| Fig. 8 |
For what concerns the nature of the data-blocks, since the {<length>,<content>} headers are in plain-text, the encryption if any is performed upstream before this protocol.
A termed here "magic string", in the form ZLLLL (ie "Z" followed by 4 uppercase letters), appears in the first 40 bytes of the data-block and it is always preceeded by the 34-byte sequence 0x7E0862...61D5EE20 (Fig. 7). In case of a multi-blocks transfer the magic string is present only in the first block ( Fig. 4). So far, the seen values are: empty, ZXPBC, ZXPBD, ZRTBC, and ZRTBD. This is another unclear point and needs further observations.
 |
| Fig. 7 |
The data obtained after the removal of the headers do not exhibit particular structures or recognizable patterns, unless the firts 40 bytes followed by the magic string.
For what concerns the HF network, they have tens(!) of channels. Anyway, at least from a monitoring by Johannes, each channel is always used with the same RCOP/UDOP protocol.
So far, matching S-5066 addresses and src/dest headers we got:
So far, matching S-5066 addresses and src/dest headers we got:
[006.046.000.zzz] block
HWK01 006.046.000.028, 006.046.000.102
ZMK002 006.046.000.037
ZMK002 006.046.000.037
[006.046.001.zzz] block
DWY 006.046.001.009
PFY 006.046.001.010
ZHO 006.046.001.028
RJY 006.046.001.029
GZL 006.046.001.030
HEH,HEH002 006.046.001.34
CAU 006.046.001.046
PFY 006.046.001.010
ZHO 006.046.001.028
RJY 006.046.001.029
GZL 006.046.001.030
HEH,HEH002 006.046.001.34
CAU 006.046.001.046
In the vast majority of the cases (almost 99%) traffic is originated from 006.046.000.zzz block nodes (HWK01,ZMK002) to 006.046.001.zzz block nodes. Very few traffic in the reverse direction. Maybe 006.046.000.zzz block is assigned to the main (strategic?) nodes of the net?
Anyway, it's interesting to note that in some transmissions the same ID "HWK01" appear in both the src and dest blocks, although with different S-5066 addresses (anyway belonging to the same block 006.046.000.zzz):
 |
| Fig. 8 |
where:
{5,HWK01}{5,HWK01} have the S-5066 addresses 006.046.000.102 and 006.046.000.028
{5,HWK01}{5,HWK01} have the S-5066 addresses 006.046.000.102 and 006.046.000.028
Perhaps two possible reasons:
a) the ID HWK01 acts like a sort of ZIP-code or global-ID with different users/services, each with a distinct S-5066 Address
a) the ID HWK01 acts like a sort of ZIP-code or global-ID with different users/services, each with a distinct S-5066 Address
b) these are two physical instances. As shown in [2] they have separated Rx and Tx stations. Maybe this is a information transfer from one Tx to its corresponding Rx station which logically share the same ID.
Helps, comments and recordings are welcome!
(to be continued)
Links: