20 March 2016

STANAG-4285 running in ASYNC mode

Although a bitstream analyzer recognizes physical or data-link layer protocols by matching known patterns and sequences, it isn't source-coding aware then  in order to get something that makes sense is important to know if we face a synchronous or asynchronous mode. For example, my friend AngazU sent me a STANAG-4285 transmission which transports a Citadel encrypted file: 75bps speed and long interleave are the settings for its right decoding into an ASCII-bits file.
Looking at the graphic representation of the stream it's possible identify something like the characteristic pattern of Citadel... but  it isn't: there are some bits more. The reason is that that STANAG-4285 was in asynchronous mode (or better in asynchronous operation) with 8N1 framing: eight data bits, no parity bit, one start bit and one stop bit and then each character will be transmitted using a total of 10 bits. This framing could be guessed looking at the period back from the analyzer: just ten bits (pic. 1).

Pic. 1
After removed both the start and the stop bits we get the clean 8-bit data and the Citadel pattern. It is worth nothing that processing the new stream, the analyzer easily detect the encryption (pic. 3).

Pic. 2
Pic. 3
The same issue may occur analyzing a Baudot (ITA-2) coded stream: five data bits, no parity bit, one start bit and two stop bit. The example is related to a STANAG-4285 transmission in clear text (no encryption and no re-protocolled) from French Navy FUG8. The bit analyzer correctly returns an 8-bit period and after removed the extra bits added by ITA-2 (1 bit start + 2 bits stop) we get the well-known text "VOYEZ VOUS LE BRICK..."

Pic. 4

Pic. 5
Then a big help comes from the period returned back from the analyzer: not always a stream is encrypted or looks not identifiable, sometimes it's only processed as synchronous when it's coded in async mode.

No comments:

Post a comment