The first step in our process of hacking the Echo Dot is getting a dump of the EMMC, so that we can see if we can exploit the boot chain.

We have specifically chosen the Amazon Echo Dot V2 in order to aid this process. First of all, this is the last version of the Echo Dot that has a real usb port integrated in the base device. Later versions of the Echo Dot use the micro-usb port for power only, and have a proprietary footprint for the debug USB connector.

The second reason we have chosen the older Echo Dot, is that it uses a generic tablet SoC chip, instead of a dedicated smart speaker chip. This means that there is a large community of people that are interested in rooting their cheap android tablets, and we can use this documentation to reduce the effort of our own linux port.

In this case, we will take advantage of a specific Mediatek SoC exploit known as amonet. This exploit originally targeted the Kindle Fire HD 8 tablet, which of course is also manufactured by Amazon, and also conveniently uses the same Mediatek SoC, the MT8163 soc.

This exploit takes advantage of unchecked function pointer usage in the BROM of the SoC, which allows for installing a small shell code which lives on the stack and reading / writing the eMMC memory in the tablet. In order to take advantage of this, we first need to force the Echo Dot into BROM boot mode.

It is a little tricky to do this on the Echo Dot. Older Android tablets had modes where certain keypress combinations could force the SoC to stay in the BROM bootloader. However, Amazon disables these functionalities so that their little kernel fork is loaded as quickly as possible, to prevent reliance on the BROM code.

Forcing an Echo Dot into BROM mode

The trick to forcing the Echo Dot into BROM mode is to prevent the SoC from loading the next boot stage, the preloader from eMMC. And the easiest way to do this is to use a small piece of wire to temporarily short the eMMC data bus to ground while the SoC is booting up.

As a first step, the Echo Dot needs to be disassembled until the main PCB is accessible. iFixit has a nice tutorial on opening up the Echo Dot and accessing the mainboard. The only special tool that should be needed is a Torx T8 screwdriver. Please note that once the PCB board is exposed, the EMI cover needs to be removed from the SoC and eMMC chips. This can be easily done using fingernails at the corners of the can, it is not soldered down.

Once the Echo Dot is opened, it can be kind of hard to find the right place to short the eMMC. Unfortunately, as far as I can tell, there are not any nice big testpoints that provide access to the eMMC interface. Fortunately, Amazon seems to have included a couple of passives on the data interface, and these provide a good enough location to short out the bus. You should be ok, taking a small piece of wire or paperclip and touching it to the passives indicated by the red arrow (near R60).

Before connecting the Echo Dot to your PC, it is important to start the amonet script bootrom-step.sh. This script will run a python script that loads the bootrom exploit, and loads a small shellcode that enables commands for reading and writing the eMMC chip. The script works by detecting when a new serial port shows up connected to the computer, so it needs to be started before plugging in the Echo Dot.

You can tell that the SoC has powered up in BROM mode, because the USB VID/PID combo will change for the Echo Dot. Normally, during bootup, the Echo shows up as VID:PID 0e8d:2000. However, when the SoC is forced into BROM mode, it will choose a different USB PID of 0003.

If you run the original amonet exploit, you should see some output that looks like this:

Waiting for bootrom
Found port = /dev/ttyACM0
Handshake
Disable watchdog
handshake success!
Init crypto engine
Disable caches
Disable bootrom range checks
Load payload from ../brom-payload/build/payload.bin = 0x46A8 bytes
Send payload
Let's rock
Wait for the payload to come online...
all good
Check GPT
gpt_parsed = {'kb': (2048, 2048), 'dkb': (4096, 2048), 'lk_a': (32768, 2048), 'tee1': (49152, 10240), 'lk_b': (65536, 2048), 'tee2': (81920, 10240), 'expdb': (98304, 20480), 'misc': (118784, 1025), 'persist': (131072, 32768), 'boot_a': (163840, 32768), 'boot_b': (196608, 32768), 'recovery': (229376, 32768), 'system_a': (294912, 1572864), 'system_b': (1867776, 1572864), 'cache': (3440640, 1605632), 'userdata': (5046272, 2588639)}
Error: RuntimeError("bad_gpt")

If we have gotten this far, it actually means we have had some success! The BROM exploit has successfully worked on our Echo Dot, and we are able to read the partition table from the eMMC. However, the partitions in the eMMC memory do not match the partions list that the original amonet exploit expects. This is because Amazon implemented a different partition map than is found in the later Kindle Fire HD, and the amonet script isn’t expecting these partition names. Here is a list of the partitions that are found, and some comments on what we can figure out about their purpose:

Partition	Size	Description
kb	1 MB	keyblock partition? seems related to DRM
dkb	1 MB	also related to keyblock
lk_a	1 MB	little kernel ‘a’, presumably first priority to boot
tee1	5 MB	trusted execution environment program image, presumably part of image a
lk_b	1 MB	little kernel ‘b’, presuably back up image to boot
tee2	5 MB	trusted execution environment program image, presumably backup
expdb	10 MB	no idea, but file seems to be all zeros
misc	512 KB	also no idea, file is almost empy
persist	16 MB	another empty partition
boot_a	16 MB	android kernel and initrd, first priority to boot
boot_b	16 MB	backup android kernel and initrd
recovery	16 MB	recovery kernel? booted if others file
system_a	768 MB	system partition for image
system_b	768 MB	backup system image
cache	784 MB	presumably locally cached files for Echo Dot
userdata	1.2 GB	presumably local data for user

It should now be possible to use the amonet bootrom exploit to dump the eMMC through the USB tty. This will take a while, given the size of the partitions, but it should be useful to get an idea about what is going on with the software. For my purposes, I am less interested in exploring the Echo Dot software created by Amazon, and more interested in being able to boot my own image, so we will next focus on exploring the Little Kernel.