Hacking Amazon's eero 6 (part 2)

This is second part of the Hacking Amazon’s eero 6 device, which covers reading and extracting firmware data directly from a eMMC flash chip. This is after the chip had been desoldered (not by me) off the device. I also share the equipment I bought during this project, including what didn’t work and what did.

You can skip to this section on modifying a BGA159 chip reader.

The firmware on the eMMC at the time version v7.1.1-16 released on X. This most likely has changed by now but it should still represent the core layout and structure of a device’s filesystem.

The first part of the blog can be found: https://markuta.com/eero-6-hacking-part-1/

What this blog is about?

Non-destructive

Before committing to removing the eMMC flash chip from the device. I tried a few non-destructive techniques . This obviously did not work for me. But here were a few things I’ve tried:

• recovery mode boot
• interrupting boot via UART
• tracing lines around eMMC
• faulting device boot-up
• analysing device test points

I had no luck with the above, and it was at this point where I decided it was time to desolder the chip, while at the same time hoping the firmware was not encrypted.

Chip removal

• I was tempted to buy a hot air station, but a decent one costs about £200
• I decided to take the device to a mobile repair shop, where they desoldered it for £20
• so now i’ve got a eMMC BGA153 chip but no easy way to read it
• tried a few super cheap ways with the tools I had on hand (didn’t work out)
• ended up buying a cheap BGA153 adapter + some other devices

eMMC and SD interfaces

In a nutshell, microSD, SD, MMC, and eMMC all work very similarly but have slight differences. eMMC stands for Embedded MultiMedia Card, and is made up of the NAND flash storage, as well as the flash controller, which sits between the host processor. A technical overview can be found here.

You should also read this excellent article by (riverloopsecurity) about their eMMC research, which includes firmware extraction. Or this Blackhat 2017 talk by Amir Etemadieh.

A few failed attempts

I have a theory that the reason most attempts failed was because I was using the eMMC in 1-bit mode, meaning only one data pin is connected. But it could also be the adapter I was using did not support this mode (very doubtful). The other, more realistic reason, could be my soldering contact points, and/or missing resistors.

tracing lines

The were several trace lines between the eMMC chip and the main CPU. One of the things I tried was scratching pieces of PCB to reveal the copper lines. And then try solder a very fine copper wire to see I could use a logic analyser. This didn’t work as it was difficult to identify a CLK signal and/or other signals.

Note: I didn’t have a photo before the eMMC was removed.

dead bugging

• used 0.1mm copper wire with a thin layer of enamel
• used a breakout board with white tack for the chip
• sacrifice a microSD adapter

probe tool

The idea behind the tool is pretty good, the problem I found was that the application is best suited for microSD card recovery and bigger PCBs. Instead of fine BGA pads. The test probes (although they were almost like needles) would slip off the pad and are quite awkward to work with.

eMMC to microSD adapter

I also tried using a cheap microSD to SD adapter, which was then plugged into a microSD reader. I used three SD card readers, a transcend SD USB adapter, a UGreen multi-tool USB-C adapter, and an old laptop with a SD card slot, all of which failed.

low-powered eMMC to SD adapter

I really thought this device would work. But it didn’t. I thought it’s likely to do with my soldering, although I did triple check the contacts points before trying to read the chip. Apparently, others have also had issues e.g. link

Shopping on Aliexpress

I began to lose patience, since I wasn’t getting anywhere with a “hacky” solutions. So I decided to go on Aliexpress and buy a BGA153 adapter to read the eMMC chip, without needing to manually solder wires to tiny BGA pads.

Aliexpress basically has anything you want when it comes to electronics. From NAND flash chips to Wi-Fi routers, JTAG/SPI programmers, and even LTE base stations, and a much more. Orders to the UK normally take around 2-weeks to arrive.

I searched for keywords like eMMC reader, eMMC to SD adapter, BGA153 adapter and others to see what’s available. Here were some of the results:

And yes somebody actually paid for the “reasonably” priced £1,007.18 one. Most of the devices were very expensive and I wasn’t prepared to spend that much on a single project. The blog post mentioned earlier used a AllSocket adapter which came with a SD interface, however, costs upwards of £90.

I purchased the cheapest (£35) eMMC BGA153 adapter that I could find. This also meant I had to purchase another device that converts signals into either a USB or a SD interface, because all the cheap adapters didn’t have a proper interface other than pins.

MKS eMMC adapter

I could try to solder these pins to a regular microSD adapter, which I have already tried. However, I did not want to go down that route again so I decided to buy a device to talk to the eMMC chip, which then talk to my system.

The MKS eMMC adapter device is typically used in 3D-printers for upgrading firmware. It supports both a microSD slot and 20-pin eMMC extension module header with a USB 3.0 interface.

You can find them almost on anywhere eBay, Amazon, Aliexpress, etc.

Putting it together

Identifying pinout

Annoyingly, I couldn’t find a pinout table for the BGA153 adapter showing what each pin is connected to. I guess it’s because the adapter is mostly used with devices such as RT809H or TL866, where you just plug it in, and let the software handle the rest.

To start, I had to get a datasheet document for the Kingston BGA153 eMMC chip, and then I compared it with the layout on the adapter. Nothing too difficult here, although I did need to order some very fine multimeter probes.

The middle square pins are for the Flash I/O and memory power supply. And the outer square pins are for the Memory controller core and MMC I/O, as well as power supply. The Flash I/O memory uses Vcc and Vss, while the Memory controller uses Vccq and Vssq.

I needed to unscrew the top plastic piece so I can easily reach the pads on the PCB with my multimeter probes. I then set it to continuity mode and touched each pin until I heard a beep, while comparing with the above chip pinout.

Here is the pin out for those those that are interested:

As you can see in the left part of the image, the pins match up exactly to the one from the eMMC flash reference document. I was confident that this should work, but there’s always room for error.

Note: Trying to read the eMMC using 1-bit mode (DAT0 only) did NOT work for me.

To communicate with the chip, the following pins must be connected - the command and clock pins CMD and CLK, data pins - DAT0, DAT1, DAT2, DAT3, power pins - Vcc, Vccq, and ground - Vss and Vssq. This allowed me to read and write to the eMMC in 4-bit transfer mode.

Soldering jumper wires

As mentioned above I found a cheap MKS EMMC Adapter device for about £5 on eBay. It supports both a microSD slot and 20-pin eMMC extension module, and also uses a USB 3.0 interface. All I needed to do is solder the wires to a eMMC module pins.

The 20-pin layout for the eMMC module was found here:

Here’s the ugly but finished product. Note: The pin numbers are numbered but they are not visible from the following photo. It would’ve been nice if there was a breakout slot.

Now all I needed to do is solder the wires to the BGA153 adapter.

Reading the chip

Here’s a photo of everything connected and what it actually looked like.

The BGA153 adapter (with the eMMC chip inside) is connected to MKS EMMC Adapter using jumper wires. It is then connected to my main system running Windows with VMware software, where I have a dedicated Linux virtual machine for doing embedded device stuff. Once plugged-in I just needed to pass-through the USB device to the VM.

I used dmesg with -W to monitor changes. It was at this point where I got super excited.

naz@looper:~$ sudo dmesg -W
[sudo] password for naz: 
[ 1880.570293] usb 3-2: new high-speed USB device number 5 using xhci_hcd
[ 1880.948845] usb 3-2: New USB device found, idVendor=05e3, idProduct=0747, bcdDevice= 8.19
[ 1880.948853] usb 3-2: New USB device strings: Mfr=3, Product=4, SerialNumber=5
[ 1880.948856] usb 3-2: Product: USB Storage
[ 1880.948858] usb 3-2: Manufacturer: Generic
[ 1880.948861] usb 3-2: SerialNumber: 000000000819
[ 1880.977681] usb-storage 3-2:1.0: USB Mass Storage device detected
[ 1880.981082] scsi host33: usb-storage 3-2:1.0
[ 1880.981818] usbcore: registered new interface driver usb-storage
[ 1880.986104] usbcore: registered new interface driver uas
[ 1882.006464] scsi 33:0:0:0: Direct-Access     Generic  STORAGE DEVICE   0819 PQ: 0 ANSI: 6
[ 1882.007017] sd 33:0:0:0: Attached scsi generic sg2 type 0
[ 1882.258668] sd 33:0:0:0: [sdb] 7471104 512-byte logical blocks: (3.83 GB/3.56 GiB)
[ 1882.261570] sd 33:0:0:0: [sdb] Write Protect is off
[ 1882.261575] sd 33:0:0:0: [sdb] Mode Sense: 87 00 00 00
[ 1882.264699] sd 33:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 1882.284287] sd 33:0:0:0: [sdb] Attached SCSI removable disk

A new disk called sdb showed up with a capacity of 4GB. I knew this was a good sign, as the Kingston eMMC chip specification matched up. But also that it didn’t automatically disconnect like my previous attempts. I quickly moved onto dumping the actual firmware.

Dumping firmware

As soon as the sdb disk was visible I wasted no time in creating a raw dump copy of the firmware. A common utility like dd should do the trick. To dump the contents of a disk to a file you can use the following command:

sudo dd if=/dev/sdb of=emmc_eer6.bin status=progress bs=16M

A screenshot of the actual command being run, which shows a transfer speed of 27MB/s.

I also used 7z l emmc_eero6.bin to see if I can identity logicial partitions names.

Extacting filesystem

In total there were 23 logical partitions. To extract the .img files I used the command 7z x emmc_eero6.bin in the current working directory. I then mounted them all, using this simple bash to loop through each img and mount then using mount as root:

for i in *.img; do
NAME=$(basename "$i" .img)
mkdir "$NAME"
mount "$i" "$NAME"
done

Output will show multiple disks when using a graphical interface like Ubuntu.

Analysing filesystem

I won’t go into any great detail in the blog post but I will share some general information about each partition that I found interesting. Also keep in mind, the firmware version I had installed was v7.1.1-16 before the eMMC was desoldered.

• rootfs a compiled python package called nodelib which is used for device management and system operations. This was found in /usr/lib/python3.10/site-packages/nodelib/ folder. Along with other custom binaries.

• rootfs_1 a second root file system which contained the same nodelib package, but this time with a different python version and it wasn’t compiled, and was fully readable. This was found in the /usr/lib/python3.8/site-packages/nodelib/ folder.

• log debugging and other messages, including a firmware download URL that had failed. Firmware archives require a authentication header e.g. https://cloudfront.eeroupdate.com/builds/v7.1.1-16%2B2023-12-13.prod.andytowngateway.tar.gz shows an error.

• cache a few private and public certificate files, which are presumably used to communicate with the backend cloud services, as well as the mobile app.

• bootconfig Qualcomm firmware and other stuff.

Systemd services

A few services which are started during device boot up.

/lib/udev/rules.d/10-qca.rules
/lib/systemd/libsystemd-shared-250.so
/lib/systemd/system/core-comms.service
/lib/systemd/system/homekit_adk.service
/lib/systemd/system/homekit-dnsmasq.service
/lib/systemd/system/captive-portal-main-dnsmasq.service
/lib/systemd/system/sd-unit-analytics.service
/lib/systemd/system/cache-mount.service
/lib/systemd/system/pppd.service
/lib/systemd/system/asset-manager.service
/lib/systemd/system/radvd.service.d/10-eero.conf
/lib/systemd/system/ace-messaging.service
/lib/systemd/system/smarthomed.service
/lib/systemd/system/ebid.service
/lib/systemd/system/lldp-poe-mgr.service
/lib/systemd/system/ace-zigbee.service
/lib/systemd/system/[email protected]
/lib/systemd/system/aicfd.service
/lib/systemd/system/[email protected]
/lib/systemd/system/btmanagerd.service
/lib/systemd/system/smart-cloud-app.service
/lib/systemd/system/captive-portal-a-dnsmasq.service
/lib/systemd/system/dnsmanager.service
/lib/systemd/system/ace-eventmgr.service
/lib/systemd/system/thermald.service
/lib/systemd/system/thermalmonitor.service
/lib/systemd/system/bookshelf.service
/lib/systemd/system/cnss_diag.service
/lib/systemd/system/ffs-provisioner.service
/lib/systemd/system/ec-dnsmasq.service
/lib/systemd/system/captive-portal-guest-dnsmasq.service
/lib/systemd/system/client-reporter.service
/lib/systemd/system/captive-portal-b-dnsmasq.service
/lib/systemd/system/noded.service
/lib/systemd/system/[email protected]
/lib/systemd/system/cache-status.service
/lib/systemd/system/pushbutton-monitor.service
/lib/systemd/system-shutdown/check_cache_discard

/usr/lib

A few libraries that are used with other binaries.

/usr/lib/libAicfIPCPrimitiveUtils.so
/usr/lib/acs-lib/libace_ffs_provisioner.so
/usr/lib/acs-lib/libace_connectivity_manager.so
/usr/lib/acs-lib/libace_map.so
/usr/lib/acs-lib/libCHIP.so
/usr/lib/acs-lib/libwebsockets.so
/usr/lib/acs-lib/libacehal_kv_storage.so
/usr/lib/acs-lib/libace_minerva_metrics_api.so
/usr/lib/acs-lib/libacehal_device_info.so
/usr/lib/acs-lib/libace_tlscfg.so
/usr/lib/acs-lib/libace_messaging.so
/usr/lib/acs-lib/libwhisperjoin_dss_clientc_sdk.so
/usr/lib/acs-lib/libffs_dssclient_sdk.so
/usr/lib/libAicfAuthZC.so
/usr/lib/libAicfUtils.so
/usr/lib/libSmartHomeZigbeeAdapter.so
/usr/lib/libSDKComponent.so
/usr/lib/libSmartHomeUtils.so
/usr/lib/libeero_system.so
/usr/lib/libacsdkAssetsMocks.so
/usr/lib/libicudata.so.70.1
/usr/lib/libNpbSerializer.so
/usr/lib/libacsdkAuthorization.so
/usr/lib/libAicfNativeAlexaComm.so
/usr/lib/libacsdkDavsClient.so
/usr/lib/libDAVSUtils.so
/usr/lib/libacsdkAicfCA.so
/usr/lib/sqm/eeroos.qos
/usr/lib/libCapabilityLibrary.so
/usr/lib/libAicfV3Helper.so
/usr/lib/libAmazonAccountUtils.so
/usr/lib/libPuffinUtils.so
/usr/lib/libSmartHomeCHRSSYNC.so
/usr/lib/libassetmgrd_client.so
/usr/lib/libPuffinCommon.so

/usr/bin

A few binaries that are not part of the default operating system.

/usr/bin/ace_messaging_service
/usr/bin/AicfD
/usr/bin/smarthome_utility_puffin
/usr/bin/SmartCloudApp
/usr/bin/assetmgrd
/usr/bin/ebid
/usr/bin/noded
/usr/bin/SmartHomed
/usr/bin/qorvo-ble-setup-service

Conclusion

I know readers might say, oh you cheated by going to a phone repair shop to desolder the eMMC chip. While that maybe true, it still didn’t stop me from running into issues with actually reading data off the chip.

In this blog post I share some of the issues and solutions I ran into while trying to extract data from a eMMC chip. It’s a shame I couldn’t find an easy way to root the device. And the destructive technique of desoldering chips means that I’m left with a completely dead device, well, unless I re-solder the chip back on. But there might be a way in the future.

Why no firmware?

While this has been fun and an interesting project, I will not be releasing any firmware files. I’m a hobbyist and do not wish to be sued by Amazon or Qualcomm for releasing proprietary content.

What’s next?

The next step is to analyse the firmware in more detail to find any security vulnerabilities, either in their applications or device itself worth reporting and possibly get a bug bounty, as they do have a program on HackerOne.

Resources

A list of great resources that I found really useful.

• Hardware Hacking 101: Identifying and Dumping eMMC flash
• Hacking Hardware With a $10 SD Card Reader
• How to Dead-Bug a BGA Flash Memory chip
• A detailed description of eMMC technology
• Flash readers by Voidstarsec