zigbee

Drone Gives Up Its Wireless Secrets To Zigbee Sniffer

February 8, 2019 by 2 Comments

There’s something thrilling about decoding an unknown communications protocol. You start with a few clues, poke at the problem with some simple tools, and eventually work your way up to that first breakthrough that lets you crack the code. It can be frustrating, but when you eventually win, it can be very rewarding.

It seems that [Jason] learned this while decoding the wireless conversation between his mass-market quad and its controller. The quad in question, a Yuneec Q500, is one of those mid-range, ready-to-fly drones that’s targeted at those looking to get in the air easily and take some cool pictures. Unsure how the drone and controller were talking, [Jason] popped the covers and found a Zigbee chipset within. With the help of a $14 Zigbee USB dongle and some packet sniffing software from TI, [Jason] was able to see packets flowing, but decoding them was laborious. Luckily, the sniffer app can be set up to stream packets to another device, so [Jason] wrote a program to receive and display packets. He used that to completely characterize each controller input and the data coming back from the drone. It’s a long and strange toolchain, but the upshot is that he’s now able to create KML in real time and track the drone on Google Earth as it flies. The video below shows the build and a few backyard test flights.

Congratulations to [Jason] for breaking the protocol and opening up drones like this for other hackers. If you’re interested in learning more about Zigbee sniffing, you can actually hack a few smarthome gadgets into useful sniffers.

Continue reading “Drone Gives Up Its Wireless Secrets To Zigbee Sniffer” →

Which Wireless is Right Wireless?

October 19, 2018 by 24 Comments

Back in the early days of Arduino proliferation (and before you ask, yes we realize there was a time before that too), wireless was a strange and foreign beast. IR communication was definitely a thing. And if you had the funds there was this cool technology called ZigBee that was available, often in funny blue house-shaped XBee boards. With even more funds and a stomach for AT commands you could even bolt on a 2G cell radio for unlimited range. WiFi existed too, but connecting it to a hobbyist ecosystem of boards was a little hairier (though maybe not for our readership).

But as cell phones pushed demand for low power wireless forward and the progression of what would become the Internet of marking Terms (the IoT, of course) began, a proliferation of options appeared for wireless communication. Earlier this week we came across a great primer on some of the major wireless technologies which was put together by Digikey earlier in the year. Let’s not bury the lede. This table is the crux of the piece:

There are some neat entries here that are a little less common (and our old friend, the oft-maligned and never market-penetrating ZigBee). It’s actually even missing some entries. Let’s break it down:

  • Extremely short range: Just NFC. Very useful for transferring small amount of sensitive information slowly, or things with high location-relevance (like between phones that are touching).
  • Short range: BLE, Zigbee, Z-Wave, etc. Handy for so-called Personal Area Networks and home-scale systems.
  • Medium/long range: Wifi, Bluetooth, Zigbee, Z-Wave, LoRaWAN: Sometimes stretching for a kilometer or more in open spaces. Useful for everything from emitting tweets to stitching together a mesh network across a forrest, as long as there are enough nodes. Some of these are also useful at shorter range.
  • Very Long range/rangeless: Sigfox, NB-IoT, LTE Category-0. Connect anywhere, usually with some sort of subscription for network access. Rangeless in the sense that range is so long you use infrastructure instead of hooking a radio up to a Raspberry Pi under your desk. Though LoRa can be a fun exception to that.

You’re unlikely to go from zero to custom wireless solution without getting down into the mud with the available dev boards for a few different common protocols, but which ones? The landscape has changed so rapidly over the years, it’s easy to get stuck in one comfortable technology and miss the appearance of the next big thing (like how LoRaWAN is becoming new cool kid these days). This guide is a good overview to help catch you up and help decide which dev kits are worth a further look. But of course we still want to hear from you below about your favorite wireless gems — past, present, and future — that didn’t make it into the list (we’re looking at you 433 MHz).

Michael Ossmann Pulls DSSS Out of Nowhere

July 29, 2017 by 22 Comments

[Michael Ossmann] spoke on Friday to a packed house in the wireless hacking village at DEF CON 25. There’s still a day and a half of talks remaining but it will be hard for anything to unseat his Reverse Engineering Direct Sequence Spread Spectrum (DSSS) talk as my favorite of the con.

DSSS is a technique used to transmit reliable data where low signal strength and high noise are likely. It’s used in GPS communications where the signal received from a satellite is often far too small for you to detect visually on a waterfall display. Yet we know that data is being received and decoded by every cell phone on the planet. It is also used for WiFi management packets, ZigBee, and found in proprietary systems especially any dealing with satellite communications.

[Michael] really pulled a rabbit out of a hat with his demos which detected the DSSS signal parameters in what appeared to be nothing but noise. You can see below the signal with and without noise; the latter is completely indiscernible as a signal at all to the eye, but can be detected using his techniques.

Strong DSSS Signal, no noise
Same DSSS signal not apparent

Detecting DSSS with Simple Math

[Michael] mentioned simple math tricks, and he wasn’t kidding. It’s easy to assume that someone as experienced in RF as he would have a different definition of ‘simple’ than we would. But truly, he’s using multiplication and subtraction to do an awful lot.

DSSS transmits binary values as a set called a chip. The chip for digital 1 might be 11100010010 with the digital 0 being the inverse of that. You can see this in the slide at the top of this article. Normal DSSS decoding compares the signal to expected values, using a correlation algorithm that multiplies the two and gives a score. If the score is high enough, 11 in this example, then a bit has been detected.

To reverse engineer this it is necessary to center on the correct frequency and then detect the chip encoding. GNU radio is the tool of choice for processing a DSSS capture from a SPOT Connect module designed to push simple messages to a satellite communication network. The first math trick is to multiply the signal by itself and then look at spectrum analysis to see if there is a noticeable spike indicating the center of the frequency. This can then be adjusted with an offset and smaller spikes on either side will be observed.

When visualized in a constellation view you begin to observe a center and two opposite clusters. The next math trick is to square the signal (multiply it by itself) and it will join those opposite clusters onto one side. What this accomplishes is a strong periodic component (the cycle from the center to the cluster and back again) which reveals the chip rate.

Detecting symbols within the chip is another math trick. Subtract each successive value in the signal from the last and you will mostly end up with zero (high signal minus high signal is zero, etc). But every time the signal spikes you’re looking at a transition point and the visualization begins to look like logic traced out on an oscilloscope. This technique can deal with small amounts of noise but becomes more robust with a bit of filtering.

This sort of exploration of the signal is both fun and interesting. But if you want to actually get some work done you need a tool. [Michael] built his own in the form of a python script that cobbles up a .cfile and spits out the frequency offset, chip rate, chip sequence length, and decoded chip sequence.

Running his sample file through with increasing levels of noise added, the script was rock solid on detecting the parameters of the signal. Interestingly, it is even measuring the 3 parts per million difference between the transmitter and receiver clocks in the detected chip rate value. What isn’t rock solid is the actual bit information, which begins to degrade as the noise is increased. But just establishing the parameters of the protocol being used is the biggest part of the battle and this is a dependable solution for doing that quickly and automatically.

You can give the script a try. It is part of [Michael’s] Clock Recovery repo. This talk was recorded and you should add it to your reminder list for after the con when talks begin to be published. To hold you over until then, we suggest you take a look at his RF Design workshop from the 2015 Hackaday Superconference.

Cheap Smarthome Gadget(s) Hacked into Zigbee Sniffer

March 27, 2017 by 7 Comments

French hacker [akila] is building up a home automation system. In particular, he’s been working with the “SmartHome” series of gadgets made by Chinese smartphone giant, Xiaomi. First, he started off by reverse-engineering their very nicely made temperature and humidity sensor. (Original in French, hit the translate button in the lower right.) With that under his belt, he opened up the PIR motion sensor unit to discover that it has the same debugging pinouts and the same processor. Almost too easy.

For a challenge, [akila] decided it was time to implement something useful in one of these gadgets: a ZigBee sniffer so that he can tell what’s going on in the rest of his home network. He built a USB/serial programming cable to work with the NXP JN5169’s bootloader, downloaded the SDK, and rolled up his sleeves to get to work.

While trolling through the SDK, he found some interesting firmware called “JennicSniffer”. Well, that was easy. There’s a demo version of a protocol analyzer that he used. It would be cool to get this working with Wireshark, but that’s a project for another day. [Akila] got far enough with the demo analyzer to discover that the packets sent by the various devices in the home network are encrypted. That’s good news for the security-conscious out there and stands as the next open item on [akila]’s to-do list.

We don’t see as many ZigBee hacks as we’d expect, but they’ve definitely got a solid niche in home automation because of commercial offerings like Philips Hue and Wink. And of course, there’s the XBee line of wireless communications modules. We just wrote up a ZigBee hack that aims to work with the Hue system, though, so maybe times are changing?

A Little IoT for Your PID Tea Kettle

March 9, 2017 by 7 Comments

For some folks, tea is a simple pleasure – boil water, steep tea, enjoy. There are those for whom tea is a sacred ritual, though, and the precise temperature control they demand requires only the finest in water heating technology. And then there are those who take things even further by making a PID-controlled electric tea kettle an IoT device with Amazon Echo integration.

Nothing worth doing isn’t worth overdoing, and [luma] scores points for that. Extra points too for prototyping an early iteration of his design on a RadioShack Electronics Learning Lab – the one with a manual written by Forrest Mims. [luma] started out using an Arduino with a Zigbee shield but realized the resulting circuit would have to live in an external enclosure. Switching to an ESP8266, the whole package – including optoisolators, relays, and a small wall-wart – is small enough to fit inside the kettle’s base. The end result is an MQTT device that publishes its status to his SmartThings home automation system, and now responds when he tells Alexa it’s time for tea.

Projects that hack the means of caffeine are no strangers to Hackaday, whether your preferred vector is tea, coffee, or even straight up.

Continue reading “A Little IoT for Your PID Tea Kettle” →

Create Cheap Philips Hue Compatible Devices

March 1, 2017 by 21 Comments

The Philips Hue range is a great way to add wirelessly controllable lighting to your home, but the protocol is proprietary which makes it difficult to add our own custom hardware. [Peter] found a way to create his own Hue compatible devices based on cheap JN5168 modules that are able to connect to the Hue bridge. This means you can roll out your own lamps using cheap RGB or White LEDs, a power supply and the JN5168 Zigbee Light Link module.

He started off by trying to clone a Zigbee Light Link device to a MeshBee — Seeed studio’s open source Zigbee Pro module based on the NXP JN5168. Even though the MeshBee used the same device as a Hue lamp, it would not connect to the Hue bridge. But another clone lamp called Innr that he purchased from the local hardware store did connect quite easily. Using NXP’s open source tools, he was able to download the flash and EEPROM contents from the Innr and copy them to the MeshBee which did the trick.

After the EEPROM transfer trick, he figured out how to modify the two keys used for the ZigBee protocol — one for Home Automation and the other for the Light Link. With this final discovery he is able to take the ZigBee Light Link demo project, edit it using Beyond Studio, and then load the binaries on the MeshBee device so it can connect to the Hue bridge.

All of this work culminates in two custom firmware binaries; one for white dimmable lights and another for RGB dimmable ones. It even runs on these cheap JN5168 breakout kits he found for a few bucks. With all of the software taken care of, and having cheap ZigBee Light Link compatible modules on hand, building low cost Hue compatible lights becomes pretty straight forward.

Thanks [wind-rider] for the tip.

OpenThread, A Solution To The WiFi Of Things

May 30, 2016 by 45 Comments

The term ‘Internet of Things’ was coined in 1999, long before every laptop had WiFi and every Starbucks provided Internet for the latte-sucking masses. Over time, the Internet of Things meant all these devices would connect over WiFi. Why, no one has any idea. WiFi is terrible for a network of Things – it requires too much power, the range isn’t great, it’s beyond overkill, and there’s already too many machines and routers on WiFi networks, anyway.

There have been a number of solutions to this problem of a WiFi of Things over the years, but none have caught on. Now, finally, there may be a solution. Nest, in cooperation with ARM, Atmel, dialog, Qualcomm, and TI have released OpenThread, an Open Source implementation of the Thread networking protocol.

The physical layer for OpenThread is 802.15.4, the same layer ZigBee is based on. Unlike ZigBee, the fourth, fifth, and sixth layers of OpenThread look much more like the rest of the Internet. OpenThread features IPv6 and 6LoWPAN, true mesh networking, and requires only a software update to existing 802.15.4 radios.

OpenThread is OS and platform agnostic, and interfacing different radios should be relatively easy with an abstraction layer. Radios and networking were always the problem with the Internet of Things, and with OpenThread – and especially the companies supporting it – these problems might not be much longer.