Excited by the prospect of $5 hackable IoT buttons, I ordered a couple to toy around with and use in my home automation setup. I knew some folks had already figured out how to hack them, but hadn’t looked closely at how they were doing it until my buttons arrived.

Not surprisingly, the hacks are pretty hacky. There were two approaches I found:

1. Listen for ARP packets sent from the dash button. Devices send ARP probes after associating with a network in order to determine whether their hardware (MAC) address is already in use. My casual experimentation showed these packets showed up 3-5 seconds after the button was pressed. This is the standard approach first outlined in Ted Benson’s medium post.
2. Listen for probe request packets sent from the dash button. Devices wishing to connect with a particular network will send these out to kick off the process. These show up much sooner after pressing the button — usually within 1 second. Outlined by ridiculousfish here.

There are some not awesome things about both of these. Probably the worst is that you need to run something like tcpdump as root, and your network device has to be put in promiscuous mode (in the case of #1), or monitor mode (in case of #2). Setting promiscuous mode on a NIC instructs it to not ignore traffic that isn’t addressed to it (it normally does). Monitor mode is a different beast. It’s more like sniffing the waves out of the air. The card sits there without being associated with a network and can report any packets it hears on whatever channel it’s set to.

#2 has some particularly nasty downsides:

• Need a dedicated wireless device that supports monitor mode. Since you’ll presumably need whatever box you’re working with connected, you’ll need another network device (second wireless device or ethernet).
• Not all wireless devices support monitor mode. Fortunately, the dongle that came with my Raspberry Pi does. This post lists a few chipsets that support monitor mode.
• Requires some networking setup. Creation of virtual monitor device feels kludgy and does not persist across restarts.
• Much easier to spoof. As we’re listening to packets sent before the device is associated with a network, an attacker would only need the MAC address of your button. Probably not a good idea to use the buttons for much beyond switching your lights on and off. : )

Even with these, I’m pursuing #2 because:

• Latency for #1 is just too high for most uses.
• Since we’re listening to probe requests, we detect a button press before it associated with a network. This means we can set the buttons up on a fake network (I used a virtual interface in dd-wrt), and delete it when we’re done. Net effect is that buttons won’t be able to connect when they’re pressed, and won’t try to order Clorox Wipes when you try to turn on the kitchen lights.
• This last benefit is mostly nice because Amazon was sending me a push notification every time I pressed a button to the effect of “Select an item to order to finish setup!”. Had to turn push notifications for Amazon off.

We’ll see how it turns out!