Scope

Publication note: these notes are intentionally framed as passive classification and metadata analysis. Raw logs, raw databases, exact cell identifiers, exact RF values, raw bitstrings, and correlatable hashes should remain private.

This note summarizes a passive SDR analysis of a live TETRA downlink/control-channel style signal using a bladeRF 2.0 micro xA5 and a Diamond D3000N discone antenna. The objective was to understand what could be reconstructed from passive reception, with a specific focus on whether readable user content such as SDS text, application messages, packet payloads or voice could be observed.

The work intentionally focused on classification and metadata analysis. No attempt was made to decrypt protected traffic or recover third-party user content.

Hardware and capture chain

Known working receive path:

GRC / SDR source
  -> channelized/narrow TETRA IQ over UDP 127.0.0.1:7356
  -> simdemod3.py
  -> tetra-rx
  -> raw decoder log
  -> tetra_sqlite_mapper.py
  -> SQLite database

Working command pattern:

cd ~/sdr
source ~/.tetra_payload_key

mkdir -p ~/sdr/tetra_dumps
chmod 700 ~/sdr/tetra_dumps

CAPTURE_LABEL="tetra_type_hunt_$(date -u +%Y%m%dT%H%M%SZ)"
DB="${CAPTURE_LABEL}.sqlite"
LOG="tetra_raw_${CAPTURE_LABEL}.log"

echo "DB=$DB"
echo "LOG=$LOG"

socat -u -b 4096 UDP-RECV:7356 STDOUT \
  | python3 /usr/share/osmo-tetra/demod/simdemod3.py \
  | stdbuf -oL tetra-rx -d "$HOME/sdr/tetra_dumps" /dev/stdin 2>&1 \
  | tee "$LOG" \
  | stdbuf -oL ./tetra_sqlite_mapper.py \
      --db "$DB" \
      --label "$CAPTURE_LABEL" \
      --key-id "$TETRA_KEY_ID" \
      --store-bitstrings-encrypted

Important operational notes:

  • Use one SQLite DB per capture run. Appending continuously to one large DB makes analysis and backup slow.
  • tetra-rx must be given a dump directory with -d, otherwise it may try to write to (null)/traffic_...out and crash.
  • The GRC graph in this setup provides complex IQ to UDP; it does not demodulate bits. simdemod3.py performs the demodulation before tetra-rx.
  • Use stdbuf -oL so the pipeline is line-buffered and the mapper receives data in real time.

Observed cell and channel characteristics

Private/raw identifiers and exact RF values should be redacted for public publication. Internally observed values included:

Downlink frequency: observed in the 390 MHz TETRA range
Uplink frequency: observed with a 10 MHz duplex split
MCC/MNC: visible in sync/system context
Air encryption advertised: yes
Advanced link: yes
Normal mode: yes
SNDCP data support advertised: yes
Voice service advertised: yes

The important distinction is that SNDCP data: 1 and Voice service: 1 were seen as system information capability flags, not as decoded SNDCP packet payload or decoded voice content.

Main findings

1. The control channel is metadata-rich

The passive decoder reconstructed a significant amount of control-plane and network metadata, including:

- cell/system identity context
- system capability information
- sync and timing context
- access assignment activity
- broadcast/network-layer signalling
- clear RESOURCE signalling
- encrypted RESOURCE grant activity
- crypto-context signalling
- repeated grant templates
- hashed SSI-like references

This is a real metadata exposure, even without readable user content.

2. No readable user content was observed

Across the tested captures, no decoder output or SQLite classification showed readable private user content such as:

- SDS text
- SHORT DATA message body
- readable application message
- decoded SNDCP packet payload
- decoded voice/speech content
- readable user data

Searches for SDS, SHORT DATA, TEXT, MESSAGE, USER DATA, APPLICATION, APP, SNDCP, PACKET, VOICE, and SPEECH produced only known false positives or capability indicators:

SNDCP data: 1       -> system information capability flag
Voice service: 1    -> system information capability flag
without start packet -> decoder fragment/reassembly warning, not packet payload

Therefore the correct conclusion is:

No readable SDS text, application message, packet payload, or voice content was observed with the current passive decoder pipeline.

This is not the same as proving that no such data was ever transmitted. It means it was not observed or decoded by this passive pipeline.

3. TM-SDU/TL-SDU payloads were mostly broadcast/control templates

Large numbers of TM-SDU and TL-SDU containers were seen, for example:

tm_sdu_encoded_payload
network_layer_broadcast
clear_network_broadcast

Repeated raw_line_sha256 values showed that high-volume TM-SDU payloads were stable templates repeating over time. Context checks showed that top templates were adjacent to:

clear_network_broadcast
network_layer_broadcast
system_info

This strongly indicates a recurring broadcast/control carousel, not user messages.

4. Rare non-broadcast TM/TL-SDU candidates existed, but stayed encoded

After filtering the high-volume broadcast/system carousel, a small set of rare TM-SDU/TL-SDU candidates remained outside direct broadcast/system context.

They were classified as:

- clear resource-adjacent encoded TM/TL-SDU
- encrypted-resource-adjacent encoded TM/TL-SDU
- fragment/parser-residual TL-SDU

One high-interest example was a frame containing:

encrypted_resource_grant Encr=2 addr_kind=ssi
sch/f_frag
TM-SDU encoded payload
TL-SDU encoded payload
encrypted_resource_grant Encr=2 addr_kind=unknown
null_resource

This is a useful metadata finding: it shows protected/resource-adjacent encoded payload activity. It does not show readable user content.

5. Clear RESOURCE signalling was observed

Several clear RESOURCE Encr=0 addr_kind=ssi rows were observed in short structured bursts.

Examples of the pattern:

RESOURCE Encr=0 addr_kind=ssi slot_grant=6  l1_len=48  l2_len=5
RESOURCE Encr=0 addr_kind=ssi slot_grant=13 l1_len=100 l2_len=49
RESOURCE Encr=0 addr_kind=ssi slot_grant=29 l1_len=226 l2_len=175

Interpretation:

Clear SSI-addressed resource signalling with encoded payload/signalling material was observed.

This is sensitive operational signalling and should not be published raw. It is still not equivalent to decoded SDS/application/user content.

6. Encrypted RESOURCE grants were significant

The captures showed many encrypted grants:

encrypted_resource_grant Encr=2 addr_kind=ssi
encrypted_resource_grant Encr=2 addr_kind=unknown
encrypted_resource_grant Encr=2 addr_kind=event_label

Key interpretation:

Protected resource assignment activity is visible at metadata level: timing, grant type, grant template, address-kind where parsed, hashed SSI references and repeated unknown/implicit grant forms.

Payload content remained protected/encoded and was not decoded as readable user content.

Risk interpretation

Readable user-content exposure

Status: not observed / not demonstrated

No clear SDS text, application message, packet payload or voice content was decoded.

Metadata exposure

Status: confirmed
Risk: medium to high, depending on environment

The passive channel reveals cell/system information, service capabilities, timing, resource-grant activity and recurring address/hash patterns.

Clear encoded signalling exposure

Status: confirmed
Risk: medium

Clear Encr=0 resource messages and encoded resource-adjacent TM/TL-SDU material were observed. These are not human-readable but may contain operational protocol information.

Protected content exposure

Status: not readable with this passive pipeline
Risk: not demonstrated

Encrypted Encr=2 resource grants were visible, but payload recovery/decryption was not performed and no readable protected content was observed.

Parser coverage uncertainty

Status: open
Risk: medium

A better Layer-3 parser could classify more encoded signalling. However, the current evidence still shows no readable content indicators.

Final conclusion

The passive capture reconstructed a metadata-rich TETRA control channel with repeated broadcast/system signalling, clear resource-signalling structures and significant encrypted resource-grant activity.

No readable SDS text, application message, packet payload or voice content was observed. The remaining non-broadcast items were encoded resource-adjacent TM-SDU/TL-SDU candidates and clear/ encrypted RESOURCE signalling, not decoded user messages.

The security finding is therefore not “user content is readable.” The stronger and accurate finding is:

The control channel exposes operationally sensitive metadata and clear encoded signalling patterns, while user-content readability was not demonstrated.
  1. Keep using one DB per capture.
  2. Keep raw logs and DBs private; do not publish unredacted captures.
  3. Improve Layer-3 classification in a staged way.
  4. Use passive mode for live/public RF observations: classify only, no payload display.
  5. Use lab mode with --show-clear-payload only for authorized test captures.
  6. Validate the parser in a lab using known SDS/SNDCP/application test messages.
  7. Add a public-safe export mode that redacts exact frequency, MCC/MNC, hashes, frame references and raw payload material.