The Echo Dot V2 is an interesting smart speaker, because while it uses a very common tablet SoC, there has been very little work published about trying to root the device.

In the echo dot configuration, we have 512 Megabytes of RAM, and 4 Gigabytes of EMMC, so there is plenty of space to do interesting things. The prices have also gotten quite cheap, since the devices are getting long in the tooth, and it is easy to find sellers willing to part with them for almost nothing.

It is also the last generation of Echo Dot to include a built-in USB port, which hopefully could be useful for rooting the device.

Review of existing exploits

Like I mentioned before, one of the appealing features of Echo Dot V2, is that it uses the a common tablet SoC. This means that there has been a lot of work done already on rooting those tablets, which we can take advantage of for our investigations.

Especially interesting, is the Kindle Fire HD 8 tablet, which, since it is made by the same manufacturer as the Echo Dot, hopefully shares much of the same underlying softare architecture.

Review of MT8163 Boot Process

MediaTek SoCs in the mid 20 teen’s go through a multi step boot process:

1. BROM: maskrom bootloader in SOC that is first startup. It checks for a usb/serial connection at poweron and can interface with proprietary MediaTek commands to access memory of device. Still has some protection. If flash tool detection times out, it moves on to Preloader, which it verifies using a write-once key stored in ROM.

2. Preloader. Larger boot image, customized by device manufacturer. Responsible for board bringup, and loading firmware into baseband. Presumably also responsible for loading trustzone firmware. Also, Preloader performs Anti-rollback checks to make sure that only correctly signed Little Kernel and Trustzone software can be executed. After preloader finishes it jumps to Little Kernel.

3. Little Kernel. Responsible for ‘full featured’ boot. Can run fastboot server. Fastboot server is implemented in ‘app’ of little kernel called mt_boot. Mt boot and little kernel are proprietary to MediaTek, but a lot of people seem to have posted dumps of MediaTek SDKs to github for various SoCs, so lots of information available. Unfortunately, none for our SoC, MT8163, but presumably the architecture is similar. Depending on the reboot type flag, Little Kernel will choose different images to boot, but eventually it will load and decompress the Android Kernel. And, of course, this loaded kernel is also required to be correctly signed.

4. Android Kernel. After Little Kernel, it seems like the normal Android kernel bootup process starts. This will be covered in more detail in future posts.

Challenges for exploiting

Looking at these steps, it is important to understand how the security is protected for each of thess stages of the boot process. And the answer, to simplify slightly, is that each boot step is responsible for verifying the signature of the subsequent step. If we have write access to the EMMC, this doesnt help us for patching a software component, since that code will not be allowed to be executed unless it is signed by Amazon.

This means that practically speaking, we are limited to specific pre-built binaries for the Preloader, Little Kernel, and Android Kernel. (there is also a TrustZone image, but I am not sure how that fits into the picture at this time).

Not only are we limited to specific images, but even if we find a vulnerability in an older version of one of these softare modules, the Preloader implements ‘Anti-Rollback Prevention’, which means that it remembers the highest version number of software it has seen for each component, and refuses to execute older code, even if the signature is correct.

And recall that by default, we dont have any kind of read or write access to the EMMC, we will need to get this first if we have any hope of moving forward.

Here we are in luck, becauase in the last couple of years there have been several exploits published for these tablets that we can hope to use.

Specifically the exploit we will try to use for Echo Dot V2 is known as amonet. This exploit takes advantage of vulnerabilities in the BROM in order to allow for read-write access to EMMC, and then takes advantage of some bugs in the littlekernel to patch the kernel software version checks.

Here is an overview of how Amonet works:

1. BROM RCE, allowing read/write access to EMMC, and access to device-specific crypto keys

2. Downgrade of bootloader software components, including bypass of Anti-Rollback software

3. Little Kernel RCE, allowing bypass of signature checking of Android Kernel

Fortunately for us, most of the Amonet exploit will work on the Echo Dot V2, without much modification. The SoC is the same, so the BROM exploit should also work on the Echo Dot, as is the RPMB bypass.

The only question remaining is the Little Kernel exploit. Presumably the littlekernel on the Echo Dot is different than the one on Kindle Fire HD, so the specific offsets and locations in the amonet RCE will need to be modified to match the Echo version. Also, there is a question if the Little Kernel in my Echo Dot will be exploitable with the known RCE. Amazon is known to update these devices, and as a smart speaker is useless without an internet connection, I would expect my speaker is pretty up to date. The hope is that this version of little kernel is still exploitable.

As a first step though, we need to confirm that the BROM RCE works on the Echo Dot hardware. This will allow us to dump the Echo Dot Little Kernel, and see where we are.