[read all the posts about this topic]
data block
Some interesting observations from the recent catches.
STANAG-5066 Addresses and "Magic Strings"
heard so far:
[006.046.000.zzz] block
HWK01 006.046.000.028, 006.046.000.102
ZMK002 006.046.000.037
OYO01 006.046.000.101 *
[006.046.001.zzz] block
FRJ 006.046.001.001 *
BYN21 006.046.001.006 *
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 006.046.001.034
HEH002 --"--
CAU 006.046.001.046
NZH21 006.046.001.052 *
VJL 006.046.001.054
ZAPCA
ZAPCG
ZAPCK
ZAPCH *
ZNTCH *
ZRTBC
ZRTBD
ZXPBC
ZXPBD
ZXPBG
ZXPCK
ZXPDA *
ZXPDK *
* new ones
[read all the posts about this topic]
data block
Adding the data blocks to form a single file show a repeated 33-byte length pattern which precedes the "magic string", probably a common heading to all the messages (Fig. 1). As well as for the "magic string", it's difficult to say the scope of these sequences: indeed, further analysis will focus on the data block trying to get some meaningful. Recordings, help and tips are welcome!
 |
| Fig. 1 |
Some interesting observations from the recent catches.
1. I had the chance to copy a transmission on 5206.3 KHz followed by an identical one on 5059.4 KHz after few seconds (Fig. 2). This is quite easy to accomplish since they use S-4538 FLSU for link setup, so the stations of the network are synched and scan the same pool of frequencies at same times. Repetitions increase the reliability of the system but do not know if it was just a planned episode or a routine scenario (more powerful monitoring tools would help...)
 |
| Fig.2 |
2. Usually transmissions are originated from nodes belonging to 006.046.000.zzz block (mostly HWK01) and directed to nodes of the 006.046.001.zzz block. This time I copied a trasmission inside the 006.046.001.zzz block (never copied so far), namely from BYN21 (006.046.001.006) to NZH21 (006.046.001.052).
As above: episode or a normal way to operate?
As above: episode or a normal way to operate?
 |
| Fig.3 |
3. Luckily I copied some transmissions probably just few minutes after the start of a new epoch time of the timestamp clock and thus with a timestamp exhibiting a length of 7, 8 and then 9 bytes (Fig. 4). This is a full automated system working in a FIFO logic, ie the messages are wrapped and forwarded in the same order they arrive (first came first served). As well as for the IDs, the wrapper does not use a fixed length for the timestamp: it simply catches the value, computes its length and arrange them in the form {<length>,<content>}. This clarifies why so far I found transmissions with 9 and 10 bytes lengths.
As already debated, the variable lengths of IDs and timestamp affect the length of the data block since it shall be computed to fit the max transmission unit of the protocol (2039 bytes).
As already debated, the variable lengths of IDs and timestamp affect the length of the data block since it shall be computed to fit the max transmission unit of the protocol (2039 bytes).
 |
| Fig.4 |
STANAG-5066 Addresses and "Magic Strings"
heard so far:
[006.046.000.zzz] block
HWK01 006.046.000.028, 006.046.000.102
ZMK002 006.046.000.037
OYO01 006.046.000.101 *
[006.046.001.zzz] block
FRJ 006.046.001.001 *
BYN21 006.046.001.006 *
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 006.046.001.034
HEH002 --"--
CAU 006.046.001.046
NZH21 006.046.001.052 *
VJL 006.046.001.054
ZAPCA
ZAPCG
ZAPCK
ZAPCH *
ZNTCH *
ZRTBC
ZRTBD
ZXPBC
ZXPBD
ZXPBG
ZXPCK
ZXPDA *
ZXPDK *
* new ones
[read all the posts about this topic]