Category: Digital Signals

New TETRA Trunk Tracker for use with SDR# and the TETRA Demodulator Plugin

Over on our forums user thewraith2008 has just released news about his new software called TETRA Trunk Tracker. The software works in conjunction with the TETRA demodulator plugin for SDR#. It works by using two dongles, one to monitor a TETRA trunking channel, and the other to decode voice audio, although a single receiver mode is also available which works with a reduced and fixed bandwidth.

TETRA Trunk Tracker
TETRA Trunk Tracker

The post reads:

TETRA Trunk Tracker will follow calls on a TETRA network.

TETRA Trunk Tracker reads DATA that is output from the SDR# plug-in TETRA Demodulator (by TSSDR) via the 'Network Info' calls log window.

It interprets this DATA to determine when a call is set-up, then instructs SDR# (VC) to move to the carrier (frequency) that the call will be on.

It will also watch out for other PDUs to determine when a SSI starts or completes transmissions and when calls are complete (Released).

Features:

  • A basic call recording (All or Selective call recording).
  • Display current call details with list of seen SSIs for that call. (SSI populate as they TX).
  • GSSI holding - will only allow calls with selected GSSI to be heard.
  • Call lockout based on GSSI. Can be unchecked in list to lockout GSSI.
  • Call Priority. (Only normal version)
  • GSSI weighted 0-9, 9 is highest. If on active call and other call event occurs, if new call has higher
  • priority then will switch to it.
  • Collect/Save all seen GSSIs with Labels and Priority, By Network.
  • Collect/Save seen SSIs with Labels and Last seen Date/Time, By Network.
  • Set a call time-out. Returns to idle state if call does not see a release PDU
    after X time in seconds.
  • Log call events to screen and file, if enabled.
  • Log raw CC and VC PDU messages as seen by the 'TETRA Demodulator' plug-in, if enabled.
  • Log GSSI daily call activity. (Simple version does not play calls when this is selected)
  • Set base frequency via UI.
  • Set CC park carrier # via UI.
  • Set VC park carrier # via UI.
  • Suppress some PDUs. (unchecked is mainly for testing only)
  • Suppress lockout messages.
  • Sort SSI and GSSIs/Lockouts (by GSSI). This only occurs on start-up.
  • Country Code label, defined via file (shown as menu item)
  • Network label, defined via file (shown in tool tip where MNC,LA is in 'Call Details' panel)
  • Location Area label, defined via file (shown in tool tip where MNC,LA is in 'Call Details' panel)
    Only shown when Network label used.
  • Ignores Encrypted PDUs (with no reference to them)
  • Set a seen GSSI priority via UI.
  • Update a seen GSSI/SSI label via UI.
  • Call active indicator.
  • Restore SDR# windows to a defined position.

If the TETRA Demodulator does not work for you this program will do nothing to change that.

This is the third release of this program. (TETRA Trunk Tracker v0.99.6)
And 2nd release for (TETRA Trunk Tracker v0.99.6s - Simple)

Two versions are available:

  • Normal (Uses 2 SDR# and 2 Dongles) with TETRA Demodulator and Net Remote plug-ins
  • Simple (Uses 1 SDR# and 1 Dongles with some features not available) with TETRA Demodulator and Net Remote plug-ins

Backup your "Tetra-trunk-tracker.dat" settings file.
Then delete "Tetra-trunk-tracker.dat" as it has changed and old one will cause error on load.

Some work as gone into trying to make TETRA Trunk Tracker easier to run once the initial setup has been done.

A MCC (Country Code) label file is included for your convenience "TETRA_mcc.txt".

It has only been tested on Windows 7 - Professional SP1 (32 bit), English

You MUST have a PC that is capable of running SDR# x 2 with the TETRA plug-in. (Not overloaded CPU usage.)

It is in alpha stage. This means is may contain errors that may cause issues with the other programs it
works with. i.e. crashing them or itself.

The TETRA plug-in currently been developed by TSSDR is also in early development. Because of this
any changes made in plug-in releases most likely will break this program.

I have created it to suit my needs. And it currently works for me with the TETRA network I monitor.

I make no claim that it will work for other networks.

Please read the provided files for set-up and usage:

  • TTT_set-up_manual.pdf
  • TTT_Features_and_Usage.pdf

I have tried to be as thorough as possible with the documentation to explain usage and features.
I believe any questions can be answered by reading these files.
These files most likely are not complete and contain errors and are not laid out as good as they could be.

It only works with the provided TETRA plug-in supplied in zip. (2018-June-06).
This version uses a custom compiled version of 'Net Remote' supplied in zip

It is only meant to be a temporary solution until something better comes along.

Hopefully all goes well for you setting it up.

Download link

MD5 HASH 6f33fcf9662573b77e177e899793b9f9

Video showing starting it and it running
Video showing starting it and it running - Simple version

Video on Hacking 433 MHz Devices with an RTL-SDR and Raspberry Pi

Over on YouTube user Andreas Spiess has uploaded a video showing how to use an RTL-SDR to reverse engineer 433 MHz ISM band devices such as Internet of Things (IoT)/home automation sensors and actuators. 

Andreas decided to do this because he has a 433 MHz remote controlled actuated outdoor awning which he wants to have automatically retract when the wind speed gets too high. To do this he wanted to use a wireless 433 MHz ISM band weather station with wind speed sensor. But unfortunately he discovered that it has a proprietary protocol that can't talk to his awning, which also has it's own proprietary protocol.

Andreas' solution is to use an RTL-SDR and Raspberry Pi running the rtl_433 decoder software to receive the weather station data. The rtl_433 software already contained a decoder for his weather station, so no further reverse engineering was required. The data is then converted into MQTT which is a common TCP/IP protocol for IoT devices. MQTT is then read by Node-RED which is a flowgraph based programming environment for IoT devices.

Next, unlike the weather station rtl_433 did not already have a decoder implemented for his awning. So Andreas had to reverse engineer the signal from scratch using the Universal Radio Hacker software. Using the reverse engineered signal information, Andreas then uses an ESP32 processor/WiFi chip and cheap 433 MHz transmitter to implement a clone of the awning's remote control signals. The ESP32 is programmed to understand the MQTT data sent from the Raspberry Pi via WiFi, so now the weather station can control the awning with a little bit of logic code in Node-RED.

#209 How to Hack your 433 MHz Devices with a Raspberry and a RTL-SDR Dongle (Weather Station)

An Update on the PantronX Titus II SDR

The PantronX Titus II is a yet-to-be-released portable Android tablet based SDR that we've been following since 2016. The device will feature a 100 kHz - 2 GHz tuning range, and software that focuses on HF digital DRM decoding, as well as DAB on VHF. 

Thomas from the excellent SWLing blog got curious about the Titus II as he had not heard any updates from the team in a while, so he emailed them requesting an update. Mike from PantronX wrote the following reply:

As you might be aware, we have joined up with Fraunhofer to include their MMPlayer app standard on Titus–what a difference a professional decoder, for both analog, DRM(+), and DAB(+), makes! MMPlayer is full featured even including reliable one way file downloads with DRM.

We are attempting also to license HD to include on the app for North America, making a truly worldwide receiver. Some deficiencies in our version of Android have caused issues as well as MMPlayer. All of which have caused delays leading to some serious business decisions – as you can imagine. You are correct that broadcasters have made large orders that will be fulfilled first. There are units in the field testing and such and continuing resolution of the software issues.

One of the issues that folks seem to have a hard time understanding is that we can not just build a few hundred or even thousands of units. Our minimum run is 10,000pcs! To do that everything has to be 100% – including the software. We simply will not ship units that are not 100%. Titus works, MMPlayer works – its that last 5% that takes the most time to resolve. These facts preclude any incremental production attempts. All that being said, we are very hopeful that the first production run is ready by last quarter of this year.

The Titus II
The Titus II

Forwarding Pager Messages Received with an RTL-SDR to Email

Over on YouTube Jack Riley has created a video that documents his system which uses an RTL-SDR to receive POCSAG pager messages and forward messages sent to specific pager addresses to an email address. He uses his RTL-SDR on a Raspberry Pi, together with rtl_fm and multimon-ng to receive and decode the pager messages.

Then using a custom program that is available on his website he filters messages for a particular 'capcode' which indicates the address of a particular pager. When a pager message to the specified capcode address is received, the program turns the message into an email which is instantly sent out.

This is a nice way to forward pager messages on to a more modern device such as a smart phone.

Creating a Pager using a Raspberry Pi and RTL-SDR to send alerts via Email.

SDR# TETRA Decoder Plugin Updated

The TETRA plugin for SDR# has been updated a few times since our last post on it back in March. The latest version can be downloaded directly here, and the original link comes from the Russian scanner forums.

In the new version the 'Net Info' button is now functioning and it is possible to see the current calls, groups, and meta information on the current cell and neighbour cell. It also appears that it has been updated to allow for multiple SDR# TETRA decoder instances to be opened simultaneously now for wider band monitoring.

SDR# TETRA Plugin Net Info Window
SDR# TETRA Plugin Net Info Window

Hacker Warehouse Demonstrates Pager Decoding with an RTL-SDR

Over on YouTube the web show Hacker Warehouse have created a video explaining wireless pagers and how RTL-SDRs can be used to sniff them. In the video host Troy Brown starts by explaining what pagers are and how they work, and then he shows how to decode them with SDR# and PDW. We have a tutorial on this project available here too.

Later in the video he shows some examples of pager messages that he's received. He shows censored messages such as hospital patient data being transmitted in plain text, sports scores, a memo from a .gov address claiming allegations of abuse from a client, office gossip about a hookup, a message about a drunk man with a knife, a message from a Windows server with IP address and URL, a message from a computer database, and messages from banks.

In the past we've also seen an art installation in New York which used SDR to highlight the blatant breach of privacy that these pager messages can contain.

Decoding Pager Data with RTLSDR - Tradecraft

Building A Low Cost GOES Weather Satellite Receiver with an RTL-SDR

Over on Twitter and his github.io page, Pieter Noordhuis (@pnoordhuis) has shared details about his low cost RTL-SDR based GOES satellite receiving setup. GOES 15/16/17 are geosynchronous weather satellites that beam back high resolution weather images and data. In particular they send beautiful high resolution 'full disk' images which show one side of the entire earth. As the satellites are in geosynchronous orbit, they are quite a bit further away from the earth. So compared to the more easily receivable low earth orbit satellites such as the NOAA APT and Meteor M2 LRPT satellites, a dish antenna, good LNA and possibly a filter is required to receive them. However fortunately, as they are in a geosynchronous orbit, the satellite is in the same position in the sky all the time, so no tracking hardware is required.

In the past we've seen people receive these images with higher end SDRs like the Airspy and SDRplay. However, Pieter has shown that it is possible to receive these images on a budget. He uses an RTL-SDR, a 1.9 GHz grid dish antenna from L-Com, a Raspberry Pi 2, the NooElec 'SAWBird' LNA, and an additional SPF5189Z based LNA. The SAWBird is a yet to be released product from NooElec. It is similar to their 1.5 GHz Inmarsat LNA, but with a different SAW filter designed for 1.7 GHz GOES satellites. The total cost of all required parts should be less than US $200 (excluding any shipping costs).

Pieter also notes that he uses the stock 1.9 GHz feed on the L-com antenna, and that it appears to work fine for the 1.7 GHz GOES satellite frequency. With this dish he is able to receive all three GOES satellites at his location with the lowest being at 25 degrees elevation. If the elevation is lower at your location he mentions that a larger dish may be required. It may be possible to extend the 1.9 GHz L-Band dish for better reception with panels from a second cheaper 2.4 GHz grid dish, and this is what @scott23192 did in his setup.

For software Pieter uses the open source goestools software that Pieter himself developed. The software is capable of running on the Raspberry Pi 2 and demodulating and decoding the signal, and then fully assembling the decoded signal into files and images.

Pieters GOES RTL-SDR Receiving Setup
Pieters Low Cost GOES RTL-SDR Receiving Setup

Explaining and Demonstrating Jam and Replay Attacks on Keyless Entry Systems with RTL-SDR, RPiTX and a Yardstick One

Thank you to Christopher for submitting to us an article that he's written for a project of his that demonstrates how vulnerable vehicle keyless entry systems are to jam and replay attacks. In the article he explains what a jam and replay attack is, the different types of keyless entry security protocols, and how an attack can be performed with low cost off the shelf hardware. He explains a jam and replay attack as follows:

The attacker utilises a device with full-duplex RF capabilities (simultaneous transmit and receive) to produce a jamming signal, in order to prevent the car from receiving the valid code from the key fob. This is possible as RKEs are often designed with a receive band that is wider than the bandwidth of the key fob signal (refer Figure 3, right). The device simultaneously intercepts the rolling code by using a tighter receive band, and stores it for later use. When the user presses the key fob again, the device captures the second code, and transmits the first code, so that the user’s required action is performed (lock or unlock) (Kamkar, 2015). This results in the attacker possessing the next valid rolling code, providing them with access to the vehicle. The process can be repeated indefinitely by placing the device in the vicinity of the car. Note that if the user unlocks the car using the mechanical key after the first try, the second code capture is not required, and the first code can be used to unlock the vehicle.

In his demonstrating the attack he uses the RTL-SDR to initially find the frequency that they keyfob operates at and to analyze the signal and determine some of it's properties. He then uses a Raspberry Pi running RPiTX to generate a jamming signal, and the YardStick One to capture and replay the car keyfob signal.

Jam and Replay Hardware: Raspberry Pi running RpiTX for the Jamming and a Yardstick One for Capture and Replay.
Jam and Replay Hardware: Raspberry Pi running RpiTX for the Jamming and a Yardstick One for Capture and Replay.