Discovering the Protocol in a USB VoIP Phone

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

Dual-mode Avalanche and RF Random Number Generator

[Paul] designed a new open-hardware RNG (random number generator) that includes two sources of entropy in a small package. The first source of entropy is a typical avalanche diode circuit, which is formed by a pair of transistors. This circuit creates high-speed random pulses which are sampled by the onboard microcontroller.

What makes this design unique is a second entropy source: a CC2531 RF receiver. The RF receiver continuously skips around channels in the 2.5Ghz band and measures the RF signal level. The least-significant bit of the signal level is captured and used as a source of entropy. The firmware can be configured to use either source of entropy individually, or to combine both. The firmware also supports optionally whitening the entropy byte stream, which evens out the number of 1′s and 0′s without reducing entropy.

The OneRNG uses the USB-CDC profile, so it shows up as a virtual serial port in most modern operating systems. With the rngd daemon and a bit of configuration, the OneRNG can feed the system entropy source in Linux. [Paul] also has a good writeup about the theory behind the entropy generator which includes images of his schematic. Firmware, drivers, and hardware design files are open-source and are available for download.

Walkman-esque Human Interface Device

Cheap keyboards never come with extra buttons, and for [Pengu MC] this was simply unacceptable. Rather than go out and buy a nice keyboard, a microcontroller was found in the parts drawer and put to work building this USB multimedia button human interface device that has the added bonus of looking like an old-school Walkman.

The functions that [Pengu MC] wants don’t require their own drivers. All of the buttons on this device are part of the USB standard for keyboards: reverse, forward, play/pause, and volume. This simplifies the software side quite a bit, but [Pengu MC] still wrote his own HID descriptors, tied all of the buttons to the microcontroller, and put it in a custom-printed enclosure.

If you’re looking to build your own similar device, the Arduino Leonardo, Micro, or Due have this functionality built in, since the USB controller is integrated on the chip with everything else. Some of the older Arduinos can be programmed to do the same thing as well! And, with any of these projects, you can emulate any keypress that is available, not just the multimedia buttons.

FTDI Screws Up, Backs Down

A few days ago we learned chip maker FTDI was doing some rather shady things with a new driver released on Windows Update. The new driver worked perfectly for real FTDI chips, but for counterfeit chips – and there are a lot of them – the USB PID was set to 0, rendering them inoperable with any computer. Now, a few days later, we know exactly what happened, and FTDI is backing down; the driver has been removed from Windows Update, and an updated driver will be released next week. A PC won’t be able to communicate with a counterfeit chip with the new driver, but at least it won’t soft-brick the chip.

Microsoft has since released a statement and rolled back two versions of the FTDI driver to prevent counterfeit chips from being bricked. The affected versions of the FTDI driver are 2.11.0 and 2.12.0, released on August 26, 2014. The latest version of the driver that does not have this chip bricking functionality is 2.10.0.0, released on January 27th. If you’re affected by the latest driver, rolling back the driver through the Device Manager to 2.10.0.0 will prevent counterfeit chips from being bricked. You might want to find a copy of the 2.10.0 driver; this will likely be the last version of the FTDI driver to work with counterfeit chips.

Thanks to the efforts of [marcan] over on the EEVblog forums, we know exactly how the earlier FTDI driver worked to brick counterfeit devices:

ftdi_evil

[marcan] disassembled the FTDI driver and found the source of the brick and some clever coding. The coding exploits  differences found in the silicon of counterfeit chips compared to the legit ones. In the small snippet of code decompiled by [marcan], the FTDI driver does nothing for legit chips, but writes 0 and value to make the EEPROM checksum match to counterfeit chips. It’s an extremely clever bit of code, but also clear evidence FTDI is intentionally bricking counterfeit devices.

A new FTDI driver, presumably one that will tell you a chip is fake without bricking it, will be released next week. While not an ideal outcome for everyone, at least the problem of drivers intentionally bricking devices is behind us.

Introducing USB Armory, a Flash Drive Sized Computer

[Andrea] tipped us about USB armory, a tiny embedded platform meant for security projects. It is based on the 800MHz ARM Cortex-A8 Freescale i.MX53 together with 512MB of DDR3 SDRAM, includes a microSD card slot, a 5-pin breakout header with GPIOs/UART, a customizable LED and is powered through USB.

This particular processor supports a few advanced security features such as secure boot and ARM TrustZone. The secure boot feature allow users to fuse verification keys that ensure only trusted firmware can be executed on the board, while the ARM TrustZone enforces domain separation between a “secure” and a “normal” world down to a memory and peripheral level. This enables many projects such as electronic wallets, authentication tokens and password managers.

The complete design is open hardware and all its files may be downloaded from the official GitHub repository. The target price for the final design of the first revision is around €100.

Mutant Kitchen TV Computer

In need of a kitchen entertainment system, [BoaSoft] headed to the parts bin and produced a project that can easily be called a mutant. That being said, we love the results!

Here’s the link to the original Russian language post. If your Russian is a bit rusty here’s a really awful machine translation. So let’s see if we can decipher this hack.

Sounds like [BoaSoft] had a broken Acer laptop on hand. Problem was the laptop can’t play over-the-air television (and similarly, a television can’t surf the net). The solution was to figure out how to utilized a TV tuner of unknown origin, combine that with the laptop and a computer monitor, then add back all the user interface you’d expect from an entertainment device.

The board shown in the first post of the thread is familiar to us. It seems to be based on the IgorPlug board which is a hack that goes waaaay back. This allows for the use of an IR media center remote and those input signals are easy to map to functions. The computer runs Windows Media Center which is already optimized for remote control but can use a wireless keyboard and mouse when more computer-centric functions are necessary.

With all on track the rest of the hack deals with hacking together a case. The laptop’s original body was ditched for some extended sides for the back of the monitor. [BoaSoft] did a great job of installing all the necessary ports in these extensions. Once in the kitchen everything is nice and neat and should stand the test of time.

[Thanks Dmitry]

Using the Boxee Remote With A PC

When it was first announced in 2010, the Boxee remote was a stroke of genius. Not because it controlled the BoxeeBox, the set-top media center PC, mind you. It was impressive because the reverse side of the remote had a small qwerty keyboard, just the thing for searching menus loaded up with movies and TV shows and entering URLs. [Martin]‘s BoxeeBox loved his BoxeeBox, but it’s an old device now, with some support for web streaming (including Netflix) gone.

Other media center devices have filled the void in [Martin]‘s life, but he loved that Boxee remote. Getting it working on his XBMC-equipped PC was a top priority. This meant figuring out a way to connect the RF receiver from a BoxeeBox to a USB port. It turns out this is pretty easy, requiring only a few parts and half of a USB cable.

[Martin] traced out the connectors on the RF receiver for the BoxeeBox, and found the usual V+, V-, Power, and Ground connections found in a USB cable. The receiver operated at 3.3 Volts, so stepping down the voltage required regulator. The rest of the project was simply putting everything in a project box and stuffing it behind his PC.

Windows identifies the RF receiver as a normal keyboard, so everything went swimmingly. Since [Martin] built this small device, a few people have come up with better keyboard layouts for XBMC and the Boxee remote, allowing this device to function far into the future.