If you’ve been into hobby electronics for even a short time, chances are you’ve got at least one software-defined radio lying around. From the cheap dongles originally intended to watch digital TV on a laptop to the purpose-built transmit-capable radio playgrounds like HackRF, SDR has opened up tons of RF experimentation. Before SDR, every change of band or mode would need new hardware; today, spinning up a new project is as simple as dragging and dropping a few blocks around on a screen, and SDRs that can monitor huge swaths of radio spectrum for the tiniest signal have been a boon to reverse engineers everywhere.
Corrosive is the handle of Harold Giddings, amateur callsign KR0SIV, and he’s gotten into SDR in a big way. Between his blog, his YouTube channel, and his podcast, all flying under the Signals Everywhere banner, he’s got the SDR community covered. Whether it’s satellite communications, aircraft tracking, amateur radio, or even listening in on railway operations, Harold has tried it all, and has a wealth of SDR wisdom to share. Join us as we discuss the state of the SDR ecosystem, which SDR to buy for your application, and even how to transmit with an SDR (hint: you’ll probably want a ham license.)
Click that speech bubble to the right, and you’ll be taken directly to the Hack Chat group on Hackaday.io. You don’t have to wait until Wednesday; join whenever you want and you can see what the community is talking about.
What’s in your crypto wallet? The simple answer should be fat stacks of Bitcoin or Ethereum and little more. But if you use a hardware cryptocurrency wallet, you may be carrying around a bit fat vulnerability, too.
At the 35C3 conference last year, [Thomas Roth], [Josh Datko], and [Dmitry Nedospasov] presented a side-channel attack on a hardware crypto wallet. The wallet in question is a Ledger Blue, a smartphone-sized device which seems to be discontinued by the manufacturer but is still available in the secondary market. The wallet sports a touch-screen interface for managing your crypto empire, and therein lies the weakness that these researchers exploited.
By using a HackRF SDR and a simple whip antenna, they found that the wallet radiated a distinctive and relatively strong signal at 169 MHz every time a virtual key was pressed to enter a PIN. Each burst started with a distinctive 11-bit data pattern; with the help of a logic analyzer, they determined that each packet contained the location of the key icon on the screen.
Next step: put together a training set. They rigged up a simple automatic button-masher using a servo and some 3D-printed parts, and captured signals from the SDR for 100 presses of each key. The raw data was massaged a bit to prepare it for TensorFlow, and the trained network proved accurate enough to give any hardware wallet user pause – especially since they captured the data from two meters away with relatively simple and concealable gear.
Every lock contains the information needed to defeat it, requiring only a motivated attacker with the right tools and knowledge. We’ve covered other side-channel attacks before; sadly, they’ll probably only get easier as technologies like SDR and machine learning rapidly advance.
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!