Search results for: unintentional RF

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

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

Etherify 3 demo

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.

Fingerprinting Electronic Devices via their RF Emissions with an RTL-SDR and ImageMagick

Thank you to José Carlos Rueda for submitting his simple shell script that he uses for fingerprinting spurious RF emissions with an RTL-SDR, rtl_power, heatmap.py and imagemagick. The result is something like Disney's EM sense created with much simpler code.

It is well known that almost all electronic devices unintentionally emit unique spurious RF signals when in operation. By using an SDR like an RTL-SDR to record the spectra from electronic devices, it's possible to build up a database of known emissions. We can then detect when an electronic device is active by comparing the live spectrum to spectra stored in the database.

In a previous post we covered Disney's EM sense which is an experimental smart watch that automatically detects what electronic device the wearer is touching. With EM Sense they use an RTL-SDR and a database of raw pre-recorded spectrum data. To detect what the wearer is touching the live signal from the RTL-SDR is correlated against the database, and the closest match is returned.

José's script does something very similar, however instead of correlating with raw spectrum data he instead uses the waterfall image that is generated by rtl_power and heatmap.py. The rtl_power program allows an RTL-SDR to scan the frequency spectrum over a wider bandwidth by rapidly scanning ~2.4 MHz chunks of bandwidth at different frequencies. Heatmap.py is a program that turns the scanned data from rtl_power into a heatmap image of the spectrum.

To add an entry to the database, the electronic device is placed 7-8 centimeters away from the RTL-SDR, and a heatmap image recorded between 24 - 921 MHz is saved to disk. This can be repeated for multiple electronic devices. Each image will record the spurious signals from the electronic device, resulting in a unique heatmap image per electronic device.

Once the database has been created, you can then place any of the devices found in the database next to the RTL-SDR, and record a heatmap for 20-30s. That heatmap will then be compared against the images in the database using imagemagick which is an image analysis and manipulation library. The electronic device associated with the closest matching image in the database will be returned.

In his experiments he tested various electronic devices like an iPhone and was able to successfully determine when it was nearby.

Various electronic device spectra waterfall images recorded in the database
Various electronic device spectra waterfall images recorded in the database

Using a HackRF SDR to Sniff RF Emissions from a Cryptocurrency Hardware Wallet and Obtain the PIN

At last years Chaos Communication Congress (35C3) Conference, leveldown security presented their findings on multiple security vulnerabilities present in cryptocurrency hardware wallets.  Cryptocurrency is a type of digital asset that relies on computers solving cryptographic equations to keep the network trusted and secure. Popular cryptocurrencies include Bitcoin, Ethereum and Ripple. To access your cryptocurrency funds on a computer, a software application called a wallet is used.

However, if a computer holding a wallet is compromised, it is possible that the wallet could be opened by a hacker and funds transferred out. To improve security, hardware wallets are available. These are USB keys that require you to enter a PIN on the key before the funds can be accessed. If the USB key is not inserted and activated by the PIN, the wallet cannot be opened.

All electronic devices including hardware cryptocurrency wallets unintentionally emit RF signals. One possible attack against a hardware wallet is to analyze these RF emissions and see if any information can be obtained from them.  The team at leveldown found that the Ledger Blue cryptocurrency wallet in particular has a flaw where each PIN number button press emits a strong RF pulse. By using a HackRF and machine learning to analyze the unintentional RF output of each button press, the team was able to retrieve the PIN number with only RF sniffing from more than 2 meters away.

To do this they created a GNU Radio flowchart that records data from the HackRF whenever an RF pulse is detected. A small Arduino powered servo then presses the buttons on the wallet hundreds of times, allowing hundreds of RF examples to be collected. Those RF samples are then used to train a neural network created in Tensorflow (a popular machine learning package). The result is a network that performs with 96% accuracy.

If you're interested in exploring other unintentional RF emissions from electronics, check out our previous post on using the TempestSDR software to spy on monitors/TVs with unintentionally emitted RF, and the various other posts on our blog on this topic.