Recently we've come into knowledge of a program on GitHub called "System Bus Radio" which lets you transmit RF directly from your computer, laptop or phone without any transmitting hardware at all. It works on the principle of manipulating the unintentional RF radiation produced by a computers system bus by sending instructions that can produce different AM tones. An SDR like the RTL-SDR V3 or RTL-SDR with upconverter, or any portable AM radio that can tune down to 1580 kHz can be used to receive the tones. To run the software don't even need to download or compile anything, as there is now a web based app that you can instantly run which will play a simple song.
However, the RF emissions don't seem to occur on every PC, or are perhaps at another frequency. We tested a Windows desktop and Dell laptop and found that no were signals produced. A list of field reports indicates that it is mostly MacBook Pro and Air computers that produce the signal, with some transmitting signals strong enough to be received from a few centimeters to up to 2m away. This could obviously be a security risk if a sophisticated attacker was able to sniff these tones and recover data.
This program runs instructions on the computer that cause electromagnetic radiation. The emissions are of a broad frequency range. To be accepted by the radio, those frequencies must:
Be emitted by the computer processor and other subsystems
Escape the computer shielding
Pass through the air or other obstructions
Be accepted by the antenna
Be selected by the receiver
By trial and error, the above frequency was found to be ideal for that equipment. If somebody would like to send me a SDR that is capable of receiving 100 kHz and up then I could test other frequencies.
There is also an interesting related piece of software based on System Bus Radio called 'musicplayer', which takes a .wav file and allows you to transmit the modulated music directly via the system bus.
If you're interested in unintentionally emitted signals from PCs, have a look at this previous post showing how to recover images from the unintentional signals emitted by computer monitors. This is also similar to RPiTX which is a similar concept for Raspberry Pi's.
Foo-Manroot first explains how easily capture and replay a signal with the HackRF. If the signal is simple without any security like rolling codes then a simple replay attack like this will allow the HackRF to control the device quite easily. In the next section he goes on to explain how to actually analyze and synthesize the packets yourself using Python and GNU Radio. Finally he also shows that a brute force attack can be applied once you know how to synthesize the signal. Brute forcing runs over every possible packet combination in a short time and this can be pretty fast for simple protocols like those used in wireless remote controls. His post also includes all the GNU Radio files required so it is easy for someone to replicate his work easily.
If you are interested in controlling simple OOK devices like a wireless powerplug with replay attacks then we have a tutorial for doing this with a simple RTL-SDR and Raspberry Pi running RpiTX which might be useful for those who don't have a HackRF.
Over on YouTube Leif (sm5bsz) has uploaded a video where he compares the Airspy HF+ with the Airspy+Spyverter combination. In the test he compares the two radios at 7 MHz. The signals come in from an antenna, are amplified and then passed into a notch filter which notches at 7.198 MHz. The antenna signal is then passed into an attenuator, and then through a directional coupler and then split into the two radios. A signal generator is used to inject a signal via the directional coupler at the notch frequency, and this signal is used to compare the two radios. This method stops antenna noise from appearing at the notch frequency and so any non-linearities appearing in the notch must be a problem with the radio.
The results that Leif finds are quoted below. They show that although the Airspy HF+ has good linearity, it can still be significantly improved in tough environments by adding a front end filter for the band of interest.
The Airspy HF+ and the Airspy+Spyverter are compared on 7 MHz with and without a band pass filter on the input. Without the filter the HF+ is a little better than the Airspy+Spyverter combo, but when the filter is inserted, the HF+ is MUCH better than the combo.
In an earlier video Leif also compares the two Airspy units on FM broadcast and the 2 meter band. Again he shows that the Airspy HF+ is better than the standard Airspy, but adding a filter to block out the broadcast FM can still help fairly significantly when trying to listen to the 2M band on the HF+.
Over on YouTube user icholakov has uploaded a video comparing the Airspy HF+ with the KiwiSDR. The Airspy HF+ and KiwiSDR are both high performance yet low cost SDR platforms. The differences are that the Airspy HF+ is normally connected directly to a PC (but can be run remotely too) whereas the KiwiSDR is designed to be run remotely only, and so can only be accessed through a browser platform. In addition the HF+ only has maximum live bandwidth of 660 kHz whereas the KiwiSDR samples the entire 30 MHz of the HF band. Both are very sensitive and fairly resistant to overloading, but the HF+ should be better in both regards.
In his video icholakov does side by side comparisons with each radio. He writes
Comparing short wave and medium wave reception from Airspy HF+ SDR Console 3 and KiwiSDR with its built in web server. Using the same 80m dipole antenna. No special noise cancelling on the Airspy HF Plus.
The official software package of the SDRplay range of products is SDRuno and it has recently been updated to version 1.22. SDRuno is also compatible with the RTL-SDR.
In addition to some UI improvements for new users, the main changes are pasted below. What's also very interesting is their road map which states that future versions of SDRuno will have frequency scanning capabilities, a remote network streaming server/client implementation and an API for the support of third party plugins. This would improve it's capabilities similar to that of SDR#.
Added • Support for 1366×768 default layout • ADC overload detection in AGC off mode • ADC overload acknowledgment system to avoid lockout condition • Custom step size for each mode • Band Button Groups (Ham Lower, Ham Upper, Broadcast) • Two additional SP1 width presets (2560 and 3840) • Additional menu option in memory panel to reset column widths (helps when upgrading) • Scheduled Recording • Auto update
Changed • Registry reset now only clears 1.2+ entries • SP1 Window max size supports 4K displays (3840×2160) • Small improvements to the memory panel (panel width and field width changes) • Improvements to the IF output mode • UTC time fixed to 24 hour format • Play!/Stop button colour coordinated • Move MUTE button to make way for VOLUME label • Moved Squelch value display to the right
Fixed • Log10 SING error • Aero support detection to try to prevent rendering issues • Freezing when switching to HiZ port in gain mode • Gain “pumping” issue when in gain mode • Settings panels not displaying properly when “un-minimised” • Zoomed in frequency scale drag out of bounds bug • Noise floor measurement bug • Improved RSP error handling • Sample rate change causing spectrum display issues • Device selection bug
Known Issues • SP2 CWAFC drift issue (Zoom/window size/freq display) – will be addressed in 1.23, workaround for now is to zoom out fully in the SP2 window and then the CWAFC feature will work. • IF output mode disabled SP1 spectrum mouse clicks – temporary issue until LO is separated from the VFO (see plans below)
Following on from the 1.21 release where we outlined the features for coming releases, we have updated our plans, as shown below. The purpose of publishing this information is to give people an insight to the development plans but it is NOT a guarantee of the exact feature line-up and we cannot give release dates.
1.23 Intermediate update • Recording of selected signal only (either I/Q or audio) to WAV file format • Selected signal piped to VAC in I/Q format
1.3 Major update • Separation of VFO and LO frequency control • Frequency scanning
1.31 Intermediate update • Remote client for network based streaming I/Q server applications
1.4 Major update • Addition of new API for third party plugins
APL is an old but very concise array oriented programming language that uses mostly special characters to represent functions and operators. Dyalog APL is a modern implementation of APL, and is designed to make it easy to analyse and process large amount of data.
Over on YouTube there has recently been a talk uploaded from the Dyalog17 conference where Moris Zucca talks about using RTL-SDRs with Dyalog APL. In the talk he shows how he processes the RF data in the APL language leading to a reverse engineered garage door opener. The talk slides can be found here and the blurb reads:
Software-defined radio (SDR) is a radio communication system in which components such as amplifiers and modulators are implemented using software instead of the traditional hardware. In the last decade, technological advances by RealTek Labs (RTL) have made SDR viable for hobbyists. Moris Zucca (SimCorp Italiana) is one of the hobbyists who has taken up the RTL-SDR challenge; he explains how he has connected the Dyalog interpreter to various devices and converted the radio signals using APL. A little bit of reverse engineering means that he now possesses possibly the only remote control for a garage door that can be activated using APL!
Over on YouTube FairlawnARC.org have uploaded a talk about SDRs and ham radio by Ria Jairam (N2RJ0). The talk is a good overview of the current state of SDRs for ham radio use, and she discusses the various hardware and software options as well as giving many tips for improving your ham station. The blurb reads:
Our speaker was Ria Jairam (N2RJ), a world class contest operator and member of the Frankford Radio Club. Ria discussed the latest technology and offerings from Flex Radio, the HPSDR project (Ananradios), RTL SDR and others, as well as practical tips for contesting, DXing and rag chewing using your SDR. This presentation was held on Friday, October 20, 2017, 1900 hours at the Fair Lawn Senior Center, 11-05 Gardiner Road, Fair Lawn, NJ. The event was open to the public & refreshments were served.
Over on his site rtl-sdr.ru, Vasilli has been back at work creating new plugins for SDR#. The latest plugin is a TCP server that takes the demodulated mono audio stream from SDR# and sends it over TCP (note that the site is in Russian but the Google translate button on the right can be used). This can be used to easily stream audio over the internet or a network, or even locally on the same PC to another program. If enough programs support TCP audio streams, then the plugin could potentially replace the need for software like Virtual Audio Cable or VBCable by allowing another method for piping the audio from SDR# into a decoding program.
Installing the plugin is the same as usual. Just extract the SDRSharp.TcpServer.dll file to the SDRSharp folder, open plugins.xml with a text editor and paste in the 'magic line' specified in MagicLine.txt.
To test the server you can connect to it with VLC media player. Some special commands need to be specified to VLC in order for it to understand the audio format. To enter them go to Media->Open Network Stream and make sure 'Show more options' is checked. Enter the network URL as 'TCP://127.0.0.1:20022' (without quotes), and enter the Edit Options field as ':demux=rawaud :rawaud-channels=1 :rawaud-samplerate=48000 :rawaud-fourcc=s16l' (without quotes). Ensure the first colon in the line is copied over properly. Then enable the TCP server in the SDR# plugin, and click Play in VLC. Ensure the SDR# is muted, and the volume in VLC turned up. Audio should now begin streaming through TCP.
Hopefully in the future we can see some audio compression algorithms and more decoding software supporting TCP audio connections.
Vasilli has also updated many of his other plugins too, including creating a DSD_TCP plugin which allows you to transmit the digital audio directly to DSD+ via a TCP connection.