Amazon Dash Button's Wireless Audio Configuration | Hacker News Reader

Amazon Dash Button's Wireless Audio Configuration

blog.jay-greco.com

156 pointsmavci33 comments

It doesn't work with android because of the wide variety of speakers and microphones on android vs the very few for ios. Many android phones can't even emit or record ultrasound.

I've worked with ultrasound on the receiving end on android before, using the built in mic to capture ultrasound data. We never came across a device that was unable to hear the data, and we tested on what I would consider a pretty large variety of phones. As far as transmitting goes you're probably right though, and seeing as the dash button is the receiver in this scenario it makes sense

I wonder why they didn't just fall back to audible sound. WiFi is okay, but having to manually connect to the button's access point is fiddly, and disconnects you from the real network.

Another solution is Electric Imp's BlinkUp, which encodes the WiFi information in flashing light from the screen. Patented.

http://arstechnica.com/uncategorized/2003/09/2886-2/

"Eight weeks later, the first public demonstration was given to the class by using a simple ping packet. With a blinding 2bps speed, the class sat patiently as the packet was received in roughly 140 seconds. "

That's why. Sound is a pretty slow wavelength. Low end is 60hz, lets call it 600hz tones in this bongo (I don't actually know). However ultra sound is at 20 kHz and above. Eg 33 times faster. 33x the data. Eg 140 seconds now takes 4.25 seconds. Lets assume the bongo was 10 too long. Now we're down to 14 seconds in audible and .42 seconds in ultrasound.

you can see the benefit.

and that's without actually doing a real data rate calculation becuase I don't have a good number on how many waveforms you have to have on sound to pick up a real signal. Somthing somthing nyquest criterion somthing somthing.

There's all sorts of funky stuff with Android audio recording and playback.

Some Android devices can only record 8kHz audio and then upsample without telling you (where iOS hardware native is 44.1kHz). Some also apply filters you wouldn't expect at the input stage. There's also automatic gain control (AGC) which varies dramatically across manufacturers and phones. Similarly for output: filtering, sample rates, speaker quality, etc. Then taking into account the immense matrix of testing, the problem becomes non-trivial very quickly on Android in ways that are not an issue on iOS. Their choice of ASK complicates things further as amplitude modulation is more prone to transmission error afaik.

As someone who's spent way, way too long playing back and recording audio on mobile devices as a mechanism of communications, let me assure you, it's hugely harder on Android than it is on iOS. I would have made the same decision if I were them.

Surprised they didn't use BLE, honestly...

[edit] Very cool approach though!

If anyone wants to play with an audio modem which can run ASK (PSK and QAM too!) then try https://github.com/quiet which has Android and JS bindings

End shameless plug :)

I'd be interested to know how much potential advertising data is collected via these microphones.

Previous discussion: https://news.ycombinator.com/item?id=10562207

For these? Probably none. Their batteries would be depleted very quickly if they were listening to the microphone more than at just setup.

Ah, very good point.

But of course, as technology matures, advertisers will go out of their way to make use of it. That's one thing you can count on.

Privacy is a huge topic in the ultrasonic audio transmission space right now, and it's definitely not something Amazon would take lightly. The potential for gathering metadata is there for sure, but as another commenter alluded to I would be more concerned with devices with microphones + rechargeable batteries. I haven't read the Alexa / Echo terms closely yet though. (Disclosure: I previously worked for a company making competing tech.)

Should Amazon have encrypted this transmission in some way or is the volume low enough that a plain text transmission of the wifi password not pose a threat?

This is definitely a valid concern if the plaintext transmission can be recorded and played back and still be valid. Hopefully they've built-in some kind of short expiration timestamp. That said, the speaker output from your phone in your home isn't going so far that anyone else could pick it up without being in your home at the time that you're configuring it.

Now the question is if there is a exploit in the rom and by crafting your own audio you can make the device much more interesting.

The easier, hacker way is to intercept the traffic with a proxy: https://medium.com/@edwardbenson/how-i-hacked-amazon-s-5-wif...

That only allows reacting to button pushes, though. I'm assuming that by default the mic is only active for initialization by default, but if you can get the microprocessor to execute arbitrary code via a crafted packet, you could presumably access the hardware directly and add more capabilities.

If you have physical access to the hardware, it actually has exposed JTAG under the covers, and it's basically a Particle Photon, so I imagine you'd be able to have a lot of fun.

Actually, here's a guide: https://learn.adafruit.com/dash-hacking-bare-metal-stm32-pro...

Minor thing, but there is no proxy at work here

> Dash buttons are turned off most of the time to preserve the battery inside. They only turn on when you push them. And that means they have to re-connect to your Wifi network every time they are pushed. That’s easy to detect.

How do they know for sure? Perhaps they also connect every month for a (status) update or for statistics, but this hacker just missed that.

I wouldn't use these buttons to launch any missiles :)

Curious if anyone knows how the Dash buttons handle when your wifi password has changed since their last successful connect.

I believe you have to use the mobile app to go through the Dash set up procedure again if you change your local AP (or get a new one, etc.)

Similar approach taken for Amazon's Echo Dot exposing parts of setup process and some broken parts: https://medium.com/@dweinstein/amazon-echo-dot-explorations-...

What do you mean?

I thought this was really cool, and you don't even need a Dash button to repeat it (just the app). I threw a mic on my desk and recorded the output real quick, and sure enough, it's pretty easy to see the waveform. I was going to post the wav file, but without knowing a bit more about how the Dash links to my Amazon account, I'm a bit hesitant.

I'm going to have a run at reproducing this in Python. Should be fun!

incredible work, jay! I like how you described everything.

I think it's going to be interesting when the Amazon dash buttons end up playing a role in next big DDOS...

I wonder how many tens of thousands of people have now unknowingly installed internet-connected microphones in their kitchens, garages, laundry rooms, and bathrooms.

Probably far fewer than the millions of people willingly carrying portable internet-connected microphones (+ GPS devices) on their person.

+ cameras + biometric info + more or less all your personal data and passwords

Well the Dash button has very little on-board storage, so it can't save much voice. It also has a very limited battery, so it turns itself off unless the button is pushed, and when the button is pushed it's only on long enough to send a command to Amazon (not long enough to send saved voice data).

People complaining about things they didn't take five seconds to understand is how FUD gets spread. Please don't contribute to this nonsense.

I don't think this qualifies as FUD, nor misinformation. If this is FUD, then all of DefCon is also. This is simply pointing out the onboard capabilities of a device people are indeed installing in their homes. Clearly this is a microphone-enabled wifi-enabled device. State actors use passive bugs [1] with vastly fewer internal capabilities, so I think it's foolish to discount the possibility that it could be misused. Especially when it's so readily available.

Given the use of passive bugs, it's pretty obvious that zero onboard storage is required for a listening device to be useful to those with resources to collect the information real-time. It's healthy to understand the inherent trade-offs you're making by installing such a device, and make sure you can monitor its usage appropriately if you choose to keep one in a place you presume is reasonably private.

[1] https://en.m.wikipedia.org/wiki/The_Thing_(listening_device)

The battery is the limitation here. Sure maybe you record for a day or two even but it simply can't last longer than that.

A Cortex M3 on a single AAA battery can only last a few hours without sleeping. 3.3 volts at 200-300 mA with a 1200 mAh battery doesn't provide much wiggle room.

"The Thing" is not powered by a battery. The Dash button is. That's the whole difference between active devices like the Dash and passive devices like The Thing.

And yes, saying "Dash buttons are secret government wiretaps!" is FUD, no matter how subtly you say it. There's literally a simple way to test: sniff the wire. And people have done that (https://medium.com/@edwardbenson/how-i-hacked-amazon-s-5-wif...). Spoilers: exactly what you'd expect. I'd also like to see how long you think a WiFi device powered by a single AAA battery would last while streaming voice to the Internet.

Conclusion: FUD.

Reply on news.ycombinator.com