So now we come to our next talk, it's about the Amazon Dash button.
Who of you knows what the Amazon Dash button is? Okay... kind of everybody.
Who has a Amazon Dash button?
Who has used it to buy something?
Okay. [clapping and laughter]
So for everybody who has never seen a Amazon Dash button you now get the chance.
I brought one.
It looks like this.
It's a small tiny thing.
You can click on it, you can order stuff, and you can order great stuff.
Like... things which make sense, like dog-food, shampoo, stuff like that.
But also fun things... so things you need regulary...
But also fun things like Play-Doh, you know, it's the stuff for kids.
I have no idea who regulary needs to buy Play-Doh... where does it go?
Is it like your child eat it all up so you need new one? Or...?
So this is something we perhaps won't learn in this talk, so why we need this.
But we will learn how you can hack it to use for a different purpose.
Some of you might say "Okay wait, I've already heard of something like that"
Yes, because the first version was shipped out, there such an analysis was already done
But there is a new version and like it's often with the Internet of Things
stuff they tried to make it more secure.
I mean that's what the 'S' stands for in "IoT".
What we'll hear about is about the hardware, the software
and also how the communication with the server looks like.
And hanz will give us a talk about this.
He is somebody hacking hardware since quite a time so...
Let's give him a warm round of applause and let's learn. [clapping]
Thanks, nice to see you.
Let's have a closer look at the Amazon Dash button now.
The Dash button is basically a Wi-Fi connected button
It's been around in the US since about 2014, I think.
And in Germany it's available since August of this year.
There are two hardware revisions and in this talk I'll only cover revision 2
because that is the current revision.
I don't think you still can get the old revision.
The old revision is also quite hacked already.
This button can be used to order or reorder certain consumer goods
like pet-food or washing supplies and stuff
It's only available for certain brands and products and you can not configure
it freely.
It costs five Euros and you get a refund on your first button-triggered order.
There is also a customizable version available, at least in the US
for twenty dollars and you still can't load your own code on this button
but you can use the Amazon Web Services to get the button presses.
So what is interesting about this thing?
Well, it has Wi-Fi and it must be some sort of a computer
so it's a sort of Internet of Shit device, though it might be more useful
than certain other products.
One question of course is: How does it work? We just want to know.
Then: What about security? If we put this thing on our network is this a security risk
and can it be used for cyber, ddos and so on?
Another important aspect for the hardware hackers is whether we can reprogram it
for our custom Internet of Thing project.
It's more powerful than the common ESP8266 and the price is comparable.
The next point of course is: If we can not run code on it we don't really own it.
So we want to run our code on it.
There is some prior research that has already been done for the old button
You can get the slides from the Fahrplan and I'll refer to these two links later
during the talk. So this has been done already, you can read it up.
The easy way of repurposing the Dash button is to use the smartphone app
and configure the Dash just normally, but you close the app
once you get to choosing a product
Then this prevents the Dash from ordering anything
The product selection is stored server-side while the Wi-Fi configuration is stored in the button
The button still contacts the server and says "I want to order something"
whatever there is configured.
The server says "Nope, there is nothing configured"
and the button blinks red and that's it.
So you don't get stuff and of course it does a lot of things to get online
It connects to your Wi-Fi, it does a DHCP request, ARP Request, DNS lookup
and so on
So you can monitor all these things to find out when the button is activated
and monitoring the DHCP logfile of course is the most easy way, I guess.
Who is doing this already?
Okay, a few, about three people.
We'll go a lot further than this in this talk.
First we'll have a look at the hardware so what's in this Dash button
the communication protocol and the crypto. The firmware revision, this revision was
still the most recent on 25th i checked it last
and we'll run some custom code on the button without desoldering anything.
I didn't analyze the Amazon smartphone apps because this is way to high-level for me
Regarding the hardware...
The housing is heat-sealed plastic, so you can't open a screw, you have to somehow
break it open or cut it open
My first attempt was with a knife, cutting along the seal
but that didn't work so well. I removed some SMD components in this process and
my latest attempt was using a cutting wheel from the top, because I already knew where
the stuff is, where I wanna get. You can see the testpoints here.
And this is the microcontroller so I simply cut it open there's some space between
the plastic package and the pcb.
The PCB has four layers and a lot of SMD 0201 parts, you can see those here.
This is all very tiny and you can see the pads of the microcontroller
here you can not because there is some black stuff poured over it.
I don't know why exactly they are doing this but you can remove it carefully.
It can be softened a bit with acetone, that makes things easier.
The microcontroller is actually quite powerful, it's a Cortex-M4 with a
floating point unit and it runs or it can be clocked at 120Mhz.
It has half a MB of flash and 160 kB of RAM
The downside is the package of this chip
So you can not easily solder additional stuff there and.. the black stuff.
Then there is the Wi-Fi IC, this is this chip here, and it's 2.4 Ghz and thus
up to 72 Mbit/s, does WPA1/2 of course, and there is a built-in IP-stack
It works a bit like with sockets in Unix, this Wi-Fi chip basically handles all the IP-stuff
and you simply open a socket from the controller and then you can communicate using this socket
It does have built-in SSL and TLS support and plenty of stuff.
Of course there needs to be a voltage regulator because there is a single AAA battery
with 1.5V or less in the button and this needs to boosted to 3.3V so this is done
with a regulator. This is actually a quite powerful regulator
they could have used a cheaper one.
Anyway. There is also Bluetooth Low Energy you can see this here, this is a BLE IC.
I'm not sure if they are using this already, they might do with the iOS app
but I haven't analyzed this.
There is a 4 MB SPI flash and a microphone
This is here. You can see the package removed, this happened accidentally.
Then there is an LED, it can not be seen here but it's 3 LEDs actually
red, green and blue.
The thing is clocked from a 32KHz oscillator, this is this thing here
and it generates a higher clock frequency internally using PLL.
There are also some discrete semiconductors here
they use them for the powering stuff.
If we put it all together it looks more or less like this
This is bit more simpler than reality but we have the Bluetooth connected to
a UART, the Wi-Fi is connected to the SPI bus and SPI flash is also connected to
another SPI bus.
This interesting thing here is that there is an additional UART
that is used for debugging.
The voltage regulator gets started by the button press and one interesting thing is
there is no other wake-up source, no real- time-clock or something like that
that means the button can never wake up on it's own terms.
You always have to press the button, and once it goes back to sleep it can't wake
up again without the button being pressed.
Power-Enable is held with an external latch, so the microcontroller simply
clears this latch and goes to shutdown.
The microcontroller can also measure the battery voltage using the ADC and there
is an enable-signal to connect or disconnect the battery from the ADC.
This value is also sent to the server, so Amazon knows when your battery
is going empty.
Regarding the power consumption...
mpetroff already did a lot of measurements regarding this and you can see that
Wi-Fi is drawing a lot of power, 400 mW. Without Wi-Fi it's down to 80 mW and
with some power-saving you should be able to go down to about 50 mW.
The built-in battery is about half a Wh, so that's about 75 minutes with Wi-Fi
enabled, and about 10 hours with some very good power-saving
Basically you could make an acoustic bug with this and listen to the microphone for
some time and then transmit it via Wi-Fi, but it's still limited with this
battery power.
The debugging interface is also there, you already saw those test-points earlier
The old Dash button hat single-wire- debugging enabled and a serial console
with debugging commands, you could simply dump memory using the serial console
The new button has test-pads for SWD and a serial console, but SWD is disabled and
the serial console is stripped down to a few boring commands
We'll come to these later.
Here you can see the debugging interfaces from the bottom side, you can mount a
connector here. Which connector you can find on the petroff website, all of these
IOs are 3.3V, the pinout is basically compatible to the old button.
Here are some UART commands, you can see there are three different modes
There is a test mode menu, this has a lot or more commands, they probably use this
in the factory to do some calibration and testing.
This is the user mode menu. You have if you open the button and connect the serial
port. There's just some firmware revision you can query and you can measure the
battery voltage. "immortal" prevents the automatic shutdown, it stays then on
until you issue a shutdown or you switch to "mortal" again.
The developer mode menu has some more interesting commands.
There is still no memory access, but you can enter certain modes, configure mode,
access point mode, scan for Wi-Fi, and so on.
Let's have a look at the communication protocols and the crypto stuff.
The communication works like this, you have the SAMG55, this is the
microcontroller, then you have the Wi-Fi chip, this is this ATWINC, and this chip
handles all the TLS stuff, so those two communicate in plain-text using SPI
and then the Dash button uses HTTPs when connecting to the Amazon server.
So you can see plain-text data here and
it's clocked at 40 MHz so this is rather fast.
One of the first things I did was I wanted to analyze the communication
that was there because I didn't actually know if they are using TLS inside the
Wi-Fi NIC or if they are doing the TLS in the microcontroller
They did it in the microcontroller in the last hardware revision, and so I put an
FPGA between those two things and logged all the data that came by.
I did cut the bus so I could do man-in- the-middle as well, and I did this before
I had the full Dash firmware, with the knowledge know this wouldn't really have
been necessary.
I looked like this, you can see I removed the microcontroller here and added plenty
of wires, this then go to some sort of base-board where I can plug in a break-
out-board for the microcontroller.
The microcontroller is actually here on this board, there are some LEDs for...
yea they are the RGB leds. Here I have the serial console, here I have SWD,
here is the reset button, and here is the actual Dash button.
This here is 3.3V supply and you can see a lot of jumpers here, these are all the
connections to bluetooth and Wi-Fi, so I can simply remove the jumper and
do man-in-the-middle there.
This is the thing with the FPGA-board plugged in.
That's how I analyzed this communication which I'm now going to present.