Have you ever found yourself in a crowded restaurant on a Saturday night, holding onto one of those little gadgets that blinks and vibrates when it’s your turn to be seated? Next time, bust out the HackRF and follow along with [Tony Tiger] as he shows how it can be used to easily fire them off. Of course, there won’t actually be a table ready when you triumphantly show your blinking pager to the staff; but there’s only so much an SDR can do.
Even if you aren’t looking to jump the line at your favorite dining establishment, the video that [Tony] has put together serves as an excellent practical example of using software defined radio (SDR) to examine and ultimately replicate a wireless communications protocol. The same techniques demonstrated here could be applied to any number of devices out in the wild with little to no modification. Granted these “restaurant pagers” aren’t exactly high security devices to begin with, but you’d be horrified surprised how many other devices out there take a similarly cavalier attitude towards security.
[Tony] starts by using inspectrum to examine the Frequency-shift keying (FSK) modulation used by the 467.750 Mhz devices, and from there, uses Universal Radio Hacker to capture the actual binary data being sent over the air. Between studying the transmissions and the information he found online, he was eventually able to piece together the packet structure used by the restaurant’s base station.
Finally, he wrote a Python script which generates packets based on which pager he wants to set off. If he’s feeling particularly mischievous, he can even set them all off at once. The script outputs a binary file which is then loaded into GNU Radio for transmission via the HackRF. [Tony] says he’s not quite ready to release his script yet, but he gives enough information in the video that the intrepid hacker could probably get their own version up and running by the time he gets it posted up to GitHub anyway.
If you’ve been following along with the build like we have, you’ll know that this stems from a previous, much larger radio telescope that [Justin] used to visualize the constellation of geosynchronous digital TV satellites. This time, he set his sights closer to home and built a system to visualize the 2.4-GHz WiFi band. A simple helical antenna rides on the stepper-driven azimuth-elevation scanner. A HackRF SDR and GNU Radio form the receiver, which just captures the received signal strength indicator (RSSI) value for each point as the antenna scans. The data is then massaged into colors representing the intensity of WiFi signals received and laid over an optical image of the scanned area. The first image clearly showed a couple of hotspots, including a previously unknown router. An outdoor scan revealed routers galore, although that took a little more wizardry to pull off.
The videos below recount the whole tale in detail; skip to part three for the payoff if you must, but at the cost of missing some valuable lessons and a few cool tips, like using flattened pieces of Schedule 40 pipe as a construction material. We hope to see more from the project soon, and wonder if this FPV racing drone tracker might offer some helpful hints for expansion.
When it comes to finding what direction a radio signal is coming from, the best and cheapest way to accomplish the task is usually a Yagi and getting dizzy. There are other methods, and at Shmoocon this last weekend, [Michael Ossmann] and [Schuyler St. Leger] demonstrated pseudo-doppler direction finding using cheap, off-the-shelf software defined radio hardware.
The hardware for this build is, of course, the HackRF, but this pseudo-doppler requires antenna switching. That means length-matched antennas, and switching antennas without interrupts or other CPU delays. This required an add-on board for the HackRF dubbed the Opera Cake. This board is effectively an eight-input antenna switcher using the state configurable timer found in the LPC43xx found on the HackRF.
The key technique for pseudo-doppler is basically switching between an array of antennas mounted in a circle. By switching through these antennas very, very quickly — on the order of hundreds of thousands of times per second — you can measure the Doppler shift of a transmitter.
However, teasing out a distinct signal from a bunch of antennas virtually whizzing about isn’t exactly easy. If you look at what the HackRF an Opera Cake receive on a waterfall display, you’ll find a big peak around where you expect, and copies of that signal trailing off, separated by whatever your antenna switching frequency is. This was initially a problem for [Schuyler] and [Ossmann]’s experiments. Spinning the antennas at 20 kHz meant there was only 20 kHz difference in these copies, resulting in a mess that can’t be decoded. The solution was to virtually spin these antennas much faster, resulting in more separation, and a clean signal.
There are significant challenges when it comes to finding the direction of modern radio targets. Internet of Things things sometimes have very short packet duration, modulation interferes with antenna rotation, and packet detection must maintain the phase. That said, is this technique actually able to find the direction of IoT garbage devices? Yes, the demo on stage was simply finding the direction of one of the wireless microphones for the talk. It mostly worked, but the guys have some ideas for the future that would make this technique work a little better. They’re going to try phase demodulation instead of only frequency-based demodulation. They’re also going to try asymmetric antenna arrays and pseudorandom antenna switching. With any luck, this is going to become an easy and cheap way to do pseudo-doppler direction finding, all enabled by a few dollars in hardware and a laser-cut jig to hold a few antennas.
Readers who were firmly on Team Nintendo in the early 2000’s or so can tell you that there was no accessory cooler for the Nintendo GameCube than the WaveBird. Previous attempts at wireless game controllers had generally either been sketchy third-party accessories or based around IR, and in both cases the end result was that the thing barely worked. The WaveBird on the other hand was not only an official product by Nintendo, but used 2.4 GHz to communicate with the system. Some concessions had to be made with the WaveBird; it lacked rumble, was a bit heavier than the stock controllers, and required a receiver “dongle”, but on the whole the WaveBird represented the shape of things to come for game controllers.
Even if you’ve never seen a GameCube or its somewhat pudgy wireless controller, you’re going to want to read though the incredible amount of information [Sam] has compiled in his GitHub repository for this project.
Starting with defining what a signal is to begin with, [Sam] walks the reader though Fourier transforms, the different types of modulations, decoding packets, and making sense of error correction. In the end, [Sam] presents a final summation of the wireless protocol, as well as a simple Python tool that let’s the HackRF impersonate a WaveBird and send button presses and stick inputs to an unmodified GameCube.
Forgive the click bait headline, but the latest work from [Marco Bartolucci] and [José A. del Peral-Rosado] is really great. They’re using multiple HackRFs, synchronized together, with hybrid positioning algorithms to derive more precise localization accuracy. (PDF)
Like all SDRs, the HackRF can be used to solve positioning problems using WIFi, Bluetooth, 3G, 4G, and GNSS. Multiple receivers can also be used, but this requires synchronization for time-based or frequency-based ranging. [Bartolucci] and [Peral-Rosado] present a novel solution for synchronizing these HackRFs using a few convenient ports available on the board, a bit of CPLD hacking, and a GNSS receiver with a 1 pps output.
This is technically two hacks in one, the first being a sort of master and slave setup between two HackRFs. Using the Xilinx XC2C64A CPLD on board the HackRF, [Bartolucci] and [Peral-Rosado] effectively chain two devices together. The synchronization error is below one sampling period, and more than two HackRFs can be chained together with the SYNC_IN port of each connected together in parallel. Read more about it in their pull request to the HackRF codebase.
This simplest technique will not work if the HackRF receivers must be separated, which brings us to the second hack. [Bartolucci] and [Peral-Rosado] present another option in that case: using the 1 pps output of a GNNS receiver for the synchronization pulse. As long as both HackRFs can see the sky, they can act as one. Very cool!
Long before everyone had a smartphone or two, the implementation of a telephone was much stranger than today. Most telephones had real, physical buttons. Even more bizarrely, these phones were connected to other phones through physical wires. Weird, right? These were called “landlines”, a technology that shuffled off this mortal coil three or four years ago.
It gets even more bizarre. some phones were wireless — just like your smartphone — but they couldn’t get a signal more than a few hundred feet away from your house for some reason. These were ‘cordless telephones’. [Corrosive] has been working on deconstructing the security behind these cordless phones for a few years now and found these cordless phones aren’t secure at all.
The phone in question for this exploit is a standard 5.8 GHz cordless phone from Vtech. Conventional wisdom says these phones are reasonably secure — at least more so than the cordless phones from the 80s and 90s — because very few people have a duplex microwave transceiver sitting around. The HackRF is just that, and it only costs $300. This was bound to happen eventually.
This is really just an exploration of the radio system inside these cordless phones. After taking a HackRF to a cordless phone, [Corrosive] found the phone technically didn’t operate in the 5.8 GHz band. Control signals, such as pairing a handset to a base station, happened at 900 MHz. Here, a simple replay attack is enough to get the handset to ring. It gets worse: simply by looking at the 5.8 GHz band with a HackRF, [Corrosive] found an FM-modulated voice channel when the handset was on. That’s right: this phone transmits your voice without any encryption whatsoever.
This isn’t the first time [Corrosive] found a complete lack of security in cordless phones. A while ago, he was exploring the DECT 6.0 standard, a European cordless phone standard for PBX and VOIP. There was no security here, either. It would be chilling if landlines existed anymore.
Most old-school remote controlled cars broadcast their controls on 27 MHz. Some software-defined radio (SDR) units will go that low. The rest, as we hardware folks like to say, is a simple matter of coding.
So kudos to [watson] for actually doing the coding. His monster drift project starts with the basics — sine and cosine waves of the right frequency — and combines them in just the right durations to spit out to an SDR, in this case a HackRF. Watch the smile on his face as he hits the enter key and the car pulls off an epic office-table 180 (video embedded below).