A 142-byte Data Link Protocol with fragmentation support

The signal captures used for this post were recorded a few days ago on 6369.0 kHz (USB) and kindly provided by my friend Kosmod; below is my analysis, which took inspiration from some observations just shared by Kosmod.

Notes:
* the following analysis remains provisional and subject to further revision;
* field designations are my own and are used for clarity and convenience of presentation;
* unless otherwise specified, all values enclosed in square brackets are in hexadecimal format.

HF Waveform Analysis
Despite the spectral appearance of the signals (Figure 1), the transmissions do not appear to be ARQ-based, as no return acknowledgments (ACKs) were observed in the demodulated bitstreams. This is further supported by the consistent fading profiles observed, which indicate that both short and long bursts likely share the same transmission path and originate from the same station. It is likely that this is a strictly unidirectional protocol. Physical layer employes MS-110A waveform, captures include various data rates (300, 600, 1200, and 2400 bps), all employing a Short Interleaver. 

Fig. 1 - part of 6369.0 KHz recordings

MS-110A demodulation of the bursts clearly indicates the use of the 8N1 asynchronous format, as shown in Figure 2.

Fig. 2 - 8N1 framing format in a demodulated bitstream

Protocol Headers Analysis
Following the removal of start/stop bits, the bitstreams are characterized by fixed-length frames with a 9-byte headers, all beginning with the same 16-bit ynchronization (SYNC) word 0xD000, likely with the least significant bit (LSB) transmitted first. Based on the observed bitstreams, byte following the SYNC (i.e., the 3rd byte) is interpreted as a Length Field for a total frame size of 142 bytes: the value 0x8C (140 decimal) representing the remaining payload (142 total bytes minus the 2 initial SYNC bytes). The reduced values in this byte, e.g. 0x6A, 0x68, 0x81, indicate a fragmented payload, typically occurring when the transmitted data does not fully occupy a standard "block". In these cases, the length field allows the receiver to correctly identify the end of valid data and ignore any subsequent padding.

Header alignment is achieved by locking the bitstream to the SYNC sequence and a 142 bytes (1136 bits) frame length, as illustrated by the HEX dumps in Figures 3a and 3b.

Fig. 3a - HEX dump of demodulated bitstreams

Fig. 3b - HEX dump of demodulated bitstreams

Note that, following the 9-byte header, the initial packet (index 0x00), and occasionally subsequent ones, begin with the fixed sequence [00 AA 79 50 D1 00 00 E9 00], which likely represents static payload values or a secondary synchronization pattern.

The proposed frame header structure is shown in the following Table I; it details the byte-level organization of the headers, assuming a Little-endian (LSB first) convention for multi-byte fields:

Table I - proposed frame header structure

The protocol utilizes a nested counting structure. Byte 5 functions as a Logical Block index, while Byte 4 acts as a Fragment index. Notably, every time Byte 5 increments, Byte 4 resets to its base value 0xD1. This behavior confirms that Byte 4 is not a global counter, but a local sequence identifier used to order individual fragments within each specific logical block.
The analysis of the Fragment ID field (Byte 4) suggests that the counter is limited to the lower nibble. The constant high-nibble value of 0xD (1101​) likely serves as a system flag, while the lower nibble provides the effective fragment index (0000 - 1111). This bitfield bifurcation explains why the byte appears to start at 0xD1 rather than 0x01. The lower-nibble implementation constrains the fragment index to a maximum value of 0xF​ (15 decimal).
The reset interval for the Logical Block index (e.g., per session, per 24-hour cycle, or per transmission burst) remains to be determined pending further signal acquisition.

SAR (Segmentation and Reassembly) Analysis
To ascertain the field functions and the underlying fragmentation hierarchy, an assessment of the headers from multiple consecutive bursts is required (see Figure 4). 

Fig. 4 - HEX dumps of multiple consecutive bursts for block 0x74

Burst #1
[D0 00 8C D1 74 04 00 00 00]
[D0 00 8C D1 74 04 00 01 00]
[D0 00 8C D1 74 04 00 02 00]
[D0 00 81 D1 74 04 00 03 00]
Burst #2
[D0 00 0C D2 74 04 00 03 00]
Burst #3
[D0 00 0D D3 74 04 00 04 00]
Burst #4
[D0 00 0D D4 74 04 00 04 00]
[D0 00 0D D4 74 04 00 04 00] 

 1    2   3    4   5   6  7   8   9 <----- bytes 

a) It is highly probable that the 0xD0 byte within the synchronization word serves a dual purpose: providing physical layer alignment while simultaneously acting as a Start-of-Frame (SoF) marker for the first fragment. Under this model, the 0xD0 marker initiates the block transmission, with all subsequent fragments identified by the sequence in Byte 04 (0xD1,0xD2,0xD3, etc.).

b)The block size field (bytes 6–7) utilizes a Little-Endian (LSB first) unsigned integer format. A value of 0x0400 indicates a 0-indexed count, confirming a total of five packets (00 through 04) within the sequence. 

c) The Packet Index field (bytes 8–9) also utilizes a Little-Endian (LSB first) unsigned integer format, indicating the relative position of the packet within the current logical block.

d) Evidence of cross-burst fragmentation is found in packet 0x03:
- Burst #1: packet 0x03 was captured with a truncated payload length of 0x81 (129 decimal);
- Burst #2: the remainder of packet 0x03 was transmitted with a payload size of 0x0C (12 decimal).

e) The aggregate length (129+12=141 bytes) slightly exceeds the standard 140-byte frame payload capacity. This discrepancy suggests that packet 0x03 was too large for a single transport frame and was intentionally fragmented across two consecutive physical bursts, indexed as fragment IDs 0xD1 and 0xD2 respectively.

f) The fact that packet 0x04 is so small, 0x0D bytes in bursts 3-4, compared to the others 0x8C bytes, is sent last and is spread across two different fragments (and bursts) suggests it is a trailer or checksum packet for the entire block.

Sumarizing:
Burst #1, Logical Block 0x74 Fragment ID 0xD1: occupied by packets 00, 01, 02, and the first part of 0x03
Burst #2, Logical Block 0x74 Fragment ID 0xD2: reserved exclusively to finish the "overflow" of packet 0x03
Burst #3 & #4, Logical Block 0x74 Fragment IDs 0xD3 & 0xD4: dedicated to packet 4

The relationship between the different layers of the protocol is shown in Figure 5 (elements are not to scale). The diagram shows the decomposition of logical block 0x74 into its constituent fragments (0xD1–0xD4) and the subsequent packets (00–04). Note the one-to-one mapping between logical fragments and physical bursts.

Fig. 5 - different layers of the protocol, the diagram is conceptual and not to scale

The diagram shown  in Figure 6 illustrates the SAR (Segmentation And Reassembly) process, i.e., the relationship between the physical burst transmission and the logical packet reassembly, highlighting cases of fragmentation and sequence continuity (all values are in Hex).

Fig. 6 - Segmentation And Reassembly process of block 0x74 (5 packets)

Consistent results are achieved through the analysis of other bursts, such as those associated with the transmission of block 0x76 (Figs. 7,8).

Fig. 7 - HEX dumps of multiple consecutive bursts for block 0x76

Fig. 8 - Segmentation And Reassembly process of block 0x76 (9 packets)

Conclusions
This is highly likely a (unid) proprietary protocol; unfortunately, at the time of writing, there are no available hypotheses regarding the transmitter site, nor the potential end-user. The protocol employs non-uniform fragmentation, where the payload size per burst is inconsistent; packet captures indicate potential truncation or the presence of trailing zero-fill sequences to maintain frame alignment. The architecture utilizes a 142-byte fixed frame with a 9-byte header to manage data encapsulation. The data stream is structured into logical blocks, mapped to individual packets, and transported via physical bursts, a process orchestrated by the Block ID ➔ Fragment ID ➔ Packet Index hierarchy.
However, based on the recordings at my disposal, the protocol does not always follow a strictly linear progression as the one shown by the diagram above. In some instances, the data flow incorporates non-linear repetitions or sequence adjustments, although the reassembly process itself does not change, e.g.:
- packet re-injection: high-index packets are interrupted by the re-insertion of earlier packets;
- fragment reversion: the sequence occasionally "rewinds" to repeat the final fragments of a previous packet before continuing with the current one.
These events can manifest either as a direct repetition of previously transmitted data or as a continuation of a previous packet's fragment sequence. 

Technical Comparisons and Alignment With Standards
- STANAG-4538 parallels: the architectural choices of this protocol, specifically the SAR mechanism and burst-oriented delivery, show significant functional parallels with the xDL protocols described by STANAG-4538. However, unlike the ARQ-based nature of xDL protocols, based on the captures at my disposal this protocol operates in a purely unidirectional mode, prioritizing redundancy over acknowledgments (1).
- STANAG-5066 & MS-110A correlation: the observed strategy also aligns closely with STANAG-5066 architectural principles. Similar to how STANAG-5066 segments data for transmission over MIL-STD-188-110A (MS-110A) modems, this protocol maps logical fragments directly to physical bursts. This is particularly evident in its configuration, where the absence of a return channel mirrors the high-reliability tactical stacks used in HF communications to ensure data persistence through noise (2).

Coming Up
While the proposed structure provides a good framework for understanding the protocol's behavior, additional captures are required to better define it. However, to avoid overcomplicating this discussion, detailed analyses of non-linear SAR and reassembled packets/blocks will be addressed in a forthcoming dedicated post.

As a side note, a special mention to Kosmod who is a great signals hunter... and a good provider :)

https://disk.yandex.com/d/TfhM9dfTb-ECww

(1) STANAG-4538 (3G), defined as an "all-in-one" monolithic protocol, integrates link setup (FLSU) and data transport (xDL) within a single ecosystem, utilizing its own proprietary waveforms specifically optimized for symbiotic operation between the modem and the data link layer.

(2) STANAG-5066 (2G) operates as a layered Data Link protocol. It serves as an interface between applications and the physical layer. Unlike STANAG-4538, it does not possess a dedicated waveform family; instead, it leverages standard external waveforms such as MIL-STD-188-110 (A/B/C/D) or STANAG-4539 to "feed" the underlying physical modem.

S-4481/S-4539 clear-text messages sent using RapidM modem (BRE1TA tests?)

The purpose of this post is to report test transmissions heard on 6963.0 kHz USB and logged during the first week of February by both Kosmod (who sent them to me for analysis) and ANgazu (whose signal was reported by KA0KA and published on the radiofrecuencias.es forum [1]). I don’t claim much credit in this post, other than confirming previous analyses and contributing further insights.
Transmissions continued for several days without interruption, almost entirely using the STANAG-4539 (MS-110B App.C) waveform. One of Kosmod’s recordings was particularly notable, as the STANAG-4539 signal was preceded by a STANAG-4481 transmission at 75 Bd/850 Hz (Figure 1). The mode switch lasted roughly 640 ms.

Fig. 1 - STANAG-4481/STANAG-4539 switch

According to STANAG-4539, each data frame contains a 256-symbol data block followed by a 31-symbol mini-probe of known data, for a total of 287 symbols per frame (119.57 ms @ 2400 symbols/s). Every 72 frames, a 72-symbol subset of the initial preamble is reinserted to aid late acquisition (1) (Figure 2).

Fig. 2 - STANAG-4539 framing

The data rate is 9600 bps, and the modulation used to achieve it is QAM-64. According to STANAG-4539, §4.2.2.1.6, “This [QAM-64] constellation is a variation on the standard 8 × 8 square constellation, which achieves a better peak-to-average ratio without sacrificing the very good pseudo-Gray code properties of the square constellation” (Figure 3).

Fig. 3 - STANAG-4539 constellations

In both cases (STANAG 4481 and STANAG 4539), the modulations are asynchronous and employ an 8N1 framing format, as shown in Figure 4.

Fig. 4 - STANAG-4481 and STANAG-4539 demodulated bitstreams

The transmitted messages are 8-bit ASCII clear text and consist of repeated instances of the same sentence, differing only in the message sequence number:
[binary header][message sequence number][text] 
The portions of the demodulated bitstreams presented below were obtained from two different recordings (header is omitted):

[STANAG-4481]
...
000013 Rapid Mobile HF & V/UHF Data Modem internally generated test message.
000014 Rapid Mobile HF & V/UHF Data Modem internally generated test message.
000015 Rapid Mobile HF & V/UHF Data Modem internally generated test message.
000016 Rapid Mobile HF & V/UHF Data Modem internally generated test message.
...

[STANAG-4539]
...
004820 Rapid Mobile HF & V/UHF Data Modem internally generated test message.
004821 Rapid Mobile HF & V/UHF Data Modem internally generated test message.
004822 Rapid Mobile HF & V/UHF Data Modem internally generated test message.
...

The message sequence numbering is likely continuous across the transition from STANAG-4481 to STANAG-4539 (Figure 2); however, this assessment cannot be confirmed due to unreliable demodulation of the initial segment of STANAG-4539.

Despite the modem-generated test traffic, the end-to-end efficiency η from payload to physical layer transmission can be evaluated for this STANAG-4539 waveform. As shown, the 9600 bps input uses asynchronous framing with 1 start bit and 1 stop bit, meaning each byte is transmitted as 10 bits of which only 8 carry payload; the symbol rate of 2400 Bd employing QAM-64 modulation (6 bits per symbol) results in a gross channel bit rate of 14400 bps. So:

- net useful payload = 9600 × (8/10) = 7680 bps
- transport efficiency relative to 14400 bps rate:
η = 7680/14400 ≈ 0.533  i.e., an effective efficiency of approximately 53.3%

overhead breakdown:
20% from serial framing (start/stop bits)
~26.7% due to physical-layer mechanisms such as FEC, preambles, and synchronization (S-4539) (2)

It's evident that a RapidM (Rapid Mobile) modem is being used that is capable of producing its own test traffic without needing an external server or another device to send data. This feature is often known as loopback testing, built-in test signal generation, or self-test mode.
Unfortunately, there is no publicly documented statement that a specific RapidM modem model generates its own test message, manufacturers often keep detailed test features in restricted datasheets. However, RM2, RM5, RM8, and RM10 RapidM modems all support STANAG -4539 and STANAG- 4481. RM2/RM5 are narrowband tactical modems (up to 9600  bps) with built-in test/loopback capabilities. RM8 is a strategic/naval narrowband modem supporting 9600–19200  bps and 2G/3G ALE, also capable of self-generated test traffic. RM10 adds wideband HF (3–24 kHz) while retaining narrowband 4539/4481 support [2].

Regarding the transmitting antenna’s location, both Kosmod and ANgazu performed direction finding using the TDoA (Time Difference of Arrival) algorithm, and both results pointed to an area near Casteau-Mons in Belgium, very close to NATO’s SHAPE headquarters (3)[3].

Fig. 5 - Direction Finding results

Direction Finding results may further substantiate ANgazu’s hypothesis that the signals could represent test transmissions associated with the NATO BRE1TA (BRASS Enhancement 1 Technical Architecture) program. BRE1TA constitutes a major architectural evolution of the NATO BRASS (Broadcast and Ship-to-Shore) HF communications system, designed to integrate advanced narrowband and wideband HF waveforms, higher spectral efficiency, improved link robustness, and IP-based data services. 

Several hours of monitoring on 6063 kHz USB over the past few days yielded only occasional short STANAG-4285 300 bps long-interleaver transmissions encrypted with KG-84. Reception was further limited by sporadic fading during the morning sessions.

https://disk.yandex.com/d/CXaz6URgUh-3zg

(1) In Change Notice 1 of MIL-STD-110C (January 2012), the United States Department of Defense removed a sentence stating that a “reinserted preamble facilitates acquisition (or re-acquisition) of an ongoing broadcast transmission.”  The reason was that the sentence referred to a feature that had become obsolete. Keeping it in the standard could have caused confusion by implying support for a legacy broadcast capability that was no longer part of the modem design. 

2) The relationship between the nominal user data rate of 9600 bit/s and the over-the-air symbol rate of 2400 baud for the STANAG-4539 QAM-64 waveform is as follows:
- the waveform employs a symbol rate of 2400 symbols per second with 64-QAM modulation, corresponding to 6 bits per symbol. This results in a gross channel bit rate of 14400 bit/s;
- the application of forward error correction (FEC) with coding rate R = 3/4 to a user data rate of 9600 bit/s produces a coded bit rate of 12800 bit/s;
- the remaining capacity of 1600 bit/s (14400-12800), representing the difference between the gross channel bit rate and the coded bit rate, is allocated to waveform overhead. This overhead includes, but is not limited to, miniprobes and periodic preamble reinsertion required to support synchronization and channel estimation functions. 

Figure below shows an example; the 1-second interval is chosen for ease of presentation.

over-the-air symbols/bits in a 1 second interval (STANAG-4539)

(3) The Supreme Headquarters Allied Powers Europe (SHAPE) is the headquarters of NATO's Allied Operations Command (ACO), located in Casteau, near Mons, Belgium. It is responsible for the planning and execution of all NATO military operations worldwide.

[1] https://www.radiofrecuencias.es/viewtopic.php?p=12527#p12527
[2] https://www.rapidm.com/
[3] https://shape.nato.int/

Citadel II 96-bit Initialization Vectors, an interesting update

A great thanks to my friend Kosmod who breakdown a Citadel II encrypted bitstream and saw that the Initialization Vector (IV) composed of 96 bits, 3 times repeated, is followed by a 64-bit field, this one also 3 times repeated. The problem is that the periodicity of the two "patterns" is different, so once the start/sync sequence is removed, it is necessary to set the bitstream period to 96 bits, remove the three IV sequences and then set the bitstream period to 64 bits (as shown in Figure 1).

Fig. 1

A question arises: could it be a 20 bytes/160 bits Initialization Vector composed of two 96 and 64 bits parts, each part 3 times repeated? Well, I think no.

It must be said that a 160-bit IV sequence is unusual, athough double-checked in other bitstreams. That length would be suspicious because most block-cipher sizes are powers of two or use multiples of 32 (32, 64, 96, 128, 256, 512) and since the IV typically matches the cipher’s internal structure or counter construction, a 160-bit length is not impossible but it would be atypical enough that cryptographers would immediately suspect parsing error or mixed fields.

Indeed, some systems prepend metadata or combine nonce + counter (1) and what looks like a single IV may actually be multiple fields, each repeated for robustness; in this case:
-  a 96-bit nonce, likely serving as the true Initialization Vector (2)
- a 64-bit nonce, likely a per-frame synchronization value or session diversifier. In other words: it's something that changes per transmission, maybe the 96-bit IV alone not being the entire initializer.
Because both fields are variable and precede the ciphertext, they could easily be mistaken as a single composite IV.

So, speaking about Citadel II,  why does the 64-bit sequence appear only with the 96-bit IV and not with the 256-bit one?

Fig. 2 - 32 bytes/256 bits IV

It likely comes down to how modern encryption systems structure their nonces. When a shorter 96-bit IV is used, a separate 64-bit counter or sequence field may be transmitted alongside it to guarantee that every message remains unique. With a 256-bit IV, that sequencing data is probably embedded inside the larger nonce itself — so the counter is still present, just no longer visible as a distinct field.  In short: we are not seeing different security levels, but two design approaches:

96-bit IV + external sequencer,
256-bit IV with internal sequencer.

The “missing” 64-bit field (or another length) is most likely hidden inside the larger initialization structure rather than removed.

(1) In cryptography, a “nonce” (short for number used once) is a value that is unique for each encryption operation – it should never repeat with the same key, usually not secret – it can be transmitted openly and used to make encryption different each time – even if  the same plaintext is encrypted with the same key, a different nonce produces a different ciphertext.

(2) A 96-bit IV is mainly used in AES-GCM, AES-CCM, and ChaCha20-Poly1305, where it strikes a balance between security (avoiding collisions) and computational efficiency. 

MEROD FSK 100Bd/600 (Indian BSF)

FSK 100Bd/600 signal (thanks to KarapuZ)

A few days ago my friend KarapuZ posted an interesting recording of a 100Bd/600 FSK signal which turned out to be a message structured according to MEROD-IND (Message Entry Read Out Device, Indian variant) message-handling principles, probably the MEROD MA4450 device [1]. MEROD  is the commercial name for the Racal manufactured equipment that uses the RACAL-ARQ mode.

Fig. 1 - main FSK parameters

MEROD-IND provided a simplified framework for organizing message elements such as originator, routing, and date-time group, supporting clarity and orderly handling under operational conditions.
While MEROD-IND is primarily associated with voice procedure mnemonics, its application in this context functioned as a content-structuring aid, with the actual transmission conducted as HF data. From a doctrinal perspective, such a transmission aligns functionally with ACP-125/ACP-131 data communication concepts, though it would normally be described using formal ACP message formats rather than the MEROD-IND designation.
The demodulated bitstream is shown in Figure 2.

Fig. 2 - demodulated bitstream

It's interesting to note that the first two 64-bit sequences are identical except for one bit, perhaps a reception error. This suggests a deliberately repeated sequence:
6D C5 F7 E0 B2 89 88 17
6D C5 F7 E0 F2 89 88 17
A confirmation comes from reading the characteristics of the MEROD MA4450 device [1], literally " [...] preamble of 64 bits used for detection and synchronization. Two sequences can be recognised on receive: one for secure messages and the other for clear messages. Sufficient redundancy is incorporated to achieve 98% probability of recognition of either sequence".

The message sent is in clear text and can be decoded by BEE, so the above 64-bit sequence refers to unencrypted messages.

OK TKS NR
DE NB SIG SRL NO 210004
RRR ZEQ APA
RRR DTO 211600
FROM FTR HQ BSF NB
TO CT WING N DELHI/SDGHE/W)/HZB/IND/TKP/ALL FTR
GR 20 BT
RESTD NO C/7101
FOR COMN. FOR AND FROM ADSO/CCT OPR.
HF COMMERCIAL REPORT UPTO 211600 HRS. FOR INFO PSE // BT
THI
CFN NO C/7101
SD B KR

It's clearly a plain-language military signal, just formatted in classic signal style, administrative/communications report. Indian origin (IND, Delhi, BSF strongly point to this). Indeed, the Border Security Force (BSF) is a central armed police force in India, under the Ministry of Home Affairs. It is responsible for guarding India's borders with Pakistan and Bangladesh. 

Line-by-line decode:

Header / routing
OK TKS NR
DE NB SIG SRL NO 210004
OK TKS – acknowledgment / thanks (common signal shorthand)
NR – Number
DE – “From”
NB SIG – NB Signals unit
SRL NO 210004 – Serial number of the message

Acknowledgments
RRR ZEQ APA
RRR DTO 211600
RRR – “Received, received, received” (strong confirmation)
ZEQ / APA – internal routing or reference codes
DTO 211600 – Date-Time Of message (21st at 1600 hrs)

Sender / recipient
FROM FTR HQ BSF NB
TO CT WING N DELHI/SDGHE/W)/HZB/IND/TKP/ALL FTR
FROM:
Frontier Headquarters, BSF NB
(BSF = Border Security Force)
TO:
Central Wing, New Delhi
SDGHE (signals directorate / HQ element)
HZB / IND / TKP (likely unit or regional designators)
ALL FTR – all frontiers
This is a broadcast-style admin signal.

Body
GR 20 BT
RESTD NO C/7101
GR 20 – Group count (20 word groups)
BT – Break (end of header, start of message)
RESTD – Restricted
NO C/7101 – Reference number

Actual message content
FOR COMN. FOR AND FROM ADSO/CCT OPR.
HF COMMERCIAL REPORT UPTO 211600 HRS.
FOR INFO PSE // BT
Plain English:
For information regarding communications for and from ADSO / CCT operations.
HF commercial report up to 211600 hours.
For information please.

End / authentication
THI
CFN NO C/7101
SD B KR
THI – End of text (Indian signals usage)
CFN – Confirmation
SD – Signed
B KR – Initials of the duty signal officer

So what does it mean? In normal language: “Frontier HQ BSF is informing all formations and central HQ about the status of HF commercial communications up to 1600 hours on the 21st, for operational coordination. This is a restricted administrative signal.”

Below a quite complete abbreviation map about the Indian Signals (CAPF doctrine) (1)

PROCEDURAL SIGNALS (PROSIGs)
OK:
Meaning: Message understood / acknowledged
Type: Informal procedural
Usage: Common in Indian HF nets
TKS
Meaning: Thanks
Type: Informal procedural
RRR
Meaning: Received, Received, Received
Doctrine: ITU / military standard
Usage: Strong confirmation of receipt
BT
Meaning: Break
Doctrine: ITU prosign
Usage: Separates header from text / clauses
DE
Meaning: From
Doctrine: ITU prosign

MESSAGE IDENTIFIERS
NR
Meaning: Number
Usage: Message or signal number
SRL NO
Meaning: Serial Number
Doctrine: Indian Signals standard
GR
Meaning: Group count
Usage: Number of word groups in body

DATE / TIME
DTO
Meaning: Date Time Origin
Doctrine: Military standard (Indian & NATO usage)
Format: DDHHMM (local or Z as context dictates)
HRS
Meaning: Hours
Usage: Indian military style (vs “hrs” in NATO)

SECURITY / CLASSIFICATION
RESTD
Meaning: Restricted
Doctrine: Indian security classification
Levels (India):
Top Secret
Secret
Confidential
Restricted

ORGANIZATIONS / FORMATIONS
BSF
Meaning: Border Security Force
Type: CAPF under MHA
FTR
Meaning: Frontier
Usage: BSF regional command (equivalent to Army Corps-area)
HQ
Meaning: Headquarters
SIG
Meaning: Signals
Context: Signals unit / communications staff
NB
Meaning: Likely North Bengal
Usage: BSF Frontier designation

ADDRESS / ROUTING TERMS
TO
Meaning: Addressee
CT WING
Meaning: Central Wing
Context: BSF / CAPF HQ directorate
DELHI
Meaning: New Delhi (HQ location)
ALL FTR
Meaning: All Frontiers
Usage: Broadcast instruction

OPERATIONS / STAFF FUNCTIONS
COMN
Meaning: Communications
Doctrine: Indian spelling (COMN vs COMM)
OPR
Meaning: Operations
ADSO
Meaning: Assistant Director (Signals / Special Operations)
Context: CAPF / HQ staff appointment
CCT
Meaning: Command & Control Team
(sometimes “Counter-Communication Team” depending on unit)

REFERENCES / FILE NUMBERS
NO C/7101
Meaning: File / reference number
Doctrine: Indian HQ filing style
CFN
Meaning: Confirmation
Usage: Cross-reference to original file number

REPORTING / CONTENT
HF
Meaning: High Frequency
Usage: 3–30 MHz band
HF COMMERCIAL
Meaning: Civil / leased HF services
Context: Backup or contingency comms
REPORT UPTO
Meaning: Status report valid until stated time
FOR INFO PSE
Meaning: For information please
Usage: Indian service English

TERMINATION / AUTHENTICATION
THI
Meaning: This is the end of message
Doctrine: India-specific signal terminator
Equivalent: NATO “AR”
SD
Meaning: Signed
Usage: Precedes sender authentication
B KR
Meaning: Initials / callsign of duty signal officer
Doctrine: Indian Signals authentication practice

UNKNOWN / CONTEXTUAL CODES
ZEQ / APA
Meaning: Internal routing or acknowledgment codes
Usage: Network-specific, not globally standardized
Common in: Indian HF fixed networks
SDGHE / HZB / IND / TKP
Meaning: Likely:
Directorate codes
Geographic or functional routing
Network node identifiers
Status: Internal BSF / Signals net designators

https://disk.yandex.com/d/nx8YASlWvDZvIQ

[1] https://www.cryptomuseum.com/crypto/racal/ma4450/files/merod_ma4450.pdf

(1) CAPF = Central Armed Police Forces, under India’s Ministry of Home. How India’s military communication systems and Central Armed Police Forces are supposed to operate, communicate, and coordinate according to official principles.

UDP datagrams sent via STANAG-5066 (2)

For background read the previous post

I ended the previous post hoping to recover new transmissions to understand more about the used application-layer protocol, and somehow this happened: my friend Kosmod indeed kindly sent me several transmissions he recorded on 20779.5 KHz/USB. The recordings date back to the end of 2024 (November) and this allowed me to understand how - actually - there has been a sort of evolution/improvement of the application-layer protocol that sits above UDP and which is therefore responsible for the UDP payloads. 

2024 transmissions follow the same schema: initial MS-141A link setup between ALE address 101 (caller) and 102 (called), then MS-110A running at 300bps/L to trasnfer data in async 8N1 mode (Figure 1). 

Fig. 1 - async 8N1 MS-110A

After removing the start/stop bits, the resulting bistreams consist of Data Transfer Protocol Data Units (D_PDUs) of the STANAG-5066 protocol, as parsed by the S-5066 dissector (as for example in Figure 2). The results are as expected, namely:

* D_PDU (Data Transfer Protocol Data Units) type 7, NON-ARQ DATA (Non-ARQ data transfer)
* the last 3 digits of the STANAG-5066 Addresses correspond to the respective MS-141A ALE addresses used during link setup
* IP-type Client/Application, ie IP over HF ("Source and Destination Service Access Point" is 9)

Fig. 2 - analysis of a  STANAG-5066 frames

The same conclusions (ie expected results) can be drawn by examining IP packets with "wireshark" tool (an example is shown in Figure 3):

* source/destination (LAN) IP addresseses are 192.168.101.15 and 192.168.102.15 (note the digits 101 and 102)
* the IP packet transports User Datagram Protocol (UDP) messages which are addressed to the destination port 2753, the "de-spot" port

Practically, just as in the recordings analyzed in the previous post... but there is a very important difference compared to the 2025 recordings: here the length of the UDP payload is 32 bytes instead of 16! (double length).

Fig. 3 - analysis of an IP packet

Below I report the 32-byte payloads related to 10 consecutive transmissions: as you can easily see, these are repeated transmissions, probably due to missed or incorrect receptions:

0020010200035b88c0a8650f0000059f67487bb400010000c0a8660f000002b1

0020010200033eaac0a8650f000005a067487caa00010000c0a8660f000002b4
0020010200033eaac0a8650f000005a067487caa00010000c0a8660f000002b4

00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6

(2025 payload: 00100003060072c6c0a8650f00000cc3)

By isolating unique payloads you get:

0020010200035b88c0a8650f0000059f67487bb400010000c0a8660f000002b1
0020010200033eaac0a8650f000005a067487caa00010000c0a8660f000002b4
00200102000379e9c0a8650f000005a56748871e00010000c0a8660f000002b6

Then I tried a parsing of the first payload, results are interesting.

00 20 → 0x0020 = 32 (matches payload length!)
01 02 → likely protocol version or message type
00 03 → subtype / command / channel ID
5b 88 → 0x5B88 = 23432 (this value changes every payload, likely a sequence number, transaction ID, or session counter)
c0 a8 65 0f → 192.168.101.15 (source IP address!)
00 00 05 9f → 1439 (changes per payload: 1439, 1440, 1445)
67 48 7b b4 → 0x67487BB4 = 1732924340 that decodes cleanly as a Unix epoch timestamp! (seconds), other packets: 67487caa, 6748871e
00 01 → flag or command = 1, constant in all payloads
00 00 → Likely reserved or alignment padding
c0 a8 66 0f → 192.168.102.15 (destination IP address!)
00 00 02 b1 → 689 (changes slightly per payload: 689, 692, 694)

Given the fixed 32-byte control packet, embedded source/destination IPs, timestamps, repeated sends with identical content, in my opinion UDP port 2753 is here used as a rendezvous/control/signaling port. Moreover, I thinked of missed or incorrect receptions: this is suggested, other than by repeated transmissions, also by some text-mode op-chats also reported by Kosmod in his comment to the previous post; chats are in Italian language and, according to some UDXF logs, this is  likely a military attaché (1):

"MESSO IN CODA 5 EMAIL.....SPERO CHE TI ARRIVI ALMENO UNA AH AH AH" (I QUEUED 5 EMAILS.....I HOPE YOU GET AT LEAST ONE AH AH AH)
"RICEVUTO QUALCHE EMAIL? DUE SU 15... MI LASCIA PERPLESSO" (RECEIVED ANY EMAILS? TWO OUT OF 15... IT LEAVES ME PERPLEXED)

Well, let's work now on the “timestamp” field, bytes 16–19:

67 48 7b b4
67 48 7c aa
67 48 87 1e

Interpreted as big-endian:

0x67487BB4 Decimal: 1732803508 UTC time: 2024-11-28 14:18:28
0x67487CAA Decimal: 1732803754 UTC time: 2024-11-28 14:22:34
0x6748871E Decimal: 1732806430 UTC time: 2024-11-28 15:07:10 

Since the same timestamp is repeated across multiple transmissions, it doesn't reflect the sending time, but rather the message creation time. It's important to note that the timestamps correspond to the recording dates, except for the time (hours:minutes:seconds):

There is something wrong though, because the timestamp in the payloads CANNOT be later than the time of their reception! Since the Unix timestamp is timezone-agnostic, perhaps they parse dates in local time by default and then convert to timestamps (without making UTC explicit) or treat local datetime as if it were UTC then convert it to a Unix timestamp: this way you’ll get a timestamp that is shifted by your local offset. It would be a bug, but this way the hour differences would make sense. If my guess is correct, the transmitting station's country should be located in the UTC+2 time zone.

For the sake of completeness, I repeat below the analysis of the payloads recorded in December 2025 followed by a little comparison.

00 10 → Possibly a message type or some identifier (2 bytes). Hex 0x0010 = 16 decimal (the length of the message!)
00 03 → Another 2-byte field, could be message type or command. Hex 0x0003 = 3 decimal.
06 00 → Could represent a flags field, version, or sub-type. Hex 0x0600 = 1536 decimal.
72 C6 → Often a transaction ID, session ID, or another 2-byte value. Hex 0x72C6 = 29318 decimal.
C0 A8 65 0F → This looks exactly like an IPv4 address in hex: C0 A8 65 0F → 192.168.101.15 (source IP address!)
00 00 → Possibly padding, reserved, or a 2-byte zero field.
0C C3 → Could be a port, checksum, or some other 2-byte value. Hex 0x0CC3 = 3267 decimal.

Both payloads share the same core structure:
[ Header | Opcode | Flags | TxID | IP #1 | Value ]
that strongly suggests same protocol or same base message format. Note that the 2024 payloads had an extended basic message with  timestamp, status/flag fields, the destination IP address and an additional numeric value.

Other UDP payloads appear to carry DCE/RPC (Distributed Computing Environment/Remote Procedure Calls) protocol: these will likely be explored in a next post.

November 2024 recordings (thanks to Kosmod) were very important because, as I said, they highlighted an improvement/adaptation of the application-layer protocol; equally important will be new recordings of these transmissions made (hopefully) in the next days. 

https://disk.yandex.com/d/L4yj5a8xQNpqBA

(1) an armed forces officer assigned by governments to diplomatic missions abroad as a technical advisor on matters of military relevance.