Reverse Engineering an HDMI Extender

reverse-engineer-hdmi-extender

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

usb-sniffer-from-beaglebone-xm

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

Getting a Nest thermostat to work in Europe

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

Bringing the Shark to the Bee

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.

Wireshark 1.2.0 available

wireshark

Everyone’s favorite packet sniffer has a new stable release. Wireshark 1.2.0 has a slew of new features. They’ve included a 64-bit Windows installer and improved their OSX support. A number of new protocols are recognized and filter selection autocompletes. One of the more interesting additions is the combined GeoIP and OpenStreetMap lookups. We’re excited about this new release as Wireshark has proven an indispensable tool in the past for figure out exactly what was going on on our network.

[via Lifehacker]

The Malware Challenge

malware

Our own [Anthony Lineberry] has written up his experience participating in the 2008 Malware Challenge as part of his work for Flexilis. The contest involved taking a piece of provided malware, doing a thorough analysis of its behavior, and reporting the results. This wasn’t just to test the chops of the researchers, but also to demonstrate to network/system administrators how they could get into malware analysis themselves.

[Anthony] gives a good overview of how he created his entry (a more detailed PDF is here). First, he unpacked the malware using Ollydbg. Packers are used to obfuscate the actual malware code so that it’s harder for antivirus to pick it up. After taking a good look at the assembly, he executed the code. He used Wireshark to monitor the network traffic and determine what URL the malware was trying to reach. He changed the hostname to point at an IRC server he controlled. Eventually he would be able to issue botnet control commands directly to the malware. We look forward to seeing what next year’s contest will bring.

Passive network tap

Making a passive network tap can be an easy and inexpensive undertaking as shown in this Instructable. Passive monitoring or port mirroring is needed because most networks use switches which isolate the network traffic and this does not allow for the entire network to be monitored.  This example uses a single tap, using multiple taps will provide access to the full-duplex data separately. By using two taps you are able to monitor inbound data that is passed through one tap, and outbound data that is passed through the other tap.  Separate taps are desired because most sniffer software handles half-duplex traffic only and requires two network cards for full-duplex.

[Read more...]