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.
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.
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.
Recently we've come into knowledge of a program on GitHub called "System Bus Radio" which lets you transmit RF directly from your computer, laptop or phone without any transmitting hardware at all. 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. An SDR like the RTL-SDR V3 or RTL-SDR with upconverter, or any portable AM radio that can tune down to 1580 kHz can be used to receive the tones. To run the software don't even need to download or compile anything, as there is now a web based app that you can instantly run which will play a simple song.
However, the RF emissions don't seem to occur on every PC, or are perhaps at another frequency. We tested a Windows desktop and Dell laptop and found that no were signals produced. A list of field reports indicates that it is mostly MacBook Pro and Air computers that produce the signal, with some transmitting signals strong enough to be received from a few centimeters to up to 2m away. This could obviously be a security risk if a sophisticated attacker was able to sniff these tones and recover data.
This program runs instructions on the computer that cause electromagnetic radiation. The emissions are of a broad frequency range. To be accepted by the radio, those frequencies must:
Be emitted by the computer processor and other subsystems
Escape the computer shielding
Pass through the air or other obstructions
Be accepted by the antenna
Be selected by the receiver
By trial and error, the above frequency was found to be ideal for that equipment. If somebody would like to send me a SDR that is capable of receiving 100 kHz and up then I could test other frequencies.
There is also an interesting related piece of software based on System Bus Radio called 'musicplayer', which takes a .wav file and allows you to transmit the modulated music directly via the system bus.
If you're interested in unintentionally emitted signals from PCs, have a look at this previous post showing how to recover images from the unintentional signals emitted by computer monitors. This is also similar to RPiTX which is a similar concept for Raspberry Pi's.
Over on YouTube user Ejo Schrama has uploaded a short video showing a demonstration of radio frequency interference (RFI) from various Arduino based devices he’s built. The interference comes from the local oscillators within the devices which are common to many electronic devices. He writes in the video description:
RFI simply means that there is a part in the radio spectrum that we wouldn’t like to see, it is usually unintentionally caused by devices around us (computers, televisions, radios, clocks, watches, etc etc) that carry local oscillators which are low power transmitters. Sometimes it is caused by illegal transmissions, so a deliberate action.
The oscillators of devices around us oftentimes feed digital circuits, sine wave become block wave, as a result higher order harmonics of the block wave pollute the spectrum. If your receiver is sensitive enough then you will pick up the RFI at some point.
In this video I’m two meter away from an antenna and I tuned the receiver to 48 MHz which is the 3rd harmonic of the 16 MHz oscillator used by all nearby Arduino experiments. Lets see what the spectrum does by turning on and off some arduino’s. The worst RFI generator was a 16 MHz atmel 328p multiplexing four 7-segment LEDs displaying the value of a IR temperature sensor. But also a nearby clock experiment clearly caused some RFI.
The receiver that I used was an airspy, and I’ve put the decimation factor high enough to get some resolution in the spectrum. The frequency offset between the different arduino’s is clearly visible. This is caused by the fact that cheap quartz oscillators are used, their accuracy is usually around 100 ppm, and this mostly determines a frequency bias.
Nowadays it is very difficult to clean up your local shortwave spectrum. For this reason reception conditions under 30 MHz and even 2 meter nowadays face the RFI problem. Only when we go to UHF frequencies like 430 MHz, better known as the the 70 cm amateur band, the RFI problem sort of disappears, apparently because higher harmonics have become insignificant.
I do not think that a lot of effort is put into keeping LW, HF but also VHF spectra clean, the worst violators are usually tracked down but only when many listeners start to complain.
They write about the performance of their results:
Using GnuPG as our study case, we can, on some machines:
distinguish between the spectral signatures of different RSA secret keys (signing or decryption), and
fully extract decryption keys, by measuring the laptop’s electromagnetic emanations during decryption of a chosen ciphertext.
In their experiments they used a Funcube Dongle Pro+ to measure the unintentional RF emissions coming out of a laptop computer at around 1.6-1.75 MHz, but they also mention that a low cost RTL-SDR with upconverter could also work.
Every time the CPU on a target PC performs a new operation the unintentional frequency signature that is emitted changes. From these emissions they are able to use the unique RF signature to determine what operations are being performed by the CPU, and from that they can work out the operations GnuPG is performing when decrypting data. They write:
Different CPU operations have different power requirements. As different computations are performed during the decryption process, different electrical loads are placed on the voltage regulator that provides the processor with power. The regulator reacts to these varying loads, inadvertently producing electromagnetic radiation that propagates away from the laptop and can be picked up by a nearby observer. This radiation contains information regarding the CPU operations used in the decryption, which we use in our attack.
In addition to the above they were also able to create portable attack hardware by connecting the Funcube Dongle Pro+ with a small Android based embedded computer called the Rikomagic MK802 IV. They also show that they were even able to perform the portable attack with a standard AM radio with the output audio being recorded with a smart phone.
The researchers write that they will present their work at the CHES 2015 conference in September 2015.
Melissa Elliot (0xABAD1DEA), an infosec security researcher has uploaded slides on the topic of investigating unintentional radio emissions from various electronic devices, and the security issues these emissions can cause. She used the RTL-SDR as the radio receiver to show that sophisticated equipment isn’t needed. One interesting experiment she performed was trying to recover a checkerboard image displayed on an LCD screen entirely via its unintentional radio emissions received with the RTL-SDR. She got close, as you can sort of make out the checkerboard pattern on the recovered image below. Update: Tomsguide have written an article on Melissa’s talk.
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
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 can be captured, and converted back into a live image of what the screen is displaying.
Until recently we have relied on an open source program by Martin Marinov called TempestSDR which has allowed RTL-SDR and other SDR owners perform interesting TEMPEST experiments with computer and TV monitors. We have a tutorial and demo on TempestSDR available on a previous post of ours. However, TempestSDR has always been a little difficult to set up and use.
The GNU Radio implementation is a good starting point for further experimentation, and we hope to see more developments in the future. They request that the GitHub repo be starred as it will help them get funding for future work on the project.
The creators have also released a video shown below that demonstrates the code with some recorded data. They have also released the recorded data, with links available on the GitHub. It's not clear which SDR they used, but we assume they used a wide bandwidth SDR as the recovered image is quite clear.