Unlocking a Car with an RTL-SDR and Yardstick One

Over on his YouTube channel Kalle Hallden has uploaded a video demonstrating how to perform a replay and "rolljam" attack on a wireless car key with an RTL-SDR and Yardstick One. His first experiment is a simple replay attack which involves recording the unlock signal from the car key with the Yardstick One in a place far away from the car so that it is not received, then replaying it close by.

This works well, but Kalle then explains rolling code security and how this would easily thwart any replay attack in the real world. However, he then goes on to explain and demonstrate the "rolljam" technique, which is one known way to get around rolling code security. The demonstrations are obviously not full tutorials, but are just high level overviews of how wireless security can be defeated.

TechMinds: Decoding GPS with an RTL-SDR

Over on his YouTube channel Tech Minds has uploaded a video showing how it's possible to receive and decode GPS signals with an RTL-SDR. To do this he uses one of our RTL-SDR Blog V3 dongles and a GPS patch antenna which is powered via the bias tee on the dongle.

On the software side he uses GNSS-SDRLIB and RTKLIB to decode the GPS signal. The result of the two programs is your current GPS coordinates which can be plotted on a map. Unfortunately in the video Tech Minds was unable to get the Google Maps display to work, but you can easily type the coordinates into Google maps yourself.

Decoding GPS using an RTL SDR Receiver

 

New ExtIO For rtl_tcp: Control R820T Bandwidth, Decimation, Auto Reconnect

A few days ago we posted about Hayati and others' work in creating a new release of the librtlsdr drivers which implemented some new interesting features. However, at the time of the post there was no GUI for actually making use of the features easily. Now Hayati has released a new rtl_tcp ExtIO interface

The interface exposes the ability to manually adjust the filtering within the R820T tuner. This is quite useful for managing out of band interference and raising overall dynamic range especially when trying to listen to a narrowband signal. It also exposes decimation controls, tcp connection features like auto reconnect and persistent connection, manual IF gain control, the ability to choose USB vs LSB tuning, and the ability to choose the highest stable sample rate of 2.56 MSPS.

The ExtIO interface is only available for SDR programs that support ExtIO, such as HDSDR. To test the ExtIO, first download and extract the latest librtlsdr release then run rtl_tcp from the command line. Extract and run the new ExtIO dll into the HDSDR folder, then run HDSDR, making sure to select the new dll when it asks on startup. You can then set the desired bandwidth and the matching decimation settings for that bandwidth.

The new ExtIO exposing new features

Automatically Starting rtl_tcp on a Remote PC via Android

Over on his YouTube channel M Khanfar has put together a tutorial for an interesting idea. The idea is to use an automatic SSH connection to tell your Windows PC to run rtl_tcp whenever you open SDRTouch or RFAnalyzer on your Android device. SDRTouch and RFAnalyzer are both Android based SDR applications and rtl_tcp is a server which allows both apps to connect to a remote RTL-SDR over a network connection.

To set this up, Khanfar first sets up OpenSSH on his Windows PC which allows a secure remote connection to the PC. On his Android device he then installs MacroDroid and RaspController. MacroDroid is an app that help you automate tasks on your Android device, and RaspController is an app designed for remotely controlling a Raspberry Pi, but also works on Windows via the SSH connection. These apps are then setup so that an SSH connection to the Windows PC is automatically opened whenever SDRTouch is run. From within the SSH connection rtl_tcp is then started.

Full text instructions are available in the video description.

Automate MacroDroid with RTL_TCP through OpenSSH under Windows 10

KerberosSDR Tracking a Drone Carrying an FM Beacon

KerberosSDR is our 4-channel phase coherent capable RTL-SDR unit that we previously successfully crowdfunded back in 2018.  With a 4-channel phase coherent RTL-SDR interesting applications like radio direction findingpassive radar and beam forming become possible. It can also be used as 4 separate RTL-SDRs for multichannel monitoring. KerberosSDR is currently in stock and available on the Othernet store.

Recently Zuokun Li et al from the University of East China Normal University published an open access conference paper that documents their results at using a KerberosSDR to track a drone. As typical drone control frequencies at 2.4 GHz are outside the range of the RTL-SDRs used on the KerberosSDR, they carried a 446 MHz FM beacon on the drone.

In their experiment they set up both circular and linear antenna arrays for the KerberosSDR, then flew the drone in front of the antenna array while recording the bearings calculated by the KerberosSDR system. The results showed that the KerberosSDR was able to successfully track the drone's bearing with either antenna array, however the linear array produced more accurate results as expected.

We note that a linear array cannot differentiate if an object is in front or behind the array. However, if this knowledge is known it can be used instead of a circular array to get more accurate bearings that are less affected by multipath.

If you're interested in this, you might also like our articles on using a KerberosSDR to track a weather balloon, to locate a P25 transmitter, or our Android app in car demos

The KerberosSDR + Drone Setup
Results from the drones at three locations.

Using a PlutoSDR and Mixer to Transmit 70cm DATV to a 23cm Satellite Receiver

Over on her YouTube channel, SignalsEverywhere, Sarah has uploaded a new video showing how she uses a PlutoSDR, HackRF and mixer to transmit DVB-S digital amateur TV to a standard satellite set top box. In this video the idea is to get a little more range by using the PlutoSDR to transmit in the 70cm band, then upconverting that to the 23cm band right at the satellite receiver. Transmitting at the lower frequency yields a higher power output from the PlutoSDR and less cable loss. The mixer consists of a passive mixer chip and a HackRF is used as the mixer LO signal source as a temporary test solution.

Digital TV Transmitter 70cm ATV to 23cm Satellite Receiver Using a Mixer/Upconverter

OpenWiFi: Open Source FPGA and SDR Based WiFi Implementation

OpenWiFi is a Linux mac80211 compatible full-stack IEEE802.11/Wi-Fi design based on an FPGA and SDR (Software Defined Radio). It aims to be the first full open source implementation of the entire WiFi stack. While the current design does not provide any feature benefits over commercial closed source chips, it is beneficial from an education standpoint, and also from a security view as any open source FPGA code can be verified to not have backdoors. The SDRs used in the project are typically not ones seen on this blog as they mostly exist on research dev boards optimized for the 2.4 GHz band.

Recently the FOSDEM 2020 conference talks from February 2020 have been released on YouTube and a talk titled Opensource "Wi-Fi chip design" and Linux drivers by Xianjun Jiao was uploaded. The talk explains OpenWiFi in detail, and why or why not you might want to use it. 

Individuals, SMEs, opensource communities and big companies have shown big interests on the openwifi project. They also asked many questions, such as MIMO support, CSI information support, roadmap and opensource license consideration. One new interesting message, which is not expected before, is that: People are willing to pay more for a WiFi chip not because the chip’s performance is better but just because they can check the chip silicon source code (Verilog/VHDL/C) on github if they have privacy/security concern. So far, not any commercial WiFi chip discloses their silicon source code. After the FOSDEM, the project has reached 545 stars on github.

Openwifi talk at FOSDEM 2020

New Updates to the librtlsdr RTL-SDR Driver Fork

Thank you to Hayati Ayguen for letting us know that he and others have submitted a slew of updates to the "librtlsdr" fork of the librtlsdr RTL-SDR drivers. The improvements made to the development branch are extensive and are pasted below, and Hayati also has also created some presentation slides about his improvements. Hayati also notes that there are several open issues being tracked, and he has labelled some as "help wanted" where help and testing would be appreciated.

If you have tested any of the new features of tools, please let us know how they work in the comments!

"Driver" Library Features

  • added support for special USB (vendor) VID 0x1209 (product) PID 0x2832: "Generic RTL2832U":
  • added support for using RTLSDR-Dongle from remote - see rtl_rpcd and README.rtlsdr_rpc
  • improvements for R820T/2 tuner also see https://codingspirit.de/librtlsdr-driver.pdf
    • added better bandwidth support
      • added smaller bandwidths, improving selectivity: 290, 375, 420, 470, 600, 860, 950, 1100, 1300, 1500, 1600, 1750, 1950 kHz. These are coarse measured values .. which might get adjusted in future.
      • bandwidth filters utilize tuner's low- and highpass filters at IF
    • added spectrum flipping (inside tuner) - and back in RTL2832
      • the band edges (low/high-pass) have different steepness; the steeper edge can be selected with the mixer sideband (rtlsdr_set_tuner_sideband()), to achieve better attenuation depending on signal scenario
    • added (automatic) control over VGA (variable gain amplifier)
      • VGA gain (besides LNA and Mixer) can be utilized and set to automatic, letting it controlled from RTL2832U. Having all automatic (AGC) including activation of digital AGC in RTL2832 (rtlsdr_set_agc_mode()), oversteering effects got reduced (a lot).
      • gain range now up to 100 dB
    • deactivated "Filter extension under weak signal" for a stable filter characteristic
    • added shifting of IF-center, to receive away from DC. See rtlsdr_set_tuner_band_center()
  • probably some more: it's highly probable, that this list is incomplete

"Driver" Library API

  • added rtlsdr_set_and_get_tuner_bandwidth(), which also delivers the bandwidth. [ with rtlsdr_set_tuner_bandwidth() does not deliver the bandwidth ]
  • added rtlsdr_set_tuner_band_center(), to set center of the filtered tuner band
  • added rtlsdr_set_tuner_sideband(), to set mixer sideband
  • added rtlsdr_set_tuner_gain_ext(), special for R820T/2 tuner
  • added rtlsdr_set_tuner_if_mode(), sets AGC modes in detail
  • added rtlsdr_set_ds_mode() including threshold frequency
  • added rtlsdr_ir_query()
  • added rtlsdr_set_opt_string() and rtlsdr_get_opt_help() for configuration of 'driver' - especially from command line
  • added rtlsdr_set_tuner_i2c_register(), rtlsdr_get_tuner_i2c_register() and rtlsdr_set_tuner_i2c_override() exposing hacking of tuner-specific I2C registers
  • added rtlsdr_get_ver_id(), to allow discrimination between osmocom library - or this fork
  • added rtlsdr_get_version()

Added Tools

  • added rtl_ir: display received IR signals.
    • requires the IR diode of an RTL-SDR - which might not exist!
  • added rtl_rpcd: a Remote Procedure Call server for RTL-SDR dongles.
    • for use, set environment variable "RTLSDR_RPC_IS_ENABLED"
    • optionally set environment varibales "RTLSDR_RPC_SERV_ADDR" and "RTLSDR_RPC_SERV_PORT". These default to "127.0.0.1" and "40000".
    • requires cmake option WITH_RPC
  • added rtl_raw2wav: save rtl_sdr or rtl_fm's output (pipe) into a wave file, including some meta information like timestamp and frequency
  • added rtl_udp: same as rtl_tcp - just using UDP instead of TCP
  • added rtl_wavestat: display wave file meta information
  • added rtl_wavestream: stream raw data (in specified format)

Improved Tools

  • rtl_fm:
    • added command file option '-C', which can trigger actions depending on signal. have a look at README.rtlfm_cmdfile.
    • added command line interface option '-E rdc', to enable dc blocking on raw I/Q data at capture rate
    • added CLI option '-E rtlagc', to enable rtl2832's digital agc
    • added CLI option '-E bclo', to use tuner bandwidths low corner as band center
    • added CLI option '-E bchi', to use tuner bandwidths high corner as band center
    • added CLI option '-O', to set RTL driver options seperated with ':', e.g. -O 'bc=30000:agc=0'
    • added CLI option '-R', to specify number of seconds to run
    • added CLI option '-H', to write wave Header to file, producing a wave file with meta information, compatible with several SDR programs
    • added CLI option '-o', to request oversampling (4 recommended) for processing gain
  • not just rtl_fm, but many tools have more options. compare all the details by starting with command line option '-h'.

"Driver" Library's UDP-Server - only on Windows

  • enabled by cmake option PROVIDE_UDP_SERVER for tests. OFF by default
  • activated by rtlsdr_set_opt_string(): "port=1" or "port=<udp_port>", default port number: 32323
  • purpose is to allow configuration at runtime with a simple text protocol, e.g. with netcat
  • for detailed protocol, see comment section in parse() of librtlsdr.c. or look for sections with '#ifdef WITH_UDP_SERVER'

RTL_TCP TCP-PROTOCOL

  • allows non-GPL programs, e.g. QIRX, to utilize the RTLSDR stuff in a license compliant way
  • added several control functions in rtl_tcp, not existing in osmocom release: UDP_ESTABLISH, UDP_TERMINATE, SET_I2C_TUNER_REGISTER, SET_I2C_TUNER_OVERRIDE, SET_TUNER_BW_IF_CENTER, SET_TUNER_IF_MODE, SET_SIDEBAND, REPORT_I2C_REGS
  • control functions documented in rtl_tcp.h
  • (by default) control port number 1234, configurable via command-line-interface (CLI)
  • response(s) at +1 of control port: 1235, configurable via CLI
  • protocol details in protocol_rtl_tcp.txt