feature request - grab OTA file from local storage (via file manager)

[nad0vs]

Basically what it says on the tin can. Instead of having a proper server for the OTAs, allow custota to be pointed to a local (file on "alleged SD card") or semi-local (LAN FTP accessed via mixplorer) location from which OTA file should be loaded into the custota system, checked, and if everything is fine with them signatures, flashed.

Security implications:
none as far as I can see, since the OTA still has to have correct signatures and follow the general "OTA update logic"

Usecase:
simpler update lifecycle with less hassle with servers-shmervers

Alternatives:
Sideloading OTAs which requires annoying process of entering stock recovery, and at least on two separate occasions have failed inexplicably for me with moderately unpleasant hard-to-resolve consequences (I blame the USB-C cable because if in doubt blame a cable) and is a bit too non-transparent

Custota-with-local-source ability strikes me as a more manageable more transparent and maybe even safer alternative to sideload process with a legitimate usecase :-)

[chenxiaolong]

Thanks for the suggestion. I agree that this would be a useful feature.

I'll have to think a bit about how this would be implemented. I don't want the local install option to have any less security. Currently, we verify two signatures:

• The payload.bin signature. This is verified by Android's update_engine unconditionally, so we don't have to worry about it.

• The whole-file signature. This is verified by Custota/custota-tool and ensures that META-INF/com/android/metadata (and .pb) contain trusted device/version information. This prevents downgrades or accidental flashing of (correctly-signed) firmware for a different device, which would make the device unbootable.

  To avoid needing the entire OTA to be downloaded first, Custota requires the user to use custota-tool to pre-verify the OTA file and save some metadata to a signed .csig file. This allows the Custota app to install the update as it's being downloaded without compromising on security.

For a local file install, I think we have two options:

1. Require the user to create the .csig file, just like with a network install. To start the update, the user would need to select both the .csig file and the .zip file.
   • This option is much easier to implement and allow most of Custota's code to be used as-is.
2. Don't require the .csig file when installing locally. Since the entire zip file is already available, there's no need to pre-verify with custota-tool. However, Custota would need to learn how to verify the whole-file signature itself. To start an update, the user would only need to select the .zip file.
   • For various reasons, it will be necessary for Custota to make an internal copy of the OTA, leading to more disk usage.
   • This is harder to implement and will require reworking a decent amount of Custota's logic. I'm not really a fan of this. I like to keep security critical code as simple as possible and would prefer not to have different code paths for network vs. local installs.

It's a bit more user unfriendly due to the user needing to select 2 files, but I'm leaning towards option 1. I'll think about it more over the next couple days.

---

semi-local (LAN FTP accessed via mixplorer)

For network-based things, we're limited by what Android's update_engine supports, which is just HTTP/HTTPS. If your file manager supports exposing a folder over HTTP, Custota should already work as-is by pointing it to http://localhost:<port>/<path>.

[chenxiaolong]

I thought about it a bit more. I'd like to make it even more simple. For a network install, the user types in a URL (like it is now). For a local install, the user selects a directory. Everything else would be identical. Same folder structure, same behavior, same functionality (eg. auto-updates), same everything.

[chenxiaolong]

I have a test build up at #27. I've been testing it quite a bit the past few hours and haven't encountered any issues (with either a local directory or an OTA server). Feel free to give it a try if you'd like.