“Alexa, What Plane Is That?”

July 2, 2017 by Dan Maloney 7 Comments

We’ve all probably done it — gazed up at a passing jetliner and wondered where it was going and what adventures its passengers were embarked upon. While the latter is hard to answer, the former just got a bit easier: just ask Alexa what the plane is.

Granted, [Nick Sypteras]’s Echo Dot isn’t quite omniscient enough to know exactly what plane you’re looking at. His system benefits from the constraints offered by the window of his Boston apartment — from the video below, we’d guess somewhere in Beacon Hill or the West End — that offers a view of the approach to Logan Airport. An RTL-SDR dongle receives the ADS-B transmissions from all aircraft in the vicinity, and a Raspberry Pi does a lookup, picks the closest plane, and scrapes the departure and arrival airports from FlightRadar24. Alexa does the rest, but we have to confess that hearing “Boeing seven hundred eighty-seven” rather than “seven eighty-seven” would drive us nuts.

If you don’t have the limited view of an airport approach that makes [Nick]’s hack workable, maybe a plane-spotting robot camera would work better for you.

Continue reading ““Alexa, What Plane Is That?”” →

Retro-Styled Raspberry Pi Radio

June 29, 2017 by James Hobson 5 Comments

Ok, so you want a radio — but not just any radio. It has to be wireless, access a variety of music services, and must have a vintage aesthetic that belies its modern innards. Oh, and a tiny screen that displays album art, because that’s always awesome. This 1938 Emerson AX212-inspired radio delivers.

Building on the backbone of a Raspberry Pi Zero W and an Adafruit MAX 98357 mono amp chip, the crux of this single-speaker radio is the program Mopidy. Mopidy is a music player that enables streaming from multiple services, with the stipulation that you have a premium Spotify account. Once signed up, [Tinkernut] helpfully outlines how to set up Mopidy to run automatically once the Pi boots up. The addition of a screen to display album art adds flair to the design, and Adafruit’s 1.8″ TFT LCD screen is small enough to fit the bill.

But wait — there’s more!

Continue reading “Retro-Styled Raspberry Pi Radio” →

TEMPEST In A Software Defined Radio

June 25, 2017 by Brian Benchoff 12 Comments

In 1985, [Wim van Eck] published several technical reports on obtaining information the electromagnetic emissions of computer systems. In one analysis, [van Eck] reliably obtained data from a computer system over hundreds of meters using just a handful of components and a TV set. There were obvious security implications, and now computer systems handling highly classified data are TEMPEST shielded – an NSA specification for protection from this van Eck phreaking.

Methods of van Eck phreaking are as numerous as they are awesome. [Craig Ramsay] at Fox It has demonstrated a new method of this interesting side-channel analysis using readily available hardware (PDF warning) that includes the ubiquitous RTL-SDR USB dongle.

The experimental setup for this research involved implementing AES encryption on two FPGA boards, a SmartFusion 2 SOC and a Xilinx Pynq board. After signaling the board to run its encryption routine, analog measurement was performed on various SDRs, recorded, processed, and each byte of the key recovered.

The results from different tests show the AES key can be extracted reliably in any environment, provided the antenna is in direct contact with the device under test. Using an improvised Faraday cage constructed out of mylar space blankets, the key can be reliably extracted at a distance of 30 centimeters. In an anechoic chamber, the key can be extracted over a distance of one meter. While this is a proof of concept, if this attack requires direct, physical access to the device, the attacker is an idiot for using this method; physical access is root access.

However, this is a novel use of software defined radio. As far as the experiment itself is concerned, the same result could be obtained much more quickly with a more relevant side-channel analysis device. The ChipWhisperer, for example, can extract AES keys using power signal analysis. The ChipWhisperer does require a direct, physical access to a device, but if the alternative doesn’t work beyond one meter that shouldn’t be a problem.

Fail Of The Week: Tracking Meteors With Weather Radio

June 24, 2017 by Dan Maloney 22 Comments

It’s not hard to detect meteors: go outside on a clear night in a dark place and you’re bound to see one eventually. But visible light detection is limiting, and knowing that meteors leave a trail of ions means radio detection is possible. That’s what’s behind this attempt to map meteor trails using broadcast signals, which so far hasn’t yielded great results.

The fact that meteor trails reflect radio signals is well-known; hams use “meteor bounce” to make long-distance contacts all the time. And using commercial FM broadcast signals to map meteor activity isn’t new, either — we’ve covered the “forward scattering” technique before. The technique requires tuning into a frequency used by a distant station but not a local one and waiting for a passing meteor to bounce the distant signal back to your SDR dongle. Capturing the waterfall display for later analysis should show characteristic patterns and give you an idea of where and when the meteor passed.

[Dave Venne] is an amateur astronomer who turns his eyes and ears to the heavens just to see what he can find. [Dave]’s problem is that the commercial FM band in the Minneapolis area that he calls home is crowded, to say the least. He hit upon the idea of using the National Weather Service weather radio broadcasts at around 160 MHz as a substitute. Sadly, all he managed to capture were passing airplanes with their characteristic Doppler shift; pretty cool in its own right, but not the desired result.

The comments in the RTL-SDR.com post on [Dave]’s attempt had a few ideas on where this went wrong and how to improve it, including the intriguing idea of using 60-meter ham band propagation beacons. Now it’s Hackaday’s turn: any ideas on how to fix [Dave]’s problem? Sound off in the comments below.

Decoding NRSC-5 With SDR To Get In Your Car

June 21, 2017 by Lewin Day 14 Comments

NRSC-5 is a high-definition radio standard, used primarily in the United States. It allows for digital and analog transmissions to share the original FM bandwidth allocations. Theori are a cybersecurity research startup in the US, and have set out to build a receiver that can capture and decode these signals for research purposes, and documented it online.

Their research began on the NRSC website, where the NRSC-5 standard is documented, however the team notes that the audio compression details are conspicuously missing. They then step through the physical layer, multiplexing layer, and finally the application layer, taking apart the standard piece by piece. This all culminates in the group’s development of an open-source receiver for NRSC-5 that works with RTL-SDR – perhaps the most ubiquitous SDR platform in the world.

The group’s primary interest in NRSC-5 is its presence in cars as a part of in-car entertainment systems. As NRSC-5 allows data to be transmitted in various formats, the group suspects there may be security implications for vehicles that do not securely process this data — getting inside your car through the entertainment system by sending bad ID3 tags, for instance. We look forward to seeing results of this ongoing research.

[Thanks to Gary McMaster for the tip!]

Long Range Wireless Internet

June 20, 2017 by Bryan Cockfield 46 Comments

While most of you reading this have broadband in your home, there are still vast areas with little access to the Internet. Ham radio operator [emmynet] found himself in just such a situation recently, and needed to get a wireless connection over 1 km from his home. WiFi wouldn’t get the job done, so he turned to a 433 MHz serial link instead. (Alternate link)

[emmynet] used an inexpensive telemetry kit that operates in a frequency that travels long distances much more easily than WiFi can travel. The key here isn’t in the hardware, however, but in the software. He went old-school, implemending peer-to-peer TCP/IP connection using SLIP — serial line Internet protocol. All of the commands to set up the link are available on his project page. With higher gain antennas than came with the telemetry kit, a range much greater than 1 km could be achieved as well.

[Editor’s note: This is how we all got Internet, over phone lines, back in the early Nineties. Also, you kids get off my lawn! But also, seriously, SLIP is a good tool to have in your toolbox, especially for low-power devices where WiFi would burn up your batteries.]

While it didn’t suit [emmynet]’s needs, it is possible to achieve extremely long range with WiFi itself. However this generally requires directional antennas with very high gain and might not be as reliable as a lower-frequency connection. On the other hand, a WiFi link will (in theory) get a greater throughput, so it all depends on what your needs are. Also, be aware that using these frequencies outside of their intended use might require an amateur radio license.

Continue reading “Long Range Wireless Internet” →

CPLD-Based Synchronization Of Multiple Software Defined Radios

June 15, 2017 by Brian Benchoff 15 Comments

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!