Worth a watch 🙂
class SRE implements DevOps
Worth a watch 🙂
class SRE implements DevOps
There have been many pages written about how people have done funky things with Amazon Dash Buttons. As they are being sold cheap currently in the UK I thought I would have a go and see what they are all about.
This is about the hardware/physical kind. Not the virtual ones you can setup in your Amazon Prime account – those are also very cool, but I wanted the ‘hack’.
So, you buy a dash button from Amazon, £2.49 at present if you aren’t worried about the logo on the actual button. Check each day in the ‘Amazon deals’ page to see which product is being discounted that day, or buy at full price £4.99 if you can’t wait.
The button arrives the next day which is cool. The next thing is to set it up, which requires you to have is a smart phone (iphone/android) and the Amazon shopping app installed. I was expecting to be able to do this all from a browser, but all becomes clear as you progress through the setup process.
The setup process is easy enough to do; turn on bluetooth and wifi on your phone, init the button by pressing it for 6 secs, then follow the on-screen instructions. BUT!!! don’t pick a product to assign the button to (cancel out at that point). Each time you add a new dash button, it remembers your WiFi password!
Don’t go any further than the above setup steps. Otherwise you’ll end up ordering tonnes of cat food or some such (I’ve got dogs BTW – did you see us at Crufts last Saturday? :))
Now that your button is accessing your WiFi you can ‘sniff’ the network traffic for the button press – which is seen as bootp/dhcp/arp broadcast traffic.
When you capture the button press, you then can do your own interesting things with it, rather than order loads of cat food. Loads of people have done weird and wonderful things at this stage (go here to see).
Capturing that button press requires you to run a little python (with scapy) script. Or use tcpdump / wireshark. I did the lot as i like to see the differences.
This is where I came unstuck for a short while as the various instructions I was following off the ‘net were for the older dash buttons (who knew there were older versions?) and the bpf / pcap filters supplied where not matching any traffic. But some googling found me lots of other people had the same issue and then I found a rather long filter that captures the traffic.
(arp or (udp and src port 68 and dst port 67)) and src host 0.0.0.0
Being an ex-network/firewall/security engineer, I did some RTFM to remind the old grey matter how to do all this again and created a more simple rule.
Basically, as it’s only the broadcast traffic that we need to see when we press the button, so as long as you aren’t doing this on your work Corporate network or have thousands of devices at home then you can simply use this…
tcpdump -i eth0 "ether dst ff:ff:ff:ff:ff:ff"
The bit you are interested in, is the bit between the quotes. This will run in tcpdump, scapy, wireshark or tshark. Slightly easier to type in, i’m sure you will agree. 🙂
You should at this point see only your button traffic, but it maybe mixed in with other traffic from other devices on your network. I see my CCTV which is now worrying me (somethig else to look into). Keep pressing your button until you are sure that the device / MAC address you see is the dash button.
So, once you have your Amazon Dash Button MAC address, things are going to be much easier. 😉
Doing a full capture on a button press using the now found MAC address, gives something like the following. Which is interesting as all sorts of different things happen as the button advertises itself on the network and devices respond to it.
tcpdump -i eth0 "ether src fc:65:de:ed:36:91"
11:17:35.735880 fc:65:de:ed:36:91 (oui Unknown) > Broadcast Null Unnumbered, xid, Flags [Response], length 46: 01 02 11:17:35.787212 fc:65:de:ed:36:91 (oui Unknown) > Broadcast Null Information, send seq 0, rcv seq 16, Flags [Command], length 349 0x0000: 0100 0020 0000 0000 a493 bd55 b0e9 f0b8 ...........U.... 0x0010: e33f 5863 f167 1349 8521 c43a fef9 0fbd .?Xc.g.I.!.:.... 0x0020: 5f3f e22b 979c 436e 5d03 9484 35e2 5a77 _?.+..Cn]...5.Zw 0x0030: 5324 bc04 1fde 68b5 688a ec93 eba0 c412 S$....h.h....... 0x0040: 70db bdba 35ac 8aad 3e9e 1eae 2f55 26aa p...5...>.../U&. 0x0050: fc00 6d3b cb3e 3af1 bc35 4cf1 a202 cb07 ..m;.>:..5L..... 0x0060: ffbb d413 ef6c e77a 4e20 0a39 f6ee 3ef1 .....l.zN..9..>. 0x0070: 9de9 621d b7e8 e7f9 f151 88f5 2198 aa7d ..b......Q..!..} 0x0080: 645c db79 a0cb 12fd 5f85 c226 f463 94e6 d\.y...._..&.c.. 0x0090: 9144 f1a9 472c fd87 6161 88ce e5b5 ddd6 .D..G,..aa...... 0x00a0: fb51 d652 99ac 9469 c746 66a6 2c63 5392 .Q.R...i.Ff.,cS. 0x00b0: b65c 6b4e 6597 41ea 7c35 8ca2 2ab6 d9a3 .\kNe.A.|5..*... 0x00c0: 43ce 2ba5 299a 7ff8 eef5 d29a 4b6e a8ee C.+.).......Kn.. 0x00d0: 9ee9 d770 b219 c70f c97e 946a 12f2 e4f1 ...p.....~.j.... 0x00e0: 7d2b 2201 d5dc c5f4 3570 ed4b 850f a076 }+".....5p.K...v 0x00f0: fec5 9da4 035e a545 2507 469c 9264 3c79 .....^.E%.F..d 255.255.255.255.bootps: BOOTP/DHCP, Request from fc:65:de:ed:36:91 (oui Unknown), length 297 11:17:36.354588 IP server.bootps > 10.0.0.10.bootpc: BOOTP/DHCP, Reply, length 300 11:17:36.356440 ARP, Request who-has server tell 10.0.0.10, length 46 11:17:36.356469 ARP, Reply server is-at 00:19:99:76:db:bb (oui Unknown), length 28 11:17:36.357786 IP 10.0.0.10.63306 > server.domain: 38792+ A? 0.amazon.pool.ntp.org. (39) 11:17:36.358231 IP server.domain > 10.0.0.10.63306: 38792 4/13/0 A 184.108.40.206, A 220.127.116.11, A 18.104.22.168, A 22.214.171.124 (314) 11:17:36.360248 ARP, Request who-has skyrouter tell 10.0.0.10, length 46 11:17:37.111902 IP 10.0.0.10.63306 > server.domain: 18997+ A? dash-button-eu-aws-opf.amazon.com. (51) 11:17:37.189044 IP 10.0.0.10.63306 > server.domain: 18997+ A? dash-button-eu-aws-opf.amazon.com. (51) 11:17:37.203976 IP server.domain > 10.0.0.10.63306: 18997 1/13/0 A 126.96.36.199 (278) 11:17:42.211942 ARP, Request who-has 10.0.0.10 tell server, length 28 11:17:43.211929 ARP, Request who-has 10.0.0.10 tell server, length 28 11:17:44.211949 ARP, Request who-has 10.0.0.10 tell server, length 28
With all that information you need to find a unique packet that you can capture to flag your button press within your server / raspberry pi.
So, people are currently capturing the bootp/dhcp request packet as the button press. This seems entirely sensible but I went a different way. 🙂
There are two initial packets which scapy, tcpdump and wireshark are not able to parse properly. This piques my interest and down the rabbit-hole I go…
The two initial packets sent before the bootp request are LLC, but (not as far as I can tell) properly created LLC packets. Of just hybrids (tut tut, Amazon).
Using python (in-line) and scapy I can tease these apart a little more. I do this as it saves me writing scripts when I’m not sure what I’m actually writing and more discovering…
First capture the packets
server:~/workspaces/amazon_dash$ sudo scapy Welcome to Scapy (2.3.3) >>> sniff(iface='eth0', filter='ether host fc:65:de:ed:36:91', count=4)
Now summarise them
>>> a=_ >>> a.nsummary() 0000 802.3 fc:65:de:ed:36:91 > ff:ff:ff:ff:ff:ff / LLC / Raw / Padding 0001 802.3 fc:65:de:ed:36:91 > ff:ff:ff:ff:ff:ff / LLC / Raw 0002 Ether / IP / UDP 0.0.0.0:bootpc > 255.255.255.255:bootps / BOOTP / DHCP 0003 Ether / IP / UDP 10.0.0.1:bootps > 10.0.0.210:bootpc / BOOTP / DHCP
Packets #0 and #1 are interesting to me.
Packet #2 is the one most people look for.
Packet #3 is my server sending back an IP address etc with DHCP.
So we can now tease the packet apart a little more. But note, it just states “LLC / Raw” as it can’t parse it any further.
Here we show the first packet as scapy understands it.
>> a.show() ###[ 802.3 ]### dst= ff:ff:ff:ff:ff:ff src= fc:65:de:ed:36:91 len= 6 ###[ LLC ]### dsap= 0x0 ssap= 0x1 ctrl= 175 ###[ Raw ]### load= '\x81\x01\x02' ###[ Padding ]### load= '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00'
Now the interesting part: the “Raw/Load” – I wonder what ‘\x81\x01\x02’ means. I can’t find any reference to it. Initially I thought it might be odd IPX traffic (from my old Novell days – but that’s 20 years ago and I can’t imagine Amazon worrying about IPX networks LOL. (DSAP and SSAP aren’t correct for IPX anyway).
But this unique packet always appears at button press so it’s a good one to look for on the network.
I delved into the packet deeper to enable me to write a better parser/lookup.
I’ll assign the first packet to a variable (pkt).
Next check that scapy knows it’s a LLC frame
>>> isinstance(pkt.payload, LLC) True
Then grab the LLC header feilds – there is an auto-complete if you press [TAB] which lists the available fields/classes.
>>> pkt.payload.dsap 0 >>> pkt.payload.ssap 1 >>> pkt.payload.ctrl 175
Of course we need the ether frame source and destination.
>>> pkt.dst 'ff:ff:ff:ff:ff:ff' >>> pkt.src 'fc:65:de:ed:36:91'
The source being out button and the destination being the broadcast.
Then lastly we have that interesting data – that I can’t quite put my finger on yet. But again it stays the same each button press and seems unique but common to the Amazon Dash Buttons I have.
>>> pkt.getlayer(Raw).load '\x81\x01\x02'
Once I had all this data I was them able to script some python on my server (or Raspberry Pi) to look for these packets and do ‘something’ when that dash button is pressed.
As far as I can tell, you can only press a dash button, once per 60-70 seconds. So no quick on/off of something connected to your dash button.
A complicated term for something so simple and useful…
I stopped the dash button from accessing dash-button-eu-aws-opf.amazon.com by adding it to my DNS RPZ list. This stops me accidentally ordering anything while i am mucking around with them. You can do this with a PiHole which I thoroughly recommend if you aren’t up to building one yourself from scratch. A PiHole will save you a load of worry not just about the dash buttons. Take a look.
Well the Amazon Dash Button was true IoT, but now it’s internal to my own network, so more intranet than internet LOL.
The new best kind of engineer is a software engineer who can not only write the code, but also knows how to jump into prod and debug it, and is happy to be in the on call rotation supporting their own code.
The new best kind of engineer is a DBA who proudly reuses terraform and packer and chef- and orchestrates their shard replacement using the same tooling as the rest of ops … and trains everyone in how to recover data.
The new best kind of engineer is a UI engineer that can not only code build configurations, but also understands how their work fits into a larger design system… and advocates for lowering the bar to producing production UI through automation.
Great example at the end showing a scaled roll-out.
Some great work published by a good friend of mine. Where he is standing up a CI/CD environment.
As I work for a service integrator this is always good to see and point people to. But my question is, why only one tool? Surely the right tool for the right situation for that customer. I will admit my favourite is Ansible because it is the easiest one to teach and hand over. But Puppet and Salt Stack are fine too.
As a self-confessed Introvert, it amazes me sometimes how many people still think Introversion means you are shy…
Sometimes you read something and you go… “Yup, that’s me” 🙂