The "Chaos Computer Club (CCC)" have recently been uploading videos to YouTube from their "Remote Chaos Experience rC3" online conference. One talk is by Jacek Lipkowski (SQ5BPF) who presents his Etherify project which we have posted about a few times on this blog already. Etherify is a program that allows users to exploit unintentional RF leakage from Ethernet hardware in order to transmit data over the air, essentially creating a primitive software defined radio. In particular the Raspberry Pi 4 was found to have extreme unintentional leakage, with the signal being receivable from over 50m away.
Primitive soft tempest demos: exfiltrating data via leakage from ethernet and more :)
In this talk i will describe shortly the concept of soft tempest, and show a demo of etherify and sonify. Etherify uses radio frequency leakage from ethernet to exfiltrate data. Sonify uses ultrasound. Both demos by design use very primitive tools and hardware, and are easy to replicate.
#rC3 Etherify - bringing the ether back to ethernet
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.
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.
Evariste (F5OEO) has just announced the release of an update to RPiTX which allows it to now be used on a Raspberry Pi 4. If you are unfamiliar with it, RPiTX is a program for Raspberry Pi single board computers that allows you to transmit almost any type of signal on frequencies between 5 KHz up to 1500 MHz with nothing more than a piece of wire connected to a GPIO pin. Evariste also notes that the new version is compatible with the beta 64-bit version of Raspbian.
Some examples of signals you can transmit with RPiTX include a simple carrier, chirp, a spectrum waterfall image, broadcast FM with RDS, SSB, SSTV, Pocsag, Freedv and Opera. You can also use an RTL-SDR to record a signal, and replay the IQ file with RPiTX. However, please remember that transmitting with RPiTX you must ensure that your transmission is legal, and appropriately filtered.
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.
There's an interesting story doing the rounds about the Raspberry Pi 4 WiFi not working at higher HDMI resolutions. I had a quick look with a HackRF & near-field probe and there's definitely a big spike that stamps right on channel 1 pic.twitter.com/FXRebYYJxw
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.