Earlier this year, Amazon announced that they’ll discontinue Dash Buttons. I don’t know how successful Dash Buttons were for their intended use, but Home Automation hackers have loved (mis-)using them for everything from warming up their coffee pot to keeping track of bodily functions.
Unfortunately for us hackers, Amazon is an unforgiving god. Not only have they stopped selling Dash Buttons, but they’ve removed the part of their app used to set new ones up. Even worse, to any button unfortunate enough to connect to The Mothership, Amazon has promised to issue a firmware update that bricks the device. It is therefore critical that you set up your buttons in an environment where they will not be able to phone home.
Fortunately for us hackers, Amazon is not an infallible god. Versions of their dash button firmware built on May 2016 and earlier are vulnerable to a buffer overflow attack during the high-frequency audio setup (Hunz did some truly awesome reverse engineering work to find this).
We can exploit this vulnerability to complete the setup.
In the following section, I’ll go into more detail about how this works.
For now, let’s do this!
- Put Dash Button in setup mode by holding down the button until the LED flashes blue.
- Connect to the
Amazon ConfigureMeWiFi network and visit
- You’ll see the button’s hardware (MAC) address. Block its Internet access in your router’s settings. If you don’t do this, the button will get an over-the-air update when it phones home and get bricked.
- Connect to the
- While in setup mode, play this .wav file through some earbuds aimed at the Dash Button.
- If the LED turns green, the exploit worked! Carry on to step (3).
- If the LED turns off, you’re probably on a firmware version that fixed the vulnerability. Unfortunately, you’re out of luck if this is the case. (unless someone finds another vulnerability)
- Put the Button in setup mode again.
- Connect to the WiFi network it creates —
- Visit this URL*:
http://192.168.0.1/?amzn_ssid=<wifi_network_name>&amzn_pw=<wifi_network_pw>. (obviously substituting wifi_network_name and wifi_network_pw for the desired values)
That’s it! It should work now.
[ * ]: Note that the setup AP is unsecured and this request is sent over HTTP. You’re sending this request in plaintext over the air. Don’t do this unless you’re comfortable with that. The buttons support a configuration flow that involves exchanging crypto keys, but this is far more involved. If there’s enough interest, I can write a script.
How this works
The Dash Button setup process has two high-level steps:
- Getting WiFi credentials from you.
- Exchanging a pair of secrets with The Mothership.
Under normal operation, these are used to authenticate with Amazon when placing an order (it uses them to generate an HMAC secret).
- The button transfers a device secret baked into the firmware to Bezos HQ.
- The button retrieves and stores a customer secret from Amazon.
(1) is easy for us to fake. In fact, all we need is the final step from the previous section — visiting the URL with the
It’s (2) that’s keeping everyone from setting up their buttons. Amazon has stopped responding to these exchange requests, meaning the buttons will never complete the setup process unless we get creative.
The part of the firmware that handles high-frequency audio packets is vulnerable to a buffer overflow attack. From Hunz’s slides, you can see that it’s doing a
memcpy without a length check:
Hunz put together some excellent scripts that pack an exploit payload in ARM assembly into an audio file.
I needed to do some reverse engineering of my own to find the function responsible for writing the customer secret to flash. I’d never so much as opened a disassembler, so this was a pretty fun challenge. Since IDA costs an arm, a leg, and the souls of any present and future offspring, I used Ghidra (I have no complaints, although a professional might). I put the archive file on Github.
The raw function that writes a customer secret to flash is at address
It takes in a pointer and a length (which appears to always be 20). This function is normally wrapped in a bunch of code that calls Amazon’s servers, does validation, etc., but since we’ve got arbitrary code execution, we can just call it directly.
My exploit payload follows:
The following three lines are parsed by Hunzs' scripts.
Registers R1, R2, and R3 will be pre-populated with the
// r1 = 0x400000 -- flash start
// r2 = 0x40faa5 -- write customer secret function ptr (+1 due to thumb)
// r3 = 0x40e721 -- set LED color function ptr +1
/* set up function call parameters */
MOV R0, R1
MOV R1, #0x14
/* call avocado_writeCustomerSecret */
/* set LED to green */
LDR R0, =0x00FF00
/* let watchdog expire */
Since it doesn’t matter what the value of this secret is so long as we’re not intending to connect to Amazon, I pass an arbitrary address (
0x400000 — the start of ROM) along with a length of 20 to the writeCustomerSecret function.
Then it sets the LED to green to indicate success. Firmware versions that have patched this vulnerability shut down when they receive the exploit.
When starting on this effort, I soldered some magnet wire onto the UART test pads to get serial access. Hunz labels the pins in his talk:
Here’s a photo of my test rig:
The most interesting thing you can do with UART access is execute more code. The audio exploit payload is limited to a small number of instructions. Hunz supplied a payload that reads data from UART into SRAM and executes it (there may be a more convenient way to do this, but I’ve not dug in yet). Soldering onto these tiny pads is pretty challenging, so I modeled and 3D-printed a crude pogo pin fixture:
I’d initially thought this was necessary in order to configure wifi credentials, but turns out you can do that using the setup AP, which is much easier.
You can’t do much of anything interesting in the serial console, but it at least appears that someone over at Amazon has a sense of humor:
**** TAOS Bootloader 0.2.11 ****
0x00000004 ms 0x000000FB us
Reset Trigger : FIRST POWER UP
(APP)(INFO)Chip ID 1503a0
(APP)(INFO)Firmware ver : 19.4.10 Svnrev 13806
(APP)(INFO)Firmware Build Oct 26 2016 Time 17:55:34
(APP)(INFO)Firmware Min driver ver : 19.3.0
(APP)(INFO)Driver ver: 19.4.10 Svnrev 12577
(APP)(INFO)Driver SVN URL branches/WIFIIOT-1400_2
(APP)(INFO)Driver built at Mar 3 2017 15:19:38
DBG: Set MAC address 18:74:2E:4D:01:D3
There is no exit from here. You are stuck in a forever loop...MUAHAHAHA!
- Hunz’s reverse engineering work is incredible. If you’re into this sort of stuff at all (and if you’re reading this, you probably are), you’d very likely get a huge kick out of his 33c3 talk, which is where I learned about the audio vulnerability.
The Dash Button hardware is pretty remarkable. It’s got a beefy microcontroller, (obviously) builtin wifi, a BLE chip, a microphone for the HFA audio configuration, and so on. I’ve not seen any official-looking estimates at the cost Amazon was paying for these things, but some have guessed in the ballpark of $20 — even at Amazon’s scale.
If we can find a way to flash custom firmware, they’d be perfect IoT buttons. As-is, they’re obviously a little janky. We’re monitoring networks for side-effects to trigger actions. This should theoretically be possible given that Amazon issues OTA firmware updates (the code that handles the OTA update process appears to be at
I don’t know how much gas is left in my motivation-for-reading-assembly tank, but this is what I’d work on next with what’s left.
It’d be really neat if Amazon open-sourced an SDK. Yes, they’ve said they have a recycling program, but something tells me most buttons are gonna end up in the landfill.
- Amazon fixed the buffer overflow vulnerability in a later version of the firmware, but almost every button I have uses the May 2016 version out of the box (there’s been ~1/20 exceptions).
- Buttons get OTA updates if they connect to the Internet. So if you have a button that’s been phoning home, in all likelihood it’s been patched.
- My setup triggers on 802.11 probe requests, meaning I don’t need (or want) the button to connect to a network, only to try. As far as I can tell, though, they will.
If this work has brought you happiness or utility, it’s more than enough for me to hear those words.
If you’re feeling especially generous, and are open to a charitable donation, that’d make me very happy. Here are some whose mission I support (in no particular order):