That reminds me of a little accident I had with my home automation interface.
In an effort to make the UI accessible from the outside (for me), I forwarded the Raspberry Pi's HTTP server port to the server where I host my normal web stuff. Only I screwed up the proxy rule in the NginX config. All of a sudden, lights and blinds went haywire all over the house.
Turns out whoever visited any of my domains at the time got the HA control panel instead. And people clicked on the devices!
I have the pleasure of having been involved with one of the first network protocol reverse-engineers of the LIFX [0], and off the back of that hacked together a NodeJS library and a Wireshark dissector. I've updated the NodeJS lib to handle the new firmware (it does more over UDP, whereas it used to use a mixture of UDP and TCP) but not the dissector yet.
There's absolutely no authentication on the network protocol at all; as long as you're in the same network as the bulbs then you can send UDP packets and control the bulbs. I imagine this is a good and a bad thing; XBoxes automatically setting mood lighting when playing games etc... I'd rather they had to ask my permission before doing that, though.
Thank you for sharing your work. I've considering getting some small cheap ir rgb bulbs and building some kind of "rPi/arduino lifx bridge" to control them all from the lifx side. This will help a lot. :)
What is the purpose of internet connected light bulbs? Is the internet of things a way to spy on people who remove the batteries from their mobile phones or what?
Is it just some excuse to con investors into buying stocks in some insanely valued IPOs?
I don't mean to be negative and I understand the value of information in our economic life, but how much info is required from the internet of things to support our home life of eating, drinking, fornicating, watching TV and going to bed at the end of day?
who keeps all this info and what to they do with it?
I'm pretty sure the intersection of people worried enough to remove the batteries from their cellphones and willing to buy internet-connected lightbulbs is indistinguishable from the null set.
This is why Nest didn't start, like many, with internet controlled colored light bulbs. It's a very lazy product with a small market (namely, people so bored with their life, they want internet controlled colored lightbulbs).
You gotta admit thermostats have a purpose for being connected though. It's nice to have your thermostat know you're coming home or going away, and adjust things accordingly.
Also doors with locks of all kinds. It's very interesting to have your key be your smartphone.
It's also very interesting for thiefs to unlock said doors without physically breaking in, causing noise and so on.
Which means you can sell internet connected home alarms.
When all is said and done, we'll be all "internet of things". Things that do stuff, and things that protect us from the side effects of the first things. The possibilities are endless.
Yes really.
The 50 to 100 MHz 486 processor was the state of the art consumer computing platform of the early 90s.
The bulb in question here has not just one, but two processors that both run faster than the 100MHz 486. Also, when Windows 95 came out - in 1996 - the minimum required RAM was 4MB. The ST processor in the light bulb has built in RAM of 1MB. So, in theory, it would be possible with a few hacks to get the bulb to run MS Windows 95...
EDIT: I guess it was OSR2 in 1996... still, the light bulb is a decent computing machine in comparison to early to mid-90s consumer tech...
> Due to the technical challenges involved, specialist equipment required and general perception that it would be the hardest, we decided to begin our search for vulnerabilities in the intra-bulb 802.15.4 6LoWPAN wireless mesh network.
Sentences like that make me happy. I love the hacker spirit.
I just bought 3 Miilight bulbs, and obviously after installing them I was like. Man my neighbours could probably control my lights... I also have a RF remote which operates on 2,4ghz and does not require network authentication.
The Wifi bridge does require authentication however.
I was thinking of building an RF "cannon" with a directional antenna and see how far I can go. I also got a DVB-T dongle. I should be able to "catch" the signal, right?
I can't seem to find anything on the Googles for that product.
Is it spelled correctly? Can you give me a link to it? I'm interested in home automation, but all the ones I've looked into so far don't really do it for me.
Here is a article [1] describing a setup involving this type of RGB light and the raspberry. It also covers some other type of RGB lights.
The wifi bridge has been sitting on my desk for a while now. not bothered yet since the remote is sufficient for now. So can not really comment on that. Otherwise happy with one of the cheaper alternatives. No problems as of yet. Waiting for my lights to get switched on and off though :D The remote doesn't require line of sight as its RF, and already has quite the range.
Have you looked much at the Philips Hue? The combination of a reletively low price (at least compared to LifX) and an open RESTful API, they're my favourite.
Recently I created a little node service that listens to events from our site from RabbitMQ and flashes the Hue lightbulbs when interesting things happen.
Seriously, I dislike this trend of making everything a closed and encrypted black box accessible only through official channels (that will disappear in 3 years anyway) for reasons mostly related to money-making and not really security. I think this is will, if continued, slow down the rate of technological progress and development of new ideas.
To quote pg,
"It is by poking about inside current technology that hackers get ideas for the next generation. No thanks, intellectual homeowners may say, we don't need any outside help. But they're wrong. The next generation of computer technology has often—perhaps more often than not—been developed by outsiders."
The hacker in me totally agrees with that point of view. It would be awesome to have a chance to decompile firmware and analyse and hack the communication protocols.
But then security is important (which is true for almost all wireless stuff), things are quite different. It's pretty hard to build embedded devices which provide basic means of security without having a poor user experience.
If the security of the system relies on the system be secret, as opposed to the keys being secret, the system isn't secure... As have been shown again and again, you can't give someone the code (obfuscated, compiled, encrypted along with the decryption key) and also not give them the code.
So you'll slow down reversing, and probably deter most hobbyists -- but not anyone with anything tangible to gain from breaking your system. Personally I think "obviously insecure" is better than "might be somewhat safe".
In an effort to make the UI accessible from the outside (for me), I forwarded the Raspberry Pi's HTTP server port to the server where I host my normal web stuff. Only I screwed up the proxy rule in the NginX config. All of a sudden, lights and blinds went haywire all over the house.
Turns out whoever visited any of my domains at the time got the HA control panel instead. And people clicked on the devices!