Software Defined Radio Hack Chat

Join us on Wednesday, September 18 at noon Pacific for the Software Defined Radio Hack Chat with Corrosive!

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.)

join-hack-chatOur Hack Chats are live community events in the Hackaday.io Hack Chat group messaging. This week we’ll be sitting down on Wednesday, September 18 at 12:00 PM Pacific time. If time zones have got you down, we have a handy time zone converter.

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.

Side-Channel Attack Shows Vulnerabilities Of Cryptocurrency Wallets

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.

[via RTL-SDR.com]

Your Table Is Ready, Courtesy Of HackRF

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.

We saw some very similar techniques demonstrated at the recent WOPR Summit security conference, so once you’re done hacking the local restaurants, you can take these same lessons and apply them to the rest of the Internet of Things. If you’re wondering, it’s even easier to eavesdrop on the non-restaurant pagers.

Continue reading “Your Table Is Ready, Courtesy Of HackRF”

Desktop Radio Telescope Images The WiFi Universe

It’s been a project filled with fits and starts, and it very nearly ended up as a “Fail of the Week” feature, but we’re happy to report that the [Thought Emporium]’s desktop WiFi radio telescope finally works. And it’s pretty darn cool.

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.

Continue reading “Desktop Radio Telescope Images The WiFi Universe”

Shmoocon: Delightful Doppler Direction Finding With Software Defined Radio

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.

Reverse Engineering The Nintendo Wavebird

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.

Finding the center frequency for the WaveBird

Given the immense popularity of the WaveBird, [Sam Edwards] was somewhat surprised to find very little information on how the controller actually worked. Looking for a project he could use his HackRF on, [Sam] decided to see if he could figure out how his beloved WaveBird communicated with the GameCube. This moment of curiosity on his part spawned an awesome 8 part series of guides that show the step by step process he used to unlock the wireless protocol of this venerable controller.

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.

This amount of work is usually reserved for those looking to create their own controllers from the ground up, so we appreciate the effort [Sam] has gone through to come up with something that can be used on stock hardware. His research could have very interesting applications in the world of “tool-assisted speedruns” or even automating mindless stat-grinding.

CPLD-Based Synchronization Of Multiple Software Defined Radios

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!