Search results for: unintentional RF

Demonstrating How Speakers Can Become an Unintentional RF Transmitter

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).

PC Speakers Acting As Microphone (Remote RF) Demo: GQRX/Pinetab

TempestSDR: An SDR tool for Eavesdropping on Computer Screens via Unintentionally Radiated RF

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.
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#
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
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

If you want to learn more about TEMPEST and TempestSDR Martin Marinovs dissertation on this software might be a good read (pdf).

Receiving Unintentionally Radiated Signals from the Computer System Bus with an RTL-SDR

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.

Etherify 4: Using PC Ethernet RF Leakage to Transmit QRSS CW

Recently we've posted about Etherify a few times, mostly about how the unintentional RF leakage from the Raspberry Pi 4 Ethernet hardware is really strong and can be modulated to transmit data. In one of his latest posts Jacek Lipkowski (SQ5BPF) explores if Ethernet ports on PC's exhibit any sort of RF leakage too, and if it can be modulated into a data signal.

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

Etherify: Pi 4 Exhibits Very Strong Ethernet RF Leakage

Not too long ago we posted about Jacek Lipkowski (SQ5BPF)'s project called "Etherify" which seeks to use unintentional RF radiation from Ethernet hardware/cables to transmit arbitrary signals such as morse code and FSK. During his earlier experiments he noted how he felt that the Raspberry Pi 4 had an unusually strong radiated Ethernet signal. In his recent post Jacek investigates this further.

Indeed his new tests seem to confirm that the Pi 4 has excessive RF leakage from the Ethernet hardware. His latest results have shown that he was able to receive the Ethernet leakage strongly from 50 meters away without any cable connected to the Ethernet port to act as a radiator. Jacek's post contains a number of demonstration videos such as the one below.

He admits that his particular Pi 4 unit might be unique in this regard. If anyone else tests this and can confirm excessive leakage, please let us know in the comments.

Ethernet RF leakage received strongly from 50m away without any antenna on the Pi 4

Video Tutorial on Debugging RF Emissions on a Circuit Board with an RTL-SDR

Over on the Hackaday YouTube channel a video by Alex Whittemore has been uploaded showing how to do some basic RF emissions debugging. When creating electronic products it's important to ensure that there is no unintentional RF leakage in excess of emissions standards, and there is often a need to debug a circuit board to determine exactly what part or areas are generating excessive RF noise. To do this expensive EMC analyzers and near field probes are typically used.

Alex's tutorial video shows us how we can create a low cost home made EMC probe using an RTL-SDR, LNA and home made near field probe made out of magnet wire. The video starts by explaining RF compliance, demonstrating some higher end equipment, then moves on to showing how to build a probe yourself, before finally demonstrating it being used on some circuit boards. For software, he uses SDRAngel and QSPectrumAnalzyer which are preinstalled on a DragonOS image. 

The Hacakday.io project page has the tutorial in text and the video slides can be found here.

In the past we've also seen another post about home made EMC probes, and how to combine this idea with OpenCV to create noise heatmaps of circuit boards.

Basics of RF Emissions Debugging: Alex Whittemore

Performing a Side Channel TEMPEST Attack on a PC

TEMPEST refers to a technique that is used 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. We have tutorials on how to do this with a program called TempestSDR available on a previous post of ours.

Recently Mikhail Davidov and Baron Oldenburg from duo.com have uploaded a write up about their TEMPEST experiments. The write up introduces the science behind TEMPEST eavesdropping first, then moves on to topics like software defined radios and antennas.

At the end of their post they perform some experiments like constantly writing data to memory on a PC, and putting the PCs GPU under varying load states. These experiments result in clear RFI bursts and pulsing carriers being visible in the spectrum, indicating that the PC is indeed unintentionally transmitting RF. They note that machine learning could be used to gather some information from these signals.

Their write up reminds us of previous TEMPEST related posts that we've uploaded in the past. One example is where an RTL-SDR was used to successfully attack AES encryption wirelessly via the unintentional RF emitted by an FPGA performing an encryption algorithm. Another interesting post was where we saw how a HackRF was used to obtain the PIN of a cyprocurrency hardware wallet via TEMPEST. Search TEMPEST on our blog for more posts like that.

TEMPEST PC Side Channel Setup: RF pulses from writing to memory and a GPU.
TEMPEST PC Side Channel Setup: RF pulses from writing to memory and a GPU.

Using a HackRF to Investigate Why WiFi on the Raspberry Pi 4 Doesn’t work when Running HDMI at 1440p

The Raspberry Pi 4 launched with it's fair share of problems, but a new problem seems to have been recently discovered and documented. It turns out that the Pi 4's WiFi stops working when running at a screen resolution of specifically 1440p.

Suspecting interference generated by the HDMI clock, Mike Walters (@assortedhackery) used a HackRF and a near field probe antenna to investigate. By placing the near field probe on the Raspberry Pi 4's PCB and running a screen at 1440p resolution he discovered a large power spike showing up at 2.415 GHz. This interferes directly with 2.4 GHz WiFi Channel 1.

An article by ExtremeTech article notes:

There’s a giant spike that could easily interfere with Channel 1 of a Wi-Fi adapter. So why is this happening? Because a 2560×[email protected] has a pixel clock of 241.5MHz and has a TMDS (transition-minimized differential signaling) clock of 2.415GHz, according to Hector Martin (@Marcan42). And what frequency does the RBP4 use for Wi-Fi? 2.4GHz. Which means… outputting on HDMI over 1440p can cause interference in a Wi-Fi channel.

The ExtremeTech article also notes that this problem is not unique to the Raspberry Pi 4 only. It turns out that USB 3.0 hardware is to blame, and this problem has occurred before with USB3.0 hard driver and on some MacBooks.

While the interference appears to be localized to the near field around the Pi4 PCB, we suspect that you could use TempestSDR to remotely eavesdrop on the Pi 4's video output if the interfering signal was boosted.