Philips Says: No Internet Of Things For You!

December 15, 2015 by Elliot Williams 159 Comments

The 900-pound gorilla in the corner of the Internet of Things (IoT) hype that everyone is trying to ignore is interoperability. In the Internet of Internets (IoI) everything works on a few standards that are widely accepted: IP and HTML. The discrepancies are in the details and the standards wars are in the past. Websites are largely interoperable. Not so in the wild-west ethos of the IoT.

Philips makes a line of ZigBee-enabled RGB lightbulbs that took the enthusiast community by storm. And initially, Philips was very friendly to other devices — it makes a ZigBee-to-WiFi bridge that would let you control all of your ZigBee-based lights, regardless of their manufacturer, from your phone. Until now.

Philips has just rolled out a “Friends of Hue” certification process, and has since pushed out a firmware update where their Hue bridges stop interoperating with non-certified devices. You can read Philips’ version of the story here.

Philips Locks Out 3rd Party ZigBee Hardware

The hub shown on the right is what's being locked down. — The hub shown on the right is what’s being locked down.

The short version is that, ZigBee standards be damned, your future non-Philips lights won’t be allowed to associate with the Philips bridge. Your GE and Osram bulbs aren’t Friends of Hue. DIY RGB strips in your lighting mix? Not Friends of Hue. In fact, you won’t be surprised to know who the “Friends of Hue” are: other Philips products, and Apple. That’s it. If you were used to running a mixed lighting system, those days are over. If you’re not on the friends list, you are an Enemy of Hue.

Their claim is that third party products may display buggy behavior on a Philips network, and that this loads up their customer-response hotlines and makes people think that Philips is responsible. Of course, they could simply tell people to disable the “other” devices and see how it works, putting the blame where it belongs. Or they could open up a “developer mode” that made it clear that the user was doing something “innovative”. But neither of these strategies prevent consumers from buying other firms’ bulbs, which cost only 30-50% of Philips’ Hue line.

While Philips is very careful to not couch it as such, the Friends of Hue program really looks like an attempt to shut out their competitors; Philips got an early lead in the RGB LED game and has a large share of the market. As they say themselves in their own press release “Today these 3rd party bulbs represent a minimal fraction of the total product connected to our bridges so the percentage of our users affected is minimal.” And they’d like to keep it that way, even though the people they’re hurting are probably their most vocal and dedicated customers.

Who owns the IoT?

This Techdirt response to the situation is positively apoplectic, and there’s been the predictable flood of tirades in the comments on Slashdot. [Joel Ward], who in January was celebrating the ability to afford enough colored lights to appease his son is not so happy anymore.

And while we, with our manual light switches, laugh comfortably at the first-world problems of Hue consumers, we have to ask ourselves whether we’re next. Today they come for our RGB lightbulbs, but tomorrow it might be our networked toasters. A chilling thought!

Snark aside, the IoT brings two of the saddest realities of the software world into your home appliances: Where there’s code, there’s vulnerabilities, and when you can’t control the code yourself you aren’t really in control. You may own the lightbulb, but you’re merely licensing the firmware that runs it. The manufacturer can change the rules of the game, or go out of the product line entirely, and you’re high and dry. What can you do? Pull out your JTAG debugger.

Of course it’s insane to suggest that everyone needs to become an embedded-device firmware hacker just to keep their fridge running. As we’ve written before, we need to come up with some solution that puts a little more control in the hands of the ostensible owners of the devices, while at the same time keeping the baddies out. We suggest a press-to-revert-firmware button, for instance. When Philips pushes a non-consumer-friendly upgrade, you could vote with your fingertips — but then you’d miss out on bug fixes as well. Maybe it’s better to just give in an learn to love Windows 10.

There are no easy solutions and no perfect software. The industry is still young and we’ll see a lot of companies staking out their turf as with any new technology. It seems to us that IoT devices leave consumers with even less choice and control than in the past, because they are driven by firmware that’s supposed to be invisible. It’s just a lightbulb, right?

What do you think? Any ideas about how to put the power back in the hands of the “owner” of the device without everyone’s refrigerators becoming botnet zombies? Let us know in the comments.

Thanks [djxfade] for the tip!

Edit: Shortly after we ran this piece, Philips backed down:

“We underestimated the impact this would have upon the small number of our customers who currently use uncertified lights from other brands in the Philips Hue system. We have decided to continue to enable our customers who wish to integrate these uncertified products within their Philips Hue system.”

Hackaday Explains: Li-Fi & Visible Light Communications

December 11, 2015 by Richard Baguley 62 Comments

A new way to transmit data is coming that could radically change the way that devices talk to each other: LiFi. Short for Light Fidelity, LiFi uses visible light to send data, creating the link between router and device with invisible pulses of light. This type of Visible Light Communication (VLC) uses something that is present in pretty much every room: an LED lightbulb.

What is LiFi?

Li-Fi sounds like the an engineer’s fevered dream: it is fast, cheap, secure and simple to implement. Speeds of up to 10Gbps have been demonstrated in the lab, and products are now available that offer 10Mbps speed. It is cheap because it can use a modified LED lightbulb. It is secure because it only works where the light is visible: step out of the room and the signal is lost. It is simple to implement because it uses an existing technology: LEDs.

The basis of the technology is in turning the LED light on and off very fast. By switching an LED on and off millions of times a second, you can create a data signal that can be detected by a sensor, but which is invisible to the human eye. At the other end, another LED detects these pulses, and can send light pulses back in response, creating a bi-directional link. If you combine this with wired Ethernet or a WiFi network, you have an awesome combination: an Internet connection that uses visible light for the last link.

Continue reading “Hackaday Explains: Li-Fi & Visible Light Communications” →

Pi Zero Ethernet The Hard Way

December 6, 2015 by Al Williams 22 Comments

[Alex@Raspi.tv] had the misfortune of blowing the USB hub and Ethernet port on a Raspberry Pi B+. He thought about using a cheap SPI to Ethernet board to rescue it, and while he bought the board, he never got around to interfacing it to the broken Pi. However, when he saw the Raspberry Pi Zero arrive and noticed that everyone wanted to connect it to the network, he remembered the SPI board, rescued it from his junk box, and a few hours later had Ethernet via Raspberry Pi GPIO working.

Continue reading “Pi Zero Ethernet The Hard Way” →

Hacking Old Ethernet Gear

December 6, 2015 by Al Williams 22 Comments

Have you ever wanted a pocket-sized device that could tell you if a network jack was live or not? [TanzerGuy] did and he hacked a piece of old networking gear to do the job.

Today when you think of Ethernet, you probably think of CAT-5 cable or something similar. But it hasn’t always been like that. In the early days of Ethernet networking, an Ethernet cable was a big piece of coax. A media attachment unit (MAU) clamped to the cable and then connected to an attachment unit interface (AUI) that resided in the actual network card. Later standards used thinner coax that attached to the card using a Tee connector, but even these are rare today.

Continue reading “Hacking Old Ethernet Gear” →

Pip Boys As A Service

November 24, 2015 by Brian Benchoff 24 Comments

A few weeks ago Fallout 4 was released, and like all future games of the year, productivity has fallen through the floor, cosplayers are busy crafting outfits, and modders are busy tearing the game to pieces. As with all big game releases, Fallout 4 has a super-deluxe, ultra-collectible edition, and this version comes with its own Pip Boy, the in-game wrist-mounted user interface that manages stats, inventory, and quests.

This Pip Boy is actually functional, relying on a smartphone to mirror the display in-game Pip Boy. This, of course, means there must be some sort of communication between the game and a phone. [Kyle] found this somewhat interesting and decided to dig into these communications to see what else could be done with the real life mirror of the in-game Pip Boy

With a simple swipe of nmap, [Kyle] discovered two ports open on his PS4. By creating a relay to listen in on whatever is passing through these ports, [Kyle] built a tool that allows anyone to dump data from the in-game Pip Boy to any other service.

The library and command line tool work with PS4 and PC and are able to dump stats and data from the in-game Pip Boy to the outside world. It will be interesting to see what kind of mashups could be created with this; especially interesting would be a leaderboard for an entire office of vault dwellers, but a TV-sized Pip Boy would also suffice.

Yes, that is a challenge.

Serial Data From The Web To An Arduino

October 10, 2015 by Al Williams 8 Comments

In the old days, a serial port often connected to an acoustic coupler that gripped a phone handset and allowed a remote connection to a far away serial port (via another phone and acoustic coupler) at a blistering 300 baud or less. The acoustic coupler would do the job of converting serial data to audio and reconstituting it after its trip through the phone lines. Modems advanced, but have mostly given way to DSL, Cable, Fiber, and other high speed networking options.

In a decidedly retro move, [James Halliday] and [jerky] put a modern spin on that old idea. They used the webaudio API to send serial data to a remote Arduino. The hack uses a FET, a capacitor, and a few resistors. They didn’t quite build a real modem with the audio. Instead, they basically spoof the audio port into sending serial data and recover it with the external circuitry. They also only implement serial sending (so the Arduino receives) so far, although they mention the next step would be to build the other side of the connection.

Continue reading “Serial Data From The Web To An Arduino” →

Managing An Unmanaged Switch

September 7, 2015 by Al Williams 13 Comments

Network switches come in two different flavors: managed, where you have some interface to configure and monitor the equipment, and unmanaged where the device just does what it is supposed to do and you can’t really control it. [Tiziano Bacocco] wanted to manage his cheap unmanaged switch, so he did what any good hacker would do: he opened it up.

Inside the Digicom 10/100 switch he found an IP178CH controller IC and a quick search turned up a data sheet. [Tiziano] noticed there were three ways to configure the switch: Some hardware pins could control very basic functions; an EEPROM (absent on the PCB) could configure the device; or the chip would accept commands via a synchronous serial port.

Since the datasheet covered the protocol required, [Tiziano] commandeered an Arduino Pro Mini and used it to send commands to configure the switch. A few resistors and some quick code allowed him to control VLAN and other functions on the switch via the USB port. Of course, he mentioned you could use a Raspberry Pi if you wanted a network interface–or maybe that’s a good excuse to use one of those Ethernet shields you got on clearance at Radio Shack.

Continue reading “Managing An Unmanaged Switch” →