How To Make Amazon Echo Control Fake WeMo Devices

July 16, 2015 by Rick Osgood 27 Comments

[Chris] has been playing with the Amazon Echo. It’s sort of like having Siri or Google Now available as part of your home, but with built-in support for certain other home automation appliances like those from Belkin WeMo and Philips. The problem was [Chris] didn’t want to be limited to only those brands. He had other home automation gear that he felt should work with Amazon Echo, but didn’t. That’s when he came up with the clever idea to just emulate one of the supported platforms.

The WeMo devices use UPnP to perform certain functions over the network. [Chris] wanted to see how these communications actually worked, so he fired up his laptop and put his WiFi adapter into monitor mode. Then he used Wireshark to start collecting packets. He found that the device detection function starts out with the Echo searching for WeMo devices using UPnP. The device then responds to the Echo with the device’s URL using HTTP over UDP. The Echo then requests the device’s description using that HTTP URL. The description is then returned as an HTTP response.

The actual “on/off” functionality of the WeMo devices is simpler since the Echo already knows about the device. The Echo simply connects to the WeMo over the HTTP interface and issues a “SetBinaryState” command. The WeMo then obliges and returns a confirmation via HTTP.

WeMo Echo — How Echo Communicates with WeMo Devices

[Steve] was able to use this information to set up his own WeMo “virtual cloud”. Each virtual device would have its own IP address. They would also need to have a listener for UDP broadcasts as well as an HTTP listener running on the WeMo port 49153. Each virtual device would also need to be able to respond to the UPnP discovery requests and the “on/off” commands.

[Chris] used a Linux server, creating a new virtual Ethernet interface for each virtual WeMo switch. A single Python script runs the WeMo emulation, listening for the UPnP broadcast and sending a different response for each virtual device. Part of the response includes the device’s “friendly name”, which is what the Echo listens for when the user says voice commands. Since the virtual WeMo devices are free, this allows [Chris] to make multiple phrases for each device. So rather than be limited to “television”, he can also make a separate device for “TV” that performs the same function. [Chris] is also no longer limited to only specific brands of home automation gear.

There’s still a long way to go in hacking this device. There’s a lot of hardware under the hood to work with. Has anyone else gotten their hands (and bench tools) on one of these?

Reverse Engineering An RC Spy Tank

March 30, 2015 by Brian Benchoff 15 Comments

[Michael] sells a remote control spy tank through his company, and although it’s a toy, there’s an impressive amount of electronics in this R/C tank. It’s controlled from an Android or iDevice over a WiFi connection, something that simply won’t do if you’re trying to sell this to the hacker and maker crowd. The solution to this problem is Wireshark, and with a little bit of work this spy tank can be controlled from just about anything, from a microcontroller via WiFi to a Python app.

Wireshark, everyone’s favorite network packet analysis and capture tool, was used to listen in on the communications between an iPad and the tank. This immediately showed the video stream coming from the camera in the tank, and pointing VLC to the correct port displayed the video.

The motors in the tank were a little trickier, but looking at the data stream, a few packets stood out as being responsible for controlling the motors. After a little experimentation the simple command set was decoded and a Python app whipped up.

These spy tanks are cheap – about $70 from [Michael]’s company and the other usual vendors. It’s not a particularly useful piece of hardware, but someone out there is sure to do something cool with this bit of reverse engineering.

Reverse Engineering The Kayak Mobile API

January 3, 2015 by Mike Szczys 8 Comments

The travel meta-search website Kayak apparently used to have a public API which is no longer available. We can’t say we mourn the loss of the interface we’d never known about. If you are someone who was automating their searches for that perfect vacation getaway deal, there’s still hope. But either way you’ll like this one. [Shubhro Saha] figured out how to access the API used by the Kayak mobile app. We like that he details how to sniff the traffic between an app and the internet and make sense of what is found.

His tool of choice is the Python package Mitmproxy. We haven’t heard of it but we have heard of Wireshark and [Shabhro] makes the case that Mitmproxy is superior for this application. As the name suggests, you set it up on your computer and use that box’s IP as the proxy connection for your phone. After using the app for a bit, there is enough data to start deconstructing what’s going on between the app and remote server which which it communicates. We could have a lot of fun with this, like seeing what info those free apps are sending home, or looking for security flaws in your own creations.

[Thanks Juan via Twitter]

Protocol Snooping Digital Audio

November 12, 2014 by Elliot Williams 21 Comments

More and more clubs are going digital. When you go out to hear a band, they’re plugging into an ADC (analog-to-digital converter) box on stage, and the digitized audio data is transmitted to the mixing console over Ethernet. This saves the venue having to run many audio cables over long distances, but it’s a lot harder to hack on. So [Michael] trained popular network analysis tools on his ProCo Momentum gear to see just what the data looks like.

[Michael]’s writeup of the process is a little sparse, but he name-drops all the components you’d need to get the job done. First, he simply looks at the raw data using Wireshark. Once he figured out how the eight channels were split up, he used the command-line version (tshark) and a standard Unix command-line tool (cut) to pull the data apart. Now he’s got a text representation for eight channels of audio data.

Using xxd to convert the data from text to binary, he then played it using sox to see what it sounded like. No dice, yet. After a bit more trial and error, he realized that the data was unsigned, big-endian integers. He tried again, and everything sounded good. Success!

While this is not a complete reverse-engineering tutorial like this one, we think that it hits the high points: using a bunch of the right tools and some good hunches to figure out an obscure protocol.

Sniffing NRF24L01+ Traffic With Wireshark

August 5, 2014 by Mathieu Stephan 6 Comments

We’re sure that some of our readers are familiar with the difficult task that debugging/sniffing nRF24L01+ communications can be. Well, [Ivo] developed a sniffing platform based on an Arduino Uno, a single nRF24L01+ module and a computer running the popular network protocol analyzer Wireshark (part1, part2, part3 of his write-up).

As these very cheap modules don’t include a promiscuous mode to listen to all frames being sent on a particular channel, [Ivo] uses for his application a variation of [Travis Goodspeed]’s technique to sniff Enhance Shockburst messages. In short, it consists in setting a shorter than usual address, setting a fix payload length and deactivating the CRC feature. The Arduino Uno connected to the nRF24L01+ is therefore in charge of forwarding the sniffed frames to the computer. An application that [Ivo] wrote parses the received data and forwards it to wireshark, on which can be set various filters to only display the information you’re interested in.

Reverse Engineering An HDMI Extender

January 25, 2014 by Eric Evenchick 63 Comments

There’s a number of devices out there that extend HDMI over IP. You connect a video source to the transmitter, a display to the receiver, and link the two with a CAT5/5e/6 cable. These cables are much cheaper than HDMI cables, and can run longer distances.

[Daniel] didn’t care about extending HDMI, instead he wanted a low cost HDMI input for his PC. Capture cards are a bit expensive, so he decided to reverse engineer an IP HDMI extender.

After connecting a DVD player and TV, he fired up Wireshark and started sniffing the packets. The device was using IP multicast on two ports. One of these ports had a high bitrate, and contained JPEG headers. It looked like the video stream was raw MJPEG data.

The next step was to write a listener that could sniff the packets and spit the data into a JPEG file. After dealing with some quirks, JPEG images could be saved from the remote device. Some more code was needed to have the computer initiate the streaming, and to extract audio from the second port.

In the end, video capture with the low cost device was possible. [Daniel] also provided a bonus teardown of the device in his writeup.

USB Sniffing With The BeagleBoard-xM

July 2, 2013 by Mike Szczys 21 Comments

[Matlo] wrote in to share his USB sniffing project using the BeagleBoard-xM. It builds on the Google Summer of Code project from 2010 that used the non-xM version of the hardware to build a pass through USB sniffer. [Matlo] couldn’t get it to work back then, but recently revisited the project. He’s cleaned up some scripts and generally made it a bit easier for others to pull off as well.

The ARM-based BeagleBoard seen above acts as man-in-the-middle. You connect your target USB device to the board and the board to a computer. The board emulates the target device, passing packets in either direction while also logging them. The captured data is in the correct format for display using WireShark, the de facto standard for making sense of captured communication packets.

This is great for figuring out how to use USB devices on non-standard systems, or vice versa.