Tagged: raspberry pi 4

Raspberry Pi 4 USB Bug Experienced with RTL-SDRs now Fixed with Kernel Update

Thank you to Michael B for letting us know about recent fixes to the Raspberry Pi kernel which affect RTL-SDR users. If you've been experiencing error "rtlsdr_read_reg failed with -7" when running RTL-SDR software on Raspberry Pi 4's running a Linux kernel with version 6.1 or higher, a Raspberry Pi kernel fix has been pushed which should fix the problem.

This problem "rtlsdr_read_reg failed with -7" appears to occur after having closed any program that uses an RTL-SDR, and then reopening it.

This doesn't seem to have been an issue for the older 5.12 and 4.19 kernels where this issue was previously fixed, but Raspberry Pi recently moved to the 6.1 kernel in May 2023 where the issue came back. Raspbian releases after this date may have been problematic.

The official Raspbian should eventually update, but if you've been experiencing this issue, you could try update your kernel now using:

sudo apt install rpi-update
sudo rpi-update

Alternatively according to Michael, kernel version 6.6.y should also have this problem fixed:

sudo rpi-update rpi-6.6.y

Note that updating the kernel could break other software, so doing this is at your own risk.

Etherify Talk from The rC3 Online Conference

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

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

RPiTX Beta for Raspberry Pi 4 Released

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.

RPiTX Logo

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×1440@60Hz 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.