2

I am using Android 8 for an embedded device, with Android Verified Boot 2.0 secured via HW-keys, and A/B OTA update (no streaming). I want to make sure that the software on the device is tightly secured; however, I'm having a hard time to trace the individual steps the update performs. One hint would be the metadata contained in the update payload.bin.

Unfortunately, there seems to be no documentation on the payload.bin file format and its contents. Is there an official documentation for the file format? Or is there a crisp piece of code (e.g., build tools( that I haven't found out about yet? The tools for "dumping" payload.bin give me the contained images, but not the metadata. What I'd like to understand is the following:

  • Which parts of payload.bin are signed with which key?
  • Are there parts that are not signed?
  • Which additional verification elements are contained in payload.bin, and how does the update_engine use them? For example: there are hashes to verify the target partitions following the installation
  • For a differential update, there must be a means to ensure that the system on the device is exactly the one used as source for the update diff. Where are those hash-values?
  • How about a full update - can the updater ensure that the update is installed only atop a specific version on the device?

I apologise if I have missed sources that answer these questions. The books about Android system programming I came across are outdated by now. Any pointers to relevant documentation beyond the basic Android docs would be highly appreciated.

Improve this question
2
  • 1
    What I understand is that Google moved A/B updates infrastructure from their closed-source Chrome OS to AOSP. But they want OEMs use Google's A/B update client (integrated in Play Service) and hence Google's update servers along with cloud hosting. After all it's about business. There is no clear documentation available but for tech-savvy souls the complete code is available in update_engine, enough to understand and implement from scratch. This is more a development related question.
    – Irfan Latif
    Commented Nov 8, 2019 at 23:28
  • "OEMs not using Google's OTA infrastructure will be able to reuse the AOSP system code but will need to supply their own client." source.android.com/devices/tech/ota/ab#overview
    – LVitya
    Commented Nov 9, 2021 at 16:03

1 Answer 1

Reset to default
0

build tool for A/B payload.bin is a call chain:

ota_from_target_files.py -> GenerateAbOtaPackage() -> payload.Generate() -> brillo_update_payload.sh -> generate_delta_main.cc

payload file format - system/update_engine/update_engine/update_metadata.proto

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .