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