Discovering The Protocol In A USB VoIP Phone

November 2, 2014 by 3 Comments

[Daniel] picked up a cheap USB handset to use with his VoIP provider, and included in the box was a CD with all the software that would make this handset work with Windows. [Daniel] is running Linux on his main battlestation, rendering the included CD worthless. Using the handset under Linux would be a problem; although the speaker and mic worked, the buttons and screen did not. No problem, then: [Daniel] just played around with the command line until he figured it out.

The handset presented itself to the Linux box as a soundcard and HID device. The soundcard was obviously the speaker and mic, leaving the buttons and display as the HID device. [Daniel] checked this out by running a hexdump on the HID device and pressed a few buttons. His suspicions were confirmed, and he could easily read the button with a little bit of Python.

With the speaker, mic, and buttons on the handset figured out, [Daniel] turned his attention to the one bit of electronics on the phone he hadn’t yet conquered: the display. After firing some random data at the phone, the display blinked and showed a messy block of pixels, confirming the display was controlled through the HID driver. Loading up usbsnoop to see what the original software does to update the screed showed [Daniel] the data format the display accepts, allowing him to control everything in this VoIP phone.

Scripting Debug Sessions: Python For GDB Remote Serial Protocol

September 22, 2014 by 10 Comments

Are you tired of hammering out the same commands over and over again in GDB? If not, we highly encourage you take more advantage of The GNU Project Debugger, which is a fantastic way to poke around inside your microcontrollers while they’re running a program.

Back to the matter at hand. [Stef] put together a Python program that leverages GDB’s Remote Serial Protocol. He calls it pyrsp and the talk he recently gave about it can be seen below.

The core feature is the ability to add a callback in your C code that triggers the Python script. Think of this a little bit like a print statement, except you have so much more power since it’s Python and GDB doing the “printing”. Anything that can be done at a breakpoint in GDB can now be executed automatically. So if you need to check a group of registers at every loop execution for hundreds of loops your wrists are going to thank you. Better yet, you can use Python to do the sanity checks automatically, continuing when the data is good and alerting you when it’s not. Neat!

Continue reading “Scripting Debug Sessions: Python For GDB Remote Serial Protocol” →

The Development Of A Lightweight Wireless Protocol

June 12, 2014 by 30 Comments

BANO[Texane] had been thinking about how to monitor the state of his garage door from a remote place. The door itself isn’t around any power outlets, and is a few floors away from where his server would be located in his apartment. This presented a few design challenges – namely, the sensor itself should have a wireless connection to the server, and being low power would be a great idea. This led to the development of a minimalist framework for wireless communication that allows a sensor to run for weeks without a battery swap.

The wireless protocol itself is based on a simple key value pair; each individual sensor, coupled with a NRF905 radio, has passes an address, a key, and a value. There are allowances for checksums and acknowledgement, but as the PDF says, this is a very minimal protocol.

With the software out of the way, [Texane] turned to the hardware. The microcontroller is a simple Arduino clone, paired with a radio and a coin cell on a small board. The micro spends most of its time in a low power state, with the sensor, in this case a reed switch, tied to an interrupt pin.

There was a problem with the power consumption of the radio, though: when the short 17-byte message was transmitting, there was a significant voltage drop. This was okay with a fully charged battery, but with a partially drained coin cell, the possibility of brownouts was high. A big cap in parallel was enough to offset this voltage drop.

It’s still a little expensive for an all-in-one home automation and monitoring system, but developing a functional wireless protocol and the hardware to go with it is no small feat. It’s actually a great piece of kit that [Texane] is sure to find a few uses for.

Verifying A Wireless Protocol With RTLSDR

January 31, 2014 by 1 Comment

rtlsdr_nrf905_rtlizer

[Texane] is developing a system to monitor his garage door from his apartment. Being seven floors apart, running wires between the door and apartment wasn’t an option, so he turned to a wireless solution. Testing this wireless hardware in an apartment is no problem, but testing it in situ is a little more difficult. For that, he turned to software defined radio with an RTLSDR dongle.

The hardware for this project is based around a TI Stellaris board and a PTR8000 radio module. All the code for this project was written from scratch (Github here), making it questionable if the code worked on the first try. To test his code, [Texane] picked up one of those USB TV tuner dongles based around the RTL2832U chipset. This allowed him to monitor the frequencies around 433MHz for the packets his hardware should be sending.

After that, the only thing left to do was to write a frame decoder for his radio module. Luckily, the datasheet for the module made this task easy.

[Texane] has a frame decoder for the NRF905 radio module available in his Git. It’s not quite ready for serious applications, but for testing a simple radio link it’s more than enough.

Designing, Simulating And Testing A Simple Radio Duty-Cycling Protocol For Contiki

January 9, 2014 by 1 Comment

A few days ago we featured [Marcus]’ Contiki port to the TI Launchpad, Contiki being an open source operating system dedicated to the Internet of Things created by [Adam Dunkels] at the SICS in Sweden. Part of [Marcus]’ work involved designing a simple radio duty-cycling protocol that achieves 3% idle listening duty cycle while allowing for an average 65ms latency with no prior contact or synchronization.

As a few readers may already know, it takes quite a lot of power for a wireless device to listen/send data. A platform therefore needs to have an algorithm that minimizes power consumption while allowing a (regular) planned data transfer. After creating his protocol named SimpleRDC, [Marcus] first simulated it using the Cooja simulator in order to check that it could perform as desired. He then implemented a real life test and checked the protocol’s performance by sniffing the SPI lines connecting his MSP430 to the wireless module and by monitoring the platform power consumption with his oscilloscope and a shunt resistor.

Sniffing Out LG Smart TV Tracking Protocol

November 23, 2013 by 68 Comments

[DoctorBeet] noticed the advertisements on the landing screen of his new LG smart television and started wondering about tracking. His curiosity got the better of him when he came across a promotional video aimed at advertisers that boasts about the information gathered from people who use these TVs. He decided to sniff the web traffic. If what he discovered is accurate, there is an invasive amount of data being collect by this hardware. To make matters worse, his testing showed that even if the user switches the “Collection of watching info” menu item to off it doesn’t stop the data from being phoned home.

The findings start off rather innocuous, with the channel name and a unique ID being transmitted every time you change the station. Based on when the server receives the packets a description of your schedule and preferred content can be put together. This appears to be sent as plain data without any type of encryption or obfuscation.

Things get a lot more interesting when he discovers that filenames from a USB drive connected to the television are being broadcast as well. The server address they’re being sent to is a dead link — which makes us think this is some type of debugging step that was left in the production firmware — but it is still a rather sizable blunder when it comes to personal privacy. If you have one of these televisions [DoctorBeet] has a preliminary list of URLs to block with your router in order to help safeguard your privacy.

[Thanks Radcom]

CAN Hacking: Protocols

October 29, 2013 by 44 Comments

We’ve gone over the basics of CAN and looked into how CAN databases work. Now we will look at a few protocols that are commonly used over CAN.

In the last article we looked at CAN databases, where each bit of a message is mapped to a specific meaning. For example, bit 1 of a CAN message with ID 0x400 might represent whether the engine is currently running or not.

However, for more complex communications we need to use protocols. These can map many meanings to a single CAN ID by agreeing on a structure for sending and receiving data.

Continue reading “CAN Hacking: Protocols” →