 | Enter Your Project for a chance to win a Spectrum Analyzer for the Most Innovative RF Project! | Project14 Home |
| Monthly Themes | ||
| Monthly Theme Poll |
I'm not sure, but my last posting on QRSS Data Exfiltration using an NFC interface may not have resonated (haha, get it?) with as many people as I might have wished. Perhaps the nature of CW transmission, Morse Code and NFC are all rather fringe technologies which are not as widely appreciated. As a result, I sought to do something a little more accessible - perhaps something using technology that people would already have at home to do something that almost anyone could appreciate. Continuing on with the theme of "radio abuse" and my tendency to gravitate towards short projects, this time, I use Wi-Fi to send a coded message in the form of Jingle Bells.
The Premise
Broadly speaking, Wi-Fi is a technology used to wirelessly network computers and devices together. Most people use this on a daily basis - whether it is the Wi-Fi access point at home communicating to your smart-phone, laptop or TV or using the free Wi-Fi at a shopping centre or cafe. Rarely do people think of it as "radio" however, even though it does use radio frequency spectrum. The more common and older incarnations of Wi-Fi (802.11b, g) focused on 2.4GHz operation, while the less common and newer incarnations (802.11a, n, ac, ax) offer operation in the less congested 5GHz band, and some of the latest (802.11ad) even operate in the 60GHz band. These transmissions are unlike the crude audio-frequency narrow-band transmissions that we commonly associate with radio - an AM signal could be contained within 9-40kHz of bandwidth depending on quality, while most narrow FM transmissions are contained within 16kHz and "wide" FM (broadcast) transmissions are contained within 200kHz. By comparison, the narrowest standard Wi-Fi signal is 20MHz wide (i.e. 100 times wider than a broadcast WFM signal). In the latest 802.11ac Wave 2, 160MHz-wide modes have been introduced as well, all of this taking advantage of the big advances in mixed-signal IC design and software defined radio modulation that has become available in the more recent years. We are less constrained by the limitations of analog circuitry components and their frequency response characteristics.
So what has this got to do with Jingle Bells? Well, if you take a standard AM receiver and tune it into a "quiet" part of the band where there are no transmissions, you'll hear a hiss. But if you bring the radio close to some source of electrical noise - you're likely to hear a series of pops, clicks and chirps. Of course, your switchmode supply (or whatever source of interference you chose) is not actually putting out a properly modulated AM signal. It's just putting out blobs of RF energy all over the place. Instead, the radio's internal circuitry reacts to this changing RF, often with changes in signal envelope (i.e. the signal power going from zero up to some level) causing the audio output to be modulated in the same way. This is why, say a 2G GSM phone on a call, has a characteristic "bllrrrrrrrrr" sound when heard in amplifiers and speakers - this is because they are demodulating the signal envelope which changes in line with the TDMA time-slotting of the phone call.
So while Wi-Fi transmissions are wide-band in nature, we could use a narrow-band receiver tuned in AM to a frequency within this wide-band transmission and expect it to demodulate the envelope of the signal. Every packet we send should result in a "plop". Send enough packets at the right times and you might even get a "beep" or a tone. String along a few of these, and before you know it, you probably have a tune on your hands.
Testing It Out
In order to test out the idea, I decided to use the following equipment and software:
- Raspberry Pi Model A - since I already had it set-up already from the last experiment.
- Wi-Pi Dongle - for wireless connection as the Model A doesn't natively have any. You could substitute another Raspberry Pi board with onboard wireless to the same effect.
- A wireless router/access point - this provides a network to connect to.
- Icom IC-R20 Communications Receiver - to listen in on the results, although any other receiver capable of narrow-band AM reception in the 2.4GHz range would be suitable including upmarket SDRs.
- Tektronix RSA306 USB Spectrum Analyzer - Review - optional, but useful to visualise what the program does.
- Python 2.7 - to run the program that is written. I could have used Python 3, but the example UDP code I borrowed doesn't seem to work with it just yet.
In order to send the packets at the timings that I needed, I wrote a short Python program. This program has an array of note frequencies (taken from here) and calculates the note periods. A transpose feature is provided to halve/double the note periods while a tempo feature is provided to adjust playback speed. The notes of the song are coded into an array numerically as indexes, with the duration in terms of beats translated into time on-the-fly.
import socket
import time
UDP_IP = "192.168.0.253"
UDP_PORT = 19999
MESSAGE = ">"
notes_hz = [130.81,138.59,146.83,155.56,164.81,174.61,185.0,196.0,207.65,220.0,233.07,246.94]
transpose = 1
notes_period = [1.0/(transpose*x) for x in notes_hz]
tempo = 120.0
# Notes
# C = 0, C# = 1, D = 2, D# = 3, E = 4, F = 5, F# = 6, G = 7, G# = 8, A = 9, A# = 10, B = 11
# Duration
# Qua = 0.5, Crot = 1, Min = 2, etc.
songnotes = [4,4,4,4,4,4,4,7,0, 2, 4,5,5,5, 5, 5,4,4,4,4,4,2,2,4,2,7,4,4,4,4,4,4,4,7,0, 2, 4,5,5,5,5,5,4,4,4,4,7,7,5,2,0]
songdurau = [1,1,2,1,1,2,1,1,1.5,0.5,4,1,1,1.5,0.5,1,1,1,1,1,1,1,1,1,2,2,1,1,2,1,1,2,1,1,1.5,0.5,4,1,1,1,1,1,1,1,1,1,1,1,1,1,4]
songdurat = [x*60/tempo for x in songdurau]
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
i=0
while i < len(songnotes):
timeend = time.time() + songdurat[i];
while time.time() < timeend :
sock.sendto(MESSAGE,(UDP_IP,UDP_PORT))
time.sleep(notes_period[songnotes[i]]/2)
i=i+1
time.sleep(0.1)
It's not the ideal code, especially on a multi-tasking operating system such as Linux, as it uses calls to time.sleep() to generate delays, which is necessarily imprecise. Adding to this, inherent delays caused by the CSMA/CA transmission method of Wi-Fi, a rather characteristic "unstable" pitch interrupted by actual network traffic is the likely result. But I'd have to say that this has a charm of its own. To try and reduce the loading on the network to make it more likely that higher notes can be generated, I've decided to send a simple message containing a single angle-bracket. This reduces the air-time consumption to the absolute minimum. As UDP is a connection-less protocol, I just decided to direct the transmission to a computer on the network (so that the hardware Ethernet address would be resolved) which would just discard the packets as part of its normal handling of unsolicited packets. The notes for the song and the durations were transcribed from this piece of sheet music - although i might have made a mistake as this was one of those "I want to try this out before I go to bed" kind of projects.
Video Demonstration
Below is a video that overviews the project including the demonstration of the resulting tune on my trusty Icom IC-R20 communications receiver.
Conclusion
While my aim was to try and do something perhaps a little more accessible, I fear that I might have failed once-more. Perhaps I'm lacking a bit in the Q-department. While many people may have access to a Raspberry Pi and Wi-Fi radio, I forgot that many people may not have a radio that could receive up into the 2.4GHz region in the AM mode to enjoy the resulting tune. Many low-cost SDRs (e.g. the RTL TV Tuner Sticks) only reach into the 1700-1800MHz ranges and even the spectrum analyser on offer in the RF Project 14 only goes up to 1.5GHz. Unless you have a super wide-band receiver, a more upmarket SDR, a down-converter or a higher-end spectrum analyser ... you won't really notice the holiday cheer that this program could bring*. But that being said, this shows us just another means by which data exfiltration and side-channel attacks could occur - even though the network in question is fully encrypted with modern WPA2-AES-CCMP encryption, a rogue node on the network could send packets at a specific timing interval with enough repetitions such that an observer could receive a coded message simply by observing the timing of the encrypted packets. This is actually harnessed by a number of products to do initial Wi-Fi set-up and communicate the encryption key to unprovisioned devices (a number of which are mentioned in this paper). But I guess I could use it to send Morse code as well ... not that anyone would really notice it in passing.
* Holiday cheer is not guaranteed. I will not be held responsible should this tune cause any damage or loss of holiday cheer either directly or consequentially. Use at your own risk.
Top Comments