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]
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.
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.
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.
[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.
[Julian] was really excited to get his hands on a Nest learning thermostat. It’s round, modern design will make it a showpiece in his home, but he knew there would be a few hiccups when trying to take advantage of its online features. That’s because [Julian] lives in Spain, and Nest is only configured to work in North America. But as you can see above, he did a bit of hacking to get it displaying his actual location.
The Nest is web-connected and phones home to the company’s server to handle configuration. Since they’ve made the decision to only support a portion of the world [Julian] had to do a little bit of digging to bend it to his will. He used Wireshark to sniff the packets it was sending. The calls to the company’s server use SSL, but the device also contacts the Weather Underground for data and this is not encrypted. So he was able to intercept that with his router and inject custom information. It’s not a full solution, but he’s part way there.
We’d really like to see what is possible with this device so please send us a link to any Nest hacks of your own.
Wireshark, a tool recognized universally as being one of the best network analyzers available, has long been used by legitimate network professionals as well as a shadier crowd (and everywhere in between). While useful for analyzing both wired and Wi-Fi traffic, monitoring 802.15.4 protocols (such as Zigbee) have not been a common use in the past. [Akiba] of FreakLabs has brought us a solution which works around the normal limitations of Wireshark’s libpcap base, which does not accept simple serial input from most homebrew setups that use FTDI or Arduinos to connect to Zigbee devices. Using named pipes and a few custom scripts, [Akiba] has been able to coax Wireshark into accepting input from one of FreakLabs Freakduino boards.
While there are certainly professional wireless analyzing tools out there that connect directly into Wireshark, we at Hackaday love showing off anyone who takes the difficult, cheap, out of the way method of doing things over the neat, expensive, commercial method any day.