Switching A/B slots in update.zip

[pascallj]

Recently I have been playing with an idea in my head, but I can't seem to figure out if it's theoretically possible or not.

The advantage of having A/B partitioning for the system is that it should be possible to easily test one system and switch back to the old one if it doesn't work. This normally happens automatically. But what if I want to test a system which successfully boots in the other slot and then just want to switch back to the old one. Of course you can sideload the full OTA and it will switch the slot back, but for repeated testing this will take some time and unnecessary wear of the flash.

When the other system has some form of root access, switching slots is possible when booted inside that system. But what if the other system doesn't have root access? When the bootloader is unlocked you can switch the slots in fastboot, but when the bootloader is locked, this is not possible. As far as I'm aware the only way to interact in such a 'low-level' way with the system when the bootloader is locked, is when sideloading a correctly signed update zip.

Do you think it is possible to fabricate some sort of correctly signed update.zip which allows you to switch slots, or perform some kind of shell scripting? Much like how the old updater-script/updater-binary used to work when A/B partitioning wasn't used. Or does this kind of scripting still works on newer devices and we just have to find a way to sign the updates?

[chenxiaolong]

When the other system has some form of root access, switching slots is possible when booted inside that system.

This used to be true, but unfortunately no longer is due to virtual A/B. Now, only partitions that are read by the bootloader, like boot and vendor_boot, have distinct _a and _b partitions. The remaining big dm-verity partitions don't.

When flashing an OTA, it takes a snapshot of the current system by setting up some sort of copy-on-write block device for each partition. Any newly written data then gets buffered to files within /data. As soon as the new slot boots successfully, the changes are merged and the old "slot" basically ceases to exist.

The only way to boot back into the old slot is to somehow simulate a boot failure to avoid triggering the "this booted successfully" process. This would prevent Android from merging the changes and telling the bootloader that the new slot is good (so that the downgrade protection won't be tripped when switching back).

[chenxiaolong]

To answer your questions directly:

Do you think it is possible to fabricate some sort of correctly signed update.zip which allows you to switch slots

On devices that don't use virtual A/B, I believe this is possible by just creating valid-but-empty payload.bin. It would just install nothing and then switch slots like normal.

or perform some kind of shell scripting?

This is kind of possible. The script needs to live inside one of the partitions in the OTA. Each partition inside payload.bin has an optional field that allows an executable to be run:

avbroot/avbroot/protobuf/update_metadata.proto

Lines 247 to 256 in 275b18b

	// Whether this partition carries a filesystem with post-install program that
	// must be run to finalize the update process. See also |postinstall_path| and
	// |filesystem_type|.
	optional bool run_postinstall = 2;
	// The path of the executable program to run during the post-install step,
	// relative to the root of this filesystem. If not set, the default "postinst"
	// will be used. This setting is only used when |run_postinstall| is set and
	// true.
	optional string postinstall_path = 3;

The system partition, for example, specifies /system/bin/otapreopt_script, which precompiles the byte code for every apk to speed up apps' first launch after an update. (But it has a check to only do this when installed from an OTA updater app, not with adb sideload)

[pascallj]

When the other system has some form of root access, switching slots is possible when booted inside that system.

This used to be true, but unfortunately no longer is due to virtual A/B. Now, only partitions that are read by the bootloader, like boot and vendor_boot, have distinct _a and _b partitions. The remaining big dm-verity partitions don't.

Unless I am remembering this wrong, I have used this before on my Pixel 6a succesfully to switch between an avbroot signed rom with Magisk, and one without (I believe by using a fake prepatched, it was before 'rootless' existed). Of course I wasn't able to switch back, but everything else worked fine. But the Pixel 6a does use Virtual A/B, doesn't it?

EDIT: Or does this actually work as expected as the boot.img is the only difference in this case?

[chenxiaolong]

EDIT: Or does this actually work as expected as the boot.img is the only difference in this case?

Yep, I think that's very likely why.

I did a quick hack to print out the payload.bin header

diff --git a/avbroot/src/format/payload.rs b/avbroot/src/format/payload.rs
index c2d3623..ffa1ee4 100644
--- a/avbroot/src/format/payload.rs
+++ b/avbroot/src/format/payload.rs
@@ -164,6 +164,8 @@ impl<R: Read> FromReader<R> for PayloadHeader {
         // Skip manifest signatures.
         reader.read_discard_exact(metadata_signature_size.into())?;
 
+        println!("Manifest: {manifest:#?}");
+
         Ok(Self {
             version,
             manifest,

and it looks like the Pixel 6a does indeed use virtual A/B:

❯ avbroot ota extract -i bluejay-ota-uq1a.231205.015-2503078c.zip -d stock | grep -A1 vabc
            vabc_enabled: Some(
                true,
--
            vabc_compression_param: Some(
                "gz",
--
            vabc_feature_set: None,
        },
[*] Extracting from the payload: boot, system, vbmeta, vbmeta_system, vbmeta_vendor, vendor_boot

[pascallj]

But in that case, the whole idea of using A/B as a quick test doesn't really work when virtual partitions are used, unless we want to get involved in creating our own snapshots and stuff like that. That's way too adventurous for my daily driver phone. So I will scrap this idea.

Thank you very much, very useful information 🙏