In their research, the team discovered that security cameras leak enough sensitive RF that an image can be recovered from the leakage over a distance. In their tests, they used a USRP B210 SDR as the receiver and tested twelve cameras including four smartphones, six smart home cameras, and two dash cams. They found that eight of the twelve leaked strongly enough for the reception of images through windows, doors, and walls. Cameras like the Xiaomi Dafang and Wyze Cam Pan 2 performed the worst, allowing for images to be recovered from distances of 500cm and 350cm respectively.
Over on YouTube channel Privacy & Tech Tips has uploaded a video showing how he used an RTL-SDR to pick up RF emissions coming from some speakers that were unintentionally acting as wireless microphones. He goes on to show how you can clean up the noisy received audio in Audacity using the noise reduction filter.
I show how electromagnetic emissions from personal devices many times turn our devices into (potential) remote listening + transmitting devices when active (as demonstrated). I discovered my speakers unintentionally transmitting audio (speaker acting as microphone) to a few different frequencies via GQRX recording (computer/Pinetab microphones completely disabled).
There are a few frequencies you can tune into to listen in remotely. This includes listening in to conversations in the room as the speaker also acts as a microphone when playing sound (***tested only on my own devices***).
When the speaker volume is turned down, the signal goes down and the broadcast goes away. When the speaker volume is down, it no longer functions as a remote microphone + transmitter.
We use Audacity to clean up the audio. GQRX is used to record the signals which are filtered on the Pinetab with internal RTL-SDR. Audio processing/noise reduction done running Parrot Linux using Audacity.
We touch on the fact all electronic devices give off their very own unique electromagnetic emissions which can act as device signatures (strength depends on shielding).
Sometimes speaker wire not properly shielded (as is found in most PC's) can act as a radio transmitter antenna without user knowledge. Here I discovered a few frequencies broadcasting the audio live (.25 second delay for SDR modulation).
📡 Laptop Speakers: Remote Listening Devices [SDR Side Channel]
Researchers from Hunan University, Boise State, and UT Arlington have published a paper called "GPSBuster" (PDF link), demonstrating how a HackRF One can sniff out covert GPS trackers by their unintended electromagnetic radiation. Hidden trackers are hard to find since they only receive satellite signals and may store coordinates locally rather than transmit. Instead of looking for transmissions, GPSBuster targets side-channel leakage from the tracker's mixed-signal SoC, specifically the coupling between the quartz oscillator, local oscillator, and mixer used to downconvert the 1575.42 MHz L1 signal.
The team found that an active tracker leaks two characteristic spectra: a low band around 26 to 104 MHz and a high band around 1545 to 1625 MHz, each with a strong peak and evenly spaced harmonics. The low band reflects coupling between the quartz oscillator (typically 26 MHz) and the IF, while the high band contains LO plus IF spacing that always sums to 1575.42 MHz, giving a database-free detection rule. The setup consists of a HackRF, an NFP-3 near-field probe, and a 35 dB LNA. The use of the near-field probe means that sweeping the probe over an area to find the tracker is necessary, and the maximum detection range was 0.61 m.
Tested against the top 10 trackers available on a popular online marketplace, GPSBuster hit a 98.4% detection rate, working through plastic, cotton, canvas, and leather, and alongside phones, laptops, and speakers. It also extended to L1+L5 modules like the Quectel LC29H series, and even metal-shielded chips still leaked enough via PCB traces to be picked up.
Covert GPS Tracker Detection with a HackRF and Near Field ProbeGPSBuster Field Prototype
Thanks to RTL-SDR.com reader 'flatflyfish' for submitting information on how to get Martin Marinov's TempestSDR up and running on a Windows system. If you didn't already know by definition "TEMPEST" refers to techniques used by some spy agencies to eavesdrop on electronic equipment via their unintentional radio emissions (as well as via sounds and vibrations). All electronics emit some sort of unintentional RF signals, and by capturing and processing those signals some data can be recovered. For example the unintentional signals from a computer screen could be captured, and converted back into a live image of what the screen is displaying.
TempestSDR is an open source tool that allows you to use any SDR that has a supporting ExtIO (such as RTL-SDR, Airspy, SDRplay, HackRF) to receive the unintentional signal radiation from a screen, and turn that signal back into a live image. This can let you view what is on a screen without any physical connections. If a high gain directional antenna is used then it may be possible to receive images from several meters away as well.
TempestSDR showing what's on the screen via unintentional RF radiation from the monitor.
Although TempestSDR has been released now for a number of years it hasn't worked properly in Windows with ExtIO interfaces. In his email flatflyfish showed us how to compile a new version that does work.
1. You need to install a 32-bit version of the Java runtime. The 64-bit version won't work with extio's possibly because they are all 32-bit. Also install the JDK.
2. You need to install MingW32 and MSYS and put their bin folders in your Windows PATH.
3. Then when compiling I was seeing a lot of CC command unknown errors. To fix that I just added CC=gcc to the top of all makefiles. I also removed the Mirics compilation line from the JavaGUI makefile to make things easier as we're not using that sdr.
4. Originally my JDK folder was in Program Files. The makefile didn't like the spaces in the folder, so I moved it to a folder without spaces and it fixed the errors.
5. Lastly to compile it you need to specify the ARCHNAME as x86 eg "make all JAVA_HOME=F:/Java/jdk1.7.0_45 ARCHNAME=X86"
After doing all that it compiled and I had a working JAR file. The extio's that are used normally with HDSDR work fine now and I get some images from my test monitor with an rtlsdr.
We tested compilation ourselves and were successful at getting a working program. To help others we've just uploaded a fork of the code with the makefile changes done, as well as a precompiled release ZIP available on the releases page so no compilation should be required to just use it. Note that to use the precompiled JAR you still need to install MingW32, and also don't forget to install the MingW /bin and msys /1.0/bin folders into the Windows PATH. You also do need to have the 32-bit Java runtime installed as the 64-bit version doesn't seem to work. On at least one Win 10 machine we also had to manually add a 'Prefs' folder to the Java path in the registry.
We've tested the software with the ExtIO for RTL-SDRs (available on the HDSDR downloads page) and confirmed that it works. Images from one of our older DELL monitors using DVI are received nicely, although they are a bit blurry. We also tried using an Airspy or SDRplay unit and this significantly improved the quality of the images a lot due to the larger bandwidth. The quality was good enough to make out large text on the screens. ExtIO's for the Airspy are available on this page, and for the SDRplay on the official SDRplay website. Note that for the SDRplay we were unable to go above 6 MHz, and on the RTL-SDR 2.8 MHz was the limit - anything higher on these SDRs did not produce an image possibly due to dropped samples.
To use the software you should ideally know the resolution and refresh rate of your target monitor. But if you don't there are auto-correlation graphs which actually help to predict the detected resolution and frame rate. Just click on the peaks. Also, you will need to know the frequency that your monitor unintentionally emits at. If you don't know you can browse around in SDR# looking for interference peaks that change depending on what the image of the screen is showing. For example in the image below we show what the interference might look like. A tip to improving images is to increase the "Lpass" option and to watch that the auto FPS search doesn't deviate too far from your expected frame rate. If it goes too far, reset it by re-selecting your screen resolution.
Unintentionally radiated RF signal from computer screen shown in SDR#
The best results were had with the Airspy listening to an older 19" DELL monitor connected via DVI. A newer Phillips 1080p monitor connected via HDMI had much weaker unintentional signals but images were still able to be recovered. A third AOC 1080p monitor produced no emissions that we could find.
Clear images were obtained with an antenna used in the same room as the monitor. In a neighboring room the images on the DELL monitor could still be received, but they were too blurry to make anything out. Possibly a higher gain directional antenna could improve that.
An example set up with RTL-SDR antenna and monitors
Below we've uploaded a video to YouTube showing our results with TempestSDR.
TempestSDR - Remotely Eavesdropping on Monitors via Unintentionally Radiated RF
Over on dereksgc's YouTube channel we've discovered a few more recent interesting videos from his satellite decoding series that people may be interested in. One from two weeks ago shows how it's possible to receive voice transmissions on navigation satellites such as GPS.
Many navigational and meteorological satellites carry a search and rescue (SAR) repeater which is intended to receive UHF emergency locator beacons and rebroadcast them in the L-band or higher. However the repeaters appear to be picking up all sorts of other signals from the ground, including voice transmissions. Dereksgc notes that the theory is that there are some land based communications systems in some countries that are sharing frequencies that emergency locator beacons use, or that malicious pirates may be actively using these SAR repeaters for their own communications.
Dereksgc shows examples of retransmitted signals on the Beidou, GLONASS and Elektro-L satellite downlinks at 1.5442 GHz and at 2.226 MHz for the GPS satellites. He also shows what sort of satellite dish and feed setup you need. In the video he uses a HackRF as the SDR, but you could also use an RTL-SDR for the satellites that transmit at 1.5442 GHz.
Receiving voice transmissions from GPS satellites || Satellite reception pt.10
Over on Twitter @dereksgc has been monitoring the 'Meridian' communications satellites, which are Russian owned and used for civilian and military purposes. The satellites are simple unsecure repeaters, meaning that actually anyone with the hardware can transmit to them, and have their signal automatically rebroadcast over a wide area. This has been taken advantage of recently by anti-Russian invasion war activists who have been trolling the satellite with SSTV images of the Ukrainian flag, as well as audio.
Apart from intentional abuse, a side effect of being an open repeater is that sometimes the satellite can pick up powerful terrestrial signals unintentionally, such as analogue broadcast TV from Turkmenistan. Over on his blog, @dereksgc has written up an excellent post documenting the background behind this finding, his entire setup involving the hardware he's using and how he's aligning with the satellite, and what software he is using to decode the TV signal. In his hardware setup he notes that he uses a HackRF, but that a RTL-SDR would suffice.
I've published a summary on how I received the analog TV broadcast via a Russian military satellite using an SDR, as well as the short story leading up to it.
Check it out if you're interested!https://t.co/mgCScsDEgPpic.twitter.com/1Oeokg3MYB
Back in 2018 we first posted about "System Bus Radio" which is code and a web based app that allows you to transmit RF directly from your computer without any transmitting hardware. 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. The idea is to demonstrate how unintentional radiation from computers could be a security risk.
Recently the creator of System Bus Radio has uploaded a guide on receiving the generated signals with an RTL-SDR. He recommends using an RTL-SDR with upconverter, balun and an AM loop antenna. He then shows how he was able to receive the signals from his MacBook Pro M1, noting that he was able to receive audible signals from several inches away at frequencies between 63 kHz to 5.5 MHz.
System Bus Radio received with an RTL-SDR and upconverter.
The answer is yes, there is some RF leakage, however unlike the Pi 4 the speed at which the leakage can be modulated is much slower, and also the signal strength is much lower. Despite the slow modulation speed, Jacek was still able to transmit data by using QRSS CW, which is essentially just very slow morse code. Using this idea he was able to transmit, and receive the CW signal with an RTL-SDR over a distance of 3 meters at 375 MHz, 625 MHz and 250 MHz. The signal strength is nothing like the Pi 4's Ethernet RF leakage which can be received strongly from over 50 meters away however.
Etherify: Transmitting QRSS CW via Ethernet RF leakage from PC to PC
![📡 Laptop Speakers: Remote Listening Devices [SDR Side Channel]](https://www.rtl-sdr.com/wp-content/plugins/wp-youtube-lyte/lyteCache.php?origThumbUrl=https%3A%2F%2Fi.ytimg.com%2Fvi%2FbK-CcnfP_ws%2F0.jpg)
