The Amazon Dash Button it an Internet connected button that allows ordering a single product from Amazon. Although it is not something I would ever use, I thought its guts might be interesting and bought two for a grand total of $2.10 with tax and free shipping. Others have already posted about disassembling it, so I’ll focus mostly on the electronics, since the aforementioned blog posts are missing high-resolution images of the circuit board and don’t quite get some details correct.
The first victim is the Cottonelle Dash Button. The outside of the Dash Button consists of a button, a microphone hole, a loop for tying to, and adhesive on the back. The different brands of Dash Buttons have the same model number,
JK76PL, differing only in the label.
Peeling back the label reveals three Torx T5 screws.
However, the two halves of the case are also glued together and must be pried apart once the screws are removed.
Opening the case reveals a small printed circuit board with an Energizer Ultimate Lithium AAA battery. Although the cost of the Dash Button is less than that of the battery alone, tabs are spot welded to the battery making reuse difficult; Amazon also limits customers to one of each brand of Dash Button.
Next are high-resolution images of the front and back of the PCB, both with components still on and with them removed. Here are full resolution copies: front with components, front without components, back with components, and back without components.
The circuit board is at least three layers and contains blind vias. The design seems based on the Broadcom BCM943362WCD4 WICED module reference design, with a Broadcom BCM43362 Wi-Fi module,
U9, and an ST STM32F205 microcontroller in a WLCSP (instead of a LQFP),
U5. This is similar to, but not the same as, the chip that is used in the Particle Photon. The Photon uses a USI chip that combines the Wi-Fi module and microcontroller into the same package but is otherwise the same. Other components on the Dash Button include an InvenSense INMP441 microphone,
MP1; a Micron M25P16 16Mbit serial Flash memory module in a UFDFPN8 package,
U6; an RGB LED,
DS1; and a 26 MHz crystal,
Y1. I transcribed the markings from the other integrated circuits but was not able to identify them.
Also included is a 0.40mm pitch 5×2 pin board-to-board connector (
Molex 503548-1020 Panasonic AXE5101271 ) and a number of test points. This header contains a JTAG interface to the microcontroller as well as what I think is a serial interface to the microcontroller. The pinout, labeled in the same order as the photo above, is:
GND NRST PC6 PA14 PC7 PA13 PB3 PA15 PB4 3.3V
which corresponds to
GND NRST USART6_TX JTCK-SWCLK USART6_RX JTMS-SWDIO JTDO/TRACESWO JTDI NJTRST 3.3V
as likely pin functions. Except for
NRST, these pins are also accessible from test points, with
TMF24->NJTRST. The column to the left of the previous test points, from top to bottom, corresponds to
JTDI. I have not yet tried to connect to either the JTAG or the USART. The other test points I was able to identify were
TX8->PB13. All identifications are based off of a combination of visual inspection and continuity testing of the PCB once all components were removed via hot air.
The Dash Button operates at 3.3 V boosted from the battery’s nominal 1.5 V, drawing 200–300 mA from the battery when on and 2.3 μA when in sleep. This means the ~1200 mAh battery should be able to power the device for at least four hours while on and decades while in sleep. Since the button is only on for a few seconds when activated, it can probably be used close to 1000 times before the battery dies. Thus, the button should become obsolete long before the battery is depleted.
Moving on to software, the Dash Button is configured using the Amazon mobile app using ultrasound2 to configure the button in the case of iOS and Wi-Fi in the case of Android. I have not reverse engineered the audio protocol, but the data seems to be transmitted using audio
frequency-shift keying around 18–19 kHz. The app transmits this message 20 times before giving up. Although not mentioned in the documentation, the Dash Button creates a Wi-Fi hotspot when placed in configuration mode,
Amazon ConfigureMe, which is used by the Android version of the Amazon Shopping app. Once connected to this hotspot, a web page is accessible at
192.168.0.1 via HTTP, which allows for configuring the Button’s Wi-Fi connection settings. However, the Amazon App is still required to finish setting up the Button. When connecting via HTTPS, a certificate signed by the
Amazon.com Internal Root Certificate Authority and issued to
Amazon.com Infosec CA G2 is presented, which expires 2016-06-22. However, I was not able to successfully connect even after bypassing the certificate error, so it might be using a different protocol over TLS. The Button’s firmware version,
v0.9.119, can be gleaned from the source of this page. By monitoring the Button’s network traffic, I was able to determine that the Button communicates with
parker-gateway-na.amazon.com via TLS.3 Additionally, it always uses
126.96.36.199 for DNS. Due to the use of ultrasound instead of Wi-Fi in the iOS version, I assume iOS doesn’t allow Amazon access to the Wi-Fi settings they want. The MAC address vendor prefix is
74-75-48 for my Tide Button when triggered; it is
6C-0B-84 when in configuration mode.
I still have a fully intact Tide Dash Button. Now that I know the pinout, I might disassemble it as well and try to connect to its microcontroller via JTAG and serial.
Edit (2015-08-01): An eagle-eyed reader pointed out that
U1 is probably a TI TPS61201 boost converter; the footprint, package markings, and pinout seem to fit.
Edit (2015-08-05): As mentioned in the comments, the Button uses a different MAC address, with a different vendor prefix, when in configuration mode versus when pressed; I updated the post to reflect this. Additionally, Buttons with different branding appear to have different MAC address vendor prefixes.
Edit (2015-08-06): I just tried configuring the Button using Android instead of iOS as I had originally done and discovered that Amazon’s Android app configures the Button using Wi-Fi instead of ultrasound like the iOS version does. I updated the post to reflect this.
Edit (2015-08-10): Ted Benson wrote an interesting article on how to repurpose the Button by watching for ARP probes.
Edit (2015-08-12): Adafruit now has a guide for reprogramming the Button. There’s also an interesting project on GitHub that has a firmware dump and other firmware and reprogramming information.
Edit (2016-01-01): Jay Greco did some fascinating work reverse engineering the iOS audio configuration protocol. It turns out Amazon is using amplitude-shift keying, not frequency-shift keying; I updated the post to reflect this.
Edit (2016-03-07): Paul Bilke pointed out in the comments that my guess as to the part number of the board-to-board connector is incorrect; I struck this out in the post.
Edit (2016-06-02): Paul Bilke noted in the comments that Nathaniel Quillin figured out the part number of the board-to-board connector; I updated the post to contain the correct part number.
Edit (2016-07-12): I just finished a teardown of the new version of the Dash Button.
The mating connector is a Panasonic AXE610124. ↩
It’s only sort of ultrasound; I can still hear it. ↩
It also does at least basic checking on the TLS certificate. When I hijacked the DNS lookup and pointed it at the server hosting this blog, it never progressed past the TLS handshake. I didn’t try anything more sophisticated. ↩
Amazon now selling the Dash retail for $5 – just bought a few of them.
I’m wondering if there is a way to easily hack them to use them as a general purpose IoT button?
I found that if you configure with Amazon App, but disable 1-click in your Amazon act settings, the button will try to work but give an error.
That should be enough as it will reach out and try to touch the amazon target URL.
Since each button has a unique MAC address, that should be enough to uniquely identify a button press, even without fully emulating/receiving the encrypted data.
Two ideas: — directly detect the button press using a sniffer-like program to “see” activity from the button’s MAC address on the current Wifi network it is already configured for, OR — using a dummy DNS server or static hosts file re-map the IP address of the server the button is trying to reach (parker-gateway-na.amazon.com ??) and then run a dummy web server at the re-directed IP address to detect activity.
Both are beyond my skills (other than ideas). Wondering if you have given any thought to this or know of anyone that has hacked this or an equivalent solution.
Given that “true” IoT buttons like the the Flic or Misfit link are only bluetooth, not WiFi, and cost $20 to $30, a $5 WiFi button is very appealing.
Your two ideas are the same two I thought of; both would have to be implemented at the router. The network traffic idea could be implemented using something along the lines of Netflow. The DNS hijacking idea is probably easier though. One could point
parker-gateway-na.amazon.comat a local server and have the DHCP server assign each button a specific IP address based on the button’s MAC address. The local server could then trigger specific actions when requests are made from the buttons’ IP addresses. Of course, you’d lose the LED confirmation functionality. Since I can’t really think of anything I’d use an IoT button for, I haven’t really put much thought into implementation. The other cheap way to make an IoT button would be to use an ESP8266 module, which run less than $3, and add a button and battery; however, you’d need to add a circuit that only powers the module when the button is pressed to be able to get decent battery life.
I did exactly this. It works very well. I’m using DNSMASQ, a web server with a self signed certificate posing as an amazon.com wildcard, an incron job, and some scripts. I’ve got the thing opening my August Smart lock.
Excellent! Would you be willing to post/share your code?
What web server are you using or recommend?
This is a report from my amazon dash tide button bought when they were $0.99
I’m getting a a0:20:dc:… mac addr listed as assigned to amazon.com
I bought a GL.iNet router ( http://www.amazon.com/gp/product/B00PNJRDT4 )
to set up my island of lies for the amazon dash button. (lies being 188.8.131.52 route, and dns for parker-gateway-na.amazon.com)
I reflashed the shipped version of openwrt that came on the GL.iNet router
with a generic one from openwrt and reinstalled the GUI.
I tried some stuff before registering the button with amazon, but it didn’t
So I enabled WiFi on the router, set up SSID and password.
I then connect the WAN port to a wired internet connection.
I started the registration process, but stop when I got to step 3 of 4, where one
selects a product to bind to the button and exited out of registration.
I then disconnected the WAN connection.
I set up my laptop with a static IP response from DHCP with it’s mac addr.
root@OpenWrt:~# cat /etc/hosts
root@OpenWrt:~# cat /etc/dnsmasq.conf
root@OpenWrt:~# cat /etc/firewall.user
# This file is interpreted as shell script.
# Put your custom iptables rules here, they will
# be executed with each firewall (re-)start.
# Internal uci firewall chains are flushed and recreated on reload, so
# put custom rules into the root chains e.g. INPUT or FORWARD or into the
# special user chains, e.g. input_wan_rule or postrouting_lan_rule.
iptables -t nat -I PREROUTING –destination 184.108.40.206 -j DNAT –to 192.168.1.1
iptables -t nat -I PREROUTING –destination 220.127.116.11 -j DNAT –to 192.168.1.1
I use https://gist.github.com/jonathantneal/774e4b0b3d4d739cbc53
to setup up http server with SSL on my OS X machine (replacing all instances of localhost with parker-gateway-na.amazon.com)
now when I press the dash button, I get following in access_log
192.168.1.216 – – [09/Aug/2015:16:12:32 -0500] “POST /2/b HTTP/1.1” 404 201
192.168.1.216 – – [09/Aug/2015:16:12:34 -0500] “POST /2/d HTTP/1.0” 404 201
192.168.1.216 – – [09/Aug/2015:16:12:34 -0500] “POST /2/d HTTP/1.0” 404 201
192.168.1.216 – – [09/Aug/2015:16:12:34 -0500] “POST /2/d HTTP/1.0” 404 201
have yet to associate those endpoints with routes on the http server, but it’s a start
* before I registered the button, I got request
192.168.1.216 – – [09/Aug/2015:15:11:45 -0500] “POST /2/r/oft HTTP/1.1” 404 205
192.168.1.216 – – [09/Aug/2015:15:11:46 -0500] “POST /2/r/oft HTTP/1.1” 404 205
192.168.1.216 – – [09/Aug/2015:15:11:46 -0500] “POST /2/r/oft HTTP/1.1” 404 205
but no long term setup of button, so pressing button didn’t send any more https request
Mark: do you have a request/response dump of the Amazon Dash communicating with the Amazon servers? I’d be interested in knowing if it does a firmware update request — if so then maybe it can be tricked into applying a custom firmware.
DNSMASQ has an option to trigger a script whenever and ARP is detected. Check the ‘dhcp-script’ option. Using this, I have setup DNSMASQ to trigger a script, where I react to only ARP requests by this button.
No external web server with certs is needed. DNSMASQ and script live on the router, curl-ing to the outside world.
I blogged about my experience at http://blog.desasha.com/2015/12/13/Amazon-Dash-as-generic-IOT-button/
It’s a shame you don’t share the actual shell script and document how to configure it in dnsmasq instead of just talking about the fact you did it so others could also do the same thing.
I use Indigo home automation server with Insteon relays for controlling lights, appliances, etc. For most things, I have automatic schedules/scripts, for manual control, I can use Indigo iOS app on iPhone.
However, for some devices, it is necessary to still have a physical button or switch. Example — lights in our family room. I don’t mind using my iPhone to turn them on or off, but wife and guests want to walk up to lamp and turn a switch and not be aware there is a remote-controlled AC-relay actually making the lights go on or off.
Insteon makes battery-powered RF keypads, but they are about $50. I’m experimenting with Flic ($30) and MisFit Link ($20) buttons, but they are Bluetooth so have limited range and must still be paired with an iPhone which means they are single-user so cannot be used for the “anyone can walk up, press the button, light goes on” true IoT use.
Another use – I have a laser printer far away from my computer. I turn it on remotely from my iPhone, print, walk over to it and take my paper. Would be nice to have a button stuck to the printer that I can press when I pick-up my printout to immediately turn off the printer. Otherwise, I am too lazy to dig phone out of my pocket and end up leaving the printer on for long periods of non-usage. (If I physically pressed the regular power button to turn it off, then next time I want to print I could not turn it on remotely.)
You’re right: BLE-only buttons are essentially just smartphone peripherals. Phones are actually poor connectivity backbones for always-on applications. The Droplet button pairs a BLE button with a wifi smart hub to meet cost and power requirements while still being able to reliably get the data to the web. You might find this meets your needs better than the BLE-only offerings.
So, I may be crazy or being dumb, but it appears to me that the Dash buttons have two MAC addresses.
I lock down my router by MAC address. So before I “linked” the button to my WiFi network I pressed the button for ~6 seconds while doing a wireless survey. The SSID of “Amazon ConfigureMe” appeared with a MAC address. I then entered that MAC address to my routers whitelist.
I then went thru the process of adding the Dash button using the Amazon app on my Android phone. The Android phone recognized the Dash button, I got to the point to where I enter my WiFi password and then nothing. The app would not connect to the Dash.
I then turned off the MAC address whitelist, so any MAC address could connect, ran thru the Amazon app to add the Dash button and it connected.
I then did another pressed the Dash button while doing a wireless survey and a MAC address appeared and it was different.
I had the same results for 5 Dash buttons. Here are two example MAC address prefixes before and and after they were associated.
Before linked: 6C:0B:84
After linked: 74:C2:46
Before linked: 6C:0B:84
After linked: 74:75:48
Can anyone else confirm this?
It doesn’t sound unreasonable. While it’s in configuration mode, it’s acting as a host, but when it’s pressed it’s acting as a client. This uses different configuration code for the Wi-Fi module. The
74-75-48MAC address vendor prefix I mentioned in the post was for a Tide button; my Cottonelle button was already disassembled by the time I started looking into the firmware. My Tide button also has a
6C-0B-84MAC address vendor prefix when in configuration mode, confirming your observation. I find it somewhat interesting the Amazon used different vendor prefixes for differently branded Dash Buttons; I guess they’re planning on making more than 224 buttons. Even more interesting is the companies the vendor prefixes are registered to. The two prefixes for the buttons after they are linked are for
Amazon Technologies Inc., which makes sense. The configuration mode prefix is for
Universal Global Scientific Industrial Co.,Ltd., also known as USI, the company that makes the integrated BCM43362 / STM32F205 chip that’s used in the Particle Photon. Although Amazon used the BCM43362 and STM32F205 as discrete chips instead of using USI’s integrated solution, they appear to have used code developed by USI for the configuration mode. What we’ll probably never know is whether Amazon meant to keep the USI MAC address or just forgot to change it when adapting the USI code.
Do you (or does anyone else) have any example audio recordings of the configuration sounds? Would be interesting to hear…
The iOS app always plays the audio through the device’s speaker, so I couldn’t get a clean recording from the headphone jack. I made a few recordings with a microphone back when I wrote the post, but I never saved them since they were so bad. I just tried making a recording using the Android app but found out that it configures the Button using Wi-Fi (I just updated the post to reflect this). From this I surmise that iOS doesn’t allow Amazon access to the Wi-Fi settings they want, hence the use of ultrasound.
Since the button uses DHCP to acquire its IP address on the local WiFi lan from the router, how does it deal with DHCP ttl issues? Does it wake up periodically to refresh/reserve the same IP address or does it re-issue DHCP request each time it powers-on? (that would seem to make it slow).
In any case, I assume for hacking the button, it would be best to assign pseudo-static IP address using IP address reservation by MAC address, which most modern routers can do.
I believe it makes a new DHCP request each time it is pressed. As far as I can tell, it never turns itself on, so it can’t refresh its assigned address (this would be a waste of power anyway). It also doesn’t appear to have a real-time clock, so it can’t keep track of whether or not its lease has expired.
Thanks a lot for this writeup, Matthew, and for the double-MAC discussion, andrew. I was trying to figure out how to hack my Dash buttons to trigger arbitrary code to run, and it really helped me figure out a way to do it easily. After trying a lot of complicated tactics (like DNS spoofing) I ended up just sniffing the network for ARP requests, as it appears the Dash buttons issue an ARP Probe each time they’re pressed. If you already know the MAC, you can just listen for that probe. Here’s a writeup of the project with working code.
Amazon is making the Dash button free – you get a refund of $4.99 purchase price if you make at least one product purchase using the button.
Does the current firmware still allow for self signed certificates?
It never allowed self-signed certificates per se. When DNS is used to point the button at a server with a self-signed certificate, the HTTPS connection fails, but the server can be configured to execute an action whenever a connection is attempted, to the HTTPS connection failing is a moot point.
I have seen in the firmware that there is a POST /2/f request. I wonder what it is for…
My colleague and I set up a man-in-the-middle proxy this evening to map the Dash data interchange. It looks like the /2/f request involves a firmware update. Each time we saw it a ~600K blob followed. Examining the blob for text strings pretty much convinced us it was a firmware image. But even though we saw several of these for the same button, the firmware never actually changed. Might be a fault with our forwarding process, but the button presented green each time.
Pete Prossen: do you still have a request/response dump of all your traffic? I’d be very interested in taking a look at it!
Yes I still have this somewhere. Sorry for the delayed response, but I haven’t been back here for many months.
A while back I wrote instructions on a forum to use Dash buttons for controlling things. My approach fully utilizes the button’s capabilities, including flashing the LED green when the control command is issued. You can get a copy at the link below, which includes a link to the scripts. Then if you still need the request/response dumps let me know and I’ll try to find them.
I’ll leave this link active for a few weeks only.
There has been a recent Dash button model change; the new model is JK29LP. This model corrects the vulnerability that allows full cooperation with my script, so it is not usable with the script. But at this time (June 23, 2016) many of the old model buttons are still being shipped. I’ve purchased a dozen or so in the past few weeks.
BE AWARE if you actually place an order with one of the original models, a firmware update occurs that corrects the vulnerability. This cripples the button for further use other than its intended product purchase use.
Has anyone figured out the IO map between the STM32 balls and the other perhiperals like the WICED module?
Matthew, since you’ve already de-populated a board, would you mind buzzing them out?
Probing a 0.4 mm pitch, 66 pad grid is easier said than done. While I probably could do it, it’s likely more trouble than it’s worth.
An interesting article about a nice hackable product, but I feel it’s going to go the same way as the CueCat barcode scanner from back in the early noughties – i.e. a product that addresses a non-existent problem** which people start hacking, only to find Amazon suing people for reverse engineering their gadgets.
**who actually goes “I need one specific item in around two days time”. One would assume most people would drive to the store if it was urgently needed, or add it to their shopping list – online or otherwise, and buy it with the rest of the groceries at a later date.
Hackster is running an AWS IoT contest where you can post a hack idea using the AWS button:
I wanted to give you credit for inspiring me to get my hands on a dash button and do some reverse engineering of my own. I took a look at the mentioned iOS audio setup protocol and found some pretty interesting stuff. Take a look at it if you’ve got some time: I’d say Amazon’s got some serious engineering time into just the iOS setup portion. http://www.blog.jay-greco.com/wp/?p=116
I found your blog post quite interesting (and added a link to it).
Excellent work – thanks!
-A young hacker
Has anyone figured out the interrupt for the actual button on the dash button circuit board. I would like to execute my code only when the button is pressed and I cannot find the interrupt to intercept when it is pressed.
The 5×2 connector is not the Molex 503548-1020. The pitch is correct but locating pin is different along with the mounting pads.
This picture is of the dash button with the original connector and the Molex just to its right.
Thanks; I updated the post to reflect this. Any ideas as to the actual part number?
Could it be a HiRose connector instead of Molex? I can’t tell really well from the picture
Mouser Part #:
Manufacturer Part #:
I don’t think the footprint looks quite right.
This guy figured it out: http://key-basher.blogspot.com/2015/05/amazon-dash-button-sourcing-connector.html
It’s available from Digikey, Panasonic connector: http://www.digikey.com/product-detail/en/AXE610124/255-3198-1-ND/2793931
He built a breakout; I have a slightly different version on my project board that is in work.
This is his GitHub site, and he has a KiCad footprint in his library and a board file. I built a KiCad footprint also before he sent me this if anyone needs also: https://github.com/nqbit
Thanks. I added the connector part number to the post.
Amazon is now offering a configurable AWS IoT Button here:
It’s $19.95, in stock August 23, 2016.
You can configure it to send messages to your Amazon Web Sevices account, where you can set it up to do whatever you want (progamming required).
I hadn’t seen it posted anywhere on the internet, but Amazon now has a REV02 of the dash button (presumably what’s in the AWS version).
It uses an Amtel ATSAMG55J19 chip as well as ATWINC 1500B WiFi chip. I also see a chip marked CYBL10563-68FNXI (Bluetooth?). The battery is now removable and the board layout is fairly different, meaning all existing teardowns/guides are now obsolete.
Anyone else tear one of these down and figure out how to play with it?
I’ve already torn one down. I’ll probably finish the post about it this weekend. The last chip you mentioned is indeed Bluetooth, which is now the primary means of configuration.
Yea I’m doing a teardown on the rev 2 button myself. As Matthew stated it’s a ble chip. It’s also reprogrammable, and a ARM Cortex-M0 CPU Core. This is a busy little chip! All the pads that were on the rev 1 board are gone; there are pads sprinkled across the board, but who knows what they are.
I have a favor for the two that have one. I made a tiny nick in the circuit board getting it open. It *looks* like it’s on the built in antenna, but there is also a place for a smd inductor. I either knocked off that inductor, or it was not used and unpopulated. Can someone check this out? It’s on the bottom of the side with the battery; it’s a long thin trace, and the part I’m talking about is labeled L1008.
I would be grateful for any info you can get so I can replace it, and fix the antenna trace. As a side note, will a trace repair with a bit of wire mess up the antenna? Some of them are tuned and need to be a specific length and width.
I just finished my teardown post for the new button, which has detailed photos. The antenna is definitely tuned, and a repair will be suboptimal. However, I’m guessing it will still work, just with less range.
Well with the prime sale yesterday, I have half a dozen buttons coming at $.99 so I will have plenty more. I’ll use the one I trashed for pin hunting, etc. One thing I found is they are aware of hacking this device and made it more difficult. The rubber around the processor so you can’t see the pins (almost have them all uncovered anyway so it just slowed me down), no obvious pads (jtag, serial, i2c, etc.)
They have nothing to gain from this, so my theory is they are selling a “hackable” button for 15 bucks and they want to shill that, but who knows…
I anxiously awaiting your results.. err…that is, my pile of buttons await..
Lol, I’m waiting on my pile o’ buttons too. I’ll do what I can but first I have to get all that garbage surrounding the atmel chip cleaned off without knocking off any components, several of which are buried in that goop. Unless someone else has a better idea, I’m assuming that was put there to keep us out. Lol @ that ;)
U7 is a high side switch, Analog Devices ADP19x or equivalent.
It connects the battery voltage to the ST processor for low battery checks.
It has a tendency to short and make the battery overheat.
If so, you can just remove it and jumper across the input (1.5VBatt) to the output (low pass C-R-C filter) and it will work fine again.
I built a small IoT framework for the Dash button rev 02: https://github.com/misc0110/dash-button
To detect button presses, it can either use the network sniffing method or a custom endpoint server on either an openWRT router or a Raspberry Pi. All methods are described on the project page.
If the press of button is detected, a message can be published either using HTTP or MQTT.
Is it possible that Amazon started enabling Read Protection (RDP) level 2 on the rev 01 buttons? I can’t get the STM32 to respond at all via SWD, and attempting SWD doesn’t seem to interrupt the normal code execution. Programmer checks out with another board, and I can see protection diodes to ground on SWCLK and SWDIO, so I assume the pads are good.
FYI decapped the ICs on one: https://twitter.com/johndmcmaster/status/794572686936576000
I got some of these from a friend, The 192.168.0.1 webpage only shows stats (battery level, mac address, fw version, etc) there is no Wifi setup in there and I don’t think I can use the Amazon app because I’m in the wrong country and not a prime user… Anyone know how to get to the Wifi Config manually or have a packet dump of the setup process?
Oops I didn’t realize there were two versions of this before I posted this… I got it setup by switching my country in the shopping app anyway.
Wow! Thanks! I was just starting to pry mine apart!