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.