By now most Hackaday readers should be familiar with this year’s latest advance in software defined radio. With a simple USB TV tuner dongle, it’s possible to receive FM broadcasts, GPS data from satellites, and even telemetry from aircraft flying overhead. There is one limitation to this setup, though: it’s receive only. Hacker extraordinaire [Michael Ossmann] is looking to make a better software defined radio called the HackRF.

The HackRF is an incredibly ambitious project – able to receive just about anything between 100 MHz and 6 GHz (this includes everything from the top of the FM radio band to cordless phones, cell phones, WiFi, and basically any radio technology that has been commercialized in the last 15 years), the HackRF is also able to transmit. Yes, with the HackRF it’s possible to build your own software-defined WiFi module, or just broadcast bogus GPS information.

Compared to the $20 TV tuner SDR dongles we’ve played around with, the HackRF isn’t exactly cheap. [Mossmann] figures he’ll be able to sell the device for about $300. A fair bit of change, but much, much less than professional, commercial SDR solutions.

A very cool advance in the state of SDR, but reason dictates we must suggest that everyone who wants a HackRF to start studying for their amateur radio exam now. Being a licensed radio operator won’t stop you from any sort of malicious intent, but with at least with licensing comes with the possibility of knowing what evil you’re doing.

You can check out the wiki for the HackRF over on the gits along with the current hardware design

Up on Kickstarter, [Michael Ossmann] is launching the HackRF, an inordinately cheap, exceedingly capable software defined radio tool that’s small enough to lose in your laptop bag.

The HackRF was the subject of a lot of interest last time it was on Hackaday – the ability to receive up to 6GHz allows the HackRF to do a lot of very interesting things, including listening in on Bluetooth, WiFi, and 4G networks. Also, the ability to transmit on these frequencies means a lot of very interesting, and quite possibly slightly evil applications are open to anyone with a HackRF. Like the RTL-SDR dongles, the HackRF works with GNU Radio out of the box, meaning all those cool SDR hacks we’ve seen so far will work with this new, more powerful board.

Compared to the USB TV tuner cards that were so popular a year ago, the HackRF has 10 times the bandwidth, is able to receive up to 6GHz, and is also able to transmit. It’s only half-duplex, so to receive and transmit simultaneously you’ll need two HackRFs, or maybe wait for a hardware revision that will hopefully come sooner rather than later.

Below you can check out [Michael]‘s presentation at Toorcon where the HackRF was unleashed to the world.

In the market for a software defined radio? [Taylor Killian] wrote a comprehensive comparison of several models that are within the price range of amateurs and hobbyists.

You can get started with SDR using a $20 TV tuner card, but there’s a lot of limitations. These cards only work as receivers, are limited to a small chunk of the radio spectrum, and have limited bandwidth and sample rates. The new SDRs on the market, including the bladeRF, HackRF, and USRP offerings are purpose built for SDR experimentation. You might want an SDR to set up a cellular base station at Burning Man, scan Police and Fire radio channels, or to track ships.

[Taylor] breaks down the various specifications of each radio, and discusses the components used in each SDR in depth. In the end, the choice depends on what you want to do and how much you’re willing to spend. This breakdown should help you choose a hacker friendly SDR.

Back in 2013, the NSA ANT Catalog was leaked. This document contained a list of devices that are available to the NSA to carry out surveillance.

[Michael Ossmann] took a look at this, and realized that a lot of their tools were similar to devices the open source hardware community had built. Based on that, he gave a talk on The NSA Playset at Toorcamp 2014. This covered how one might implement these devices using open hardware.

The above image is a parody of an ANT Catalog page, which shows [Michael]‘s HackRF, an open source software defined radio. In the talk, [Michael] and [Dean Pierce] go over the ANT Catalog devices one by one, discussing the hardware that would be needed to build your own.

Some of these tools already have open source counterparts. The NIGHTSTAND WiFi exploitation tools is essentially a WiFi Pineapple. SPARROW II is more or less a device running Kismet attached to a drone, which we’ve seen before.

A video of the Toorcamp talk is available on [Michael]‘s blog. There will also be a variety of talks on this subject at DEFCON next week, which we’re looking forward to. For further reading, Wikipedia has a great summary of the ANT Catalog.

What do you get when you combine one of the best (and certainly one of the best for the price) software defined radios with the user interface of a 10-year-old iPod? The HackRF PortaPack, developed by [Jared Boone], and demonstrated at DEFCON last weekend.

[Jared] is one of the original developers for the HackRF, a 10MHz to 6GHz software defined radio that can also transmit in half duplex. Since the development of the HackRF has (somewhat) wrapped up, [Jared] has been working on the PortaPack, an add-on for the HackRF that turns it into a portable, ARM Cortex M4-powered software defined radio. No, it’s not as powerful as a full computer running GNU Radio, but it does have the capability to listen in on a surprising amount of radio signals.

Because [Jared] is using a fairly low-power micro for the PortaPack, there’s a lot of tricks he’s using to get everything running smoothly. He gave a lightning talk at the Wireless Village at DEFCON going over the strengths and weaknesses of the chip he’s using, and surprisingly he’s using very little floating point arithmetic in his code. You can check out the video for that talk below.

Remember that episode of Leverage (season 5, episode 3), where Alec uses Marvin to wirelessly change all the street lights green so they can catch up to an SUV? And you scoffed and said “that’s so not real!”… well actually they got it right. A new study out of the University of Michigan (PDF warning), shows just how easy it is to make your morning commute green lights all the way.

The study points out that a large portion of traffic lights in the United States communicate with each other wirelessly over the 900Mhz and 5.8Ghz ISM band with absolutely no encryption. In order to connect to the 5.8Ghz traffic signals, you simply need the SSID (which is set to broadcast) and the proper protocol. In the study the researchers used a wireless card that is not available to the public, but they do point out that with a bit of social engineering you could probably get one. Another route is the HackRF SDR, which could be used to both sniff and transmit the required protocol. Once connected to the network you will need the default username and password, which can be found on the traffic light manufacturer’s website. To gain access to the 900Mhz networks you need all of the above and a 16-bit slave ID. This can be brute forced, and as the study shows, no ID was greater than 100. Now you have full access, not to just one traffic signal, but EVERY signal connected to the network.

Once on the network you have two options. The completely open debug port in the VxWorks OS which allows you to read-modify-write any memory register. Or by sending a(n) UDP packet where the last byte encodes the button pressed on the controller’s keypad. Using the remote keypad you can freeze the current intersection state, modify the signal timing, or change the state of any light. However the hardware Malfunction Management Unit (MMU) will still detect any illegal states (conflicting green or yellow lights), and take over with the familiar 4-way red flashing. Since a technician will have to come out and manually reset the traffic signal to recover from an illegal state, you could turn every intersection on the network into a 4-way stop.

So the next time you stop at a red light, and it seems to take forever to change, keep an eye out for the hacker who just green lit their commute.

Thanks for the tip [Matt]

For anyone getting into the world of Software Defined Radio, the first purchase should be an RTL-SDR TV tuner. With a cheap, $20 USB TV tuner, you can listen to just about anything between 50 and 1750 MHz. You can’t send, the sample rate isn’t that great, but this USB dongle gives you everything you need to begin your explorations of the radio spectrum.

Your second Software Defined Radio purchase is a matter of contention. There are a lot of options out there for expanding a rig, and the HackRF is a serious contender to expand an SDR rig. You get 10 MHz to 6 Gigahertz operating frequency, 20 million samples per second, and the ability to transmit. You have your license, right?

Unfortunately the HackRF is a little expensive and is unavailable everywhere. [Gareth] is leading the charge and producing the HackRF Blue, a cost-reduced version of the HackRF designed by [Michael Ossmann].

The HackRF Blue’s feature set is virtually identical, and the RF performance is basically the same: both the Blue and the HackRF One can get data from 125kHz RFID cards. All software and firmware is interchangeable. If you were waiting on another run of the HackRF, here ‘ya go.

[Gareth] and the HackRF Blue team are doing something rather interesting with their crowdfunding campaign: they’re giving away Blues to underprivileged hackerspaces, with hackerspaces from Togo, Bosnia, Iran, India, and Detroit slated to get a HackRF Blue if the campaign succeeds.

Thanks [Praetorian] and [Brendan] for sending this in.

It hasn’t become a household term yet, but Software-Defined Radio (SDR) is a major player on the developing technology front. Whether you’re building products for mass consumption, or just playing around for fun, SDR is worth knowing something about and I’ll prove it to you.

SDR Boils Down a Hard Problem

First off let’s reconcile what is meant by “radio”. If it sends or receives via radio frequency it has a radio in it. This means your WiFi router, your cellphone, your laptop, many water and electrical meters, your garage door opener (but not your TV remote, that uses light), wireless security system sensors, police radios, your wireless mouse/keyboard, and that quadcopter you keep crashing in the neighbor’s yard all have one. Radios are so prolific we’re tempted to tell you they’re in absolutely everything.

Radio used to be a lot harder. On the communications side of things you could buy an expensive radio receiver and/or transmitter that required a skilled operator to use. At a lower level, you would be looking at choosing a specific band and dealing with things like modulator, mixer, and filter design, along with plenty of roadblocks to manufacturing which would also lock you into a specific application.

Software-Defined Radio solves some of these problems by allowing you to control how the radio hardware functions based on software. The advent of this has also been boosted by the availability of inexpensive hardware produced at scale. It is not the end-all of radio, but it makes the problem easier. That has led to wider adoption but we think what has been seen so far is only the tip of the iceberg.

Seen here is the USRP N210 which is a professional tool used by hardware developers that work with RF in their products. This tool proved to be so popular that National Instruments bought designer Ettus Research and now incorporate the USRP with their LabVIEW systems. The midrange USRP-210 model is a very capable SDR, operating DC to 6 GHz.

You Can Change It After It’s Built

The multiplier is, of course, crowd-sourcing development. One forecast of the future is a connected world. If device firmware has been released as Open Source, a motivated community will find a way to make that hardware even more useful.

In the next section I’m going to talk about the DVB-T dongle seen here. But one important thing to realize about it is that the chip inside this device is an SDR and is already in use commercially. The versatility of the chipset inside proves the point that SDR is a viable choice in consumer hardware. I’d love to see reliable numbers on how many of these have been sold to watch television, versus to tinker with SDR. Either way it’s great for the companies churning them out.

Start Learning for a Few Dollars

Don’t be ashamed if you know next-to-nothing about all of this. That’s where most people stand, and you don’t have to spend big or know much to dabble in SDR. Let’s face it, wireless communication is as close as a pragmatic mind will get to calling something “magic” and that makes SDR a delight.

Starting Simple

The thing that really turned my head was the advent of what is known as RTL-SDR. This is the practice of using television tuner USB dongles for Software-Defined Radio. That’s right, these “DVB Sticks” are made to watch broadcast television on a computer but inside is a Realtek 2832U.

Connecting the dongle to your computer and launching some software allows you to listen in — both audible signals and transmitted data — on all kinds of things. We’re enjoyed reading [Dr. Droopy Nayhey’s] SDR guide on Hackaday.io because he’s taking this route. $12 in hardware (plus the computer and cables to be fair) and he’s tracking aircraft, listening to emergency band, FM radio, and “treasure hunting” for all the things in our world that are transmitting.

Don’t be afraid of this, these are receivers-only so you need no license or prior training. We’ve seen these morph into automated airplane filming rigs and you could end up adding to the flight tracking data network of FlightAware. The Grand Prize winners of the 2014 Hackaday Prize even built a satellite receiving station around a DVB dongle! See that little black stick centered vertically? Satellites do transmit information back to earth, you just need to listen for the data.

For getting started, and well-targetted applications, these dongles are a good option. But they are limited from around 22MhZ to 2200Mhz depending on which particular dongle you have. Going beyond those limits requires a jump to different hardware.

Getting More Serious

Earlier I said that SDR solves some problems but certainly not all. One device can’t rule all RF communications (yet). So those getting a bit more serious look to purpose-built SDR rather than piggy-backing on those TV receivers. This is still better in many ways than radio equipment of yore, as these boards boasts a highly versatile set of features.

Here we see an interesting take on SDR which placed 3rd in the 2014 Hackaday Prize. PortableSDR does away with the need for a computer to drive the software side of things and puts the circuitry in a durable case with a dedicated display as part of the user interface. It is aimed at people who are getting more serious about amateur radio, but as it stands is still a receive-only instrument.

On Monday we made an appeal for a Cinderella-story finish for the PortableSDR Kickstarter. I’m still hoping that this one makes it as I do believe it’s part of the modernization of the amateur radio movement.

Another example of that rebirth is SDR equipment specifically designed for amateur radio operators. We’ve been watching one such build as it progresses. This one centers around a Softrock SDR board which is controlled by a Teensy 3.1 and again, has a dedicated user interface that requires no computer. Notice the convergence here between traditional ham radio skills and the hacker movement?

Conclusion

Need I say more? There’s a growing movement of people who are playing with SDR. That will lead to interesting new applications and I believe it will eventually drive consumer electronic design. But if you need more inspiration, just look at the kinds of things people are building around SDR and make your own predictions.

[Featured image source: HDSDR.de]

Conference badges are getting more complex each year. DEFCON, LayerONE, Shmoocon, The Next Hope, Open Hardware Summit, The EMF, SAINTCON, SXSW Create, The Last Hope, TROOPERS11, ZaCon V and of course the CCC, have all featured amazing badges over the years. This years CCCamp 2015 rad1o badge is taking things several notches higher. The event will run from 13th through 17th August, 2015.

The rad1o Badge contains a full-featured SDR (software defined radio) transceiver, operating in a frequency range of about 50 MHz – 4000 MHz, and is software compatible to the HackRF One open source SDR platform. The badge uses a Wimax transceiver which sends I/Q (in-phase/quardrature-phase) samples in the range of 2.3 to 2.7 GHz to an ARM Cortex M4 CPU. The CPU can process the data standalone for various applications such as FM radio, spectrogram display, RF controlled power outlets, etc., or pass the samples to a computer using USB 2.0 where further signal processing can take part, e.g. using GnuRadio. The frequency range can be extended by inserting a mixer in the RF path. Its got an on-board antenna tuned for 2.5GHz, or an SMA connector can be soldered to attach an external antenna. There’s a Nokia 6100 130×130 pixel LCD and a joystick, which also featured in the earlier CCCamp 2011 badge known as the r0ket.

A 3.5mm TRRS audio connector allows hooking up a headphone and speaker easily. The LiPo battery can be charged via one of the USB ports, while the other USB port can be used for software updates and data I/O to SDR Software like GnuRadio. Check out the project details from their Github repository and more from the detailed wiki which has information on software and hardware. There’s also a Twitter account if you’d like to follow the projects progress.

This years Open Hardware Summit also promises an awesome hackable badge. We’ll probably feature it before the OHS2015 conference in September.

Thanks to [Andz] for tipping us off about this awesome Badge.

The first talk at 2016 Shmoocon was a great one. Joseph Hall and Ben Ramsey presented their work hacking Z-Wave, a network that has been gaining a huge market share in both consumer and industrial connected devices. EZ-Wave uses commodity Software Defined Radio to exploit Z-Wave networks. This is not limited to sniffing, but also used for control with the potential for mayhem.

Z-Wave is a proprietary wireless protocol which operates in the 900 Mhz spectrum. This spectrum is great for penetrating walls and floors which is part of the reason Z-Wave has been seeing a lot of success in the market.

To being their research, Joseph and Ben looked to see what tools are already available. OpenZWave is available but doesn’t support operations outside of the protocol. Two other options are Z-Force and Scapy0-radio. Both presented at past Blackhat Conferences and looked promising, but lacked availability. They decided to roll their own.

EZ-Wave is a chain of different tools. ezstumbler is used for network discovery; are there Z-Wave devices in use around us? ezrecon interrogates devices once a network has been found, yielding the software version, supported commands, current state*, and current configuration*. These last two traits (marked with asterisks) are not available on encrypted devices. With this in mind, the question becomes: how many devices are using encryption. As I’m sure you guessed, the answer is few.

Joseph and Ramsey purchased 33 different Z-Wave devices currently on the market and tested them. The test hardware is quite familiar to us. During the talk they demonstrated detecting, contacting, and controlling devices using a pair of HackRF One, the spectacular unit developed by Michael Ossmann who is also on hand for this year’s Shmoocon. One unit was issuing commands, the other unit was listening for Z-Wave packets.

In their tests of these 33 units the researchers found only nine utilized encryption. Five of the nine were Z-Wave enabled door locks — good on them for having encryption. The really bad news is that 3 of the remaining four had “opt-in” encryption that only runs if the user explicitly configures them to use it.

I previously alluded to the mayhem that is opened up by these unencrypted systems. During the talk, a paper discussing damage to industrial compact fluorescent lights (PDF) was referenced that showed bulbs can be damaged by turning them on and off using specific timings. This is due to thermal stress — turn them on and they warm up, turn them off and they cool down, repeat. The trick is to figure out how quickly they can be switched while still maximizing the thermal stress. Their testing determined that it is possible to destroy CFLs in half of one night. Why? Mayhem is a reason in itself, but industrial espionage is another. If all the lights in an entire warehouse are destroyed in a single night it will disrupt work for quite some time. Sure, we’re only talking CFLs in this example, but there are all kinds of other devices using the technology. I live in a cold climate. If someone turns off your thermostat for an extended period of time the water pipes in your house will freeze and burst.

Of course this isn’t all doom and gloom. The moral of the story is that as the number of connected devices grows, encryption must be included and should be enabled by default.

Using Xcode to spoof GPS locations in Pokemon Go (like we saw this morning) isn’t that much of a hack, and frankly, it’s not even a legit GPS spoof. After all, it’s not like we’re using an SDR to spoof the physical GPS signal to cheat Pokemon Go.

To [Stefan Kiese], this isn’t much more than an exercise. He’s not even playing Pokemon Go. To squeeze a usable GPS signal out of his HackRF One, a $300 Software Defined Radio, [Stefan] uses an external precision clock. This makes up for the insufficient calibration of the HackRF’s internal clock, although he points out that this might also be fixed entirely in software.

Using SatGen and a conversion tool that comes with the software-defined GPS signal simulator gps-sdr-sim, [Stefan] turned a *.KML-exported GoogleEarth path into a *.CSV file that can be played back by the GPS simulator.

After firing up the GPS transmission, he found his avatar running happily through the Pokemon world. Someone still has to write the code that lets you navigate freely and actually catch ’em all, but it looks doable, and we are curious to see how and if it will affect the game. For the novice SDR cheater, [Stefan] has some extra advice: Disable A-GPS on your device and use a signal attenuator on the SDR (a shielded box should do).

A legit GPS spoof might still exceed the efforts and investments the average player might want to undertake. Meaning, that if done right, you might actually get away with it. If done wrong however, the legal consequences might be even more severe. But how many players will actually go so far to try this? And will Niantic be able to reliably detect SDR cheaters? What do you think? Let us know in the comment section!

Thanks to [sabas1080] for the tip!

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

If JavaScript is your thing, you should check out this project. It uses the node-hackrf library to communicate with the SDR, and it looks pretty straightforward. Why let the C-coding folks have all the fun? Start scripting your own remote control car maneuvers today!

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.

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!

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.

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.

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.

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.

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.

[Thanks to DarkSim905 for the tip.]

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]

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

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