Hacker News new | past | comments | ask | show | jobs | submit login

I've got a couple of these WiFi switches (different brands and configuration) and most of them are variants of the Broadlink SP1/SP2 switches/plugs.

They work by sending UDP packets between the device and the app, either over the internet (Ankuoo attaches to AWS hosts in the US and EU) or on the local network segment. The AWS host is used for time sync and to allow internet control of devices behind NAT firewalls. I've traced the packets and they're pretty benign (though I haven't grabbed the traffic of the initial "connect it to the network" part, so there may be scary bits there). The packets are UDP port 80 and the most frequent is the sending of the device MAC and IP/Port to AWS which is replied to with the same packet and the server's time appended.

As best I can tell, no encryption is used anywhere, however, the reply to a Device Query command contains data I can't make any sense of so part of it might be encrypted. The devices have a 4-byte code associated which appears to be used by a method in the firmware that looks to be creating an AES key and doing an AES-CBC encryption/decryption, but other than that Device Query command, the other packets are easy to parse and have no encrypted parts, so I'm not sure where that's actually used, yet.

The traffic between the different brands is extremely similar, varying mostly only by the hosts they contact and the first 32-bytes of each packet which I believe is a key identifying the variant of the Broadlink based device so that the different apps don't pick up devices that aren't meant for them (since capabilities of each vary, as well). The Ankuoo device has two ports open, one on port 80 and one other, UDP way up in the user ports, that I can't figure out. They listen on UDP port 80 for everything. The other device brand has an http web service exposed, as well, which makes interacting with it a lot easier, but adds one more attack vector.

Though the lack of encryption bothers me, these devices are also completely proprietary, very cheap and lack any API or any way to work with any home automation solutions other than their apps, so the fact that it's unprotected is allowing me to easily write a plug-in to tie these in with my home automation tools.

My plan is to block them from communicating with the internet and replace their heartbeat packets with replies from a local host. They're already running on a separate wireless network that's isolated from my home network and all but the hosts they contact. I did this because of another ugly limitation: the devices all require your network be WPA-PSK (or WEP, I assume). WPA2 is not supported and the passphrase has a maximum length of 32 characters. When I do this, the (worthless) apps will stop working but since I'm tying into my home automation solution, that's no issue from where I sit.

As for the neutral wire, it's purpose is pretty obvious when you think about it: The neutral wire is required to power the switch when the switch is turned off. Without it, there's no current going to the switch and therefore nothing to power the device -- bye, bye WiFi connection. My house was built in the 1980s and includes neutral wires in all of the switches. Whether or not a house has neutral wires, though, seems to be pretty random. Since a lot of switches include LEDs for making finding the switch easier in the dark (though many are battery powered), a lot of house wiring includes the neutral wire to some/all switches. Code in my area requires it for new wiring and I assume that's common, but my parent's house built in the late 90s lacks the neutral wire in the switches I looked at. I'm a little surprised they didn't include this in bold lettering in the listing, but if you do a bit of home wiring you'd assume this limitation was there, anyway.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: