Datto AP440

Pre-Intro warnings

Since this device is not officially supported, and in fact, no device with the ipq60xx is officially supported yet, you will not be able to fully utilize the package manager. Not all packages will be available since this target platform doesn’t exist.

*** Failed to download the package list from https://downloads.openwrt.org/releases/24.10.4/targets/qualcommax/ipq60xx/packages/Packages.gz

Switching to a snapshot build will resolve this error, but not all packages are available for snapshots either.

Intro

Goal: Permanently unlock the uBoot shell and install a vanilla OpenWrt on this device.

Roadblocks: The AP440 is not in the OpenWrt ToH (Table of hardware). So it isn’t officially supported.

Observations. Other models from the same company were/are running OpenWrt.

Hypothesis: This device is also running OpenWrt, but they never contributed back to the project to add official support.
Not surprising, but kinda rude imo. Building your product off of Free Open Source Software but not contributing back to the project at all. Anyway…

Getting started

My original feasibility analysis of this project was that it was beyond me. But, after reading a blog post by Brendan Horan I gained some confidence to give it a try, thinking that maybe this glitch method he used might be possible on the AP440 device as well. And it was, to some extent.

While it is possible to glitch the SPI, I am not skilled or knowledgeable enough to have figured out a reliable way to do it. The best I could come up with was tapping the SPI chips D0 pin to ground and praying I somehow got the timing right. I will also note that changing any of the uBoot env vars seems to affect the timing. So, spoiler alert, I ended up buying an inexpensive ch341a spi programmer.

This method is so much more reliable, and faster. But I WAS able to successfully glitch the SPI chip many times to get it to load a custom fwupgrade.cfg file. If you don’t have access to a ch341a or feel it may be too complicated (it’s not) and you want to rely on the glitch method, then by all means proceed: Glitching-Method

The first step in this process was to acquire the Datto flash tool and try to determine what it was doing, and how. To do this, I first plugged a device in via ethernet and ran the tool with wireshark running. This revealed 3 files: fwupgrade.cfg, rootfs, kernel. Since wireshark intercepted the traffic, it has these files, which you can then export: File > Export Objects > TFTP

With the obtained rootfs I now have a reference from which to work with. Looking at the stock dts/dtb i am able to build a custom dts file and add board support to OpenWrt, which allows me to then create an OpenWrt image for this target device. I won’t go into a lot of details here on how that was done, but suffice it to say, I had never done this before and I had no clue what I was doing. Having said that… Claude to the rescue.

Once the build is finished, you can use the initramfs to confirm everything is working properly.

Now you have a custom OpenWrt build which provides you with an initramfs image, kernel, and a rootfs.

By glitching the SPI chip at the right moment you can bypass the signature check on the fwupgrade.cfg file, which will let the device execute the cmd_success commands you set in the file.

Using a custom fwupgrade.cfg that sets the bootcmd you can tell uboot to boot via tftp to your initramfs. Note that you can also use the bootcmd to make the changes necessary to re-enable the uboot shell

From here, you can use the fw_setenv command to alter the uboot env vars, in particular the bootcmd and install our openwrt image. You could also dump the existing NAND contents from here if you felt so inclined, but we’re not going to get into that.

If you haven’t already skipped ahead, this is the part where you proceed to the Flashing Instructions